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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
