[RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control

[Rahul Sharma]

On Tue, Jun 18, 2013 at 5:07 PM, Kishon Vijay Abraham I <kishon at ti.com>wrote:

> Hi,
>
> On Tuesday 18 June 2013 03:33 PM, Rahul Sharma wrote:
> > Thanks all,
> >
> > On Fri, Jun 14, 2013 at 11:39 AM, 김승우 <sw0312.kim at samsung.com> 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 at samsung.com]
> >>>>> Sent: Thursday, June 13, 2013 5:56 PM
> >>>>> To: Rahul Sharma
> >>>>> Cc: Rahul Sharma; Inki Dae; linux-samsung-soc at vger.kernel.org;
> >>>>> devicetree-
> >>>>> discuss at lists.ozlabs.org; DRI mailing list; Kukjin Kim; Seung-Woo
> Kim;
> >>>>> Sean Paul; sunil joshi; Kishon Vijay Abraham I; Stephen Warren;
> >>>>> grant.likely at linaro.org
> >>>>> 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.
>
> I would recommend creating a wrapper to the existing PHY framework
> for HDMI PHY. That way, we can have other HDMI phys added
> easily. We need to figure out all the ops that might be needed by the
> HDMI PHY to be added to the wrapper.
> IMO extended callbacks can lead to abuse of the system and should be
> used only when absolutely necessary.
>
> Thanks
> Kishon
>

Thanks Kishon,

I have started working on this wrapper layer which is customized for video
phys.
As if now, adding set_dv_timing, get_dv_timing as the only additional
callbacks.
I will post the RFC patches.

regards,
Rahul Sharma.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130730/924b5482/attachment-0001.html>