[PATCH] ARM: dts: AM35xx: fix system control module clocks

[Paul Walmsley]

Hi Jeroen,

On Sun, 7 Jun 2015, Paul Walmsley wrote:

> On Sun, 7 Jun 2015, Jeroen Hofstee wrote:
> 
> > On 05-06-15 10:04, Jeroen Hofstee wrote:
> > > 
> > > On 05-06-15 10:01, Jeroen Hofstee wrote:
> > > > 
> > > > On 01-06-15 19:44, Paul Walmsley wrote:
> > > > > The best way to make this work IMHO would be for us not to accept any
> > > > > new
> > > > > feature addition patches as long as there are warnings reported in the
> > > > > test results.  The only real exception that I would foresee is if those
> > > > > warnings are due to something outside of our control, e.g., a crappy
> > > > > bootloader, as I suspect the USB_OTG initiator warnings are for the
> > > > > CM-T3517.
> > > > > 
> > > > 
> > > > I doubt this is related to the bootloader. I have the suspicion that is
> > > > actually
> > > > a bug in linux but only triggered depending on whether the ROMcode setup
> > > > the USB OTG or not. Here is some data to backup my statement:
> > > > 
> > 
> > Turns out my suspicion was wrong. This is what I know at the moment,
> > depending on the bootpins, u-boot will trigger a bad access when loading
> > a file over ethernet, but only the first time. Clearing the pending interrupt
> > before booting linux make the "USB_OTG address hole seen" go away.
> 
> Oh, too bad.  I had been hoping that you were right and that I was wrong 
> ;-)  I'll try this on the CM-T3517 here.

I used your debugging technique here and was able to reproduce your 
results - with one difference:

http://www.pwsan.com/omap/testlogs/test_v4.1-rc6/20150607194102/boot/cmt3517/cmt3517_log.txt

The interconnect error was logged upon the first interaction with the 
network.  In my case this was with the U-boot 'dhcp' command.  The pending 
interrupt bit was cleared before loading the kernel via tftp, and the 
interrupt bit was not set again, even after a tftp load.


regards,

- Paul