On Fri, 14 Jan 2011, Russell King - ARM Linux wrote:
> On Fri, Jan 14, 2011 at 12:18:50PM -0700, Paul Walmsley wrote:
> > On Thu, 13 Jan 2011, Russell King - ARM Linux wrote:
> > > On Thu, Jan 13, 2011 at 07:51:53AM -0800, Tony Lindgren wrote:
> > > > * Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> [110113 01:15]:
> > > > > Given the very sorry state of OMAP in mainline at present, I'm surprised
> > > > > that this kind of stuff is still going on...
> > > >
> > > > At least I boot test the patches I send..
> > >
> > > Which is why OMAP3 and OMAP4 can't be built in mainline because they
> > > spit out lots of compile errors in the OMAP code... As they won't
> > > even compile they couldn't have been boot tested.
> >
> > Current mainline != the patches that Tony sent to Linus[1].
> >
> > The patches that Tony sent to Linus, which Linus merged, build fine
> > with omap2plus_defconfig[2].
>
> Right, but is that sufficient testing?
>
> Can I read into your statement that the only testing which was done was
> a build of the omap2plus defconfig?
No. The patches that Tony merged from me were built with omap1_defconfig
and boot-tested on OMAP5912 OSK; they were built with an N8x0-specific
configuration and boot-tested on N800; and they were built with
omap2plus_defconfig and boot-tested on 2430SDP, OMAP3530 Beagle, DM37xx
Beagle XM, and OMAP4430 ES2 Panda. A brief summary of that testing was
part of the pull request that was sent to Tony[1].
The problem in this case was that I did not compile-test them with an
OMAP4-only configuration - hence the clockdomain and PRM breakage.
> Weren't builds specific to OMAP2, OMAP3, and OMAP4 tried?
>
> As there is stuff like:
>
> struct clockdomain {
> const char *name;
> union {
> const char *name;
> struct powerdomain *ptr;
> } pwrdm;
> #if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
> const u16 clktrctrl_mask;
> #endif
>
> would you consider it's a good idea to at least run a build test with
> an OMAP4-only configuration?
Yes. Given the clockdomain and PRM breakage from this merge window, I
plan to compile-test future branches that I send to Tony with quite a few
non-multi-OMAP configs. I consider it my responsibility to catch breakage
from my branches before it makes it to Tony.
> If it helps, here's what I do - not only do I run a few of the standard
> defconfigs in the tree, but I also run a number of platform specific
> builds, both covering platforms I do and do not have. I'll pick a random
> selection of existing build trees to rebuild and see what the results are.
> This shows the spread of trees which I've built over the last year - and
> note that many of these I don't even have:
>
> drwxrwxr-x. 20 rmk rmk 4096 Jan 14 20:30 omap4
> drwxrwxr-x. 21 rmk rmk 4096 Jan 14 11:45 versatile
> drwxrwxr-x. 21 rmk rmk 4096 Jan 14 11:14 iop13xx
> drwxrwxr-x. 20 rmk rmk 4096 Jan 13 23:10 vexpress
> drwxrwxr-x. 21 rmk rmk 4096 Jan 11 13:48 integrator
> drwxrwxr-x. 21 rmk rmk 4096 Jan 11 13:44 realview
> drwxrwxr-x. 21 rmk rmk 4096 Jan 8 11:10 assabet
> drwxrwxr-x. 21 rmk rmk 4096 Jan 8 11:07 rpc
> drwxrwxr-x. 21 rmk rmk 4096 Jan 7 17:34 omap3
> drwxrwxr-x. 20 rmk rmk 4096 Jan 6 14:24 nommu
> drwxrwxr-x. 21 rmk rmk 4096 Jan 6 10:44 omap2
> drwxrwxr-x. 21 rmk rmk 4096 Jan 6 10:27 omap
> drwxrwxr-x. 21 rmk rmk 4096 Jan 6 10:24 u300
> drwxrwxr-x. 21 rmk rmk 4096 Jan 5 19:14 pxa
> drwxrwxr-x. 21 rmk rmk 4096 Jan 5 10:30 msm
> drwxrwxr-x. 21 rmk rmk 4096 Jan 4 17:25 orion-kirkwood
> drwxrwxr-x. 21 rmk rmk 4096 Dec 24 11:06 ks8695
> drwxrwxr-x. 21 rmk rmk 4096 Dec 16 16:12 s3c2410
> drwxrwxr-x. 21 rmk rmk 4096 Dec 11 17:17 ixp4xx
> drwxrwxr-x. 20 rmk rmk 4096 Oct 9 22:59 netwinder2
> drwxrwxr-x. 21 rmk rmk 4096 Sep 5 23:54 ebsa285
> drwxrwxr-x. 21 rmk rmk 4096 Aug 4 2010 zylonite
> drwxrwxr-x. 21 rmk rmk 4096 Jul 8 2010 ep93xx
> drwxrwxr-x. 21 rmk rmk 4096 Jun 29 2010 corgi
> drwxrwxr-x. 21 rmk rmk 4096 Apr 25 2010 ebsa110
> drwxrwxr-x. 21 rmk rmk 4096 Mar 25 2010 clps711x
> drwxrwxr-x. 21 rmk rmk 4096 Mar 24 2010 ixp23xx
> drwxrwxr-x. 21 rmk rmk 4096 Mar 20 2010 n2100
> drwxrwxr-x. 21 rmk rmk 4096 Feb 19 2010 iop32x
> drwxrwxr-x. 21 rmk rmk 4096 Jan 20 2010 mx1
> drwxrwxr-x. 21 rmk rmk 4096 Jan 10 2010 w90p910evb
>
> omap4 = 4430SDP only (I have).
> omap3 = 3430LDP (I have) + 3430SDP + RX51 (I don't)
> omap2 = H2 (whose config can be traced to 2005 from when I once had one.)
> omap = some random omap1 config
> realview = realview eb/smp only
> assabet = assabet+neponset daugter board
>
> All those are build trees, built from my git tree with:
> make ARCH=arm CROSS_COMPILE=arm-linux- O=../build/$tree <args>
>
> You can see from the above that I built a kernel for at least orion-kirkwood,
> msm, u300, omap, nommu trees before sending my pull to Linus on the 6th,
> none of which I have (ever) had hardware for. I also built omap3, omap4,
> and a bunch of the ARM evaluation platforms as well as older platforms
> like RiscPC, but those are hidden by later re-builds for work I've been
> doing since (which is all based upon commit 9e9bc97.)
>
> I'm not saying that's perfect - it isn't. It's better than just testing
> the defconfigs - and with regular checking of kautobuild/linux-next, it
> seems to catch quite a bit of really silly stuff.
I agree with you. I do think it's a good idea, and it's something that I
plan to do for future branches that I send to Tony.
regards
- Paul
1. Walmsley, Paul. _[GIT PULL v3] OMAP: core/PM architecture: pull request
for 2.6.38_. Posted to linux-omap@xxxxxxxxxxxxxxx mailing list on 22
December 2010. Available from
http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg41289.html
(among others).
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
