Messages in this thread | | | Date | Thu, 31 May 2012 12:46:17 +0300 | From | Felipe Balbi <> | Subject | Re: [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] | |