[RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control
Rahul Sharma
r.sh.open at gmail.com
Mon Jul 29 22:49:54 PDT 2013
On Tue, Jul 30, 2013 at 10:37 AM, Kishon Vijay Abraham I <kishon at ti.com>wrote:
> Hi,
>
> On Tuesday 30 July 2013 09:12 AM, Rahul Sharma wrote:
> >
> >
> > On Tue, Jun 18, 2013 at 5:07 PM, Kishon Vijay Abraham I <kishon at ti.com
> > <mailto: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
> > <mailto: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
> > <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
> > <mailto:linux-samsung-soc at vger.kernel.org>;
> > >>>>> devicetree-
> > >>>>> discuss at lists.ozlabs.org <mailto: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 <mailto: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.
>
> Idea of creating wrapper layer for different types of controller is shot
> down
> in the community [1] :-s
>
> [1] ->
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/181710.html
>
> Thanks
> Kishon
>
Thanks Kishon,
I didn't notice the mail thread. I will continue the discussion there.
Regards,
Rahul Sharma
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130730/d531e3fc/attachment.html>
More information about the dri-devel
mailing list