search for: ungat

...clocks and resets without DT, so I think that's a reasonable > trade-off. > > It seems to me like there are only two dependencies: > > DIS and DISB depend on SOR > VE depends on DIS > > That's according to 5.6.6 "Programming Guide for Power Gating and > Ungating" of the Tegra K1 TRM. It also seems like a bunch of modules are > part of seemingly unrelated domains. Especially SOR seems to cover a > large range of modules (MIPI-CAL, DPAUX, SOR, HDMI, DSI, DSIB and > HDA2HDMI). > > Given that we may want to more fine-grainedly control c...

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

...orrect. 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 domain they be...

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

...le 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 > be fine to occur between power ungating and gating sequences. > > > > > > modules on demand because they might be in the same power domain as one > > > other module that's still busy. > > > > > > > The powerdomain framework keeps track of which modules are active (by hooking >...

...t's a reasonable > > trade-off. > > > > It seems to me like there are only two dependencies: > > > > DIS and DISB depend on SOR > > VE depends on DIS > > > > That's according to 5.6.6 "Programming Guide for Power Gating and > > Ungating" of the Tegra K1 TRM. It also seems like a bunch of modules are > > part of seemingly unrelated domains. Especially SOR seems to cover a > > large range of modules (MIPI-CAL, DPAUX, SOR, HDMI, DSI, DSIB and > > HDA2HDMI). > > > > Given that we may want to more...

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

Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu: > This patch adds some missing pieces of the rail gaing/ungating sequence that > can improve the stability in theory. > > Signed-off-by: Vince Hsu <vinceh at nvidia.com> > --- > drm/nouveau_platform.c | 42 ++++++++++++++++++++++++++++++++++++++++++ > drm/nouveau_platform.h | 3 +++ > 2 files changed, 45 insertions(+) > >...

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 Thu, Dec 25, 2014 at 10:42:58AM +0800, Vince Hsu wrote: > > On 12/24/2014 09:23 PM, Lucas Stach wrote: > >Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu: > >>This patch adds some missing pieces of the rail gaing/ungating sequence that > >>can improve the stability in theory. > >> > >>Signed-off-by: Vince Hsu <vinceh at nvidia.com> > >>--- > >> drm/nouveau_platform.c | 42 ++++++++++++++++++++++++++++++++++++++++++ > >> drm/nouveau_platform.h | 3 +++ &...

On Sep 10, 2016, at 3:33 AM, Steve Canon <scanon at apple.com> wrote: >>> >>> Pretty much. In particular, imagine a user trying to debug an unexpected floating point result caused by conversion of a*b + c into fma(a, b, c). >> >> I think that’s unavoidable, because of the way the optimization levels work. Even fma contraction is on by default (something I’d

...n unknown key > > > >On Thu, Dec 25, 2014 at 10:42:58AM +0800, Vince Hsu wrote: > >>On 12/24/2014 09:23 PM, Lucas Stach wrote: > >>>Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu: > >>>>This patch adds some missing pieces of the rail gaing/ungating sequence that > >>>>can improve the stability in theory. > >>>> > >>>>Signed-off-by: Vince Hsu <vinceh at nvidia.com> > >>>>--- > >>>> drm/nouveau_platform.c | 42 ++++++++++++++++++++++++++++++++++++++++++ > &gt...

...Tegra contains some standard AXI <-> AHB <-> APB bridges. That a read is needed to assure the write is posted to the APB bus seems to imply that there is some write buffering in one of those bridges. Can we get this documented somewhere? And isn't it needed for the other partition ungating function too then? Regards, Lucas

...;>>On Thu, Dec 25, 2014 at 10:42:58AM +0800, Vince Hsu wrote: > >>>>On 12/24/2014 09:23 PM, Lucas Stach wrote: > >>>>>Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu: > >>>>>>This patch adds some missing pieces of the rail gaing/ungating sequence that > >>>>>>can improve the stability in theory. > >>>>>> > >>>>>>Signed-off-by: Vince Hsu <vinceh at nvidia.com> > >>>>>>--- > >>>>>> drm/nouveau_platform.c | 42 +++++++++++...

This patch adds some missing pieces of the rail gaing/ungating sequence that can improve the stability in theory. Signed-off-by: Vince Hsu <vinceh at nvidia.com> --- drm/nouveau_platform.c | 42 ++++++++++++++++++++++++++++++++++++++++++ drm/nouveau_platform.h | 3 +++ 2 files changed, 45 insertions(+) diff --git a/drm/nouveau_platform.c b/drm/nou...

...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 be fine to occur between power ungating and gating sequences. > > > modules on demand because they might be in the same power domain as one > > other module that's still busy. > > > > The powerdomain framework keeps track of which modules are active (by hooking > into runtime pm) and won't try...

...in 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 >> be fine to occur between power ungating and gating sequences. >> >>>> modules on demand because they might be in the same power domain as one >>>> other module that's still busy. >>>> >>> The powerdomain framework keeps track of which modules are active (by hooking >>> in...

...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 12/24/2014 09:23 PM, Lucas Stach wrote: > Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu: >> This patch adds some missing pieces of the rail gaing/ungating sequence that >> can improve the stability in theory. >> >> Signed-off-by: Vince Hsu <vinceh at nvidia.com> >> --- >> drm/nouveau_platform.c | 42 ++++++++++++++++++++++++++++++++++++++++++ >> drm/nouveau_platform.h | 3 +++ >> 2 files changed...

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