Thanks Sylwester, On Wed, Jul 31, 2013 at 5:41 PM, Sylwester Nawrocki <s.nawrocki@xxxxxxxxxxx> 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 > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
