On Mon, Mar 19, 2012 at 02:41:04PM +0200, Tomi Valkeinen wrote: > On Mon, 2012-03-19 at 12:30 +0000, Russell King - ARM Linux wrote: > > On Mon, Mar 19, 2012 at 11:33:21AM +0200, Tomi Valkeinen wrote: > > > But that's a bigger work item, so what I did in the series above is that > > > I changed platform_driver_register()s to platform_driver_probe()s. All > > > the DSS subdevices are present at boot time and are non-hotpluggable, so > > > I think that should work fine. > > > > platform_driver_probe() is just a wrapper around platform_driver_register() - > > the difference between the two is that _probe() will temporarily set the > > probe method in the passed driver structure, call platform_driver_register(), > > and then NULL the probe method out. > > I meant that platform_driver_probe() solves the issue with the > initialization order of the dss subdrivers. > > The deadlock is solved in the series by moving the driver registration > to module_init. > > > So, merely changing platform_driver_register() for platform_driver_probe() > > won't solve the deadlock. > > > > I'm not sure what's caused this regression, as I can't see any DSS changes, > > nor core driver model changes which would account for this. Has something > > changed in hwmod to cause this? > > > > 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 > > Currently all omap_devices are forced to have the dummy device > 'omap_device_parent' as a parent. This was used to distinguish > omap_devices from "normal" platform_devices in the OMAP PM core code. > > Now that we implement the PM core using PM domains, this is no longer > needed, and is removed. > > This also frees up omap_devices to have a more complex parent/child > relationships that model actual device relationships. > > The only in-tree user of omap_device_parent was the OMAP PM layer to > handle lost-context count for omap_devices. That is now converted to > use the presence of the omap_device_pm_domain instead. > > Signed-off-by: Kevin Hilman <khilman@xxxxxx> Yes, it could well be caused by this. What would've happened before is that the omapdss device would have been parented to the 'platform' device, while the hwmod-built devices would've been parented to omap_device_parent. With the above commit, both devices would be parented to the 'platform' device, which would cause lock contention. I've just built with this reverted (which was a relatively clean revert) - and doing so appears to allow the kernel to boot again. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
