[PATCH 25/64] drm/vc4: dpi: Add action to disable the clock

[Maxime Ripard]

On Thu, Jun 16, 2022 at 10:47:56AM +0100, Dave Stevenson wrote:
> On Thu, 16 Jun 2022 at 09:38, Maxime Ripard <maxime at cerno.tech> wrote:
> >
> > Hi Dave,
> >
> > On Tue, Jun 14, 2022 at 05:47:28PM +0100, Dave Stevenson wrote:
> > > Hi Maxime.
> > >
> > > On Fri, 10 Jun 2022 at 10:30, Maxime Ripard <maxime at cerno.tech> wrote:
> > > >
> > > > Adding a device-managed action will make the error path easier, so let's
> > > > create one to disable our clock.
> > >
> > > The DPI block has two clocks (core and pixel), and this is only
> > > affecting one of them (the core clock).
> >
> > Thanks for the suggestion, I've amended the commit message.
> >
> > > (I'm actually puzzling over what it's wanting to do with the core
> > > clock here as it's only enabling it rather than setting a rate. I
> > > think it may be redundant).
> >
> > Could it be that it a "bus" clock that we need it to access the
> > registers?
> 
> No idea. Normally it's the power domain that is required to access
> registers.

For HDMI at least, the power domain being off will make a read return
some bogus value, but the core clock being off will just make the CPU
stall. I can only assume it would be the same for the DPI controller?

> AFAIK the core clock is never turned off, so the request for it is
> just a little odd.

Even if the clock driver never shuts it off, I think it still has value
to follow the Clock Framework conventions. We might have a different
clock policy in the future, and it would throw people reading the DPI
driver off.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20220620/ea69dfaa/attachment.sig>