All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	<linux-fbdev@vger.kernel.org>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Tom Gall <tom.gall@linaro.org>,
	Ragesh Radhakrishnan <ragesh.r@linaro.org>,
	<dri-devel@lists.freedesktop.org>,
	Rob Clark <rob.clark@linaro.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Benjamin Gaignard <benjamin.gaignard@linaro.org>,
	Bryan Wu <bryan.wu@canonical.com>,
	Maxime Ripard <maxime.ripard@free-electrons.com>,
	Vikas Sajjan <vikas.sajjan@linaro.org>,
	Sumit Semwal <sumit.semwal@linaro.org>,
	Sebastien Guiriec <s-guiriec@ti.com>,
	<linux-media@vger.kernel.org>
Subject: Re: [RFC v2 0/5] Common Display Framework
Date: Wed, 19 Dec 2012 17:07:50 +0200	[thread overview]
Message-ID: <50D1D846.6010005@ti.com> (raw)
In-Reply-To: <87pq26ay2z.fsf@intel.com>

[-- Attachment #1: Type: text/plain, Size: 2265 bytes --]

On 2012-12-19 16:57, Jani Nikula wrote:

> It just seems to me that, at least from a DRM/KMS perspective, adding
> another layer (=CDF) for HDMI or DP (or legacy outputs) would be
> overengineering it. They are pretty well standardized, and I don't see
> there would be a need to write multiple display drivers for them. Each
> display controller has one, and can easily handle any chip specific
> requirements right there. It's my gut feeling that an additional
> framework would just get in the way. Perhaps there could be more common
> HDMI/DP helper style code in DRM to reduce overlap across KMS drivers,
> but that's another thing.
> 
> So is the HDMI/DP drivers using CDF a more interesting idea from a
> non-DRM perspective? Or, put another way, is it more of an alternative
> to using DRM? Please enlighten me if there's some real benefit here that
> I fail to see!

The use of CDF is an option, not something that has to be done. A DRM
driver developer may use it if it gives benefit for him for that
particular driver.

I don't know much about desktop display hardware, but I guess that using
CDF would not really give much there. In some cases it could, if the IPs
used on the graphics card are something that are used elsewhere also
(sounds quite unlikely, though). In that case there could be separate
drivers for the IPs.

And note that CDF is not really about the dispc side, i.e. the part that
creates the video stream from pixels in the memory. It's more about the
components after that, and how to connect those components.

> For DSI panels (or DSI-to-whatever bridges) it's of course another
> story. You typically need a panel specific driver. And here I see the
> main point of the whole CDF: decoupling display controllers and the
> panel drivers, and sharing panel (and converter chip) specific drivers
> across display controllers. Making it easy to write new drivers, as
> there would be a model to follow. I'm definitely in favour of coming up
> with some framework that would tackle that.

Right. But if you implement drivers for DSI panels with CDF for, say,
OMAP, I think it's simpler to use CDF also for HDMI/DP on OMAP.
Otherwise it'll be a mishmash with two different models.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	linux-fbdev@vger.kernel.org,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Tom Gall <tom.gall@linaro.org>,
	Ragesh Radhakrishnan <ragesh.r@linaro.org>,
	dri-devel@lists.freedesktop.org, Rob Clark <rob.clark@linaro.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Benjamin Gaignard <benjamin.gaignard@linaro.org>,
	Bryan Wu <bryan.wu@canonical.com>,
	Maxime Ripard <maxime.ripard@free-electrons.com>,
	Vikas Sajjan <vikas.sajjan@linaro.org>,
	Sumit Semwal <sumit.semwal@linaro.org>,
	Sebastien Guiriec <s-guiriec@ti.com>,
	linux-media@vger.kernel.org
Subject: Re: [RFC v2 0/5] Common Display Framework
Date: Wed, 19 Dec 2012 15:07:50 +0000	[thread overview]
Message-ID: <50D1D846.6010005@ti.com> (raw)
In-Reply-To: <87pq26ay2z.fsf@intel.com>

[-- Attachment #1: Type: text/plain, Size: 2265 bytes --]

On 2012-12-19 16:57, Jani Nikula wrote:

> It just seems to me that, at least from a DRM/KMS perspective, adding
> another layer (=CDF) for HDMI or DP (or legacy outputs) would be
> overengineering it. They are pretty well standardized, and I don't see
> there would be a need to write multiple display drivers for them. Each
> display controller has one, and can easily handle any chip specific
> requirements right there. It's my gut feeling that an additional
> framework would just get in the way. Perhaps there could be more common
> HDMI/DP helper style code in DRM to reduce overlap across KMS drivers,
> but that's another thing.
> 
> So is the HDMI/DP drivers using CDF a more interesting idea from a
> non-DRM perspective? Or, put another way, is it more of an alternative
> to using DRM? Please enlighten me if there's some real benefit here that
> I fail to see!

The use of CDF is an option, not something that has to be done. A DRM
driver developer may use it if it gives benefit for him for that
particular driver.

I don't know much about desktop display hardware, but I guess that using
CDF would not really give much there. In some cases it could, if the IPs
used on the graphics card are something that are used elsewhere also
(sounds quite unlikely, though). In that case there could be separate
drivers for the IPs.

And note that CDF is not really about the dispc side, i.e. the part that
creates the video stream from pixels in the memory. It's more about the
components after that, and how to connect those components.

> For DSI panels (or DSI-to-whatever bridges) it's of course another
> story. You typically need a panel specific driver. And here I see the
> main point of the whole CDF: decoupling display controllers and the
> panel drivers, and sharing panel (and converter chip) specific drivers
> across display controllers. Making it easy to write new drivers, as
> there would be a model to follow. I'm definitely in favour of coming up
> with some framework that would tackle that.

Right. But if you implement drivers for DSI panels with CDF for, say,
OMAP, I think it's simpler to use CDF also for HDMI/DP on OMAP.
Otherwise it'll be a mishmash with two different models.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	linux-fbdev@vger.kernel.org,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Tom Gall <tom.gall@linaro.org>,
	Ragesh Radhakrishnan <ragesh.r@linaro.org>,
	dri-devel@lists.freedesktop.org, Rob Clark <rob.clark@linaro.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Benjamin Gaignard <benjamin.gaignard@linaro.org>,
	Bryan Wu <bryan.wu@canonical.com>,
	Maxime Ripard <maxime.ripard@free-electrons.com>,
	Vikas Sajjan <vikas.sajjan@linaro.org>,
	Sumit Semwal <sumit.semwal@linaro.org>,
	Sebastien Guiriec <s-guiriec@ti.com>,
	linux-media@vger.kernel.org
Subject: Re: [RFC v2 0/5] Common Display Framework
Date: Wed, 19 Dec 2012 17:07:50 +0200	[thread overview]
Message-ID: <50D1D846.6010005@ti.com> (raw)
In-Reply-To: <87pq26ay2z.fsf@intel.com>

[-- Attachment #1: Type: text/plain, Size: 2265 bytes --]

On 2012-12-19 16:57, Jani Nikula wrote:

> It just seems to me that, at least from a DRM/KMS perspective, adding
> another layer (=CDF) for HDMI or DP (or legacy outputs) would be
> overengineering it. They are pretty well standardized, and I don't see
> there would be a need to write multiple display drivers for them. Each
> display controller has one, and can easily handle any chip specific
> requirements right there. It's my gut feeling that an additional
> framework would just get in the way. Perhaps there could be more common
> HDMI/DP helper style code in DRM to reduce overlap across KMS drivers,
> but that's another thing.
> 
> So is the HDMI/DP drivers using CDF a more interesting idea from a
> non-DRM perspective? Or, put another way, is it more of an alternative
> to using DRM? Please enlighten me if there's some real benefit here that
> I fail to see!

The use of CDF is an option, not something that has to be done. A DRM
driver developer may use it if it gives benefit for him for that
particular driver.

I don't know much about desktop display hardware, but I guess that using
CDF would not really give much there. In some cases it could, if the IPs
used on the graphics card are something that are used elsewhere also
(sounds quite unlikely, though). In that case there could be separate
drivers for the IPs.

And note that CDF is not really about the dispc side, i.e. the part that
creates the video stream from pixels in the memory. It's more about the
components after that, and how to connect those components.

> For DSI panels (or DSI-to-whatever bridges) it's of course another
> story. You typically need a panel specific driver. And here I see the
> main point of the whole CDF: decoupling display controllers and the
> panel drivers, and sharing panel (and converter chip) specific drivers
> across display controllers. Making it easy to write new drivers, as
> there would be a model to follow. I'm definitely in favour of coming up
> with some framework that would tackle that.

Right. But if you implement drivers for DSI panels with CDF for, say,
OMAP, I think it's simpler to use CDF also for HDMI/DP on OMAP.
Otherwise it'll be a mishmash with two different models.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

  reply	other threads:[~2012-12-19 15:08 UTC|newest]

Thread overview: 174+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-22 21:45 [RFC v2 0/5] Common Display Framework Laurent Pinchart
2012-11-22 21:45 ` Laurent Pinchart
2012-11-22 21:45 ` [RFC v2 1/5] video: Add generic display entity core Laurent Pinchart
2012-11-22 21:45   ` Laurent Pinchart
2012-11-27 13:07   ` Tomi Valkeinen
2012-11-27 13:07     ` Tomi Valkeinen
2012-11-27 13:07     ` Tomi Valkeinen
2012-11-22 21:45 ` [RFC v2 2/5] video: panel: Add DPI panel support Laurent Pinchart
2012-11-22 21:45   ` Laurent Pinchart
2012-11-27 13:02   ` Tomi Valkeinen
2012-11-27 13:02     ` Tomi Valkeinen
2012-11-27 13:02     ` Tomi Valkeinen
2012-11-30  9:26   ` Philipp Zabel
2012-11-30  9:26     ` Philipp Zabel
2012-11-22 21:45 ` [RFC v2 3/5] video: display: Add MIPI DBI bus support Laurent Pinchart
2012-11-22 21:45   ` Laurent Pinchart
2012-11-30 12:02   ` Tomi Valkeinen
2012-11-30 12:02     ` Tomi Valkeinen
2012-11-30 12:02     ` Tomi Valkeinen
2012-11-22 21:45 ` [RFC v2 4/5] video: panel: Add R61505 panel support Laurent Pinchart
2012-11-22 21:45   ` Laurent Pinchart
2012-11-22 21:45 ` [RFC v2 5/5] video: panel: Add R61517 " Laurent Pinchart
2012-11-22 21:45   ` Laurent Pinchart
2012-11-23 14:51 ` [RFC v2 0/5] Common Display Framework Tomi Valkeinen
2012-11-23 14:51   ` Tomi Valkeinen
2012-11-23 14:51   ` Tomi Valkeinen
2012-12-17 14:36   ` Laurent Pinchart
2012-12-17 14:36     ` Laurent Pinchart
2012-12-17 15:29     ` Tomi Valkeinen
2012-12-17 15:29       ` Tomi Valkeinen
2012-12-17 15:29       ` Tomi Valkeinen
2012-12-17 23:18       ` Laurent Pinchart
2012-12-17 23:18         ` Laurent Pinchart
2012-12-17 16:53     ` Jani Nikula
2012-12-17 16:53       ` Jani Nikula
2012-12-17 22:19       ` Laurent Pinchart
2012-12-17 22:19         ` Laurent Pinchart
2012-12-19 14:57         ` Jani Nikula
2012-12-19 14:57           ` Jani Nikula
2012-12-19 15:07           ` Tomi Valkeinen [this message]
2012-12-19 15:07             ` Tomi Valkeinen
2012-12-19 15:07             ` Tomi Valkeinen
2012-12-24 17:31             ` Laurent Pinchart
2012-12-24 17:31               ` Laurent Pinchart
2012-12-19 15:26           ` Rob Clark
2012-12-19 15:26             ` Rob Clark
2012-12-19 15:37             ` Tomi Valkeinen
2012-12-19 15:37               ` Tomi Valkeinen
2012-12-19 16:05               ` Rob Clark
2012-12-19 16:05                 ` Rob Clark
2012-12-19 16:05                 ` Rob Clark
2012-12-24 17:40                 ` Laurent Pinchart
2012-12-24 17:40                   ` Laurent Pinchart
2012-12-24 17:35             ` Laurent Pinchart
2012-12-24 17:35               ` Laurent Pinchart
2012-12-27 16:10               ` Rob Clark
2012-12-27 16:10                 ` Rob Clark
2012-12-24 17:27           ` Laurent Pinchart
2012-12-24 17:27             ` Laurent Pinchart
2012-12-27 16:04             ` Rob Clark
2012-12-27 16:04               ` Rob Clark
2012-12-27 19:19               ` Sascha Hauer
2012-12-27 19:19                 ` Sascha Hauer
2012-11-23 19:56 ` Thierry Reding
2012-11-23 19:56   ` Thierry Reding
2012-11-24  7:15   ` Tomi Valkeinen
2012-11-24  7:15     ` Tomi Valkeinen
2012-11-24  7:15     ` Tomi Valkeinen
2012-11-26 14:47     ` Alan Cox
2012-12-17 15:15       ` Laurent Pinchart
2012-12-17 15:15         ` Laurent Pinchart
2012-11-26  7:53   ` Philipp Zabel
2012-11-26  7:53     ` Philipp Zabel
2012-12-17 14:58   ` Laurent Pinchart
2012-12-17 14:58     ` Laurent Pinchart
2012-11-23 21:41 ` Sascha Hauer
2012-11-23 21:41   ` Sascha Hauer
2012-12-17 15:02   ` Laurent Pinchart
2012-12-17 15:02     ` Laurent Pinchart
     [not found] ` <CAD025yS5rGMbiRBdDxv=YLP6_fsQndAkr+3t29_mNhcvow_SwA@mail.gmail.com>
     [not found]   ` <3133576.BkqAl7V01U@avalon>
2012-12-18  3:01     ` Vikas Sajjan
2012-12-18  6:13       ` Vikas Sajjan
2012-12-18  6:25         ` Vikas Sajjan
2012-12-21 10:00       ` Tomasz Figa
2012-12-21 10:00         ` Tomasz Figa
2012-12-24 14:12         ` Laurent Pinchart
2012-12-24 14:12           ` Laurent Pinchart
2012-12-27 14:43           ` Tomasz Figa
2012-12-27 14:43             ` Tomasz Figa
2012-12-27 14:43             ` Tomasz Figa
2012-12-28  3:26             ` Vikas Sajjan
2012-12-28  3:38               ` Vikas Sajjan
2013-01-08  8:18             ` Laurent Pinchart
2013-01-08  8:18               ` Laurent Pinchart
2013-01-08 10:12               ` Marcus Lorentzon
2013-01-08 10:12                 ` Marcus Lorentzon
2013-01-08 16:36                 ` Tomasz Figa
2013-01-08 16:36                   ` Tomasz Figa
2013-01-08 17:08                   ` Marcus Lorentzon
2013-01-08 17:08                     ` Marcus Lorentzon
2013-02-01 23:35                     ` Laurent Pinchart
2013-02-01 23:35                       ` Laurent Pinchart
2013-02-04 10:05                       ` Marcus Lorentzon
2013-02-04 10:05                         ` Marcus Lorentzon
2013-02-06  9:52                         ` Archit Taneja
2013-02-06  9:52                           ` Archit Taneja
2013-02-08 10:51                         ` Tomi Valkeinen
2013-02-08 10:51                           ` Tomi Valkeinen
2013-02-08 12:43                           ` Marcus Lorentzon
2013-02-08 12:43                             ` Marcus Lorentzon
2013-02-01 23:37                 ` Laurent Pinchart
2013-02-01 23:37                   ` Laurent Pinchart
2012-12-24 12:59       ` Laurent Pinchart
2012-12-24 13:00         ` Laurent Pinchart
2012-12-18  5:04 ` Dave Airlie
2012-12-18  5:04   ` Dave Airlie
2012-12-18  5:04   ` Dave Airlie
2012-12-18  6:21   ` Rob Clark
2012-12-18  6:21     ` Rob Clark
2012-12-18  8:30     ` Daniel Vetter
2012-12-18  8:30       ` Daniel Vetter
2012-12-18  9:38       ` Inki Dae
2012-12-19 20:13         ` Stéphane Marchesin
2012-12-19 20:13           ` Stéphane Marchesin
2012-12-24 14:08         ` Laurent Pinchart
2012-12-24 14:08           ` Laurent Pinchart
2012-12-24 13:39       ` Laurent Pinchart
2012-12-24 13:39         ` Laurent Pinchart
2012-12-18 10:59     ` Sylwester Nawrocki
2012-12-18 10:59       ` Sylwester Nawrocki
2012-12-24 17:19       ` Laurent Pinchart
2012-12-24 17:19         ` Laurent Pinchart
2012-12-19 20:05     ` Stéphane Marchesin
2012-12-19 20:05       ` Stéphane Marchesin
2012-12-24 13:37     ` Laurent Pinchart
2012-12-24 13:37       ` Laurent Pinchart
2012-12-27 15:54       ` Rob Clark
2012-12-27 15:54         ` Rob Clark
2012-12-27 19:18         ` Sascha Hauer
2012-12-27 19:18           ` Sascha Hauer
2012-12-27 19:57           ` Rob Clark
2012-12-27 19:57             ` Rob Clark
2012-12-28  0:04             ` Sascha Hauer
2012-12-28  0:04               ` Sascha Hauer
2013-01-08  8:33               ` Laurent Pinchart
2013-01-08  8:33                 ` Laurent Pinchart
2013-01-08  8:25         ` Laurent Pinchart
2013-01-08  8:25           ` Laurent Pinchart
2013-01-08 16:13           ` Rob Clark
2013-01-08 16:13             ` Rob Clark
2013-01-09  8:23             ` Rahul Sharma
2013-01-09  8:35               ` Rahul Sharma
2013-01-09  8:23               ` Rahul Sharma
2013-02-01 23:42               ` Laurent Pinchart
2013-02-01 23:42                 ` Laurent Pinchart
2013-02-02 10:08                 ` Rob Clark
2013-02-02 10:08                   ` Rob Clark
2012-12-18 10:39   ` Marcus Lorentzon
2012-12-18 10:39     ` Marcus Lorentzon
2012-12-18 10:39     ` Marcus Lorentzon
2012-12-24 17:09     ` Laurent Pinchart
2012-12-24 17:09       ` Laurent Pinchart
2012-12-24 17:09       ` Laurent Pinchart
2012-12-27 15:57       ` Rob Clark
2012-12-27 15:57         ` Rob Clark
2012-12-27 15:57         ` Rob Clark
2013-01-06 17:46         ` Daniel Vetter
2013-01-06 17:46           ` Daniel Vetter
2013-01-06 17:46           ` Daniel Vetter
2013-01-08  8:41           ` Laurent Pinchart
2013-01-08  8:41             ` Laurent Pinchart
2012-12-24 13:24   ` Laurent Pinchart
2012-12-24 13:24     ` Laurent Pinchart
2012-12-14  4:57 Vikas Sajjan
2012-12-17 22:00 ` Laurent Pinchart

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=50D1D846.6010005@ti.com \
    --to=tomi.valkeinen@ti.com \
    --cc=benjamin.gaignard@linaro.org \
    --cc=bryan.wu@canonical.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=kyungmin.park@samsung.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=maxime.ripard@free-electrons.com \
    --cc=p.zabel@pengutronix.de \
    --cc=ragesh.r@linaro.org \
    --cc=rob.clark@linaro.org \
    --cc=s-guiriec@ti.com \
    --cc=sumit.semwal@linaro.org \
    --cc=thomas.petazzoni@free-electrons.com \
    --cc=tom.gall@linaro.org \
    --cc=vikas.sajjan@linaro.org \
    /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.