search for: powergating

On Thu, Dec 25, 2014 at 10:28:08AM +0800, Vince Hsu wrote: > On 12/24/2014 09:16 PM, Lucas Stach wrote: > >Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu: > >>The Tegra124 and later Tegra SoCs have a sepatate rail gating register > >>to enable/disable the clamp. The original function > >>tegra_powergate_remove_clamping() is not sufficient for the

On Tue, Jan 06, 2015 at 10:11:41AM +0800, Vince Hsu wrote: > > On 01/05/2015 11:09 PM, Thierry Reding wrote: > >* PGP Signed by an unknown key > > > >On Thu, Dec 25, 2014 at 10:28:08AM +0800, Vince Hsu wrote: > >>On 12/24/2014 09:16 PM, Lucas Stach wrote: > >>>Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu: > >>>>The Tegra124

On Tue, Dec 23, 2014 at 06:39:55PM +0800, Vince Hsu wrote: > The flush operation of memory clients is needed for various IP blocks in > the Tegra SoCs to perform a clean reset. > > Signed-off-by: Vince Hsu <vinceh at nvidia.com> > --- > drivers/memory/tegra/mc.c | 21 +++++++++++++++++++++ > include/soc/tegra/mc.h | 23 ++++++++++++++++++++++- > 2 files changed,

...he power sequence of GK20A from the generic power > domain? No, what I mean is move the power gating into the PMC driver as part of the generic power domain implementation. At the same time, keep the control of the regulator within the gk20a driver. That way we can use runtime PM to control the powergating but we can still control the GPU voltage within Nouveau. Thierry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/nouveau/attachments/...

On 01/07/2015 06:19 PM, Peter De Schrijver wrote: > On Mon, Jan 05, 2015 at 04:09:33PM +0100, Thierry Reding wrote: >> * PGP Signed by an unknown key >> >> On Thu, Dec 25, 2014 at 10:28:08AM +0800, Vince Hsu wrote: >>> On 12/24/2014 09:16 PM, Lucas Stach wrote: >>>> Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu: >>>>> The

On 04:12:54PM Jan 07, Peter De Schrijver wrote: > On Wed, Jan 07, 2015 at 06:49:27PM +0800, Vince Hsu wrote: > > > > On 01/07/2015 06:19 PM, Peter De Schrijver wrote: > > >On Mon, Jan 05, 2015 at 04:09:33PM +0100, Thierry Reding wrote: > > >>* PGP Signed by an unknown key > > >> > > >>On Thu, Dec 25, 2014 at 10:28:08AM +0800, Vince Hsu

...> > 1) set the FLUSH_ENABLE bit for the client > 2) poll the FLUSH_DONE bit for the client > 3) assert reset to the client using the CAR > 4) deassert reset to the client using the CAR > 5) clear the FLUSH_ENABLE bit for the client > Do we ever need to do this outside a powergating or railgating sequence? > This is really inconvenient because we can't flush the client using a > single operation. So I think we'll need two functions here, something > like: tegra_mc_flush_enable/disable(), or tegra_mc_flush_{,de}assert(). > Or maybe even: tegra_mc_reset_{,de...

...m the generic power > > domain? > > No, what I mean is move the power gating into the PMC driver as part of > the generic power domain implementation. At the same time, keep the > control of the regulator within the gk20a driver. That way we can use > runtime PM to control the powergating but we can still control the GPU > voltage within Nouveau. Okay. Do you insist to introduce the generic power domain at this moment? If so, I can try to continue your previous work and rebase this series on that. That might take some time though. Thanks, Vince

On 01/05/2015 11:09 PM, Thierry Reding wrote: > * PGP Signed by an unknown key > > On Thu, Dec 25, 2014 at 10:28:08AM +0800, Vince Hsu wrote: >> On 12/24/2014 09:16 PM, Lucas Stach wrote: >>> Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu: >>>> The Tegra124 and later Tegra SoCs have a sepatate rail gating register >>>> to enable/disable

On 01/06/2015 07:15 PM, Thierry Reding wrote: > * PGP Signed by an unknown key > > On Tue, Jan 06, 2015 at 10:11:41AM +0800, Vince Hsu wrote: >> On 01/05/2015 11:09 PM, Thierry Reding wrote: >>>> Old Signed by an unknown key >>> On Thu, Dec 25, 2014 at 10:28:08AM +0800, Vince Hsu wrote: >>>> On 12/24/2014 09:16 PM, Lucas Stach wrote:

> > And specify the dependencies between domains in DT? > > I think the dependencies could be in the driver. Of course the power > domains are per-SoC data, so really shouldn't be in the DTS either (the > data is all implied by the compatible value) but there's no good way to > get at the clocks and resets without DT, so I think that's a reasonable > trade-off.

On Wed, Jan 07, 2015 at 06:49:27PM +0800, Vince Hsu wrote: > > On 01/07/2015 06:19 PM, Peter De Schrijver wrote: > >On Mon, Jan 05, 2015 at 04:09:33PM +0100, Thierry Reding wrote: > >>* PGP Signed by an unknown key > >> > >>On Thu, Dec 25, 2014 at 10:28:08AM +0800, Vince Hsu wrote: > >>>On 12/24/2014 09:16 PM, Lucas Stach wrote: >

On Wed, Jan 07, 2015 at 06:49:27PM +0800, Vince Hsu wrote: > > On 01/07/2015 06:19 PM, Peter De Schrijver wrote: > >On Mon, Jan 05, 2015 at 04:09:33PM +0100, Thierry Reding wrote: > >>* PGP Signed by an unknown key > >> > >>On Thu, Dec 25, 2014 at 10:28:08AM +0800, Vince Hsu wrote: > >>>On 12/24/2014 09:16 PM, Lucas Stach wrote: >

On Wed, Jan 07, 2015 at 10:19:52PM +0800, Vince Hsu wrote: > On 04:12:54PM Jan 07, Peter De Schrijver wrote: > > On Wed, Jan 07, 2015 at 06:49:27PM +0800, Vince Hsu wrote: > > > > > > On 01/07/2015 06:19 PM, Peter De Schrijver wrote: > > > >On Mon, Jan 05, 2015 at 04:09:33PM +0100, Thierry Reding wrote: > > > >>* PGP Signed by an unknown key

On Mon, Jan 05, 2015 at 04:09:33PM +0100, Thierry Reding wrote: > * PGP Signed by an unknown key > > On Thu, Dec 25, 2014 at 10:28:08AM +0800, Vince Hsu wrote: > > On 12/24/2014 09:16 PM, Lucas Stach wrote: > > >Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu: > > >>The Tegra124 and later Tegra SoCs have a sepatate rail gating register > >

On Tegra186, powergating is handled by the BPMP power domain provider and the "legacy" powergating API is not available. Therefore skip these calls if we are attached to a power domain. Signed-off-by: Mikko Perttunen <mperttunen at nvidia.com> --- drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 10 ++...

...you think? > > This whole situation is quite messy. The above sequence basically means > that drivers can't reset hardware modules because otherwise they might > race with the power domain code. It also means that we can't powergate The powerdomain framework won't call any powergating method as long as a module in the domain is still active. So as long as drivers don't try to reset the hw without having done a pm_runtime_get(), we shouldn't have such a race? > modules on demand because they might be in the same power domain as one > other module that's still b...

...on is quite messy. The above sequence basically means > > > that drivers can't reset hardware modules because otherwise they might > > > race with the power domain code. It also means that we can't powergate > > > > The powerdomain framework won't call any powergating method as long as a > > module in the domain is still active. So as long as drivers don't try to > > reset the hw without having done a pm_runtime_get(), we shouldn't have such > > a race? > Agree. And as long as the driver has the correct reset procedure, that should &...

Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu: > The Tegra124 and later Tegra SoCs have a sepatate rail gating register > to enable/disable the clamp. The original function > tegra_powergate_remove_clamping() is not sufficient for the enable > function. So add a new function which is dedicated to the GPU rail > gating. Also don't refer to the powergate ID since the

On Thu, Jan 08, 2015 at 11:32:06AM +0200, Peter De Schrijver wrote: > > > And specify the dependencies between domains in DT? > > > > I think the dependencies could be in the driver. Of course the power > > domains are per-SoC data, so really shouldn't be in the DTS either (the > > data is all implied by the compatible value) but there's no good way to