On Fri, Oct 03, 2014 at 01:39:21PM +0200, Daniel Vetter wrote: > On Fri, Oct 3, 2014 at 11:42 AM, Andrzej Hajda <a.hajda@xxxxxxxxxxx> wrote: > > But this is an issue closely connected with component framework. > > Component framework separates master component probe and drm device > > initialization. As a result PM ops which are synchronized with probe > > (via device_lock) > > are no more synchronized with drm initialization which is usually called > > from > > .bind callback. > > Now I'm confused. component->bind and drm initialization is about > driver load, but all this code here is about system suspend/resume > really. So I'm rather confused what problem you actually want to fix > .. The component *helper* will disconnect the bind of the master device from its probe if the components aren't already known. If all the components are known at the point the master device probes, the master device lock will be held (since we'll be operating within the master device's probe function.) The issue here is that while the master device is being probed, the per-device lock is held. Beneath that lock there are locks in the component helper which will be taken, and thus will end up depending upon the per-device lock. This means that we pretty much can not guarantee synchronisation between PM on the master device and the component helper calling the bind callback - if we tried to take the per-device lock here, we would either deadlock, or we would end up with AB-BA lock dependencies. What we /could/ do is expose lock/unlock functions from the component helper so that PM implementations can synchronise with binds - or I could look at whether we could integrate the component helper into the device model. I suspect the latter would not be met with enthusiasm as it would mean adding bloat to the driver core structures, which would not be needed in 99% of cases. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |