<br><br><div class="gmail_quote">On Tue, Jul 30, 2013 at 10:37 AM, Kishon Vijay Abraham I <span dir="ltr"><<a href="mailto:kishon@ti.com" target="_blank">kishon@ti.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi,<br> <div><br> On Tuesday 30 July 2013 09:12 AM, Rahul Sharma wrote:<br> ><br> ><br> > On Tue, Jun 18, 2013 at 5:07 PM, Kishon Vijay Abraham I <<a href="mailto:kishon@ti.com" target="_blank">kishon@ti.com</a><br> </div><div>> <mailto:<a href="mailto:kishon@ti.com" target="_blank">kishon@ti.com</a>>> wrote:<br> ><br> > Hi,<br> ><br> > On Tuesday 18 June 2013 03:33 PM, Rahul Sharma wrote:<br> > > Thanks all,<br> > ><br> > > On Fri, Jun 14, 2013 at 11:39 AM, 김승우 <<a href="mailto:sw0312.kim@samsung.com" target="_blank">sw0312.kim@samsung.com</a><br> </div><div>> <mailto:<a href="mailto:sw0312.kim@samsung.com" target="_blank">sw0312.kim@samsung.com</a>>> wrote:<br> > >> Hello Kishon,<br> > >><br> > >> On 2013년 06월 13일 21:54, Kishon Vijay Abraham I wrote:<br> > >>> Hi,<br> > >>><br> > >>> On Thursday 13 June 2013 04:51 PM, Inki Dae wrote:<br> > >>>><br> > >>>><br> > >>>>> -----Original Message-----<br> > >>>>> From: Sylwester Nawrocki [mailto:<a href="mailto:s.nawrocki@samsung.com" target="_blank">s.nawrocki@samsung.com</a><br> > <mailto:<a href="mailto:s.nawrocki@samsung.com" target="_blank">s.nawrocki@samsung.com</a>>]<br> > >>>>> Sent: Thursday, June 13, 2013 5:56 PM<br> > >>>>> To: Rahul Sharma<br> > >>>>> Cc: Rahul Sharma; Inki Dae; <a href="mailto:linux-samsung-soc@vger.kernel.org" target="_blank">linux-samsung-soc@vger.kernel.org</a><br> </div><div>> <mailto:<a href="mailto:linux-samsung-soc@vger.kernel.org" target="_blank">linux-samsung-soc@vger.kernel.org</a>>;<br> > >>>>> devicetree-<br> > >>>>> <a href="mailto:discuss@lists.ozlabs.org" target="_blank">discuss@lists.ozlabs.org</a> <mailto:<a href="mailto:discuss@lists.ozlabs.org" target="_blank">discuss@lists.ozlabs.org</a>>; DRI<br> > mailing list; Kukjin Kim; Seung-Woo Kim;<br> > >>>>> Sean Paul; sunil joshi; Kishon Vijay Abraham I; Stephen Warren;<br> </div>> >>>>> <a href="mailto:grant.likely@linaro.org" target="_blank">grant.likely@linaro.org</a> <mailto:<a href="mailto:grant.likely@linaro.org" target="_blank">grant.likely@linaro.org</a>><br> <div><div>> >>>>> Subject: Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with<br> > >>>>> pmu reg control<br> > >>>>><br> > >>>>> Hi,<br> > >>>>><br> > >>>>> On 06/13/2013 06:26 AM, Rahul Sharma wrote:<br> > >>>>>> Mr. Dae,<br> > >>>>>><br> > >>>>>> Thanks for your valuable inputs.<br> > >>>>>><br> > >>>>>> I posted it as RFC because, I also have received comments to register<br> > >>>>>> hdmiphy as a clock controller. As we always configure it for specific<br> > >>>>>> frequency, hdmi-phy looks similar to a PLL. But it really doesn't<br> > >>>>>> belong to that class. Secondly prior to exynos5420, it was a i2c<br> > >>>>>> device. I am not sure we can register a I2C device as a clock<br> > >>>>>> controller. I wanted to discuss and explore this option here.<br> > >>>>><br> > >>>>> Have you considered using the generic PHY framework for those HDMI<br> > >>>>> PHY devices [1] ? I guess we could add a dedicated group of ops for<br> > >>>>> video PHYs, similarly as is is done with struct v4l2_subdev_ops. For<br> > >>>>> configuring things like the carrier/pixel clock frequency or anything<br> > >>>>> what's common across the video PHYs.<br> > >>>>><br> > >>>>> Perhaps you could have a look and see if this framework would be<br> > >>>>> useful for HDMI and possibly point out anything what might be missing ?<br> > >>>>><br> > >>>>> I'm not sure it it really solves the issues specific to the Exynos<br> > >>>>> HDMI but at least with a generic PHY driver the PHY module would be<br> > >>>>> separate from the PHY controller, as often same HDMI DPHY can be used<br> > >>>>> with various types of a HDMI controller. So this would allow to not<br> > >>>>> duplicate the HDMI PHY drivers in the long-term perspective.<br> > >>>><br> > >>>> Yeah, at least, it seems that we could use PHY module to control PMU<br> > >>>> register, HDMI_PHY_CONTROL. However, PHY module provides only init/on/off<br> > >>>> callbacks. As you may know, HDMIPHY needs i2c interfaces to control<br> > >>>> HDMIPHY<br> > >>>> clock. So with PHY module, HDMIPHY driver could enable PMU more<br> > >>>> generically,<br> > >>>> but also has to use existing i2c stuff to control HDMIPHY clock. I had a<br> > >>>> quick review to Generic PHY Framework[v6] but I didn't see that the PHY<br> > >>>> module could generically support more features such as i2c stuff.<br> > >>><br> > >>> I don't think PHY framework needs to provide i2c interfaces to program<br> > >>> certain configurations. Instead in one of the callbacks (init/on/off)<br> > >>> PHY driver can program whatever it wants using any of the interfaces it<br> > >>> needs. IMO PHY framework should work independent of the interfaces.<br> > >><br> > >> In exnoys hdmi case, i2c interface is not the exact issue. In exynos<br> > >> hdmi, hdmiphy should send i2c configuration about video clock<br> > >> information as the video mode information including resolution, bit per<br> > >> pixel, refresh rate passed from drm subsystem. So init/on/off callbacks<br> > >> of phy framework are not enough for exynos hdmiphy and it should have a<br> > >> callback to set video mode.<br> > >><br> > >> Do you have plan to add driver specific extend callback pointers to phy<br> > >> framework?<br> > >><br> > >> Currently, hdmi directly calls phy operations, but Rahul's another patch<br> > >> set, mentioned by Inki, divides hdmi and hdmiphy and hdmi and hdmiphy is<br> > >> connected with exynos hdmi own sub driver callback operations.<br> > >><br> > >> IMHO, if phy framework can support extend callback feature, then this<br> > >> own sub driver callbacks can be replaced with phy framework at long term<br> > >> view.<br> > ><br> > > Extended callbacks are always welcome. I can also use phy device<br> > > private data to pass on private ops like get_pixelclk and set_pixelclk.<br> ><br> > I would recommend creating a wrapper to the existing PHY framework<br> > for HDMI PHY. That way, we can have other HDMI phys added<br> > easily. We need to figure out all the ops that might be needed by the<br> > HDMI PHY to be added to the wrapper.<br> > IMO extended callbacks can lead to abuse of the system and should be<br> > used only when absolutely necessary.<br> ><br> > Thanks<br> > Kishon<br> ><br> ><br> > Thanks Kishon,<br> ><br> > I have started working on this wrapper layer which is customized for video phys.<br> > As if now, adding set_dv_timing, get_dv_timing as the only additional callbacks.<br> > I will post the RFC patches.<br> <br> </div></div>Idea of creating wrapper layer for different types of controller is shot down<br> in the community [1] :-s<br> <br> [1] -> <a href="http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/181710.html" target="_blank">http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/181710.html</a><br> <br> Thanks<br> <span><font color="#888888">Kishon<br> </font></span></blockquote></div><div><br></div><div>Thanks Kishon,</div><div><br></div><div>I didn't notice the mail thread. I will continue the discussion there.</div><div><br></div><div>Regards,</div><div>Rahul Sharma</div>