Hi, On Wed, May 21, 2014 at 11:43:19AM -0700, Tony Lindgren wrote: > > > Just noticed that this patch seems to somehow break idle > > > modes on n900, so dropping both dts changes for now. > > > > > > Basically the n900 debug LEDs won't ever go off with > > > these two dts patches enabled, even without the modem > > > drivers loaded. I did not dig deeper, but it's probably > > > something related to hwmod using this data for some > > > settings. > > > > Is hwmod data interpreted at all without the DT entries? > > Yes for autoidling unused devices. We parse that with > omap_device_build_from_dt(). That function seems to parse DT stuff. What I meant was not without the *driver*, but without the *DT entry*. I think the hwmod entries are completly ignored until there is a DT device? > > The hwmod data may be wrong. The information from commit > > 398917ce161e10d3c66afaefdb89c73c64c4b02d was simply > > interpolated from all information I found. The OMAP3 > > public TRM does not contain *any* information about the > > ssi IP-Core. > > It's probably something with the sysc or idlemodes that > keeps things from idling. Maybe wrong address? Or wrong > flags? I'm pretty sure it was the first .dts patch out of > these two as the second one alone did not apply. > > > > Sorry did not notice it earlier as I did not have the > > > PM regression fix patches merged with my testing branch. > > > > I hoped to see working modem in 3.16, which will probably > > be used for the next Debian stable :( > > That would indeed be nice, let's try to debug it as we > still have few days. I will have a look at it now. > I'm finally able to test for PM regressions with DT patches, > too > bad we did not have that earlier because of multiple issues. Yes. More time would have been nice. > Anyways, this dts issue should not prevent merging the > driver changes, I'm all for that! Of course, driver changes are unrelated. They are already in linux-next btw. -- Sebastian
Attachment:
signature.asc
Description: Digital signature
