Hi Andrzej,
On Wed, Aug 04, 2021 at 04:09:38PM +0200, a.hajda wrote:
Hi Maxime,
I have been busy with other tasks, and I did not follow the list last time, so sorry for my late response.
On 28.07.2021 15:32, Maxime Ripard wrote:
Hi,
We've encountered an issue with the RaspberryPi DSI panel that prevented the whole display driver from probing.
The issue is described in detail in the commit 7213246a803f ("drm/vc4: dsi: Only register our component once a DSI device is attached"), but the basic idea is that since the panel is probed through i2c, there's no synchronization between its probe and the registration of the MIPI-DSI host it's attached to.
We initially moved the component framework registration to the MIPI-DSI Host attach hook to make sure we register our component only when we have a DSI device attached to our MIPI-DSI host, and then use lookup our DSI device in our bind hook.
However, all the DSI bridges controlled through i2c are only registering their associated DSI device in their bridge attach hook, meaning with our change
I guess this is incorrect. I have promoted several times the pattern that device driver shouldn't expose its interfaces (for example component_add, drm_panel_add, drm_bridge_add) until it gathers all required dependencies. In this particular case bridges should defer probe until DSI bus becomes available. I guess this way the patch you reverts would work.
I advised few times this pattern in case of DSI hosts, apparently I didn't notice the similar issue can appear in case of bridges. Or there is something I have missed???
Anyway there are already eleven(?) bridge drivers using this pattern. I wonder if fixing it would be difficult, or if it expose other issues??? The patches should be quite straightforward - move of_find_mipi_dsi_host_by_node and mipi_dsi_device_register_full to probe time.
I gave this a try today, went back to the current upstream code and found that indeed it works. I converted two bridges that works now. I'll send a new version some time next week and will convert all the others if we agree on the approach.
Thanks for the suggestion!
Finally I think that if we will not fix these bridge drivers we will encounter another set of issues with new platforms connecting "DSI host drivers assuming this pattern" and "i2c/dsi device drivers assuming pattern already present in the bridges".
Yeah, this is exactly the situation I'm in :)
Maxime