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). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
