On 10/06/2016 02:47 PM, Daniel Vetter wrote:
On Thu, Oct 06, 2016 at 11:02:58AM +0200, Andrzej Hajda wrote:
Hi Daniel, Archit,
On 30.09.2016 12:33, Andrzej Hajda wrote:
On 30.09.2016 12:07, Daniel Vetter wrote:
On Fri, Sep 30, 2016 at 09:30:16AM +0530, Archit Taneja wrote:
Hi Andrezj,
On 09/26/2016 07:10 PM, Andrzej Hajda wrote:
SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0.
It is controlled via I2C bus. Its interaction with other
devices in video pipeline is performed mainly on HW level.
The only interaction it does on device driver level is
filtering-out unsupported video modes, it exposes drm_bridge
interface to perform this operation.
The patchset looks good to me. Is the MHL header patch
accepted? I was wondering how we pull this in.
+Daniel
I think someone with real clue about what MHL is needs to review that
header. Also I have no idea why that's under video/, is there another
driver in media we want to share this with?
-Daniel
I have put it into include/linux as MHL could be used to transmit:
- video,
- audio,
- remote control protocol (input device),
- ... embed other protocols (USB for example),
But since I am not aware of other MHL users in near future
I can put the header together with the bridge driver.
These patches are hanging on the list for almost year,
since Archit decided to review it (thanks Archit), I would
like to end this process.
The options I see:
1. Leave it as is, mhl.h is like hdmi.h - it can server for
multiple subsystems. I guess it can be hard to find
MHL specialist to review it as it does not seems
to be popular subject, on the other side it is only
in-kernel header so it should pose serious danger.
2. Move the header to some of drm dirs:
a) drivers/gpu/drm/bridge/
b) include/drm/bridge/
c) include/drm/
...
3. Incorporate it into drivers/gpu/drm/bridge/sil-sii8620.h
This is the least problematic solution, but possible
future abstraction of MHL will be more noisy.
Daniel, which option do you prefer? For me any option
is OK, I just want to end this little bit frustrating process.
I just brought this up as a question, I don't personally care all that
much. Except for option 2a) I think they are all ok (we only have internal
headers outside of include/). Whatever you&Archit can agree on is fine
with me (and then Archit can all push it directly to drm-misc).
I think we can go with 2b), and later move it elsewhere if other
places need it.
Thanks,
Archit
-Daniel
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
