Hi Laurent, Dne sreda, 30. november 2016 09.08.22 UTC+1 je oseba Laurent Pinchart napisala: > > Hi Jernej, > > On Tuesday 29 Nov 2016 15:24:25 Jernej Skrabec wrote: > > Dne torek, 29. november 2016 23.56.31 UTC+1 je oseba Laurent Pinchart > > napisala: > > > On Tuesday 29 Nov 2016 14:47:20 Jernej Skrabec wrote: > > >> Dne torek, 29. november 2016 22.37.03 UTC+1 je oseba Maxime Ripard > > > napisala: > > >>> On Tue, Nov 29, 2016 at 11:18:35AM +0100, Jean-Francois Moine wrote: > > >>>> This patchset series adds HDMI video support to the Allwinner > > >>>> sun8i SoCs which include the display engine 2 (DE2). > > >>>> The driver contains the code for the A83T and H3 SoCs, and > > >>>> some H3 boards, but it could be used/extended for other SoCs > > >>>> (A64, H2, H5) and boards (Banana PIs, Orange PIs). > > >>> > > >>> Honestly, I'm getting a bit worried by the fact that you ignore > > >>> reviews. > > >>> > > >>> On the important reviews that you got that are to be seen as major > > >>> issues that block the inclusion, we have: > > >>> - The fact that the HDMI driver is actually just a designware IP, > > >>> and while you should use the driver that already exists, you > just > > >>> duplicated all that code. > > >> > > >> That might be hard thing to do. A83T fits perfectly, but H3 and newer > > >> SoCs do not. They are using completely different HDMI phy. Decoupling > > >> controller and phy code means rewritting a good portion of the code, > > >> unless some tricks are applied, like calling phy function pointers, > if > > >> they are defined. > > > > > > Same HDMI TX but different HDMI TX PHY ? Kieran is working on > decoupling > > > the PHY configuration code for a Renesas SoC, that might be of > interest to > > > you. > > > > Exactly. I'm developing only U-Boot driver, but Jean-Francois will > probably > > have more interest in this. > > We'll post patches as soon as they're ready. >
Great. Is datasheet public? I'm curious if HDMI PHY is by any chance similar. > > By the way, do you know if the H3 and newer SoCs use a different PHY from > Synopsys, or a custom PHY developed by Allwinner ? > > Unfortunatelly, noone managed to identify PHY and Alliwinner never released a bit of information about HDMI. Does config2_id code 0xFE (PHY type) tell you anything? > > >> Register addresses also differ, but that can be easily solved by > using > > >> undocumented magic value to restore them. > > > > > > I love that :-) > > > > Is it allowed to use magic number which was found in binary blob? I'm > new in > > all this. > > I don't really see a problem with that, we have many drivers in the kernel > that have been developed through reverse-engineering. You should not > include > large pieces of code that have been obtained through decompilation of a > proprietary binary blob as those could be protected by copyright, but > writing > to undocumented registers based on information found through usage of a > binary > driver isn't a problem. (Please remember that I'm not a lawyer though) > > > >>> - The fact that you ignored Rob (v6) and I (v5) comment on using > OF > > >>> graph to model the connection between the display engine and the > > >>> TCON. Something that Laurent also pointed out in this version. > > >>> > > >>> - The fact that you ignored that you needed an HDMI connector node > > >>> as a child of the HDMI controller. This has been reported by Rob > > >>> (v6) and yet again in this version by Laurent. > > >>> > > >>> - And finally the fact that we can't have several display engine > in > > >>> parallel, if needs be. This has happened in the past already on > > >>> Allwinner SoCs, so it's definitely something we should consider > in > > >>> the DT bindings, since we can't break them. > > >>> > > >>> Until those are fixed, I cannot see how this driver can be merged, > > >>> unfortunately. > Best regards, Jernej Å krabec -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161130/80c41fe7/attachment-0001.html>
