search for: powergated

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,

On Tue, Jan 06, 2015 at 08:03:03PM +0800, Vince Hsu wrote: > 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,

...you mentioned is correct. The resets > of all modules in a domain need to be asserted and the memory clients need to > be flushed. All this needs to be done with module clocks enabled (resets are > synchronous). Then all module clocks need to be disabled and then the > partition can be powergated. After ungating, the module resets need to be > deasserted and the FLUSH bit cleared with clocks enabled. Yeah. I plan to have the information of all the clock client of the partitions and the memory clients be defined statically in c source, e.g. pmc-tegra124.c. All modules can declare which d...

...> > >of all modules in a domain need to be asserted and the memory clients need to > > >be flushed. All this needs to be done with module clocks enabled (resets are > > >synchronous). Then all module clocks need to be disabled and then the > > >partition can be powergated. After ungating, the module resets need to be > > >deasserted and the FLUSH bit cleared with clocks enabled. > > Yeah. I plan to have the information of all the clock client of the > > partitions and > > the memory clients be defined statically in c source, e.g. pmc-tegra...

On Tue, Jan 06, 2015 at 03:18:22PM +0100, Thierry Reding wrote: > * PGP Signed by an unknown key > > 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> > > --- >

On 02:29:32PM Jan 06, Thierry Reding wrote: > * PGP Signed by an unknown key > > On Tue, Jan 06, 2015 at 08:03:03PM +0800, Vince Hsu wrote: > > On 01/06/2015 07:15 PM, Thierry Reding wrote: > > >> Old 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

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.

...correct. The resets > >of all modules in a domain need to be asserted and the memory clients need to > >be flushed. All this needs to be done with module clocks enabled (resets are > >synchronous). Then all module clocks need to be disabled and then the > >partition can be powergated. After ungating, the module resets need to be > >deasserted and the FLUSH bit cleared with clocks enabled. > Yeah. I plan to have the information of all the clock client of the > partitions and > the memory clients be defined statically in c source, e.g. pmc-tegra124.c. > All modu...

...correct. The resets > >of all modules in a domain need to be asserted and the memory clients need to > >be flushed. All this needs to be done with module clocks enabled (resets are > >synchronous). Then all module clocks need to be disabled and then the > >partition can be powergated. After ungating, the module resets need to be > >deasserted and the FLUSH bit cleared with clocks enabled. > Yeah. I plan to have the information of all the clock client of the > partitions and > the memory clients be defined statically in c source, e.g. pmc-tegra124.c. > All modu...

...of all modules in a domain need to be asserted and the memory clients need to > > > >be flushed. All this needs to be done with module clocks enabled (resets are > > > >synchronous). Then all module clocks need to be disabled and then the > > > >partition can be powergated. After ungating, the module resets need to be > > > >deasserted and the FLUSH bit cleared with clocks enabled. > > > Yeah. I plan to have the information of all the clock client of the > > > partitions and > > > the memory clients be defined statically in c so...

...the implementation you mentioned is correct. The resets of all modules in a domain need to be asserted and the memory clients need to be flushed. All this needs to be done with module clocks enabled (resets are synchronous). Then all module clocks need to be disabled and then the partition can be powergated. After ungating, the module resets need to be deasserted and the FLUSH bit cleared with clocks enabled. Cheers, Peter.

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 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git

On Wed, Jan 07, 2015 at 02:27:10PM +0100, Thierry Reding wrote: > > Yeah. I plan to have the information of all the clock client of the > > partitions and > > the memory clients be defined statically in c source, e.g. pmc-tegra124.c. > > All modules can declare which domain they belong to in DT. One domain can > > be really power gated only when no module is awake.

On Wed, Jan 07, 2015 at 10:28:29PM +0800, Vince Hsu wrote: > On 04:08:52PM Jan 07, Peter De Schrijver wrote: > > On Wed, Jan 07, 2015 at 02:27:10PM +0100, Thierry Reding wrote: > > > > > > Yeah. I plan to have the information of all the clock client of the > > > > partitions and > > > > the memory clients be defined statically in c source, e.g.

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