[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

On Fri, 14 Jan 2011, Russell King - ARM Linux wrote:

On Fri, Jan 14, 2011 at 12:18:50PM -0700, Paul Walmsley wrote:

quoted

On Thu, 13 Jan 2011, Russell King - ARM Linux wrote:

quoted

On Thu, Jan 13, 2011 at 07:51:53AM -0800, Tony Lindgren wrote:

quoted

* Russell King - ARM Linux [off-list ref] [110113 01:15]:

quoted

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 at vger.kernel.org mailing list on 22 
   December 2010. Available from 
   http://www.mail-archive.com/linux-omap at vger.kernel.org/msg41289.html
   (among others).