On Wed, 2 Aug 2023 at 18:26, Chris Morgan <macroalpha82@xxxxxxxxx> wrote: > > * Spam * > On Mon, Jul 31, 2023 at 07:03:07PM +0200, Maxime Ripard wrote: > > Hi, > > > > On Mon, Jul 31, 2023 at 11:33:22AM -0500, Chris Morgan wrote: > > > In my case a few different panel drivers disable the regulators in the > > > unprepare/disable routines. > > > > And that's totally fine. > > > > > For at least the Rockchip DSI implementations for some reason the > > > panel gets unprepared more than once, which triggers an unbalanced > > > regulator disable. > > > > "For some reason" being that DW-DSI apparently finds it ok to bypass any > > kind of abstraction and randomly calling panel functions by itself: > > > > https://elixir.bootlin.com/linux/v6.4.7/source/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c#L868 > > > > It looks like it's fixed it current drm-misc-next though. > > Good, when I get a chance I will test it out with the existing panels > I have at my disposal and submit some patches to clean them up. > > > > > > Obviously though the correct course of action is to fix the reason why > > > the panel is disabled more than once, but that's at least the root > > > cause of this behavior on the few panels I've worked with. > > > > Like I said we already have a commit on the way to fix that, so it > > shouldn't be an issue anymore. > > > > I stand by what I was saying earlier though, I think it's mostly > > cargo-cult or drivers being very wrong. If anything, the DW-DSI stuff > > made me even more convinced that we shouldn't even entertain that idea > > :) DW-DSI is hacking around the fact that DSI panels may want to send DCS commands in unprepare, however the DSI host driver shuts down the controller in the DSI bridge post_disable which gets called first. That ordering can now be reversed with pre_enable_prev_first flag in struct drm_bridge, or prepare_prev_first in drm_panel, hence no need for the DSI controller to jump around the bridge chain. Dave > > Maxime > > Thank you, and yes if a driver is doing something it shouldn't we > shouldn't be patching around that, we should be fixing things. Thanks > for providing me with the additional info. > > Chris >
