Re: [PATCH 2/3] drm: rcar-du: DRM_RCAR_USE_LVDS should depend on DRM_RCAR_DU

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Laurent,

On Wed, Dec 15, 2021 at 11:30 AM Laurent Pinchart
<laurent.pinchart@xxxxxxxxxxxxxxxx> wrote:
> On Wed, Dec 15, 2021 at 12:23:39PM +0200, Laurent Pinchart wrote:
> > On Wed, Dec 15, 2021 at 11:17:37AM +0100, Geert Uytterhoeven wrote:
> > > On Wed, Dec 15, 2021 at 11:12 AM Laurent Pinchart wrote:
> > > > On Wed, Dec 15, 2021 at 10:27:46AM +0100, Geert Uytterhoeven wrote:
> > > > > The Renesas R-Car LVDS encoder driver is a subdriver of the R-Car
> > > > > Display Unit driver, and enabling DRM_RCAR_USE_LVDS while DRM_RCAR_DU is
> > > > > disabled doesn't have any impact on the kernel built.  Hence add a
> > > > > dependency on DRM_RCAR_DU, to prevent asking the user about this driver
> > > > > when configuring a kernel without R-Car Display Unit support, like is
> > > > > already done for DRM_RCAR_CMM.
> > > > >
> > > > > Fixes: 42d95d1b3a9c649b ("drm/rcar: stop using 'imply' for dependencies")
> > > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
> > > > > ---
> > > > > The problem pre-existed before commit 42d95d1b3a9c649b, as the
> > > > > dependency of DRM_RCAR_LVDS on DRM_RCAR_DU was accidentally removed
> > > > > before.
> > > > > Fixes: c6a27fa41fabb35f ("drm: rcar-du: Convert LVDS encoder code to bridge driver")
> > > > > ---
> > > > >  drivers/gpu/drm/rcar-du/Kconfig | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
> > > > > index 65d72be50f46f19e..a7aa556e301d1087 100644
> > > > > --- a/drivers/gpu/drm/rcar-du/Kconfig
> > > > > +++ b/drivers/gpu/drm/rcar-du/Kconfig
> > > > > @@ -32,7 +32,7 @@ config DRM_RCAR_DW_HDMI
> > > > >
> > > > >  config DRM_RCAR_USE_LVDS
> > > > >       bool "R-Car DU LVDS Encoder Support"
> > > > > -     depends on DRM_BRIDGE && OF
> > > > > +     depends on DRM_BRIDGE && OF && DRM_RCAR_DU
> > > >
> > > > Shouldn't the same be done for DRM_RCAR_DW_HDMI ? Even better, we could
> > >
> > > DRM_RCAR_DW_HDMI can be enabled and built with CONFIG_COMPILE_TEST=y
> > > and CONFIG_DRM_RCAR_DU=n (yes I've tried on RISC-V ;-)
> >
> > It would seem so indeed, my question is whether that shouldn't be fixed
> > as well.

What is there to fix? You can build the HDMI fine without the DU driver,
when compile-testing.

> > > > wrap all the entries for the subdrivers in a 'if DRM_RCAR_DU'.
> > >
> > > That might work.  It can be tricky with bool/tristate, as sometimes m
> > > is not properly propagated.
> >
> > Would you give it a try for a v2 ?
>
> Another option is to introduce DRM_RCAR_USE_HDMI and DRM_RCAR_USE_DSI.
> I'd like to keep Kconfig consistent, with the same method to handle all
> subdrivers if no specific reason requires doing otherwise.

The HDMI and DSI drivers are separate drivers that can be (test)compiled,
regardless of DRM_RCAR_DU is enabled or not.

The DRM_RCAR_USE_LVDS symbol is different: enabling it does not
have any impact on the kernel build when DRM_RCAR_DU=y.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

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



[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux