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