All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Ulrich Hecht <ulrich.hecht+renesas@gmail.com>,
	Koji Matsuoka <koji.matsuoka.xm@renesas.com>,
	Arnd Bergmann <arnd@arndb.de>, LUU HOAI <hoai.luu.ub@renesas.com>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH 2/3] drm: rcar-du: DRM_RCAR_USE_LVDS should depend on DRM_RCAR_DU
Date: Wed, 15 Dec 2021 11:47:27 +0100	[thread overview]
Message-ID: <CAMuHMdWkoJ=VFqWhN9fyZcSncdaypSOwG1yNSPN=tsuv=WW=vg@mail.gmail.com> (raw)
In-Reply-To: <YbnD3RwTC9su+8WQ@pendragon.ideasonboard.com>

Hi Laurent,

On Wed, Dec 15, 2021 at 11:30 AM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> 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@glider.be>
> > > > > ---
> > > > > 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@linux-m68k.org

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

WARNING: multiple messages have this Message-ID (diff)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Arnd Bergmann <arnd@arndb.de>, David Airlie <airlied@linux.ie>,
	Koji Matsuoka <koji.matsuoka.xm@renesas.com>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>,
	Ulrich Hecht <ulrich.hecht+renesas@gmail.com>,
	LUU HOAI <hoai.luu.ub@renesas.com>
Subject: Re: [PATCH 2/3] drm: rcar-du: DRM_RCAR_USE_LVDS should depend on DRM_RCAR_DU
Date: Wed, 15 Dec 2021 11:47:27 +0100	[thread overview]
Message-ID: <CAMuHMdWkoJ=VFqWhN9fyZcSncdaypSOwG1yNSPN=tsuv=WW=vg@mail.gmail.com> (raw)
In-Reply-To: <YbnD3RwTC9su+8WQ@pendragon.ideasonboard.com>

Hi Laurent,

On Wed, Dec 15, 2021 at 11:30 AM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> 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@glider.be>
> > > > > ---
> > > > > 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@linux-m68k.org

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

  reply	other threads:[~2021-12-15 10:47 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-15  9:27 [PATCH 0/3] drm: rcar-du: Add missing dependencies Geert Uytterhoeven
2021-12-15  9:27 ` Geert Uytterhoeven
2021-12-15  9:27 ` [PATCH 1/3] drm: rcar-du: DRM_RCAR_DW_HDMI should depend on ARCH_RENESAS Geert Uytterhoeven
2021-12-15  9:27   ` Geert Uytterhoeven
2021-12-15 10:24   ` Laurent Pinchart
2021-12-15 10:24     ` Laurent Pinchart
2021-12-15 10:48     ` Geert Uytterhoeven
2021-12-15 10:48       ` Geert Uytterhoeven
2021-12-15  9:27 ` [PATCH 2/3] drm: rcar-du: DRM_RCAR_USE_LVDS should depend on DRM_RCAR_DU Geert Uytterhoeven
2021-12-15  9:27   ` Geert Uytterhoeven
2021-12-15 10:12   ` Laurent Pinchart
2021-12-15 10:12     ` Laurent Pinchart
2021-12-15 10:17     ` Geert Uytterhoeven
2021-12-15 10:17       ` Geert Uytterhoeven
2021-12-15 10:23       ` Laurent Pinchart
2021-12-15 10:23         ` Laurent Pinchart
2021-12-15 10:30         ` Laurent Pinchart
2021-12-15 10:30           ` Laurent Pinchart
2021-12-15 10:47           ` Geert Uytterhoeven [this message]
2021-12-15 10:47             ` Geert Uytterhoeven
2021-12-15 11:02             ` Laurent Pinchart
2021-12-15 11:02               ` Laurent Pinchart
2021-12-15 13:34               ` Geert Uytterhoeven
2021-12-15 13:34                 ` Geert Uytterhoeven
2021-12-15  9:27 ` [PATCH 3/3] drm: rcar-du: DRM_RCAR_MIPI_DSI should depend on ARCH_RENESAS Geert Uytterhoeven
2021-12-15  9:27   ` Geert Uytterhoeven
2021-12-15 10:25   ` Laurent Pinchart
2021-12-15 10:25     ` Laurent Pinchart
2021-12-15 10:29     ` Laurent Pinchart
2021-12-15 10:29       ` Laurent Pinchart
2021-12-15  9:42 ` [PATCH 0/3] drm: rcar-du: Add missing dependencies Laurent Pinchart
2021-12-15  9:42   ` Laurent Pinchart
2021-12-15 10:12   ` Geert Uytterhoeven
2021-12-15 10:12     ` Geert Uytterhoeven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMuHMdWkoJ=VFqWhN9fyZcSncdaypSOwG1yNSPN=tsuv=WW=vg@mail.gmail.com' \
    --to=geert@linux-m68k.org \
    --cc=airlied@linux.ie \
    --cc=arnd@arndb.de \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hoai.luu.ub@renesas.com \
    --cc=kieran.bingham+renesas@ideasonboard.com \
    --cc=koji.matsuoka.xm@renesas.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=ulrich.hecht+renesas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.