[PATCH 2/2] usb: dwc3: exynos: use clk_prepare_enable and clk_disable_unprepare

Vivek Gautam gautamvivek1987 at gmail.com
Fri Mar 15 17:06:00 EST 2013


Hi,


On Thu, Mar 14, 2013 at 4:23 PM, Felipe Balbi <balbi at ti.com> wrote:
> Hi,
>
> On Thu, Mar 14, 2013 at 04:14:58PM +0530, Vivek Gautam wrote:
>> Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare
>> calls as required by common clock framework.
>>
>> Signed-off-by: Vivek Gautam <gautam.vivek at samsung.com>
>> CC: Felipe Balbi <balbi at ti.com>
>> CC: Kukjin Kim <kgene.kim at samsung.com>
>> ---
>>  drivers/usb/dwc3/dwc3-exynos.c |    6 +++---
>>  1 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
>> index 66ca9ac..b03f609 100644
>> --- a/drivers/usb/dwc3/dwc3-exynos.c
>> +++ b/drivers/usb/dwc3/dwc3-exynos.c
>> @@ -129,7 +129,7 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
>>       exynos->dev     = dev;
>>       exynos->clk     = clk;
>>
>> -     clk_enable(exynos->clk);
>> +     clk_prepare_enable(exynos->clk);
>
> eventually we need to pass this clock handling to dwc3/core.c. Just make
> sure it's optional since not all platforms need it.
>
True, as of now i could see only exynos platform getting a device
clock for dwc3-glue.
So, if not all platforms need to do this, why should we plan to move
this to dwc3/core.c ?

> I guess the best way would be to handle clocks via
> ->runtime_suspend()/->runtime_resume() ??

Right, but there was a doubt actually if you can please clear that.
In device probe, after enabling runtime_pm we would need to
'pm_runtime_get_sync' the device.
Thereby, in runtime_resume the clocks will be enabled.
Now as soon as the device probe finishes, the device will go in
suspend state, calling runtime_suspend
and the clocks would be disabled.
Now would it be possible for the controller to detect any connect/disconnect.

Pardon me if there is something very silly i am missing out.

>
> --
> balbi



-- 
Thanks & Regards
Vivek


More information about the devicetree-discuss mailing list