Thanks all, On Fri, Jun 14, 2013 at 11:39 AM, 김승우 <sw0312.kim@xxxxxxxxxxx> wrote: > Hello Kishon, > > On 2013년 06월 13일 21:54, Kishon Vijay Abraham I wrote: >> Hi, >> >> On Thursday 13 June 2013 04:51 PM, Inki Dae wrote: >>> >>> >>>> -----Original Message----- >>>> From: Sylwester Nawrocki [mailto:s.nawrocki@xxxxxxxxxxx] >>>> Sent: Thursday, June 13, 2013 5:56 PM >>>> To: Rahul Sharma >>>> Cc: Rahul Sharma; Inki Dae; linux-samsung-soc@xxxxxxxxxxxxxxx; >>>> devicetree- >>>> discuss@xxxxxxxxxxxxxxxx; DRI mailing list; Kukjin Kim; Seung-Woo Kim; >>>> Sean Paul; sunil joshi; Kishon Vijay Abraham I; Stephen Warren; >>>> grant.likely@xxxxxxxxxx >>>> Subject: Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with >>>> pmu reg control >>>> >>>> Hi, >>>> >>>> On 06/13/2013 06:26 AM, Rahul Sharma wrote: >>>>> Mr. Dae, >>>>> >>>>> Thanks for your valuable inputs. >>>>> >>>>> I posted it as RFC because, I also have received comments to register >>>>> hdmiphy as a clock controller. As we always configure it for specific >>>>> frequency, hdmi-phy looks similar to a PLL. But it really doesn't >>>>> belong to that class. Secondly prior to exynos5420, it was a i2c >>>>> device. I am not sure we can register a I2C device as a clock >>>>> controller. I wanted to discuss and explore this option here. >>>> >>>> Have you considered using the generic PHY framework for those HDMI >>>> PHY devices [1] ? I guess we could add a dedicated group of ops for >>>> video PHYs, similarly as is is done with struct v4l2_subdev_ops. For >>>> configuring things like the carrier/pixel clock frequency or anything >>>> what's common across the video PHYs. >>>> >>>> Perhaps you could have a look and see if this framework would be >>>> useful for HDMI and possibly point out anything what might be missing ? >>>> >>>> I'm not sure it it really solves the issues specific to the Exynos >>>> HDMI but at least with a generic PHY driver the PHY module would be >>>> separate from the PHY controller, as often same HDMI DPHY can be used >>>> with various types of a HDMI controller. So this would allow to not >>>> duplicate the HDMI PHY drivers in the long-term perspective. >>> >>> Yeah, at least, it seems that we could use PHY module to control PMU >>> register, HDMI_PHY_CONTROL. However, PHY module provides only init/on/off >>> callbacks. As you may know, HDMIPHY needs i2c interfaces to control >>> HDMIPHY >>> clock. So with PHY module, HDMIPHY driver could enable PMU more >>> generically, >>> but also has to use existing i2c stuff to control HDMIPHY clock. I had a >>> quick review to Generic PHY Framework[v6] but I didn't see that the PHY >>> module could generically support more features such as i2c stuff. >> >> I don't think PHY framework needs to provide i2c interfaces to program >> certain configurations. Instead in one of the callbacks (init/on/off) >> PHY driver can program whatever it wants using any of the interfaces it >> needs. IMO PHY framework should work independent of the interfaces. > > In exnoys hdmi case, i2c interface is not the exact issue. In exynos > hdmi, hdmiphy should send i2c configuration about video clock > information as the video mode information including resolution, bit per > pixel, refresh rate passed from drm subsystem. So init/on/off callbacks > of phy framework are not enough for exynos hdmiphy and it should have a > callback to set video mode. > > Do you have plan to add driver specific extend callback pointers to phy > framework? > > Currently, hdmi directly calls phy operations, but Rahul's another patch > set, mentioned by Inki, divides hdmi and hdmiphy and hdmi and hdmiphy is > connected with exynos hdmi own sub driver callback operations. > > IMHO, if phy framework can support extend callback feature, then this > own sub driver callbacks can be replaced with phy framework at long term > view. Extended callbacks are always welcome. I can also use phy device private data to pass on private ops like get_pixelclk and set_pixelclk. Similar logic has been used to pass struct omap_usb to usb phy controller. I can add these changes for migration of hdmiphy to generic phy framwork to my hdmiphy separation patch set. regards, Rahul Sharma. > > Thanks and Regards, > - Seung-Woo Kim > >> >> For example, twl4030 phy driver actually uses i2c to program its >> registers but still it uses the PHY framework [1]. >> >> [1] --> http://www.gossamer-threads.com/lists/linux/kernel/1729414 >> >> Thanks >> Kishon >> -- >> To unsubscribe from this list: send the line "unsubscribe >> linux-samsung-soc" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > -- > Seung-Woo Kim > Samsung Software R&D Center > -- > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |