From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-vb0-f53.google.com ([209.85.212.53]:33472 "EHLO mail-vb0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751387Ab2LSQNq (ORCPT ); Wed, 19 Dec 2012 11:13:46 -0500 MIME-Version: 1.0 In-Reply-To: <50D1DF42.3070008@ti.com> References: <1353620736-6517-1-git-send-email-laurent.pinchart@ideasonboard.com> <1608840.IleINgrx5J@avalon> <87pq28hb72.fsf@intel.com> <1671267.x0lxGrFjjV@avalon> <87pq26ay2z.fsf@intel.com> <50D1DF42.3070008@ti.com> Date: Wed, 19 Dec 2012 10:05:27 -0600 Message-ID: Subject: Re: [RFC v2 0/5] Common Display Framework From: Rob Clark To: Tomi Valkeinen Cc: Jani Nikula , Laurent Pinchart , Thomas Petazzoni , Linux Fbdev development list , Philipp Zabel , Tom Gall , Ragesh Radhakrishnan , "dri-devel@lists.freedesktop.org" , Kyungmin Park , Benjamin Gaignard , Maxime Ripard , Vikas Sajjan , Sumit Semwal , Sebastien Guiriec , "linux-media@vger.kernel.org" Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-media-owner@vger.kernel.org List-ID: On Wed, Dec 19, 2012 at 9:37 AM, Tomi Valkeinen wrote: > On 2012-12-19 17:26, Rob Clark wrote: >> >> And, there are also external HDMI encoders (for example connected over >> i2c) that can also be shared between boards. So I think there will be >> a number of cases where CDF is appropriate for HDMI drivers. Although >> trying to keep this all independent of DRM (as opposed to just >> something similar to what drivers/gpu/i2c is today) seems a bit >> overkill for me. Being able to use the helpers in drm and avoiding an >> extra layer of translation seems like the better option to me. So my >> vote would be drivers/gpu/cdf. > > Well, we need to think about that. I would like to keep CDF independent > of DRM. I don't like tying different components/frameworks together if > there's no real need for that. > > Also, something that Laurent mentioned in our face-to-face discussions: > Some IPs/chips can be used for other purposes than with DRM. > > He had an example of a board, that (if I understood right) gets video > signal from somewhere outside the board, processes the signal with some > IPs/chips, and then outputs the signal. So there's no framebuffer, and > the image is not stored anywhere. I think the framework used in these > cases is always v4l2. > > The IPs/chips in the above model may be the exact same IPs/chips that > are used with "normal" display. If the CDF was tied to DRM, using the > same drivers for normal and these streaming cases would probably not be > possible. Well, maybe there is a way, but it really seems to be over-complicating things unnecessarily to keep CDF independent of DRM.. there will be a lot more traditional uses of CDF compared to one crazy use-case. So I don't really fancy making it more difficult than in needs to be for everyone. Probably the thing to do is take a step back and reconsider that one crazy use-case. For example, KMS doesn't enforce that the buffer handled passed when you create a drm framebuffer object to scan out is a GEM buffer. So on that one crazy platform, maybe it makes sense to have a DRM/KMS display driver that takes a handle to identify which video stream coming from the capture end of the pipeline. Anyways, that is just an off-the-top-of-my-head idea, probably there are other options too. BR, -R > Tomi > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Clark Date: Wed, 19 Dec 2012 16:05:27 +0000 Subject: Re: [RFC v2 0/5] Common Display Framework Message-Id: List-Id: References: <1353620736-6517-1-git-send-email-laurent.pinchart@ideasonboard.com> <1608840.IleINgrx5J@avalon> <87pq28hb72.fsf@intel.com> <1671267.x0lxGrFjjV@avalon> <87pq26ay2z.fsf@intel.com> <50D1DF42.3070008@ti.com> In-Reply-To: <50D1DF42.3070008@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Tomi Valkeinen Cc: Thomas Petazzoni , Linux Fbdev development list , Benjamin Gaignard , Tom Gall , "dri-devel@lists.freedesktop.org" , Kyungmin Park , Ragesh Radhakrishnan , Laurent Pinchart , Philipp Zabel , Maxime Ripard , Vikas Sajjan , Sumit Semwal , Sebastien Guiriec , "linux-media@vger.kernel.org" On Wed, Dec 19, 2012 at 9:37 AM, Tomi Valkeinen wrote: > On 2012-12-19 17:26, Rob Clark wrote: >> >> And, there are also external HDMI encoders (for example connected over >> i2c) that can also be shared between boards. So I think there will be >> a number of cases where CDF is appropriate for HDMI drivers. Although >> trying to keep this all independent of DRM (as opposed to just >> something similar to what drivers/gpu/i2c is today) seems a bit >> overkill for me. Being able to use the helpers in drm and avoiding an >> extra layer of translation seems like the better option to me. So my >> vote would be drivers/gpu/cdf. > > Well, we need to think about that. I would like to keep CDF independent > of DRM. I don't like tying different components/frameworks together if > there's no real need for that. > > Also, something that Laurent mentioned in our face-to-face discussions: > Some IPs/chips can be used for other purposes than with DRM. > > He had an example of a board, that (if I understood right) gets video > signal from somewhere outside the board, processes the signal with some > IPs/chips, and then outputs the signal. So there's no framebuffer, and > the image is not stored anywhere. I think the framework used in these > cases is always v4l2. > > The IPs/chips in the above model may be the exact same IPs/chips that > are used with "normal" display. If the CDF was tied to DRM, using the > same drivers for normal and these streaming cases would probably not be > possible. Well, maybe there is a way, but it really seems to be over-complicating things unnecessarily to keep CDF independent of DRM.. there will be a lot more traditional uses of CDF compared to one crazy use-case. So I don't really fancy making it more difficult than in needs to be for everyone. Probably the thing to do is take a step back and reconsider that one crazy use-case. For example, KMS doesn't enforce that the buffer handled passed when you create a drm framebuffer object to scan out is a GEM buffer. So on that one crazy platform, maybe it makes sense to have a DRM/KMS display driver that takes a handle to identify which video stream coming from the capture end of the pipeline. Anyways, that is just an off-the-top-of-my-head idea, probably there are other options too. BR, -R > Tomi > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Clark Subject: Re: [RFC v2 0/5] Common Display Framework Date: Wed, 19 Dec 2012 10:05:27 -0600 Message-ID: References: <1353620736-6517-1-git-send-email-laurent.pinchart@ideasonboard.com> <1608840.IleINgrx5J@avalon> <87pq28hb72.fsf@intel.com> <1671267.x0lxGrFjjV@avalon> <87pq26ay2z.fsf@intel.com> <50D1DF42.3070008@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-vb0-f50.google.com (mail-vb0-f50.google.com [209.85.212.50]) by gabe.freedesktop.org (Postfix) with ESMTP id 461D4E6506 for ; Wed, 19 Dec 2012 08:05:28 -0800 (PST) Received: by mail-vb0-f50.google.com with SMTP id fr13so2457679vbb.37 for ; Wed, 19 Dec 2012 08:05:27 -0800 (PST) In-Reply-To: <50D1DF42.3070008@ti.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Tomi Valkeinen Cc: Thomas Petazzoni , Linux Fbdev development list , Benjamin Gaignard , Tom Gall , "dri-devel@lists.freedesktop.org" , Kyungmin Park , Ragesh Radhakrishnan , Laurent Pinchart , Philipp Zabel , Maxime Ripard , Vikas Sajjan , Sumit Semwal , Sebastien Guiriec , "linux-media@vger.kernel.org" List-Id: dri-devel@lists.freedesktop.org On Wed, Dec 19, 2012 at 9:37 AM, Tomi Valkeinen wrote: > On 2012-12-19 17:26, Rob Clark wrote: >> >> And, there are also external HDMI encoders (for example connected over >> i2c) that can also be shared between boards. So I think there will be >> a number of cases where CDF is appropriate for HDMI drivers. Although >> trying to keep this all independent of DRM (as opposed to just >> something similar to what drivers/gpu/i2c is today) seems a bit >> overkill for me. Being able to use the helpers in drm and avoiding an >> extra layer of translation seems like the better option to me. So my >> vote would be drivers/gpu/cdf. > > Well, we need to think about that. I would like to keep CDF independent > of DRM. I don't like tying different components/frameworks together if > there's no real need for that. > > Also, something that Laurent mentioned in our face-to-face discussions: > Some IPs/chips can be used for other purposes than with DRM. > > He had an example of a board, that (if I understood right) gets video > signal from somewhere outside the board, processes the signal with some > IPs/chips, and then outputs the signal. So there's no framebuffer, and > the image is not stored anywhere. I think the framework used in these > cases is always v4l2. > > The IPs/chips in the above model may be the exact same IPs/chips that > are used with "normal" display. If the CDF was tied to DRM, using the > same drivers for normal and these streaming cases would probably not be > possible. Well, maybe there is a way, but it really seems to be over-complicating things unnecessarily to keep CDF independent of DRM.. there will be a lot more traditional uses of CDF compared to one crazy use-case. So I don't really fancy making it more difficult than in needs to be for everyone. Probably the thing to do is take a step back and reconsider that one crazy use-case. For example, KMS doesn't enforce that the buffer handled passed when you create a drm framebuffer object to scan out is a GEM buffer. So on that one crazy platform, maybe it makes sense to have a DRM/KMS display driver that takes a handle to identify which video stream coming from the capture end of the pipeline. Anyways, that is just an off-the-top-of-my-head idea, probably there are other options too. BR, -R > Tomi > >