On Tue, Jan 08, 2019 at 09:35:21AM +0100, Andrzej Hajda wrote: > On 07.01.2019 22:56, Daniel Vetter wrote: > > If you call drm_dev_register before you have all the components > > assembled (i.e. anywhere else than in master bind) that sounds like a > > driver bug. > > > This is how components work, every component calls component_add usually > in probe, and this function checks if all components are present, if yes > (ie. during probe of the last component) master bind is called and it > creates drm device and then registers it. If you add device link at this > moment, it is still before end of probe of the last component. I wonder if device links will create more problems with the component stuff, because we'll end up with two different systems fighting to achieve the same aim. 1) a component device is probed, and is added to the component helper as a component. (Repeat for as many component devices as are required.) 2) the main device is probed, added as a master. The system is complete, so the master bind is called, and device links are created - the component device is a provider, and the main device is a consumer. 3) the component device is unbound, which triggers the device links to unbind the provider device. This undoes everything, removing the device links and removing the main device from the component helper. 4) the component device is re-probed, and added to the component helper again. At this point, there is nothing that causes the main device to be re-probed. As far as userspace is concerned, that's confusing because userspace never asked for any change of status of the provider device. Without device links, the main device would not be unbound, and there would be an additional stage: 5) the component helper notices the re-appearance of the component device, notices that the system is again complete, and re-binds the master device bring the system back up. This seems to be a disadvantage with device links, but there is an advantage that device links offer - the ability to deal with other resources (such as clocks, regulators, etc) going away more gracefully than is possible today - but folk have to understand that a consumer device will only ever be unbound, it will never be re-bound automatically when the resources re-appear. I suppose that could be fixed by moving the consumer devices onto the deferred probe list, so when a device is re-bound, they are retried. At that point, the component helper becomes entirely redundant, since its functionality can be implemented completely using device links. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
