On Wed, Jun 12, 2024 at 10:22:49AM -0700, Doug Anderson wrote: > Hi, > > On Wed, Jun 12, 2024 at 9:47 AM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > > > > On Wed, Jun 12, 2024 at 5:11 PM Daniel Vetter <daniel@xxxxxxxx> wrote: > > > On Wed, Jun 12, 2024 at 07:49:31AM -0700, Doug Anderson wrote: > > (...) > > > > The problem is that the ordering is wrong, I think. Even if the OS was > > > > calling driver shutdown functions in the perfect order (which I'm not > > > > convinced about since panels aren't always child "struct device"s of > > > > the DRM device), the OS should be calling panel shutdown _before_ > > > > shutting down the DRM device. That means that with your suggestion: > > > > > > > > 1. Shutdown starts and panel is on. > > > > > > > > 2. OS calls panel shutdown call, which prints warnings because panel > > > > is still on. > > > > > > > > 3. OS calls DRM driver shutdown call, which prints warnings because > > > > someone else turned the panel off. > > > > > > Uh, that's a _much_ more fundamental issue. > > > > > > The fix for that is telling the driver core about this dependency with > > > device_link_add. Unfortuantely, despite years of me trying to push for > > > this, drm_bridge and drm_panel still don't automatically add these, > > > because the situation is a really complex mess. > > > > > > Probably need to read dri-devel archives for all the past attempts around > > > device_link_add. > > > > I think involving Saravana Kannan in the discussions around this > > is the right thing to do, because he knows how to get devicelinks > > to do the right thing. > > > > If we can describe what devicelink needs to do to get this ordering > > right, I'm pretty sure Saravana can tell us how to do it. > > I'm really not convinced that hacking with device links in order to > get the shutdown notification in the right order is correct, though. > The idea is that after we're confident that all DRM modeset drivers > are calling shutdown properly that we should _remove_ any code > handling shutdown from panel-edp and panel-simple. They should just > get disabled as part of DRM's shutdown. That means that if we messed > with devicelinks just to get a different shutdown order that it was > just for a short term thing. The device links would allow us to add consistency checks to the panel code to make sure that the shutdown has already happened. And we do kinda need the device ordering still, because if they're shut down in the wrong order the panel might lose it's power already, before the drm driver had a chance to have the last chat with it. Only relevant for non-dumb panels like dsi, but there's cases. > That being said, one could argue that having device links between the > DRM device and the panel is the right thing long term anyway and that > may well be. I guess the issue is that it's not necessarily obvious > how the "parent/child" or "supplier/consumer" relationship works w/ > DRM devices, especially panels. My instinct says that the panel > logically is a "child" or "consumer" of the DRM device and thus > inserting the correct long term device link would mean we'd get > shutdown notification in the wrong order. It would be hard to argue > that the panel is the "parent" of a DRM device, but I guess you could > call it a "supplier"? ...but it's also a "consumer" of some other > stuff, like the pixels being output and also (perhaps) the DP AUX bus. > All this complexity is why the DRM framework tends to use its own > logic for things like prepare/enable instead of using what Linux gives > you. I'm sure Saravanah can also tell you about all the crazy device > link circular dependencies that DRM has thrown him through... The panel driver provides the panel, the drm device driver consumes it. I'm not really clear why you want to structure this the other way round, I can't come up with another way that makes sense from a device driver model. And it's device driver model stuff here, not what's really going on at the hardware level when everything is set up. > In any case, I guess I'll continue asserting that I'm not going to try > to solve this problem. If folks don't like my patch and there's no > suggestion other than solving years-old problems then I'm happy to > live with the way things are and hope that someone eventually comes > along and solves it. See my other reply, I do think there's an intermediate solution, without the maintenance headache of a "these drivers work for this extremely narrow special case" list. And without having to step into the device_link complexity. But also I think we've piled up years of hacks by now because people don't want to solve the fundamental problem here, which device links are meant to be the solution for. But I guess we can do another few years of papering over the fundamental crack, *shrugs* Cheers, Sima -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
