Re: arm-soc + rmk's tree boot failure on OMAP4430SDP

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]

On Mon, 2012-03-19 at 14:41 +0200, Tomi Valkeinen wrote:
> On Mon, 2012-03-19 at 12:30 +0000, Russell King - ARM Linux wrote:

> > It is _very_ important that we discover what has caused this regression
> > and prevent it going upstream until the problem is resolved.  Until we
> > know that, I suggest that _no_ OMAP changes go upstream during this
> > merge window until we understand what's caused this.
> 
> I didn't try yet, but it could be this:
> 
> commit 3ec2decbb6dfcdbbb6e6a8ddf5adc7edbc429ed7
> Author: Kevin Hilman <khilman@ti.com>
> Date:   Wed Feb 15 11:47:45 2012 -0800
> 
>     ARM: OMAP: omap_device: remove omap_device_parent

Reverting that patch makes dss work again. I don't know all the details
of device/driver registration, but I guess the problem is this:

"omapdss" device is a platform_device, and there's no hwmod for it. The
dss subdrivers (which have a corresponding hwmod) are being registered
in omapdss-driver's probe. Previously the dss subdrivers had
"omap_device_parent" device as their parent, and this avoided the
deadlock between omapdss and the subdrivers.

Now, with that patch, both omapdss and dss subdrivers have
platform_driver as parent, causing the deadlock.

The patch does make sense, though. I hope nothing else than omapdss is
using the device framework in similar braindead way.

I'll see if I can make a single patch that fixes the issue. The patch
series I mentioned earlier does lots of things, but I think just moving
the driver registration out of the probe function should be enough to
avoid the problem.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]