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. Regards, Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |