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@xxxxxx> > 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:
signature.asc
Description: This is a digitally signed message part
