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

[김승우]

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.

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
--