[RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control

[Rahul Sharma]

Thanks all,

On Fri, Jun 14, 2013 at 11:39 AM, 김승우 <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]
>>>> Sent: Thursday, June 13, 2013 5:56 PM
>>>> To: Rahul Sharma
>>>> Cc: Rahul Sharma; Inki Dae; linux-samsung-soc at vger.kernel.org;
>>>> devicetree-
>>>> 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
>>>> 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.
Similar logic has been used to pass struct omap_usb to usb phy
controller. I can add these changes for migration of hdmiphy to
generic phy framwork to my hdmiphy separation patch set.

regards,
Rahul Sharma.

>
> Thanks and Regards,
> - Seung-Woo Kim
>
>>
>> For example, twl4030 phy driver actually uses i2c to program its
>> registers but still it uses the PHY framework [1].
>>
>> [1] --> http://www.gossamer-threads.com/lists/linux/kernel/1729414
>>
>> Thanks
>> Kishon
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-samsung-soc" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
> --
> Seung-Woo Kim
> Samsung Software R&D Center
> --
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html