Hi Jose, On Monday 28 Nov 2016 12:09:59 Jose Abreu wrote: > On 28-11-2016 11:45, Laurent Pinchart wrote: > > On Monday 28 Nov 2016 19:34:59 Andy Yan wrote: > >> On 2016年11月26日 03:26, Laurent Pinchart wrote: > >>> On Friday 25 Nov 2016 17:08:13 Philipp Zabel wrote: > >>>> Am Freitag, den 25.11.2016, 17:45 +0200 schrieb Laurent Pinchart: > >>>>> On Friday 25 Nov 2016 10:56:55 Philipp Zabel wrote: > >>>>>> Am Donnerstag, den 24.11.2016, 23:16 +0200 schrieb Laurent Pinchart: > >>>>>>> Hi Andy, > >>>>>>> > >>>>>>> As the author of the DW-HDMI DT bindings this question is addressed > >>>>>>> to > >>>>>>> you, but information from anyone is more than welcome. > >>>>>>> > >>>>>>> The DT bindings specify two clocks named "iahb" and "isfr" but don't > >>>>>>> describe them. While I assume that the "isfr" clock corresponds to > >>>>>>> the > >>>>>>> "isfrclk" input signal of the DW HDMI, there is no "iahb" clock > >>>>>>> described in the IP core datasheet. > >>>>>> > >>>>>> The Table 33-1 "HDMI clocks" in the i.MX6DQ reference manual [1] > >>>>>> lists > >>>>>> iahbclk (AHB bus clock), icecclk (32 kHz CEC clock), ihclk (module > >>>>>> clock) and isfrclk (27 MHz internal SFR clock). > >>>>>> > >>>>>> [1] > >>>>>> http://www.nxp.com/assets/documents/data/en/reference-manuals/IMX6DQR > >>>>>> M. > >>>>>> pdf > >>>>>> > >>>>>>> The DW HDMI IP exposes control registers through an APB, not an AHB. > >>>>>>> There is a bus clock named "iapbclk", is "iahb" just an incorrect > >>>>>>> name > >>>>>>> for that clock ? > >>>>>> > >>>>>> According to figure 33-3 "HDMI TX Top Level Block Diagram" the > >>>>>> control > >>>>>> interface is AMBA AHB on i.MX6. Both iahbclk and ihclk are clocked by > >>>>>> ahb_clk_root on i.MX6. > >>>>>> > >>>>>> Register 5 (HDMI_CONFIG1_ID) contains a few bits (confsfrdir, > >>>>>> confi2c, > >>>>>> confocp, confapb, confahb) that indicate which control interface is > >>>>>> used. > >>>>> > >>>>> That's interesting. The DW HDMI TX documentation I found (1.40a-ea00, > >>>>> Early Adopter Edition) only has the confahb bit in that register. Do > >>>>> you > >>>>> know which version of the IP is used in iMX.6 ? I wonder whether the > >>>>> above > >>>>> is a Freescale-specific modification to the IP core. > >>>> > >>>> The driver reports:r > >>>> > >>>> dwhdmi-imx 120000.hdmi: Detected HDMI controller 0x13:0xa:0xa0:0xc1 > >>>> > >>>> That is DESIGN_ID 0x13, REVISION_ID 0x0a. > >>>> > >>>>> I'm also a bit puzzled by the differences in the HDMI PHY between > >>>>> Freescale and Renesas. The Renesas datasheet documents three registers > >>>>> only for the PHY (other might exist and be undocumented), and while > >>>>> they > >>>>> contain fields similar to the ones documented in the Freescale > >>>>> datasheet, > >>>>> the exact register layouts are different. > >>>> > >>>> Do you mean the HDMI_PHY_* registers in the HDMI TX register space or > >>>> the separate HDMI PHY i2c registers? The PHY may very well be > >>>> completely > >>>> different. I think OMAP5 HDMI driver uses the same DesignWare HDMI TX > >>>> as > >>>> i.MX6, but not the same PHY. > >>> > >>> I meant the HDMI PHY I2C registers, yes. If the PHYs are really > >>> SoC-specific maybe we should move the supporting code to the platform > >>> glue driver. > >> > >> Yes, it's really have this case, Some Soc uses DW HDMI controller, > >> but uses another different phy. So it's worth moving the phy related > >> code to soc platform glue driver. > > As a fellow worker with DW-HDMI driver and as a Synopsys SW > developer there is something I would like to say: The > configuration of the phy in this scenario is made through > controller registers. There is a I2C interface but the regbank of > this interface is mapped in the controller, so in order to > configure phy you need to have access to the controller regbank > and status. Sure, of course. The idea would be to delegate PHY configuration to the platform glue code, using an API exported by the dw-hdmi core driver to read/write the PHY registers through I2C. Speaking of this, I assume that the rationale is a reduction in the number signals, but using I2C internally between HDMI TX and the PHY ? Seriously ? :-) > There are many phys available for our customers and some of them > are "custom" made. That was my conclusion, yes. So far there are two vendors using the dw-hdmi driver (Freescale i.MX6 and Rockchip RK3288), and a third one I'm working on (Renesas Gen3). The Freescale and Rockchip platforms seem to use very similar PHYs, which I assume is the Synopsys IP (perhaps customized by the vendors). Renesas platforms seem to use a different PHY: although there are some similarities in register names, only 3 registers are documented, with a bit layout different than the Freescale and Rockchip PHYs. Synopsys offers two different kind of PHYs (3D TX and HEAC), I'm thus also wondering whether Freescale and Rockchip could be using one of them and Renesas the other one. Can you tell, based on the existing driver code, whether the Freescale and Rockchip platforms have a 3D TX or HEAC PHY ? > In my tests I only used one phy, but at the time I checked the source of DW- > HDMI and the phy initialization procedure matched the one that we used > internally for most of the phys. OK, this confirms that Freescale and Rockchip use the Synopsys PHY then (unless you use a 3rd party PHY for internal testing, but I'd be surprised :-)). > > OK, sounds like we have a plan. Kieran, here's work for you :-) > > > >>> Would anyone happen to have access to the Synopsys HDMI TX PHY > >>> documentation ? > > I have but I can't share :( I'm not surprised. Maybe we need a wikileaks for datasheets ;-) > Though, we are moving into mainline now and we are planning to submit > patches to DW-HDMI introducing HDMI 2.0 features, like scrambling and 4:2:0 > support. -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
