Rahul, ping~~~
2013/8/1 Rahul Sharma <r.sh.o...@gmail.com> > Thanks Sylwester, > > On Wed, Jul 31, 2013 at 5:41 PM, Sylwester Nawrocki > <s.nawro...@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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
_______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
