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