[linux-sunxi] Re: [PATCH 06/11] dt-bindings: display: sun4i-drm: Add A83T HDMI pipeline
From: Jernej Škrabec <hidden>
Date: 2018-01-05 06:20:57
Also in:
dri-devel, linux-clk, linux-devicetree, lkml
Hi, Dne petek, 05. januar 2018 ob 03:49:09 CET je Icenowy Zheng napisal(a):
? 2018?1?5? GMT+08:00 ??2:52:10, Maxime Ripard <maxime.ripard@free-
electrons.com> ??:
quoted
On Wed, Jan 03, 2018 at 10:32:26PM +0100, Jernej ?krabec wrote:quoted
Hi Rob, Dne sreda, 03. januar 2018 ob 21:21:54 CET je Rob Herring napisal(a):quoted
On Sat, Dec 30, 2017 at 10:01:58PM +0100, Jernej Skrabec wrote:quoted
This commit adds all necessary compatibles and descriptionsneeded toquoted
quoted
quoted
implement A83T HDMI pipeline. Mixer is already properly described, so only compatible is added. However, A83T TCON1, which is connected to HDMI, doesn't havechannel 0,quoted
quoted
quoted
contrary to all TCONs currently described. Because of that, TCON documentation is extended. A83T features Synopsys DW HDMI controller with a custom PHY whichlooksquoted
quoted
quoted
like Synopsys Gen2 PHY with few additions. Since there is no documentation, needed properties were found out throughexperimentationquoted
quoted
quoted
and reading BSP code. At the end, example is added for newer SoCs, which features DE2and DWquoted
quoted
quoted
HDMI. Signed-off-by: Jernej Skrabec <redacted> --- .../bindings/display/sunxi/sun4i-drm.txt | 188 ++++++++++++++++++++- 1 file changed, 181 insertions(+), 7deletions(-)quoted
quoted
quoted
diff --gita/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txtquoted
quoted
quoted
b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txtindexquoted
quoted
quoted
9f073af4c711..3eca258096a5 100644 ---a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txtquoted
quoted
quoted
+++b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txtquoted
quoted
quoted
@@ -64,6 +64,40 @@ Required properties: first port should be the input endpoint. The second shouldbe thequoted
quoted
quoted
output, usually to an HDMI connector. +DWC HDMI TX Encoder +----------------------------- + +The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TXcontroller IPquoted
quoted
quoted
+with Allwinner's own PHY IP. It supports audio and video outputsand CEC.quoted
quoted
quoted
+ +These DT bindings follow the Synopsys DWC HDMI TX bindingsdefined inquoted
quoted
quoted
+Documentation/devicetree/bindings/display/bridge/dw_hdmi.txtwith thequoted
quoted
quoted
+following device-specific properties. + +Required properties: + + - compatible: value must be one of: + * "allwinner,sun8i-a83t-dw-hdmi" + - reg: two pairs of base address and size of memory-mappedregion,quoted
quoted
quoted
first + for controller and second for PHY + registers.Seems like the phy should be a separate node and use the phybinding.quoted
quoted
You can use the phy binding even if you don't use the kernel phy framework...Unfortunately, it's not so straighforward. Phy is actually accessedthroughquoted
I2C implemented in HDMI controller. Second memory region in this casehasquoted
small influence on phy. However, it has big influence on controller.Forquoted
example, magic number has to be written in one register in secondmemoryquoted
region in order to unlock read access to any register from firstmemory regionquoted
(controller). However, they shouldn't be merged to one region,because firstquoted
memory region requires byte access while second memory region can beaccessedquoted
per byte or word. To complicate things more, later I want to add support for anotherSoC whichquoted
has same glue layer (unlocking read access, etc.) and uses memorymapped phyquoted
registers in second memory region. I think current binding is the least complicated way to representthis. I agree with Rob here. I did a similar thing for the DSI patches I've sent a few monthes ago and it turned out to not be that difficult, so I'm sure you can come up with something :)In A83T/H3/A64/H5/R40 this part is not purely a PHY. It controls the access of main controller's register (e.g. read/write lock and register obfuscation). So it should be called a "glue" with PHY part (and on A83T seems a pure glue) but not a simple PHY.
It's not so simple. Actually it has PHY settings also on A83T. For example, value at 0x01EF0001 depends on polarity. Value at 0x01EF0002 sets PHY I2C address. Bit 7 at 0x01EF0007 enables/disables external resistor. That is info I discovered/received after I sent patches, so it's not cleary marked. Proper memory map (starts at 0x01EE0000): 0x00000 - 0x10000 -> DW HDMI controller 0x10000 - 0x10010 -> (almost?) Common PHY settings 0x10010 - 0x10020 -> Allwinner proprietary glue layer 0x10020 - 0x10040 -> Allwinner proprietary PHY (not present on A83T) In preliminary PHY doc AW released, there are additional regs at 0x01EF0FF8 and 0x01EF0FFC for controller ID and phy ID, but it was always 0 at A83T and H3. So splitting memory in so many regions just to satisfy clean division it doesn't seem sane to me. Now that I checked how Maxime did it with MIPI DSI driver, I'm good with dividing it into two parts. Best regards, Jernej
quoted
Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel at lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel-- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/d/optout.