[PATCH] omap2-beagle: Depend upon CONFIG_GPIO_TWL4030

[PATCH] omap2-beagle: Depend upon CONFIG_GPIO_TWL4030

[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 <bgamari.foss@gmail.com>
---
 arch/arm/mach-omap2/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index ab784bf..74173f1 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -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
 
-- 
1.7.0.4

[PATCH] omap2-beagle: Depend upon CONFIG_GPIO_TWL4030

[Felipe Balbi]

Hi,

On Mon, Jan 17, 2011 at 04:25:48PM -0500, Ben Gamari wrote:
> 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 <bgamari.foss@gmail.com>
> ---
>  arch/arm/mach-omap2/Kconfig |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index ab784bf..74173f1 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -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.

-- 
balbi

[PATCH] omap2-beagle: Depend upon CONFIG_GPIO_TWL4030

[Ben Gamari]

On Tue, 18 Jan 2011 05:10:39 +0200, Felipe Balbi <balbi@ti.com> wrote:
> 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] omap2-beagle: Depend upon CONFIG_GPIO_TWL4030

[Felipe Balbi]

On Tue, Jan 18, 2011 at 08:51:52AM -0500, Ben Gamari wrote:
> On Tue, 18 Jan 2011 05:10:39 +0200, Felipe Balbi <balbi@ti.com> wrote:
> > 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?

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.

-- 
balbi

[PATCH] omap2-beagle: Depend upon CONFIG_GPIO_TWL4030

[Ben Gamari]

On Wed, 19 Jan 2011 05:45:28 +0200, Felipe Balbi <balbi@ti.com> wrote:
> 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] omap2-beagle: Depend upon CONFIG_GPIO_TWL4030

[Felipe Balbi]

On Wed, Jan 19, 2011 at 03:04:13PM -0500, Ben Gamari wrote:
> On Wed, 19 Jan 2011 05:45:28 +0200, Felipe Balbi <balbi@ti.com> wrote:
> > 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.

> 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

I'll leave this for Tony to decide, but I don't like your proposal.

> 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.

-- 
balbi

[PATCH] omap2-beagle: Depend upon CONFIG_GPIO_TWL4030

[Tony Lindgren]

* Felipe Balbi <balbi@ti.com> [110119 20:07]:
> On Wed, Jan 19, 2011 at 03:04:13PM -0500, Ben Gamari wrote:
> > On Wed, 19 Jan 2011 05:45:28 +0200, Felipe Balbi <balbi@ti.com> wrote:
> > > 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.
> 
> > 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
> 
> I'll leave this for Tony to decide, but I don't like your proposal.
> 
> > 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.

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] omap2-beagle: Depend upon CONFIG_GPIO_TWL4030

[Ben Gamari]

--text follows this line--
On Thu, 20 Jan 2011 06:08:25 +0200, Felipe Balbi <balbi@ti.com> wrote:
> On Wed, Jan 19, 2011 at 03:04:13PM -0500, Ben Gamari wrote:
> > 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.

> > 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
> 
> I'll leave this for Tony to decide, but I don't like your proposal.
> 
Fair enough.

> 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