Question regarding clocks in the DW-HDMI DT bindings

[Jose Abreu]

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