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 considerin
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