Question regarding clocks in the DW-HDMI DT bindings

[Jose Abreu]

Hi All,


On 28-11-2016 11:45, Laurent Pinchart wrote:
> Hi Andy,
>
> (CC'ing Kieran Bingham)
>
> 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/IMX6DQRM.
>>>>>> 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.

There are many phys available for our customers and some of them
are "custom" made. 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, 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 :( 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