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