Hi Tomi,
On Fri, 15 May 2026 at 10:17, Tomi Valkeinen
<[email protected]> wrote:
> On 15/05/2026 11:05, Geert Uytterhoeven wrote:
> > On Fri, 15 May 2026 at 10:03, Tomi Valkeinen
> > <[email protected]> wrote:
> >> On 15/05/2026 10:49, Geert Uytterhoeven wrote:
> >>> On Thu, 14 May 2026 at 14:25, Tomi Valkeinen
> >>> <[email protected]> wrote:
> >>>> From: Marek Vasut <[email protected]>
> >>>>
> >>>> The Renesas DSC Display Stream Compression is a bridge embedded in the
> >>>> Renesas R-Car V4H SoC. The bridge performs VESA DSC encoding of up to
> >>>> 8k or 400 Mpixel/s . Add rudimentary driver, which currently acts as a
> >>>> pass-through bridge and allows DSI1 to be operational on R-Car V4H.
> >>>>
> >>>> Signed-off-by: Marek Vasut <[email protected]>
> >>>> [tomi.valkeinen: use bridge->next_bridge, minor changes]
> >>>> Signed-off-by: Tomi Valkeinen <[email protected]>
> >>>
> >>> Thanks for your patch!
> >>>
> >>>> --- /dev/null
> >>>> +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_dsc.c
> >>>
> >>>> +
> >>>> +static void rcar_dsc_atomic_enable(struct drm_bridge *bridge,
> >>>> + struct drm_atomic_state *state)
> >>>> +{
> >>>> + struct rcar_dsc *dsc = bridge_to_rcar_dsc(bridge);
> >>>> +
> >>>> + WARN_ON(clk_prepare_enable(dsc->clk));
> >>
> >> Ah, just missed your comment and sent the v2.
> >>
> >>> Who don't you use pm_runtime_resume_and_get() instead, like
> >>> rcar_cmm.c? Then you don't need to get the clock at all, and the driver
> >>
> >> Hmm, why wouldn't I need to get the clock? What does the runtime PM do
> >> on Renesas?
> >
> > Runtime PM powers on the power domain (if present), and starts
> > the device by enabling its module clock.
> >
> >>> will keep on working if the DSC ever ends up in a power domain.
> >> I can add runtime PM. I just felt that it was overcomplicating a "dummy"
> >> driver that just needs to enable the clock when the video pipeline is
> >> enabled.
> >
> > Funny, I would say you are overcomplicating a dummy driver by adding
> > explicit clock control ;-)
> Well, now that I know the runtime PM does magics behind the scenes, you
> are right =).
>
> How's "module clock" defined? Is it the first clock in the clocks DT
> property?
It's the clock pointing to the cpg device node, and having "CPG_MOD"
as its first cell. Usually it's the first clock. Note that e.g. the
DU is special, as it' is represented by a single device node with
multiple module clocks (and multiple (but less) resets), due to the
tight integration between the individual channels.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
