search for: ungate

...erence between having a reference and actually enabling the clock. the domain powergate method will only be called when the clocks of all modules in the domain are off. So the powergate method can then turn them on again, do the module resets and client flushes and then disable them again. Same for ungate. So I don't see a problem here? Cheers, Peter.

...t; > one domain might not equal to the clocks of the module. The reset is > > not either. > > So I don't get the clock and reset from module. How do you think? > > > > I think it's indeed better to have a direct reference to the required clocks > to powergate/ungate a domain. As you said, there is no easy way to derive the > required clocks from the DT module declarations. My suggestion would be to > have powerdomain definitions in DT and for each domain have references to > the required clocks and resets. > And specify the dependencies between do...

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

...qual to the clocks of the module. The reset is > > > not either. > > > So I don't get the clock and reset from module. How do you think? > > > > > > > I think it's indeed better to have a direct reference to the required clocks > > to powergate/ungate a domain. As you said, there is no easy way to derive the > > required clocks from the DT module declarations. My suggestion would be to > > have powerdomain definitions in DT and for each domain have references to > > the required clocks and resets. > > > And specify th...

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.

...nly be called when the clocks of > all modules in the domain are off. No, the power domain will be disabled when all devices in the domain are idle. > So the powergate method can then turn them on again, do the module > resets and client flushes and then disable them again. Same for > ungate. So I don't see a problem here? I think that could work, but we'd need to make sure that drivers that use runtime PM and are connected to a power domain enable clocks only after taking a runtime PM reference and disable the clocks before they release that reference. So to simplify things,...

.... Note the clock > clients of > one domain might not equal to the clocks of the module. The reset is > not either. > So I don't get the clock and reset from module. How do you think? > I think it's indeed better to have a direct reference to the required clocks to powergate/ungate a domain. As you said, there is no easy way to derive the required clocks from the DT module declarations. My suggestion would be to have powerdomain definitions in DT and for each domain have references to the required clocks and resets. Cheers, Peter.

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

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

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

On Tue, Jan 06, 2015 at 05:34:01PM +0800, Vince Hsu wrote: > > On 01/05/2015 11:25 PM, Thierry Reding wrote: > >* PGP Signed by an 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

Am Donnerstag, den 25.12.2014, 10:28 +0800 schrieb Vince Hsu: > 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

On Tue, Jan 06, 2015 at 08:13:01PM +0800, Vince Hsu wrote: > > On 01/06/2015 07:36 PM, Thierry Reding wrote: > >* PGP Signed by an unknown key > > > >On Tue, Jan 06, 2015 at 05:34:01PM +0800, Vince Hsu wrote: > >>On 01/05/2015 11:25 PM, Thierry Reding wrote: > >>>>Old Signed by an unknown key > >>>On Thu, Dec 25, 2014 at 10:42:58AM

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/nouveau_platform.c index

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. pmc-tegra124.c. > > > All modules can declare which domain they belong to in DT.

On 01/07/2015 10:48 PM, Thierry Reding wrote: > * PGP Signed by an unknown key > > 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

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

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