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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
