Re: [RFC v2 0/5] Common Display Framework

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

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

On 2012-12-19 17:26, Rob Clark wrote:
> On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula
> <jani.nikula@linux.intel.com> wrote:
>>
>> Hi Laurent -
>>
>> On Tue, 18 Dec 2012, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
>>> Hi Jani,
>>>
>>> On Monday 17 December 2012 18:53:37 Jani Nikula wrote:
>>>> I can see the need for a framework for DSI panels and such (in fact Tomi
>>>> and I have talked about it like 2-3 years ago already!) but what is the
>>>> story for HDMI and DP? In particular, what's the relationship between
>>>> DRM and CDF here? Is there a world domination plan to switch the DRM
>>>> drivers to use this framework too? ;) Do you have some rough plans how
>>>> DRM and CDF should work together in general?
>>>
>>> There's always a world domination plan, isn't there ? :-)
>>>
>>> I certainly want CDF to be used by DRM (or more accurately KMS). That's what
>>> the C stands for, common refers to sharing panel and other display entity
>>> drivers between FBDEV, KMS and V4L2.
>>>
>>> I currently have no plan to expose CDF internals to userspace through the KMS
>>> API. We might have to do so later if the hardware complexity grows in such a
>>> way that finer control than what KMS provides needs to be exposed to
>>> userspace, but I don't think we're there yet. The CDF API will thus only be
>>> used internally in the kernel by display controller drivers. The KMS core
>>> might get functions to handle common display entity operations, but the bulk
>>> of the work will be in the display controller drivers to start with. We will
>>> then see what can be abstracted in KMS helper functions.
>>>
>>> Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the CDF
>>> API. That's just a thought for now, I haven't tried to implement them, but it
>>> would be nice to handle HDMI screens and DPI/DBI/DSI panels in a generic way.
>>>
>>> Do you have thoughts to share on this topic ?
>>
>> 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!
> 
> fwiw, I think there are at least a couple cases where multiple SoC's
> have the same HDMI IP block.
> 
> 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.

 Tomi



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