lkml.org 
[lkml]   [2012]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH] clk: add extension API
On Thu, May 31, 2012 at 12:43:01PM +0300, Peter De Schrijver wrote:
> > > > on Tegra:
> > > >
> > > > device_reset(dev)
> > > > -> dev_pm_domain->reset()
> > > > -> tegra_periph_reset()
> > > >
> > >
> > > These methods are also needed internally by the powergating code.
> >
> > so ? Just call them when you need...
> >
>
> the powergating code calls assert and deassert indepedently
> ie:
>
> tegra_periph_reset_assert()
>
> do stuff
>
> tegra_periph_reset_assert()

I don't see the issue here. expose tegra_periph_reset() for the device
API only, internally you can do whatever you like. Call them
independently if you need.

> > > > on OMAP:
> > > >
> > > > device_reset(dev)
> > > > -> dev_pm_domain->reset()
> > > > -> omap_hwmod_reset()
> > > >
> > > >
> > > > btw:
> > > >
> > > > tegra_periph_reset(....)
> > > > {
> > > > tegra_periph_reset_assert(...);
> > > > udelay(2);
> > > > tegra_periph_reset_deassert(...);
> > > > }
> > >
> > > which uses the clockframework currently.
> >
> > no problems there. The point is that you already know which clock feed
> > into which device, so if you have a device-based API for device
> > soft-reset, you can figure out which exact clock to toggle, right ?
>
> you have the struct clk, you could dive into that and grab clk_hw and call
> some function directly. But sounds quite horrible to me.

Well, that's just because struct device doesn't know about its own clock
providers, right ? Should that be patched too ?

Russell, as the orignal author of the clk API, what do you think ?

--
balbi
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2012-05-31 12:21    [W:0.255 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site