omap2-beagle: Depend upon CONFIG_GPIO_TWL4030
Subsystems (3)
PATCH 1/1 omap2-beagle: Depend upon CONFIG_GPIO_TWL4030
Some very basic setup (i.e. MMC) is done in the beagleboard's setup callback for the TWL4030's gpio driver, causing a kernel without this support to fail to find its root filesystem. I can't imagine why one would want to build a kernel for this board without this driver, so I think it's worthwhile to explicitly depend on it.
--- arch/arm/mach-omap2/Kconfig | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/Kconfig +1 -0
@@ -120,6 +120,7 @@ config MACH_OMAP_2430SDP config MACH_OMAP3_BEAGLE bool "OMAP3 BEAGLE board" depends on ARCH_OMAP3 + depends on GPIO_TWL4030 default y select OMAP_PACKAGE_CBB
Signature · 1 line
1.7.0.4
PATCH 1/1 omap2-beagle: Depend upon CONFIG_GPIO_TWL4030
Hi,
Quoted 16 lines · Ben Gamari
Some very basic setup (i.e. MMC) is done in the beagleboard's setup callback for the TWL4030's gpio driver, causing a kernel without this support to fail to find its root filesystem. I can't imagine why one would want to build a kernel for this board without this driver, so I think it's worthwhile to explicitly depend on it.
Signed-off-by Ben Gamari <[email protected]>--- arch/arm/mach-omap2/Kconfig | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)arch/arm/mach-omap2/Kconfig +0
-0
arch/arm/mach-omap2/Kconfig config MACH_OMAP_2430SDP · line 125
Quoted 6 lines
arch/arm/mach-omap2/Kconfig +1
-0@@ -120,6 +120,7 @@ config MACH_OMAP_2430SDP config MACH_OMAP3_BEAGLE bool "OMAP3 BEAGLE board" depends on ARCH_OMAP3 + depends on GPIO_TWL4030 default y select OMAP_PACKAGE_CBB
NAK. This is totally bogus. The board doesn't really depend on GPIO_TWL4030, the MMC driver does.
Signature · 1 line
balbi
PATCH 1/1 omap2-beagle: Depend upon CONFIG_GPIO_TWL4030
Quoted 3 lines · Felipe Balbi
NAK. This is totally bogus. The board doesn't really depend on
GPIO_TWL4030, the MMC driver does.
I've looked a little more deeply into this and I'm not entirely convinced that what you claim is true. It seems that the only dependency that the MMC module _might_ have on the TWL4030 is for the LDOs, which I believe should be covered in the regulator driver, not GPIO.
In light of this, I think the use of the TWL's GPIO lines for MMC it might be a board specific design decision. In the case of the Beagleboard, they are only TWL GPIO used by the MMC configuration is for .gpio_cd but as far as I could see they could have chosen any GPIO for this. Am I missing something?
Cheers,
- Ben
PATCH 1/1 omap2-beagle: Depend upon CONFIG_GPIO_TWL4030
Quoted 9 lines · Ben Gamari
Quoted 3 lines · Felipe Balbi
NAK. This is totally bogus. The board doesn't really depend on
GPIO_TWL4030, the MMC driver does.I've looked a little more deeply into this and I'm not entirely convinced that what you claim is true. It seems that the only dependency that the MMC module _might_ have on the TWL4030 is for the LDOs, which I believe should be covered in the regulator driver, not GPIO.
Quoted 5 lines
In light of this, I think the use of the TWL's GPIO lines for MMC it might be a board specific design decision. In the case of the Beagleboard, they are only TWL GPIO used by the MMC configuration is for .gpio_cd but as far as I could see they could have chosen any GPIO for this. Am I missing something?
it's all true, still you making a board depend on a driver is inverting the dependencies. If you don't enable TWL4030_GPIO, all what will happen is that MMC won't work, but that's completely valid if I'm e.g. debugging UART of USB.
The point is, being able to disable features I don't want on my kernel image, is completely valid, if there's a compile breakage, then fix the breakage but don't prevent the board from compiling.
Signature · 1 line
balbi
PATCH 1/1 omap2-beagle: Depend upon CONFIG_GPIO_TWL4030
Quoted 4 lines · Felipe Balbi
The point is, being able to disable features I don't want on my kernel image, is completely valid, if there's a compile breakage, then fix the breakage but don't prevent the board from compiling.
I understand. That being said, Linus has made it well known that defconfigs will not be an option going forward. Have we found another means of selecting the basic drivers necessary to get a fully functional board? Perhaps a CONFIG_MACH_OMAP3_BEAGLE_CORE option selecting the necessary driver for a fully functional board would be a solution. I remember this being discussed several months ago (when Linus started pulling defconfigs out of the tree), but I don't recall there being any replacement proposals. It should be possible to build a functional kernel from the mainline without iterating over all available configuration options.
- Ben
PATCH 1/1 omap2-beagle: Depend upon CONFIG_GPIO_TWL4030
Quoted 7 lines · Ben Gamari
Quoted 4 lines · Felipe Balbi
The point is, being able to disable features I don't want on my kernel image, is completely valid, if there's a compile breakage, then fix the breakage but don't prevent the board from compiling.
I understand. That being said, Linus has made it well known that defconfigs will not be an option going forward. Have we found another
I never mentioned defconfigs here.
Quoted 3 lines
means of selecting the basic drivers necessary to get a fully functional board? Perhaps a
CONFIG_MACH_OMAP3_BEAGLE_COREoption selecting the necessary driver for a fully functional board would be a solution. I
I'll leave this for Tony to decide, but I don't like your proposal.
Quoted 5 lines
remember this being discussed several months ago (when Linus started pulling defconfigs out of the tree), but I don't recall there being any replacement proposals. It should be possible to build a functional kernel from the mainline without iterating over all available configuration options.
So you're saying that when you're building a kernel for you laptop/desktop you don't have to get a menuconfig and choose the drivers you want to compile ? I dare to doubt that.
Signature · 1 line
balbi
Tony Lindgren
maintainerPATCH 1/1 omap2-beagle: Depend upon CONFIG_GPIO_TWL4030
Quoted 23 lines · Felipe Balbi
Quoted 7 lines · Ben Gamari
Quoted 4 lines · Felipe Balbi
The point is, being able to disable features I don't want on my kernel image, is completely valid, if there's a compile breakage, then fix the breakage but don't prevent the board from compiling.
I understand. That being said, Linus has made it well known that defconfigs will not be an option going forward. Have we found another
I never mentioned defconfigs here.
Quoted 3 lines
means of selecting the basic drivers necessary to get a fully functional board? Perhaps a
CONFIG_MACH_OMAP3_BEAGLE_COREoption selecting the necessary driver for a fully functional board would be a solution. II'll leave this for Tony to decide, but I don't like your proposal.
Quoted 5 lines
remember this being discussed several months ago (when Linus started pulling defconfigs out of the tree), but I don't recall there being any replacement proposals. It should be possible to build a functional kernel from the mainline without iterating over all available configuration options.
Quoted 3 lines
So you're saying that when you're building a kernel for you laptop/desktop you don't have to get a menuconfig and choose the drivers you want to compile ? I dare to doubt that.
What we want to do in the long run is build a minimal kernel and make everything else loaded as modules from initramfs. In order to do that we need to cut down all the dependencies between core omap code and the drivers. So I'd stay away from selecting things for boards where possible.
Tony
PATCH 1/1 omap2-beagle: Depend upon CONFIG_GPIO_TWL4030
In reply to Felipe Balbi--text follows this line--
Quoted 6 lines · Felipe Balbi
Quoted 2 lines · Ben Gamari
I understand. That being said, Linus has made it well known that defconfigs will not be an option going forward. Have we found another
I never mentioned defconfigs here.
Certainly, I was trying to point out that there is no good way to package a configuration for a given board, which definitely increases the learning curve for a board integrator.
Quoted 6 lines
Quoted 3 lines
means of selecting the basic drivers necessary to get a fully functional board? Perhaps a
CONFIG_MACH_OMAP3_BEAGLE_COREoption selecting the necessary driver for a fully functional board would be a solution. II'll leave this for Tony to decide, but I don't like your proposal.
Fair enough.
Quoted 4 lines
So you're saying that when you're building a kernel for you laptop/desktop you don't have to get a menuconfig and choose the drivers you want to compile ? I dare to doubt that.
On the whole x86 hardware is far more uniform than ARM hardware. There is a good reason why there used to be so many defconfigs for ARM in the tree.
Cheers,
- Ben