Enable BCM2835 mailbox support
Subsystems (5)
RFC PATCH 3/3 Enable BCM2835 mailbox support
Implement BCM2835 CPU thermal sensor support.
---
Beyond the usual reviews of rubbish code, there are two points here that I'm looking for feedback on.
First is the placement of the mailbox directory make target in drivers/Makefile. I placed it as early as I did in anticipation of implemented a frame buffer driver, which needs mailbox support at probe time. Another option would be to initialise the driver at architecture initialisation time, but I'm unfamiliar with good practice about when to initialise different bits and pieces. Especially with generic mailbox support looking kinda new.
Second is the propmsg_ fuctions and related structures. They don't belong here. And the fact that they are is something that would count against this being an acceptable patch. But I don't know where to put them. It's the header file I have trouble with. I don't really know where I can put it. Multi-architecture support rules out arch/arm/mach-bcm2835, and I don't want to place a header file that only supports one very specific system into include.
---
arch/arm/boot/dts/bcm2835.dtsi +4 -0
@@ -37,6 +37,10 @@ brcm,channel-nums = <0 1 3 8>; }; + thermal { + compatible = "brcm,bcm2835-thermal"; + }; + watchdog { compatible = "brcm,bcm2835-pm-wdt"; reg = <0x7e100000 0x28>;
arch/arm/configs/bcm2835_defconfig +2 -0
@@ -67,6 +67,8 @@ CONFIG_SPI=y CONFIG_SPI_BCM2835=y CONFIG_GPIO_SYSFS=y # CONFIG_HWMON is not set +CONFIG_THERMAL=y +CONFIG_BCM2835_THERMAL=y CONFIG_FB=y CONFIG_FB_SIMPLE=y CONFIG_FRAMEBUFFER_CONSOLE=y
drivers/Makefile +3 -1
@@ -15,6 +15,9 @@ obj-y += pwm/ obj-$(CONFIG_PCI) += pci/ obj-$(CONFIG_PARISC) += parisc/ obj-$(CONFIG_RAPIDIO) += rapidio/ + +# Mailbox must come before drivers that rely on it +obj-$(CONFIG_MAILBOX) += mailbox/ obj-y += video/ obj-y += idle/
@@ -133,7 +136,6 @@ obj-y += platform/ #common clk code obj-y += clk/ -obj-$(CONFIG_MAILBOX) += mailbox/ obj-$(CONFIG_HWSPINLOCK) += hwspinlock/ obj-$(CONFIG_NFC) += nfc/ obj-$(CONFIG_IOMMU_SUPPORT) += iommu/
drivers/thermal/Kconfig +9 -0
@@ -130,6 +130,15 @@ config DOVE_THERMAL Support for the Dove thermal sensor driver in the Linux thermal framework. +config BCM2835_THERMAL + tristate "Temperature sensor on Broadcom BCM2835 SoC" + depends on ARCH_BCM2835 + depends on BCM2835_MBOX + help + Support for the Broadcom BCM2835 thermal sensor driver in the Linux + thermal framework. The BCM2835 has one sensor on chip, with one trip + point and no cooling devices. + config DB8500_THERMAL bool "DB8500 thermal management" depends on ARCH_U8500
drivers/thermal/Makefile +1 -0
@@ -25,3 +25,4 @@ obj-$(CONFIG_DB8500_CPUFREQ_COOLING) += db8500_cpufreq_cooling.o obj-$(CONFIG_INTEL_POWERCLAMP) += intel_powerclamp.o obj-$(CONFIG_X86_PKG_TEMP_THERMAL) += x86_pkg_temp_thermal.o obj-$(CONFIG_TI_SOC_THERMAL) += ti-soc-thermal/ +obj-$(CONFIG_BCM2835_THERMAL) += bcm2835-thermal.o
drivers/thermal/bcm2835-thermal.c new file +274 -0
274 lines not on this page · raw message
RFC PATCH 3/3 Enable BCM2835 mailbox support
Quoted 8 lines · Craig McGeachie
Implement BCM2835 CPU thermal sensor support.
Signed-off-by Craig McGeachie <[email protected]>---
Beyond the usual reviews of rubbish code, there are two points here that I'm looking for feedback on.
Quoted 7 lines
First is the placement of the mailbox directory make target in
drivers/Makefile. I placed it as early as I did in anticipation of implemented a frame buffer driver, which needs mailbox support at probe time. Another option would be to initialise the driver at architecture initialisation time, but I'm unfamiliar with good practice about when to initialise different bits and pieces. Especially with generic mailbox support looking kinda new.
These days, all drivers should support deferred probe, so that if they get probe()d and find that resources they need aren't yet available, they return -EPROBE_DEFER from probe(), and the driver core will call their probe() again later, when hopefully the resources actually will be available. Once this works, most drivers will simply use module_initcall(). This all avoids having to play games with link order or initcall ordering.
RFC PATCH 3/3 Enable BCM2835 mailbox support
Quoted 17 lines · Stephen Warren
Quoted 8 lines · Craig McGeachie
Implement BCM2835 CPU thermal sensor support.
Signed-off-by Craig McGeachie <[email protected]>---
Beyond the usual reviews of rubbish code, there are two points here that I'm looking for feedback on.
Quoted 7 lines
First is the placement of the mailbox directory make target in
drivers/Makefile. I placed it as early as I did in anticipation of implemented a frame buffer driver, which needs mailbox support at probe time. Another option would be to initialise the driver at architecture initialisation time, but I'm unfamiliar with good practice about when to initialise different bits and pieces. Especially with generic mailbox support looking kinda new.
Quoted 7 lines
These days, all drivers should support deferred probe, so that if they get probe()d and find that resources they need aren't yet available, they return -EPROBE_DEFER from
probe(), and the driver core will call theirprobe()again later, when hopefully the resources actually will be available. Once this works, most drivers will simply usemodule_initcall(). This all avoids having to play games with link order or initcall ordering.
Thank you. That's the information I needed. I mostly kick started my kernel knowledge with LDD3. It's getting a little old.
Cheers,
Craig.