[PATCH 4/5] [POWERPC] QE: implement support for the GPIO LIB API

David Brownell david-b at pacbell.net
Tue Apr 22 08:19:02 EST 2008


On Monday 21 April 2008, Anton Vorontsov wrote:
> On Mon, Apr 21, 2008 at 01:01:12PM -0700, David Brownell wrote:

> > The way other platforms do this is to hav SOC-specific
> > init code, and have board-specific initcalls call the
> > relevant SOC-specific setup.
> 
> I don't know about other platforms other than PowerPC and some ARM,
> of course. For example, PXA boards don't call any SOC specific code.
> Instead, looking into reworked PXA code, I can see that there are
> separate arch_initcalls() for the pxa25x, pxa27x, and pxa3xx SOCs.

Exactly:  SOC-specific initcalls.


> > Among other things that facilitates kernels that handle
> > multiple SOCs (if they're closely-enough related).  That
> > may not be used by many distros (handhelds.org being at
> > least a partial exception), but it certainly helps cut
> > the number of configurations that need build-testing.
> 
> Is this about QE_GPIO being user-selectable?

No.  It's about "kernels that handle multiple SOCs".  Like
for example pxa{25,27,3x}x ... or omap{16xx,17xx,5912}.

Consider several ways to support a family of SOCs.

 - One way supports only one board at a time.  Testing
   builds after arch level changes means rebuilding kernels
   for each board ... quite possibly several dozen.

 - Another supports several boards, but only if they use
   the same SOC.  Testing builds here takes fewer kernels;
   one per SOC; better, but still routinely shortchanged.

 - Yet another way supports any number of boards, using
   a variety of mostly-compatible SOCs.  This allows test
   builds that support entire SOC families (e.g. OMAP1,
   or OMAP2/OMAP3, or PXA XScale, etc).

Test builds are a quality control thing.  If they're done
regularly, it's less likely you'll push code upstream
that can't build in some configuration.


> And well, I'm not objecting for placing qe gpio code under arch/, too.
> I'll resend this patch once again reverting its placement to arch/.

OK, good.  Then I don't really have to be involved with that.

- Dave




More information about the Linuxppc-dev mailing list