All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	dri-devel@lists.freedesktop.org,
	Mauro Carvalho Chehab <mchehab@infradead.org>,
	Mauro Carvalho Chehab <mchehab@s-opensource.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: Wed, 25 Apr 2018 09:03:22 +0000	[thread overview]
Message-ID: <1818588.4EAHIaV2gL@avalon> (raw)
In-Reply-To: <70b5e60f-346e-4b34-8235-ce62de720a99@ti.com>

Hi Tomi,

On Wednesday, 25 April 2018 09:24:14 EEST Tomi Valkeinen wrote:
> On 23/04/18 23:09, Mauro Carvalho Chehab wrote:
> >> 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.
> 
> Yes, I'm fine with renaming omapfb functions if that helps. But still,
> if omapdrm is enabled in the kernel as module or built-in, omapfb will
> not work. So even if we get them to compile and link, it'll break at
> runtime one way or another.
> 
> >> 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.
> 
> The problem is that it supports old devices which are not supported by
> omapdrm. But both omapfb and omapdrm support many of the same devices.

Could we trim down omapfb to remove support for the devices supported by 
omapdrm ?

-- 
Regards,

Laurent Pinchart




WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	dri-devel@lists.freedesktop.org,
	Mauro Carvalho Chehab <mchehab@infradead.org>,
	Mauro Carvalho Chehab <mchehab@s-opensource.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: Wed, 25 Apr 2018 12:03:22 +0300	[thread overview]
Message-ID: <1818588.4EAHIaV2gL@avalon> (raw)
In-Reply-To: <70b5e60f-346e-4b34-8235-ce62de720a99@ti.com>

Hi Tomi,

On Wednesday, 25 April 2018 09:24:14 EEST Tomi Valkeinen wrote:
> On 23/04/18 23:09, Mauro Carvalho Chehab wrote:
> >> 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.
> 
> Yes, I'm fine with renaming omapfb functions if that helps. But still,
> if omapdrm is enabled in the kernel as module or built-in, omapfb will
> not work. So even if we get them to compile and link, it'll break at
> runtime one way or another.
> 
> >> 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.
> 
> The problem is that it supports old devices which are not supported by
> omapdrm. But both omapfb and omapdrm support many of the same devices.

Could we trim down omapfb to remove support for the devices supported by 
omapdrm ?

-- 
Regards,

Laurent Pinchart



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

WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>,
	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
Subject: Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP
Date: Wed, 25 Apr 2018 12:03:22 +0300	[thread overview]
Message-ID: <1818588.4EAHIaV2gL@avalon> (raw)
In-Reply-To: <70b5e60f-346e-4b34-8235-ce62de720a99@ti.com>

Hi Tomi,

On Wednesday, 25 April 2018 09:24:14 EEST Tomi Valkeinen wrote:
> On 23/04/18 23:09, Mauro Carvalho Chehab wrote:
> >> 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.
> 
> Yes, I'm fine with renaming omapfb functions if that helps. But still,
> if omapdrm is enabled in the kernel as module or built-in, omapfb will
> not work. So even if we get them to compile and link, it'll break at
> runtime one way or another.
> 
> >> 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.
> 
> The problem is that it supports old devices which are not supported by
> omapdrm. But both omapfb and omapdrm support many of the same devices.

Could we trim down omapfb to remove support for the devices supported by 
omapdrm ?

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2018-04-25  9:03 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
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
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
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
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 [this message]
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
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
2018-05-04 14:24         ` Bartlomiej Zolnierkiewicz
2018-05-04 14:24           ` Bartlomiej Zolnierkiewicz
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=1818588.4EAHIaV2gL@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@infradead.org \
    --cc=mchehab@s-opensource.com \
    --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.