[RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control
Rahul Sharma
r.sh.open at gmail.com
Wed Jul 31 04:23:26 PDT 2013
On Tue, Jul 30, 2013 at 2:21 PM, Rahul Sharma <r.sh.open at gmail.com> wrote:
> Thanks Seung-Woo,
>
> On Tue, Jul 30, 2013 at 11:36 AM, Seung-Woo Kim <sw0312.kim at samsung.com> wrote:
>> Hi Rahul,
>>
>> On 2013년 07월 30일 12:42, 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.
>>
>> 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.
regards,
Rahul Sharma.
> regards,
> Rahul Sharma.
>
>>>
>>> regards,
>>> Rahul Sharma.
>>>
>>>
>>>
>>> _______________________________________________
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>>
>> --
>> Seung-Woo Kim
>> Samsung Software R&D Center
>> --
>>
More information about the dri-devel
mailing list