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

[Inki Dae]

Rahul, ping~~~


2013/8/1 Rahul Sharma <r.sh.open at gmail.com>

> Thanks Sylwester,
>
> On Wed, Jul 31, 2013 at 5:41 PM, Sylwester Nawrocki
> <s.nawrocki at samsung.com> wrote:
> > Hi Rahul,
> >
> > On 07/31/2013 01:23 PM, Rahul Sharma wrote:
> >>>> I think your hdmiphy pmu patch is good enough just if dt binding for
> pmu
> >>>> >> is in hdmiphy binding instead of hdmi binding. So I recommended to
> make
> >>>> >> pmu patch set on the top of independent hdmiphy patch set because
> with
> >>>> >> independent hdmiphy patch set hdmiphy pmu code is moved to hdmiphy
> driver.
> >>>> >>
> >>>> >> Is it possible that hdmi driver references pmu information from
> hdmiphy
> >>>> >> binding? If that, it seems one possible solution to fix current
> exynos
> >>>> >> hdmi broken.
> >>>> >>
> >>>> >> Thanks and Regards,
> >>>> >> - Seung-Woo Kim
> >>>> >>
> >>> >
> >>> > I can surely do that but, I am worried about hdmiphy control bus.
> >>> > change In 5420. It is changed to platform bus from i2c. Isolating
> >>> > hdmiphy from hdmi driver seems the only clean method to handle
> >>> > control bus change, changed phy configurations and power control
> >>> > through PMU bit.
> >>> >
> >>> > To fix broken hdmi for 5420, I can again post the "hdmiphy
> >>> > separation patches" to place hdmiphy driver in DRM. Later we can
> >>> > migrate to Generic Phy Framework.
> >>> >
> >>
> >> Hi Seung Woo, Mr. Dae, Sylwester,
> >>
> >> What you say on this? Shall I separate hdmiphy in following manner:
> >>
> >> 1) Move all phy related code to hdmiphy driver i.e. exynos_hdmiphy.c
> >> 2) hdmiphy driver exposes power_on/off and set_pixel callbacks for
> >> hdmi driver.
> >> 3) let hdmi driver behave as phy controller for hdmiphy.
> >> 4) move PMU bit control to hdmiphy driver, instead of hdmi driver.
> >>
> >> This way we will be very close to generic phy framework implementation
> >> and migration to generic phy framework will be just a cakewalk.
> >
> > This all sound good to me, it seem natural to put the HDMI PHY
> > functionality into a separate module. Hardware-wise the PHY is quite
> > separate and as experience shows different PHYs can be attached to
> > same controller. Well, we have well known that before...
> >
> > I'm not sure what the problem is with adding subsystem specific
> > classes of operations (set of callback) to the generic PHY API, until
> > that gets sorted out your approach looks good to me.
> >
> > As a side note, originally the V4L2 driver exposed the HDMI PHY
> > as struct v4l2_subdev object, have a look at drivers/media/platform/
> > s5p-tv/hdmiphy_drv.c. And in case of exynos5 we would just have
> > created a platform driver for the HDMI PHY which would expose same
> > subdev interface. So something similar as you proposed above.
> >
>
> Yea, it is very similar to s5p-tv/hdmiphy_drv.c. On top of this, I want
> to make hdmiphy platform device as Clock provider for hdmiphy clock,
> as you have done for cam_clkout*. Hdmi driver will call set_rate on this
> clock.
>
> I will post patches for the above separation and move hdmiphy to Generic
> Phy framework after we get clarity on how to add additional callbacks.
>
> Thanks for your reply.
>
> Regards,
> Rahul Sharma
>
> >
> > Regards,
> > Sylwester
> >
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130828/4166f26b/attachment-0001.html>