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
