Thread (14 messages) flat view 14 messages, 6 authors, 2013-02-08

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

From: Marcus Lorentzon <hidden>
Date: 2013-02-08 12:44:03
Also in: dri-devel, linux-media

Possibly related (same subject, not in this thread)

On 02/08/2013 11:51 AM, Tomi Valkeinen wrote:
On 2013-02-04 12:05, Marcus Lorentzon wrote:
quoted
As discussed at FOSDEM I will give DSI bus with full feature set a
try.
Please do, but as a reminder I want to raise the issues I see with a DSI
bus:

- A device can be a child of only one bus. So if DSI is used only for
video, the device is a child of, say, i2c bus, and thus there's no DSI
bus. How to configure and use DSI in this case?

- If DSI is used for both control and video, we have two separate APIs
for the bus. What I mean here is that for the video-only case above, we
need a video-only-API for DSI. This API should contain all necessary
methods to configure DSI. But we need similar methods for the control
API also.

So, I hope you come up with some solution for this, but as I see it,
it's easily the most simple and clear option to have one video_source
style entity for the DSI bus itself, which is used for both control and
video.
Thanks, it is not that I'm totally against the video source stuff. And I 
share your concerns, none of the solutions are perfect. It just doesn't 
feel right to create this dummy source "device" without investigating 
the DSI bus route. But I will try to write up some history/problem 
description and ask Greg KH for guidance. If he has a strong opinion 
either way, there is not much more to discuss ;)

/BR
/Marcus
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help