Question regarding clocks in the DW-HDMI DT bindings

[Laurent Pinchart]

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.

> 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]

-- 
Regards,

Laurent Pinchart