On Tue, Jan 8, 2019 at 11:16 AM Russell King - ARM Linux <linux@xxxxxxxxxxxxxxx> wrote: > > 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. Hm, I thought there was patches floating around to remedy that, I guess they never landed? Without that device links aren't really useful beyond fixing suspend/resume issues. > 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. There's still the benefit that component doesn't have opinions about what exactly the things are you're collecting together - device links only work if you have a struct device. That's generally ok for DT platforms, but a notch more work on x86 (since you need to create platform devices, which then creates lifetime issues since the platform device is managed by the driver bound to the pci device, so if you unload that again the platform device itself has to disappear). I guess if device links really don't work plan B would be to have a standard wrapper for bridg-as-component: drm_bridge_add would also register a component, and a new of_drm_bridge_component_add would add it to the component_match. We could probably even do standard bind/unbind functions for that bridge component, which links it up to the right encoder (or just to a given bridge pointer, whether that's in drm_encoder of in a drm_bridge for chaining). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
