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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Quoting Andrzej Hajda (2021-10-07 03:16:27)
> Hi Stephen,
>
> On 06.10.2021 21:37, Stephen Boyd wrote:
> > 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.



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux