On Tuesday 18 June 2013 03:33 PM, Rahul Sharma wrote:
> Thanks all,
>
> On Fri, Jun 14, 2013 at 11:39 AM, ±è½Â¿ì <
sw0312.kim@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@samsung.com]
>>>>> Sent: Thursday, June 13, 2013 5:56 PM
>>>>> To: Rahul Sharma
>>>>> Cc: Rahul Sharma; Inki Dae;
linux-samsung-soc@vger.kernel.org;
>>>>> devicetree-
>>>>>
discuss@lists.ozlabs.org; DRI mailing list; Kukjin Kim; Seung-Woo Kim;
>>>>> Sean Paul; sunil joshi; Kishon Vijay Abraham I; Stephen Warren;
>>>>>
grant.likely@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.