Hi Geert,
On Monday, 15 January 2018 10:30:23 EET Geert Uytterhoeven wrote:
> On Sat, Jan 13, 2018 at 12:14 AM, Laurent Pinchart wrote:
> > The LVDS encoders used to be described in DT as part of the DU. They now
> > have their own DT node, linked to the DU using the OF graph bindings.
> > This allows moving internal LVDS encoder support to a separate driver
> > modelled as a DRM bridge. Backward compatibility is retained as legacy
> > DT is patched live to move to the new bindings.
> >
> > Signed-off-by: Laurent Pinchart
> > <laurent.pinchart+renesas@xxxxxxxxxxxxxxxx>
> >
> > --- /dev/null
> > +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> >
> > +static void rcar_lvds_enable(struct drm_bridge *bridge)
> > +{
> > + struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);
> > + u32 lvdhcr;
> > + int ret;
> > +
> > + WARN_ON(lvds->enabled);
> > +
> > + ret = clk_prepare_enable(lvds->clock);
>
> What about starting to use Runtime PM to manage the clock, and thus calling
> pm_runtime_get_sync() here instead?
> That will make the driver future-proof w.r.t. LVDS blocks in power domains.
>
> You do need a "power-domains" property, though, which may complicate DT
> runtime patching.
And that's why I've left it out for now. It's on my to-do list, but I will do
so in a separate patch series. Depending on the complexity I might use runtime
PM for new DTs only and leave the runtime-patched devices trees out.
--
Regards,
Laurent Pinchart
