Question regarding clocks in the DW-HDMI DT bindings

[Jose Abreu]

Hi Laurent,



On 28-11-2016 19:19, Laurent Pinchart wrote:
> Hi Jose,
>
> On Monday 28 Nov 2016 15:25:18 Jose Abreu wrote:
>> On 28-11-2016 14:24, Laurent Pinchart wrote:
>>> 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:
> [snip]
>
>>>>>>>>> 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.
> Yes, the code should certainly be shared between compatible implementations. 
> I'm thinking about moving it to dw-hdmi-phy.c but still compiling that in in 
> dw-hdmi.ko (we're talking about a very small amount of code), and letting glue 
> code select the PHY handler they want to use through a field in the dw-hdmi 
> platform data.

Sounds fine by me. Let me know if you need someone to review.

>> 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
> I'll try to review that when time permits, but I'm afraid I'm very busy at the 
> moment.
>
> [snip]
>

Best regards,
Jose Miguel Abreu