mbox series

[v2,0/7] drm/vc4: Fix the core clock behaviour

Message ID 20220815-rpi-fix-4k-60-v2-0-983276b83f62@cerno.tech (mailing list archive)
Headers show
Series drm/vc4: Fix the core clock behaviour | expand

Message

Maxime Ripard Sept. 20, 2022, 12:50 p.m. UTC
Hi,

Those patches used to be part of a larger clock fixes series:
https://lore.kernel.org/linux-clk/20220715160014.2623107-1-maxime@cerno.tech/

However, that series doesn't seem to be getting anywhere, so I've split out
these patches that fix a regression that has been there since 5.18 and that
prevents the 4k output from working on the RaspberryPi4.

Hopefully, we will be able to merge those patches through the DRM tree to avoid
any further disruption.

Let me know what you think,
Maxime

To: Florian Fainelli <f.fainelli@gmail.com>
To: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
To: Ray Jui <rjui@broadcom.com>
To: Scott Branden <sbranden@broadcom.com>
To: Michael Turquette <mturquette@baylibre.com>
To: Stephen Boyd <sboyd@kernel.org>
To: Emma Anholt <emma@anholt.net>
To: Maxime Ripard <mripard@kernel.org>
To: David Airlie <airlied@linux.ie>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: linux-rpi-kernel@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Dom Cobley <popcornmix@gmail.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>

---

Changes in v2:
- Dropped the clock patches, made an ad-hoc function in the firmware driver
- Link to v1: https://lore.kernel.org/r/20220815-rpi-fix-4k-60-v1-0-c52bd642f7c6@cerno.tech

---
Dom Cobley (1):
      drm/vc4: hdmi: Add more checks for 4k resolutions

Maxime Ripard (6):
      firmware: raspberrypi: Introduce rpi_firmware_find_node()
      firmware: raspberrypi: Move the clock IDs to the firmware header
      firmware: raspberrypi: Provide a helper to query a clock max rate
      drm/vc4: hdmi: Fix hdmi_enable_4kp60 detection
      drm/vc4: hdmi: Rework hdmi_enable_4kp60 detection code
      drm/vc4: Make sure we don't end up with a core clock too high

 drivers/clk/bcm/clk-raspberrypi.c          | 18 -----------
 drivers/firmware/raspberrypi.c             | 22 +++++++++++++
 drivers/gpu/drm/vc4/vc4_drv.h              | 16 ++++++++++
 drivers/gpu/drm/vc4/vc4_hdmi.c             | 25 ++++++++-------
 drivers/gpu/drm/vc4/vc4_hdmi.h             |  8 -----
 drivers/gpu/drm/vc4/vc4_hvs.c              | 26 +++++++++++++++
 drivers/gpu/drm/vc4/vc4_kms.c              | 13 +++++---
 include/soc/bcm2835/raspberrypi-firmware.h | 51 ++++++++++++++++++++++++++++++
 8 files changed, 136 insertions(+), 43 deletions(-)
---
base-commit: 521a547ced6477c54b4b0cc206000406c221b4d6
change-id: 20220815-rpi-fix-4k-60-17273650429d

Best regards,

Comments

Maxime Ripard Oct. 10, 2022, 11:44 a.m. UTC | #1
Hi Florian,

On Tue, Sep 20, 2022 at 02:50:19PM +0200, Maxime Ripard wrote:
> Those patches used to be part of a larger clock fixes series:
> https://lore.kernel.org/linux-clk/20220715160014.2623107-1-maxime@cerno.tech/
> 
> However, that series doesn't seem to be getting anywhere, so I've split out
> these patches that fix a regression that has been there since 5.18 and that
> prevents the 4k output from working on the RaspberryPi4.
> 
> Hopefully, we will be able to merge those patches through the DRM tree to avoid
> any further disruption.

Could you review this? Ideally this would be merged through drm-misc due
to the dependencies between the new firmware functions and the DRM
patches.

Thanks!
Maxime
Florian Fainelli Oct. 10, 2022, 7:07 p.m. UTC | #2
On 10/10/22 04:44, Maxime Ripard wrote:
> Hi Florian,
> 
> On Tue, Sep 20, 2022 at 02:50:19PM +0200, Maxime Ripard wrote:
>> Those patches used to be part of a larger clock fixes series:
>> https://lore.kernel.org/linux-clk/20220715160014.2623107-1-maxime@cerno.tech/
>>
>> However, that series doesn't seem to be getting anywhere, so I've split out
>> these patches that fix a regression that has been there since 5.18 and that
>> prevents the 4k output from working on the RaspberryPi4.
>>
>> Hopefully, we will be able to merge those patches through the DRM tree to avoid
>> any further disruption.
> 
> Could you review this? Ideally this would be merged through drm-misc due
> to the dependencies between the new firmware functions and the DRM
> patches.

I suppose I can review the firmware parts if you would like me to, for 
vc4 I am pretty much clueless, and despite efforts from Emma to get the 
vc4 driver to be usable on platforms other than Pi, that never happened 
unfortunately. It would be better to keep the firmware and vc4 drivers 
decoupled, just so "wrong" assumptions are not made, but for all 
practical purposes this is the only combination that exists.
Maxime Ripard Oct. 13, 2022, 8:59 a.m. UTC | #3
Hi Florian,

On Mon, Oct 10, 2022 at 12:07:22PM -0700, Florian Fainelli wrote:
> On 10/10/22 04:44, Maxime Ripard wrote:
> > Hi Florian,
> > 
> > On Tue, Sep 20, 2022 at 02:50:19PM +0200, Maxime Ripard wrote:
> > > Those patches used to be part of a larger clock fixes series:
> > > https://lore.kernel.org/linux-clk/20220715160014.2623107-1-maxime@cerno.tech/
> > > 
> > > However, that series doesn't seem to be getting anywhere, so I've split out
> > > these patches that fix a regression that has been there since 5.18 and that
> > > prevents the 4k output from working on the RaspberryPi4.
> > > 
> > > Hopefully, we will be able to merge those patches through the DRM tree to avoid
> > > any further disruption.
> > 
> > Could you review this? Ideally this would be merged through drm-misc due
> > to the dependencies between the new firmware functions and the DRM
> > patches.
> 
> I suppose I can review the firmware parts if you would like me to

I was of course asking for the firmware parts :)

> for vc4 I am pretty much clueless, and despite efforts from Emma to
> get the vc4 driver to be usable on platforms other than Pi, that never
> happened unfortunately.

Stefan had the same concerns, but I don't think that's a big one. If
needs be, we can move the call to the firware into an if statement or
whatever and support a firmware-less device.

> It would be better to keep the firmware and vc4 drivers decoupled,
> just so "wrong" assumptions are not made, but for all practical
> purposes this is the only combination that exists.

I know, and my initial proposal was relying on a generic CCF function to
implement this. Stephen didn't feel like a single user for it was
enough, and there were some technical drawbacks too that might not have
made this solution robust enough. Hence the firmware solution.

Maxime