On Thu, Jun 16, 2022 at 10:47:56AM +0100, Dave Stevenson wrote: > On Thu, 16 Jun 2022 at 09:38, Maxime Ripard <maxime@xxxxxxxxxx> 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@xxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
