search for: powerg

...ince 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 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 GPU ID makes no > >>sense here. > >> > >>Signed-off-by: Vince Hsu...

...14 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 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 GPU ID makes no > >>>>sense here. > >>>> > &...

...resets = <&tegra_car 184>, <&mc TEGRA_SWGROUP_GPU>; reset-names = "module", "client"; }; ... }; }; The PMC driver could then grab the "module" and "client" resets and do something like this: reset_control_assert(powergate->rst_client); reset_control_assert(powergate->rst_module); reset_control_deassert(powergate->rst_module); reset_control_deassert(powergate->rst_client); Optionally the above could be extended with a reset_control_status()- loop. Alternatively reset_control_assert() would block un...

...> >>>>>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 GPU ID makes no > >>>>>>sense here. >...

...14 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 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 GPU ID makes no >>>>> sense here. >>>>> >&gt...

...> >>>>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 GPU ID makes no > > >>>>>sense here. &...

...> > 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...

...t;>>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 GPU ID makes no > > >>>>>>s...

...> 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 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 GPU ID makes no >>>> sense here. >>>> >>>> Signed...

...as 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 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 GPU ID makes no >>>>>> sense here. >>>>...

...> 1) domain->resume > 2) device->resume > > But then we're back to square one, namely that the MC flush doesn't work > properly, since it needs to be implemented in domain->suspend. Does that > mean we can't clock-gate modules? In order to ensure a proper powergate > sequence, the domain code would need to clk_enable() the module clock to > make sure it stays on during the reset sequence. But if the domain code > has a reference to the clock, then the driver can't clock-gate the > module anymore by calling clk_disable(). > > Am I mis...

...as 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 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 GPU ID makes no > >>>>>sense here. > >>&gt...

...as 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 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 GPU ID makes no > >>>>>sense here. > >>&gt...

...gt;>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 GPU ID makes no > > > >>>>&g...

...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 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 GPU ID makes no > > >>sense here. > > >> > > >>...

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 |...

...I don't get the clock and reset from module. How do 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...

...module. How do 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? &gt...

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 GPU ID makes no > sense here. > > Signed-off-by: Vince Hsu <vinceh at nvidia.com> To be hone...

...ume > > 2) device->resume > > > > But then we're back to square one, namely that the MC flush doesn't work > > properly, since it needs to be implemented in domain->suspend. Does that > > mean we can't clock-gate modules? In order to ensure a proper powergate > > sequence, the domain code would need to clk_enable() the module clock to > > make sure it stays on during the reset sequence. But if the domain code > > has a reference to the clock, then the driver can't clock-gate the > > module anymore by calling clk_disable()....