From: Geert Uytterhoeven <geert@linux-m68k.org> To: Arnd Bergmann <arnd@arndb.de> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Masahiro Yamada <masahiroy@kernel.org>, Nicolas Pitre <nico@fluxnic.net>, Andrzej Hajda <a.hajda@samsung.com>, Neil Armstrong <narmstrong@baylibre.com>, Jonas Karlman <jonas@kwiboo.se>, Jernej Skrabec <jernej.skrabec@siol.net>, David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>, Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>, "David S. Miller" <davem@davemloft.net>, Saeed Mahameed <saeedm@mellanox.com>, Leon Romanovsky <leon@kernel.org>, dri-devel <dri-devel@lists.freedesktop.org>, Linux-Renesas <linux-renesas-soc@vger.kernel.org>, Networking <netdev@vger.kernel.org>, linux-rdma <linux-rdma@vger.kernel.org> Subject: Re: [RFC 5/6] drm/rcar-du: fix selection of CMM driver Date: Wed, 15 Apr 2020 16:13:27 +0200 [thread overview] Message-ID: <CAMuHMdUb=XXucGUbxt26tZ1xu9pdyVUB8RVsfB2SffURVVXwSg@mail.gmail.com> (raw) In-Reply-To: <CAK8P3a1PZbwdvdH_Gi9UQVUz2+_a8QDxKuWLqPtjhK1stxzMBQ@mail.gmail.com> Hi Arnd, On Wed, Apr 15, 2020 at 3:47 PM Arnd Bergmann <arnd@arndb.de> wrote: > On Tue, Apr 14, 2020 at 10:52 PM Laurent Pinchart > <laurent.pinchart@ideasonboard.com> wrote: > > On Tue, Apr 14, 2020 at 10:38:27PM +0200, Arnd Bergmann wrote: > > > On Tue, Apr 14, 2020 at 10:17 PM Laurent Pinchart wrote: > > > > On Wed, Apr 08, 2020 at 10:27:10PM +0200, Arnd Bergmann wrote: > > > > > The 'imply' statement does not seem to have an effect, as it's > > > > > still possible to turn the CMM code into a loadable module > > > > > in a randconfig build, leading to a link error: > > > > > > > > > > arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_enable': > > > > > rcar_du_crtc.c:(.text+0xad4): undefined reference to `rcar_lvds_clk_enable' > > > > > arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_disable': > > > > > rcar_du_crtc.c:(.text+0xd7c): undefined reference to `rcar_lvds_clk_disable' > > > > > arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_drv.o: in function `rcar_du_init': > > > > > rcar_du_drv.c:(.init.text+0x4): undefined reference to `rcar_du_of_init' > > > > > arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_encoder.o: in function `rcar_du_encoder_init': > > > > > > > > > > Remove the 'imply', and instead use a silent symbol that defaults > > > > > to the correct setting. > > > > > > > > This will result in the CMM always being selected when DU is, increasing > > > > the kernel size even for devices that don't need it. I believe we need a > > > > better construct in Kconfig to fix this. > > > > > > I had expected this to have the same meaning that we had before the > > > Kconfig change: whenever the dependencies are available, turn it on, > > > otherwise leave it disabled. > > > > > > Can you describe what behavior you actually want instead? > > > > Doesn't "imply" mean it gets selected by default but can be manually > > disabled ? > > That may be what it means now (I still don't understand how it's defined > as of v5.7-rc1), but traditionally it was more like a 'select if all > dependencies are met'. That's still what it is supposed to mean right now ;-) Except that now it should correctly handle the modular case, too. > > > > > --- a/drivers/gpu/drm/rcar-du/Kconfig > > > > > +++ b/drivers/gpu/drm/rcar-du/Kconfig > > > > > @@ -4,7 +4,6 @@ config DRM_RCAR_DU > > > > > depends on DRM && OF > > > > > depends on ARM || ARM64 > > > > > depends on ARCH_RENESAS || COMPILE_TEST > > > > > - imply DRM_RCAR_CMM > > > > > imply DRM_RCAR_LVDS > > > > > select DRM_KMS_HELPER > > > > > select DRM_KMS_CMA_HELPER > > > > > @@ -15,9 +14,8 @@ config DRM_RCAR_DU > > > > > If M is selected the module will be called rcar-du-drm. > > > > > > > > > > config DRM_RCAR_CMM > > > > > - tristate "R-Car DU Color Management Module (CMM) Support" > > > > > + def_tristate DRM_RCAR_DU > > > > > depends on DRM && OF > > > > > - depends on DRM_RCAR_DU > > > > > help > > > > > > It would be easy enough to make this a visible 'bool' symbol and > > > build it into the rcu-du-drm.ko module itself. Would that help you? > > > > That could indeed simplify a few things. I wonder if it could introduce > > a few small issues though (but likely nothing we can't fix). The two > > that come to mind are the fact that the module would have two > > MODULE_DESCRIPTION and MODULE_LICENSE entries (I have no idea if that > > could cause breakages), and that it could make module unloading more > > difficult as the CMM being used by the DU would increase the refcount on > > the module. I think the latter could be worked around by manually > > unbinding the DU device through sysfs before unloading the module (and I > > can't say for sure that unloading the DU module is not broken today > > *innocent and naive look* :-)). > > In that case, a Makefile trick could also work, doing > > ifdef CONFIG_DRM_RCAR_CMM > obj-$(CONFIG_DRM_RCAR_DU) += rcar-cmm.o > endif > > Thereby making the cmm module have the same state (y or m) as > the du module whenever the option is enabled. What about dropping the "imply DRM_RCAR_CMM", but defaulting to enable CMM if DU is enabled? config DRM_RCAR_CMM tristate "R-Car DU Color Management Module (CMM) Support" depends on DRM_RCAR_DU && OF default DRM_RCAR_DU 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: Arnd Bergmann <arnd@arndb.de> Cc: Jernej Skrabec <jernej.skrabec@siol.net>, Leon Romanovsky <leon@kernel.org>, Neil Armstrong <narmstrong@baylibre.com>, David Airlie <airlied@linux.ie>, Networking <netdev@vger.kernel.org>, Masahiro Yamada <masahiroy@kernel.org>, Nicolas Pitre <nico@fluxnic.net>, Saeed Mahameed <saeedm@mellanox.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, dri-devel <dri-devel@lists.freedesktop.org>, Linux-Renesas <linux-renesas-soc@vger.kernel.org>, Andrzej Hajda <a.hajda@samsung.com>, Jonas Karlman <jonas@kwiboo.se>, Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, "David S. Miller" <davem@davemloft.net>, linux-rdma <linux-rdma@vger.kernel.org> Subject: Re: [RFC 5/6] drm/rcar-du: fix selection of CMM driver Date: Wed, 15 Apr 2020 16:13:27 +0200 [thread overview] Message-ID: <CAMuHMdUb=XXucGUbxt26tZ1xu9pdyVUB8RVsfB2SffURVVXwSg@mail.gmail.com> (raw) In-Reply-To: <CAK8P3a1PZbwdvdH_Gi9UQVUz2+_a8QDxKuWLqPtjhK1stxzMBQ@mail.gmail.com> Hi Arnd, On Wed, Apr 15, 2020 at 3:47 PM Arnd Bergmann <arnd@arndb.de> wrote: > On Tue, Apr 14, 2020 at 10:52 PM Laurent Pinchart > <laurent.pinchart@ideasonboard.com> wrote: > > On Tue, Apr 14, 2020 at 10:38:27PM +0200, Arnd Bergmann wrote: > > > On Tue, Apr 14, 2020 at 10:17 PM Laurent Pinchart wrote: > > > > On Wed, Apr 08, 2020 at 10:27:10PM +0200, Arnd Bergmann wrote: > > > > > The 'imply' statement does not seem to have an effect, as it's > > > > > still possible to turn the CMM code into a loadable module > > > > > in a randconfig build, leading to a link error: > > > > > > > > > > arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_enable': > > > > > rcar_du_crtc.c:(.text+0xad4): undefined reference to `rcar_lvds_clk_enable' > > > > > arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_disable': > > > > > rcar_du_crtc.c:(.text+0xd7c): undefined reference to `rcar_lvds_clk_disable' > > > > > arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_drv.o: in function `rcar_du_init': > > > > > rcar_du_drv.c:(.init.text+0x4): undefined reference to `rcar_du_of_init' > > > > > arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_encoder.o: in function `rcar_du_encoder_init': > > > > > > > > > > Remove the 'imply', and instead use a silent symbol that defaults > > > > > to the correct setting. > > > > > > > > This will result in the CMM always being selected when DU is, increasing > > > > the kernel size even for devices that don't need it. I believe we need a > > > > better construct in Kconfig to fix this. > > > > > > I had expected this to have the same meaning that we had before the > > > Kconfig change: whenever the dependencies are available, turn it on, > > > otherwise leave it disabled. > > > > > > Can you describe what behavior you actually want instead? > > > > Doesn't "imply" mean it gets selected by default but can be manually > > disabled ? > > That may be what it means now (I still don't understand how it's defined > as of v5.7-rc1), but traditionally it was more like a 'select if all > dependencies are met'. That's still what it is supposed to mean right now ;-) Except that now it should correctly handle the modular case, too. > > > > > --- a/drivers/gpu/drm/rcar-du/Kconfig > > > > > +++ b/drivers/gpu/drm/rcar-du/Kconfig > > > > > @@ -4,7 +4,6 @@ config DRM_RCAR_DU > > > > > depends on DRM && OF > > > > > depends on ARM || ARM64 > > > > > depends on ARCH_RENESAS || COMPILE_TEST > > > > > - imply DRM_RCAR_CMM > > > > > imply DRM_RCAR_LVDS > > > > > select DRM_KMS_HELPER > > > > > select DRM_KMS_CMA_HELPER > > > > > @@ -15,9 +14,8 @@ config DRM_RCAR_DU > > > > > If M is selected the module will be called rcar-du-drm. > > > > > > > > > > config DRM_RCAR_CMM > > > > > - tristate "R-Car DU Color Management Module (CMM) Support" > > > > > + def_tristate DRM_RCAR_DU > > > > > depends on DRM && OF > > > > > - depends on DRM_RCAR_DU > > > > > help > > > > > > It would be easy enough to make this a visible 'bool' symbol and > > > build it into the rcu-du-drm.ko module itself. Would that help you? > > > > That could indeed simplify a few things. I wonder if it could introduce > > a few small issues though (but likely nothing we can't fix). The two > > that come to mind are the fact that the module would have two > > MODULE_DESCRIPTION and MODULE_LICENSE entries (I have no idea if that > > could cause breakages), and that it could make module unloading more > > difficult as the CMM being used by the DU would increase the refcount on > > the module. I think the latter could be worked around by manually > > unbinding the DU device through sysfs before unloading the module (and I > > can't say for sure that unloading the DU module is not broken today > > *innocent and naive look* :-)). > > In that case, a Makefile trick could also work, doing > > ifdef CONFIG_DRM_RCAR_CMM > obj-$(CONFIG_DRM_RCAR_DU) += rcar-cmm.o > endif > > Thereby making the cmm module have the same state (y or m) as > the du module whenever the option is enabled. What about dropping the "imply DRM_RCAR_CMM", but defaulting to enable CMM if DU is enabled? config DRM_RCAR_CMM tristate "R-Car DU Color Management Module (CMM) Support" depends on DRM_RCAR_DU && OF default DRM_RCAR_DU 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-04-15 14:13 UTC|newest] Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-08 20:27 [RFC 0/6] Regressions for "imply" behavior change Arnd Bergmann 2020-04-08 20:27 ` Arnd Bergmann 2020-04-08 20:27 ` [RFC 1/6] thunder: select PTP driver if possible Arnd Bergmann 2020-04-08 20:27 ` Arnd Bergmann 2020-04-08 20:27 ` [RFC 2/6] net/mlx5e: fix VXLAN dependency Arnd Bergmann 2020-04-08 20:27 ` Arnd Bergmann 2020-04-08 20:27 ` [RFC 3/6] LiquidIO VF: add dependency for PTP_1588_CLOCK Arnd Bergmann 2020-04-08 20:27 ` Arnd Bergmann 2020-04-08 21:10 ` kbuild test robot 2020-04-08 21:13 ` Arnd Bergmann 2020-04-08 20:27 ` [RFC 4/6] drm/bridge/sii8620: fix extcon dependency Arnd Bergmann 2020-04-08 20:27 ` Arnd Bergmann 2020-04-10 6:56 ` Andrzej Hajda 2020-04-10 6:56 ` Andrzej Hajda 2020-04-14 15:04 ` Arnd Bergmann 2020-04-14 15:04 ` Arnd Bergmann 2020-04-14 15:37 ` Daniel Vetter 2020-04-14 15:37 ` Daniel Vetter 2020-04-15 6:58 ` Jani Nikula 2020-04-15 6:58 ` Jani Nikula 2020-04-08 20:27 ` [RFC 5/6] drm/rcar-du: fix selection of CMM driver Arnd Bergmann 2020-04-08 20:27 ` Arnd Bergmann 2020-04-14 20:17 ` Laurent Pinchart 2020-04-14 20:17 ` Laurent Pinchart 2020-04-14 20:38 ` Arnd Bergmann 2020-04-14 20:38 ` Arnd Bergmann 2020-04-14 20:51 ` Laurent Pinchart 2020-04-14 20:51 ` Laurent Pinchart 2020-04-14 21:10 ` Arnd Bergmann 2020-04-14 21:10 ` Arnd Bergmann 2020-04-15 14:13 ` Geert Uytterhoeven [this message] 2020-04-15 14:13 ` Geert Uytterhoeven 2020-04-15 15:18 ` Arnd Bergmann 2020-04-15 15:18 ` Arnd Bergmann 2020-04-15 19:07 ` Arnd Bergmann 2020-04-15 19:07 ` Arnd Bergmann 2020-04-15 21:12 ` Laurent Pinchart 2020-04-15 21:12 ` Laurent Pinchart 2020-04-15 21:22 ` Arnd Bergmann 2020-04-15 21:22 ` Arnd Bergmann 2020-04-16 6:51 ` Daniel Vetter 2020-04-16 6:51 ` Daniel Vetter 2020-04-16 15:17 ` Laurent Pinchart 2020-04-16 15:17 ` Laurent Pinchart 2020-04-08 20:27 ` [RFC 6/6] drm/rcar-du: fix lvds dependency Arnd Bergmann 2020-04-08 20:27 ` Arnd Bergmann 2020-04-08 20:38 ` [RFC 0/6] Regressions for "imply" behavior change Nicolas Pitre 2020-04-08 20:38 ` Nicolas Pitre 2020-04-08 20:46 ` Saeed Mahameed 2020-04-08 20:46 ` Saeed Mahameed 2020-04-08 20:49 ` Arnd Bergmann 2020-04-08 20:49 ` Arnd Bergmann 2020-04-08 21:17 ` Nicolas Pitre 2020-04-08 21:17 ` Nicolas Pitre 2020-04-08 22:42 ` Jason Gunthorpe 2020-04-08 22:42 ` Jason Gunthorpe 2020-04-09 8:41 ` Jani Nikula 2020-04-09 8:41 ` Jani Nikula 2020-04-10 2:40 ` Saeed Mahameed 2020-04-10 2:40 ` Saeed Mahameed 2020-04-10 7:26 ` Geert Uytterhoeven 2020-04-10 7:26 ` Geert Uytterhoeven 2020-04-10 17:13 ` Jason Gunthorpe 2020-04-10 17:13 ` Jason Gunthorpe 2020-04-10 19:04 ` Saeed Mahameed 2020-04-10 19:04 ` Saeed Mahameed 2020-04-14 13:29 ` Jason Gunthorpe 2020-04-14 13:29 ` Jason Gunthorpe 2020-04-14 14:27 ` Arnd Bergmann 2020-04-14 14:27 ` Arnd Bergmann 2020-04-14 15:23 ` Jason Gunthorpe 2020-04-14 15:23 ` Jason Gunthorpe 2020-04-14 15:25 ` Arnd Bergmann 2020-04-14 15:25 ` Arnd Bergmann 2020-04-14 17:49 ` Saeed Mahameed 2020-04-14 17:49 ` Saeed Mahameed 2020-04-14 18:47 ` Arnd Bergmann 2020-04-14 18:47 ` Arnd Bergmann 2020-04-16 3:25 ` Saeed Mahameed 2020-04-16 3:25 ` Saeed Mahameed 2020-04-16 7:20 ` Arnd Bergmann 2020-04-16 7:20 ` Arnd Bergmann 2020-04-16 10:17 ` Jani Nikula 2020-04-16 10:17 ` Jani Nikula 2020-04-16 12:38 ` Arnd Bergmann 2020-04-16 12:38 ` Arnd Bergmann 2020-04-16 14:52 ` Jason Gunthorpe 2020-04-16 14:52 ` Jason Gunthorpe 2020-04-16 15:58 ` Arnd Bergmann 2020-04-16 15:58 ` Arnd Bergmann 2020-04-16 18:05 ` Jason Gunthorpe 2020-04-16 18:05 ` Jason Gunthorpe 2020-04-16 18:38 ` Saeed Mahameed 2020-04-16 18:38 ` Saeed Mahameed 2020-04-16 15:12 ` Nicolas Pitre 2020-04-16 15:12 ` Nicolas Pitre 2020-04-16 18:21 ` Jason Gunthorpe 2020-04-16 18:21 ` Jason Gunthorpe 2020-04-16 19:56 ` Andrzej Hajda 2020-04-16 19:56 ` Andrzej Hajda
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='CAMuHMdUb=XXucGUbxt26tZ1xu9pdyVUB8RVsfB2SffURVVXwSg@mail.gmail.com' \ --to=geert@linux-m68k.org \ --cc=a.hajda@samsung.com \ --cc=airlied@linux.ie \ --cc=arnd@arndb.de \ --cc=daniel@ffwll.ch \ --cc=davem@davemloft.net \ --cc=dri-devel@lists.freedesktop.org \ --cc=jernej.skrabec@siol.net \ --cc=jonas@kwiboo.se \ --cc=kieran.bingham+renesas@ideasonboard.com \ --cc=laurent.pinchart@ideasonboard.com \ --cc=leon@kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-rdma@vger.kernel.org \ --cc=linux-renesas-soc@vger.kernel.org \ --cc=masahiroy@kernel.org \ --cc=narmstrong@baylibre.com \ --cc=netdev@vger.kernel.org \ --cc=nico@fluxnic.net \ --cc=saeedm@mellanox.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: linkBe 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.