Hi Laurent,
On 28-11-2016 14:24, Laurent Pinchart wrote: > 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. Sounds fine but might be beneficial if instead of doing this in the glue code, do it in a new driver that then glues with the dw-hdmi driver. This way we can avoid code duplication. I'm working in HDMI RX now (that uses a JTAG interface to communicate with the phy, again mapped in the controller [not my fault :)]) and this is what I am doing: - Create a phy interface in controller driver (which would be dw-hdmi) - Create a phy driver - Create a controller driver (dw-hdmi) - Phy to be used is passed by pdata to controller driver - Controller driver requests and registers phy driver I submitted a RFC for the phy driver to media ML, you can find it here: http://www.spinics.net/lists/linux-media/msg107610.html > > 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 ? > :-) Yeah, not very usual and not very convenient :/ >> 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. Hmm. I talked with a colleague of mine and we agree that different bit layout may suggest that Renesas can be using a non-synopsys phy. The controller and the phy can be sell separately so this can happen. If you send me the documentation you have I can compare it here. > > 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 ? Im not an expert in phys but HEAC is a quite old one and 3D TX is very generic. I tested dw-hdmi using "DesignWare Cores HDMI-MHL Tx PHY for TSMC 28-nm HPM/1.8 V" and the configuration flow was the same as the Rockchip, I only needed to change the phy configuration settings (mpll, ctrl, ...), but these are always different in each phy version. >> 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. Best regards, Jose Miguel Abreu