Re: [PATCH v2 00/34] component: Make into an aggregate bus

On Thu, Oct 07, 2021 at 04:46:22PM -0400, Stephen Boyd wrote:

Quoting Andrzej Hajda (2021-10-07 03:16:27)

quoted

Hi Stephen,

On 06.10.2021 21:37, Stephen Boyd wrote:

quoted

This series is from discussion we had on reordering the device lists for
drm shutdown paths[1]. I've introduced an 'aggregate' bus that we put
the aggregate device onto and then we probe the aggregate device once
all the components are probed and call component_add(). The probe/remove
hooks are where the bind/unbind calls go, and then a shutdown hook is
added that can be used to shutdown the drm display pipeline at the right
time.

This works for me on my sc7180 board. I no longer get a warning from i2c
at shutdown that we're trying to make an i2c transaction after the i2c
bus has been shutdown. There's more work to do on the msm drm driver to
extract component device resources like clks, regulators, etc. out of
the component bind function into the driver probe but I wanted to move
everything over now in other component drivers before tackling that
problem.

As I understand you have DSI host with i2c-controlled DSI bridge. And
there is an issue that bridge is shutdown before msmdrm. Your solution
is to 'adjust' device order on pm list.
I had similar issue and solved it locally by adding notification from
DSI bridge to DSI host that is has to be removed: mipi_dsi_detach, this
notification escalates in DSI host to component_del and this allow to
react properly.

Advantages:
- it is local (only involves DSI host and DSI device),
- it does not depend on PM internals,
- it can be used in other scenarios as well - unbinding DSI device driver

Disadvantage:
- It is DSI specific (but this is your case), I have advertised some
time ago more general approach [1][2].

[1]: https://static.sched.com/hosted_files/osseu18/0f/deferred_problem.pdf
[2]: https://lwn.net/Articles/625454/

I think these are all points for or against using the component code in
general? Maybe you can send patches that you think can solve the problem
I'm experiencing and we can review them on the list.

Yeah I think this is entirely orthogonal. If you use component, then
component should provide a way to handle this.

If you use something else, like drm_bridge or dsi or whatever, then that
part should provide a solution to stage stuff correctly and handle all the
ordering.

Now there's a bunch of drivers which mix up component with bridge use and
hilarity ensues, but since there's no real effort to fix that I think it's
toally fine to just improve component.c meanwhile.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch