[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120531094301.GT8026@tbergstrom-lnx.Nvidia.com>
Date: Thu, 31 May 2012 12:43:01 +0300
From: Peter De Schrijver <pdeschrijver@...dia.com>
To: Felipe Balbi <balbi@...com>
CC: Stephen Boyd <sboyd@...eaurora.org>,
Russell King <linux@....linux.org.uk>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Mike Turquette <mturquette@...com>
Subject: Re: [RFC PATCH] clk: add extension API
> > > 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()
> > > 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.
Cheers,
Peter.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists