All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	Mauro Carvalho Chehab <mchehab@infradead.org>,
	dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
	Tomi Valkeinen <tomi.valkeinen@ti.com>
Subject: Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP
Date: Mon, 23 Apr 2018 17:09:55 -0300	[thread overview]
Message-ID: <20180423170955.13421017@vento.lan> (raw)
In-Reply-To: <2458408.nymfr4Soza@avalon>

Em Mon, 23 Apr 2018 22:48:06 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:

> Hi Mauro,
> 
> On Monday, 23 April 2018 17:22:27 EEST Mauro Carvalho Chehab wrote:
> > Em Mon, 23 Apr 2018 15:56:53 +0200 Bartlomiej Zolnierkiewicz escreveu:  
> > > On Monday, April 23, 2018 02:47:28 PM Bartlomiej Zolnierkiewicz wrote:  
> > >> On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:  
> > >>> Add stubs for omapfb_dss.h, in the case it is included by
> > >>> some driver when CONFIG_FB_OMAP2 is not defined, with can
> > >>> happen on ARM when DRM_OMAP is not 'n'.
> > >>> 
> > >>> That allows building such driver(s) with COMPILE_TEST.
> > >>> 
> > >>> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>  
> > >> 
> > >> This patch should be dropped (together with patch #6/7) as it was
> > >> superseded by a better solution suggested by Laurent:
> > >> 
> > >> https://patchwork.kernel.org/patch/10325193/
> > >> 
> > >> ACK-ed by Tomi:
> > >> 
> > >> https://www.spinics.net/lists/dri-devel/msg171918.html
> > >> 
> > >> and already merged by you (commit 7378f1149884 "media: omap2:
> > >> omapfb: allow building it with COMPILE_TEST")..  
> > > 
> > > Hmm, I see now while this patch is still included:
> > > 
> > > menuconfig FB_OMAP2
> > >         tristate "OMAP2+ frame buffer support"
> > >         depends on FB
> > >         depends on DRM_OMAP = n
> > > 
> > > Ideally we should be able to build both drivers in the same kernel
> > > (especially as modules).
> > > 
> > > I was hoping that it could be fixed easily but then I discovered
> > > the root source of the problem:
> > > 
> > > drivers/gpu/drm/omapdrm/dss/display.o: In function
> > > `omapdss_unregister_display': display.c:(.text+0x2c): multiple definition
> > > of `omapdss_unregister_display'
> > > drivers/video/fbdev/omap2/omapfb/dss/display.o:display.c:(.text+0x198):
> > > first defined here ...  
> > 
> > Yes, and declared on two different places:
> > 
> > drivers/gpu/drm/omapdrm/dss/omapdss.h:void omapdss_unregister_display(struct
> > omap_dss_device *dssdev); include/video/omapfb_dss.h:void
> > omapdss_unregister_display(struct omap_dss_device *dssdev);
> > 
> > one alternative would be to give different names to it, and a common
> > header for both.
> > 
> > At such header, it could be doing something like:
> > 
> > static inline void omapdss_unregister_display(struct omap_dss_device
> > *dssdev) {
> > #if enabled(CONFIG_DRM_OMAP)
> > 	omapdss_unregister_display_drm(struct omap_dss_device *dssdev);
> > #else
> > 	omapdss_unregister_display_fb(struct omap_dss_device *dssdev);
> > ##endif
> > }
> > 
> > Yet, after a very quick check, it seems that nowadays only the
> > media omap driver uses the symbols at FB_OMAP:
> > 
> > $ git grep omapfb_dss.h
> > drivers/media/platform/omap/omap_vout.c:#include <video/omapfb_dss.h>
> > drivers/media/platform/omap/omap_voutdef.h:#include <video/omapfb_dss.h>
> > drivers/media/platform/omap/omap_voutlib.c:#include <video/omapfb_dss.h>
> > 
> > So, perhaps just renaming the common symbols and changing FB_OMAP2 to:
> > 
> > 	menuconfig FB_OMAP2
> > 	         tristate "OMAP2+ frame buffer support"
> > 	         depends on FB
> > 	         depends on (DRM_OMAP = n) || COMPILE_TEST
> > 
> > would be enough to allow to build both on ARM.  
> 
> I don't think it's worth it renaming the common symbols. They will change over 
> time as omapdrm is under heavy rework, and it's painful enough without having 
> to handle cross-tree changes.

It could just rename the namespace-conflicting FB_OMAP2 functions,
keeping the DRM ones as-is.

> Let's just live with the fact that both drivers 
> can't be compiled at the same time, given that omapfb is deprecated.

IMO, a driver that it is deprecated, being in a state where it
conflicts with a non-deprecated driver that is under heavy rework
is a very good candidate to go to drivers/staging or even to /dev/null.

Thanks,
Mauro

WARNING: multiple messages have this Message-ID (diff)
From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: linux-fbdev@vger.kernel.org,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	dri-devel@lists.freedesktop.org,
	Mauro Carvalho Chehab <mchehab@infradead.org>,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP
Date: Mon, 23 Apr 2018 20:09:55 +0000	[thread overview]
Message-ID: <20180423170955.13421017@vento.lan> (raw)
In-Reply-To: <2458408.nymfr4Soza@avalon>

Em Mon, 23 Apr 2018 22:48:06 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:

> Hi Mauro,
> 
> On Monday, 23 April 2018 17:22:27 EEST Mauro Carvalho Chehab wrote:
> > Em Mon, 23 Apr 2018 15:56:53 +0200 Bartlomiej Zolnierkiewicz escreveu:  
> > > On Monday, April 23, 2018 02:47:28 PM Bartlomiej Zolnierkiewicz wrote:  
> > >> On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:  
> > >>> Add stubs for omapfb_dss.h, in the case it is included by
> > >>> some driver when CONFIG_FB_OMAP2 is not defined, with can
> > >>> happen on ARM when DRM_OMAP is not 'n'.
> > >>> 
> > >>> That allows building such driver(s) with COMPILE_TEST.
> > >>> 
> > >>> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>  
> > >> 
> > >> This patch should be dropped (together with patch #6/7) as it was
> > >> superseded by a better solution suggested by Laurent:
> > >> 
> > >> https://patchwork.kernel.org/patch/10325193/
> > >> 
> > >> ACK-ed by Tomi:
> > >> 
> > >> https://www.spinics.net/lists/dri-devel/msg171918.html
> > >> 
> > >> and already merged by you (commit 7378f1149884 "media: omap2:
> > >> omapfb: allow building it with COMPILE_TEST")..  
> > > 
> > > Hmm, I see now while this patch is still included:
> > > 
> > > menuconfig FB_OMAP2
> > >         tristate "OMAP2+ frame buffer support"
> > >         depends on FB
> > >         depends on DRM_OMAP = n
> > > 
> > > Ideally we should be able to build both drivers in the same kernel
> > > (especially as modules).
> > > 
> > > I was hoping that it could be fixed easily but then I discovered
> > > the root source of the problem:
> > > 
> > > drivers/gpu/drm/omapdrm/dss/display.o: In function
> > > `omapdss_unregister_display': display.c:(.text+0x2c): multiple definition
> > > of `omapdss_unregister_display'
> > > drivers/video/fbdev/omap2/omapfb/dss/display.o:display.c:(.text+0x198):
> > > first defined here ...  
> > 
> > Yes, and declared on two different places:
> > 
> > drivers/gpu/drm/omapdrm/dss/omapdss.h:void omapdss_unregister_display(struct
> > omap_dss_device *dssdev); include/video/omapfb_dss.h:void
> > omapdss_unregister_display(struct omap_dss_device *dssdev);
> > 
> > one alternative would be to give different names to it, and a common
> > header for both.
> > 
> > At such header, it could be doing something like:
> > 
> > static inline void omapdss_unregister_display(struct omap_dss_device
> > *dssdev) {
> > #if enabled(CONFIG_DRM_OMAP)
> > 	omapdss_unregister_display_drm(struct omap_dss_device *dssdev);
> > #else
> > 	omapdss_unregister_display_fb(struct omap_dss_device *dssdev);
> > ##endif
> > }
> > 
> > Yet, after a very quick check, it seems that nowadays only the
> > media omap driver uses the symbols at FB_OMAP:
> > 
> > $ git grep omapfb_dss.h
> > drivers/media/platform/omap/omap_vout.c:#include <video/omapfb_dss.h>
> > drivers/media/platform/omap/omap_voutdef.h:#include <video/omapfb_dss.h>
> > drivers/media/platform/omap/omap_voutlib.c:#include <video/omapfb_dss.h>
> > 
> > So, perhaps just renaming the common symbols and changing FB_OMAP2 to:
> > 
> > 	menuconfig FB_OMAP2
> > 	         tristate "OMAP2+ frame buffer support"
> > 	         depends on FB
> > 	         depends on (DRM_OMAP = n) || COMPILE_TEST
> > 
> > would be enough to allow to build both on ARM.  
> 
> I don't think it's worth it renaming the common symbols. They will change over 
> time as omapdrm is under heavy rework, and it's painful enough without having 
> to handle cross-tree changes.

It could just rename the namespace-conflicting FB_OMAP2 functions,
keeping the DRM ones as-is.

> Let's just live with the fact that both drivers 
> can't be compiled at the same time, given that omapfb is deprecated.

IMO, a driver that it is deprecated, being in a state where it
conflicts with a non-deprecated driver that is under heavy rework
is a very good candidate to go to drivers/staging or even to /dev/null.

Thanks,
Mauro

WARNING: multiple messages have this Message-ID (diff)
From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: linux-fbdev@vger.kernel.org,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	dri-devel@lists.freedesktop.org,
	Mauro Carvalho Chehab <mchehab@infradead.org>,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP
Date: Mon, 23 Apr 2018 17:09:55 -0300	[thread overview]
Message-ID: <20180423170955.13421017@vento.lan> (raw)
In-Reply-To: <2458408.nymfr4Soza@avalon>

Em Mon, 23 Apr 2018 22:48:06 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:

> Hi Mauro,
> 
> On Monday, 23 April 2018 17:22:27 EEST Mauro Carvalho Chehab wrote:
> > Em Mon, 23 Apr 2018 15:56:53 +0200 Bartlomiej Zolnierkiewicz escreveu:  
> > > On Monday, April 23, 2018 02:47:28 PM Bartlomiej Zolnierkiewicz wrote:  
> > >> On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:  
> > >>> Add stubs for omapfb_dss.h, in the case it is included by
> > >>> some driver when CONFIG_FB_OMAP2 is not defined, with can
> > >>> happen on ARM when DRM_OMAP is not 'n'.
> > >>> 
> > >>> That allows building such driver(s) with COMPILE_TEST.
> > >>> 
> > >>> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>  
> > >> 
> > >> This patch should be dropped (together with patch #6/7) as it was
> > >> superseded by a better solution suggested by Laurent:
> > >> 
> > >> https://patchwork.kernel.org/patch/10325193/
> > >> 
> > >> ACK-ed by Tomi:
> > >> 
> > >> https://www.spinics.net/lists/dri-devel/msg171918.html
> > >> 
> > >> and already merged by you (commit 7378f1149884 "media: omap2:
> > >> omapfb: allow building it with COMPILE_TEST")..  
> > > 
> > > Hmm, I see now while this patch is still included:
> > > 
> > > menuconfig FB_OMAP2
> > >         tristate "OMAP2+ frame buffer support"
> > >         depends on FB
> > >         depends on DRM_OMAP = n
> > > 
> > > Ideally we should be able to build both drivers in the same kernel
> > > (especially as modules).
> > > 
> > > I was hoping that it could be fixed easily but then I discovered
> > > the root source of the problem:
> > > 
> > > drivers/gpu/drm/omapdrm/dss/display.o: In function
> > > `omapdss_unregister_display': display.c:(.text+0x2c): multiple definition
> > > of `omapdss_unregister_display'
> > > drivers/video/fbdev/omap2/omapfb/dss/display.o:display.c:(.text+0x198):
> > > first defined here ...  
> > 
> > Yes, and declared on two different places:
> > 
> > drivers/gpu/drm/omapdrm/dss/omapdss.h:void omapdss_unregister_display(struct
> > omap_dss_device *dssdev); include/video/omapfb_dss.h:void
> > omapdss_unregister_display(struct omap_dss_device *dssdev);
> > 
> > one alternative would be to give different names to it, and a common
> > header for both.
> > 
> > At such header, it could be doing something like:
> > 
> > static inline void omapdss_unregister_display(struct omap_dss_device
> > *dssdev) {
> > #if enabled(CONFIG_DRM_OMAP)
> > 	omapdss_unregister_display_drm(struct omap_dss_device *dssdev);
> > #else
> > 	omapdss_unregister_display_fb(struct omap_dss_device *dssdev);
> > ##endif
> > }
> > 
> > Yet, after a very quick check, it seems that nowadays only the
> > media omap driver uses the symbols at FB_OMAP:
> > 
> > $ git grep omapfb_dss.h
> > drivers/media/platform/omap/omap_vout.c:#include <video/omapfb_dss.h>
> > drivers/media/platform/omap/omap_voutdef.h:#include <video/omapfb_dss.h>
> > drivers/media/platform/omap/omap_voutlib.c:#include <video/omapfb_dss.h>
> > 
> > So, perhaps just renaming the common symbols and changing FB_OMAP2 to:
> > 
> > 	menuconfig FB_OMAP2
> > 	         tristate "OMAP2+ frame buffer support"
> > 	         depends on FB
> > 	         depends on (DRM_OMAP = n) || COMPILE_TEST
> > 
> > would be enough to allow to build both on ARM.  
> 
> I don't think it's worth it renaming the common symbols. They will change over 
> time as omapdrm is under heavy rework, and it's painful enough without having 
> to handle cross-tree changes.

It could just rename the namespace-conflicting FB_OMAP2 functions,
keeping the DRM ones as-is.

> Let's just live with the fact that both drivers 
> can't be compiled at the same time, given that omapfb is deprecated.

IMO, a driver that it is deprecated, being in a state where it
conflicts with a non-deprecated driver that is under heavy rework
is a very good candidate to go to drivers/staging or even to /dev/null.

Thanks,
Mauro
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2018-04-23 20:10 UTC|newest]

Thread overview: 94+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-20 17:42 [PATCH 0/7] Enable most media drivers to build on ARM Mauro Carvalho Chehab
2018-04-20 17:42 ` Mauro Carvalho Chehab
2018-04-20 17:42 ` Mauro Carvalho Chehab
2018-04-20 17:42 ` Mauro Carvalho Chehab
2018-04-20 17:42 ` [PATCH 1/7] asm-generic, media: allow COMPILE_TEST with virt_to_bus Mauro Carvalho Chehab
2018-04-20 17:42   ` Mauro Carvalho Chehab
2018-04-24  7:33   ` Geert Uytterhoeven
2018-04-24  7:33     ` Geert Uytterhoeven
2018-04-24  7:55   ` Arnd Bergmann
2018-04-24  7:55     ` Arnd Bergmann
2018-04-24 10:25     ` Mauro Carvalho Chehab
2018-04-24 10:25       ` Mauro Carvalho Chehab
2018-04-20 17:42 ` [PATCH 2/7] media: meye: allow building it with COMPILE_TEST on non-x86 Mauro Carvalho Chehab
2018-04-22 18:12   ` Andy Shevchenko
2018-05-04 14:12     ` [PATCH 2/7 v2] " Mauro Carvalho Chehab
2018-04-20 17:42 ` [PATCH 3/7] media: rc: allow build pnp-dependent drivers with COMPILE_TEST Mauro Carvalho Chehab
2018-04-23  8:56   ` Sean Young
2018-04-20 17:42 ` [PATCH 4/7] media: ipu3: allow building it with COMPILE_TEST on non-x86 archs Mauro Carvalho Chehab
2018-04-23 20:32   ` Sakari Ailus
2018-04-20 17:42 ` [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP Mauro Carvalho Chehab
2018-04-20 17:42   ` Mauro Carvalho Chehab
2018-04-20 17:42   ` Mauro Carvalho Chehab
2018-04-23 12:47   ` Bartlomiej Zolnierkiewicz
2018-04-23 12:47     ` Bartlomiej Zolnierkiewicz
2018-04-23 12:47     ` Bartlomiej Zolnierkiewicz
2018-04-23 13:55     ` Mauro Carvalho Chehab
2018-04-23 13:55       ` Mauro Carvalho Chehab
2018-04-23 13:55       ` Mauro Carvalho Chehab
     [not found]       ` <CGME20180425104736eucas1p1b448ce1c188b661c5e743217511110d7@eucas1p1.samsung.com>
2018-04-25 10:47         ` Bartlomiej Zolnierkiewicz
2018-04-25 10:47           ` Bartlomiej Zolnierkiewicz
2018-04-25 10:47           ` Bartlomiej Zolnierkiewicz
2018-05-04 13:52           ` Mauro Carvalho Chehab
2018-05-04 13:52             ` Mauro Carvalho Chehab
2018-05-04 13:52             ` Mauro Carvalho Chehab
     [not found]     ` <CGME20180423135655eucas1p1a935ce9c167e52cf1e76adcc0b4486e4@eucas1p1.samsung.com>
2018-04-23 13:56       ` Bartlomiej Zolnierkiewicz
2018-04-23 13:56         ` Bartlomiej Zolnierkiewicz
2018-04-23 13:56         ` Bartlomiej Zolnierkiewicz
2018-04-23 14:11         ` Tomi Valkeinen
2018-04-23 14:11           ` Tomi Valkeinen
2018-04-23 14:11           ` Tomi Valkeinen
2018-04-23 14:25           ` Mauro Carvalho Chehab
2018-04-23 14:25             ` Mauro Carvalho Chehab
2018-04-23 14:25             ` Mauro Carvalho Chehab
     [not found]           ` <CGME20180425111319eucas1p163fa4f5f7f51bc854763ba3c3c87b605@eucas1p1.samsung.com>
2018-04-25 11:13             ` Bartlomiej Zolnierkiewicz
2018-04-25 11:13               ` Bartlomiej Zolnierkiewicz
2018-04-25 11:13               ` Bartlomiej Zolnierkiewicz
2018-04-26  6:36               ` Tomi Valkeinen
2018-04-26  6:36                 ` Tomi Valkeinen
2018-04-26  6:36                 ` Tomi Valkeinen
2018-04-23 14:22         ` Mauro Carvalho Chehab
2018-04-23 14:22           ` Mauro Carvalho Chehab
2018-04-23 14:22           ` Mauro Carvalho Chehab
2018-04-23 19:48           ` Laurent Pinchart
2018-04-23 19:48             ` Laurent Pinchart
2018-04-23 19:48             ` Laurent Pinchart
2018-04-23 20:09             ` Mauro Carvalho Chehab [this message]
2018-04-23 20:09               ` Mauro Carvalho Chehab
2018-04-23 20:09               ` Mauro Carvalho Chehab
2018-04-23 20:22               ` Laurent Pinchart
2018-04-23 20:22                 ` Laurent Pinchart
2018-04-23 20:22                 ` Laurent Pinchart
2018-04-25  6:24               ` Tomi Valkeinen
2018-04-25  6:24                 ` Tomi Valkeinen
2018-04-25  6:24                 ` Tomi Valkeinen
2018-04-25  9:03                 ` Laurent Pinchart
2018-04-25  9:03                   ` Laurent Pinchart
2018-04-25  9:03                   ` Laurent Pinchart
2018-04-25  9:33                   ` Tomi Valkeinen
2018-04-25  9:33                     ` Tomi Valkeinen
2018-04-25  9:33                     ` Tomi Valkeinen
2018-04-25 10:02                     ` Laurent Pinchart
2018-04-25 10:02                       ` Laurent Pinchart
2018-04-25 10:02                       ` Laurent Pinchart
2018-04-25 10:10                       ` Tomi Valkeinen
2018-04-25 10:10                         ` Tomi Valkeinen
2018-04-25 10:10                         ` Tomi Valkeinen
2018-04-25 10:28                         ` Laurent Pinchart
2018-04-25 10:28                           ` Laurent Pinchart
2018-04-25 10:28                           ` Laurent Pinchart
2018-04-20 17:42 ` [PATCH 6/7] media: omap2: allow building it " Mauro Carvalho Chehab
2018-04-20 17:42 ` [PATCH 7/7] media: via-camera: allow build on non-x86 archs with COMPILE_TEST Mauro Carvalho Chehab
2018-04-20 17:42   ` Mauro Carvalho Chehab
2018-04-20 19:03   ` [PATCH v2 " Mauro Carvalho Chehab
2018-04-20 19:03     ` Mauro Carvalho Chehab
     [not found]     ` <CGME20180423121932eucas1p212eb6412ff8df511047c3afa782db6e0@eucas1p2.samsung.com>
2018-04-23 12:19       ` Bartlomiej Zolnierkiewicz
2018-04-23 12:19         ` Bartlomiej Zolnierkiewicz
2018-05-04 14:02         ` Mauro Carvalho Chehab
2018-05-04 14:02           ` Mauro Carvalho Chehab
2018-05-04 14:07         ` Mauro Carvalho Chehab
2018-05-04 14:07           ` Mauro Carvalho Chehab
     [not found]           ` <CGME20180504142416eucas1p1d8028ba30719c1a0a6e7c5edfb2bc152@eucas1p1.samsung.com>
2018-05-04 14:24             ` Bartlomiej Zolnierkiewicz
2018-05-04 14:24               ` Bartlomiej Zolnierkiewicz
     [not found]               ` <CGME20180515102628eucas1p16f05cb2a1189768f1426b6e5e99aa0a3@eucas1p1.samsung.com>
2018-05-15 10:26                 ` Bartlomiej Zolnierkiewicz
2018-05-15 10:26                   ` Bartlomiej Zolnierkiewicz

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=20180423170955.13421017@vento.lan \
    --to=mchehab@s-opensource.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@infradead.org \
    --cc=tomi.valkeinen@ti.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.