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