[PATCH v3 3/3] drm/bridge: add Silicon Image SiI8620 driver

Andrzej Hajda a.hajda at samsung.com
Thu Oct 6 09:02:58 UTC 2016


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.

Regards
Andrzej


More information about the dri-devel mailing list