search for: powerdomain

...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 same power domain as...

...; > > > > 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? > Agree. And as long as the driver has t...

...>> >> Also adding Peter whom I had discussed this with earlier. Can we finally >> get this converted? I'd rather not keep complicating this custom API to >> avoid making the conversion even more difficult. > Conceptually I fully agree that we should use runtime PM and powerdomains. > However I don't think 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 ne...

...ng Peter whom I had discussed this with earlier. Can we finally > > >>get this converted? I'd rather not keep complicating this custom API to > > >>avoid making the conversion even more difficult. > > >Conceptually I fully agree that we should use runtime PM and powerdomains. > > >However I don't think 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 > > >sync...

...le. 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? Agree. And as long as the driver has the correct reset pro...

...ou 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? >> Agree. And as long as the...

...t;>Also adding Peter whom I had discussed this with earlier. Can we finally > >>get this converted? I'd rather not keep complicating this custom API to > >>avoid making the conversion even more difficult. > >Conceptually I fully agree that we should use runtime PM and powerdomains. > >However I don't think 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...

...had discussed this with earlier. Can we finally > > > >>get this converted? I'd rather not keep complicating this custom API to > > > >>avoid making the conversion even more difficult. > > > >Conceptually I fully agree that we should use runtime PM and powerdomains. > > > >However I don't think 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 &gt...

...s of true/false not 1/0 security: Use bool function return values of true/false not 1/0 sound: wm5100-tables: Use bool function return values of true/false not 1/0 arch/arm/include/asm/dma-mapping.h | 8 ++-- arch/arm/include/asm/kvm_emulate.h | 2 +- arch/arm/mach-omap2/powerdomain.c | 14 +++--- arch/arm64/include/asm/dma-mapping.h | 2 +- arch/hexagon/include/asm/dma-mapping.h | 2 +- arch/ia64/include/asm/dma-mapping.h | 2 +- arch/mips/include/asm/dma-mapping.h | 2 +- arch/powerpc/include/asm/dcr-native.h | 2 +- arc...

...s of true/false not 1/0 security: Use bool function return values of true/false not 1/0 sound: wm5100-tables: Use bool function return values of true/false not 1/0 arch/arm/include/asm/dma-mapping.h | 8 ++-- arch/arm/include/asm/kvm_emulate.h | 2 +- arch/arm/mach-omap2/powerdomain.c | 14 +++--- arch/arm64/include/asm/dma-mapping.h | 2 +- arch/hexagon/include/asm/dma-mapping.h | 2 +- arch/ia64/include/asm/dma-mapping.h | 2 +- arch/mips/include/asm/dma-mapping.h | 2 +- arch/powerpc/include/asm/dcr-native.h | 2 +- arc...

...s of true/false not 1/0 security: Use bool function return values of true/false not 1/0 sound: wm5100-tables: Use bool function return values of true/false not 1/0 arch/arm/include/asm/dma-mapping.h | 8 ++-- arch/arm/include/asm/kvm_emulate.h | 2 +- arch/arm/mach-omap2/powerdomain.c | 14 +++--- arch/arm64/include/asm/dma-mapping.h | 2 +- arch/hexagon/include/asm/dma-mapping.h | 2 +- arch/ia64/include/asm/dma-mapping.h | 2 +- arch/mips/include/asm/dma-mapping.h | 2 +- arch/powerpc/include/asm/dcr-native.h | 2 +- arc...

...untime PM instead. > > Also adding Peter whom I had discussed this with earlier. Can we finally > get this converted? I'd rather not keep complicating this custom API to > avoid making the conversion even more difficult. Conceptually I fully agree that we should use runtime PM and powerdomains. However I don't think 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 a...

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

...t;>Also adding Peter whom I had discussed this with earlier. Can we finally > >>get this converted? I'd rather not keep complicating this custom API to > >>avoid making the conversion even more difficult. > >Conceptually I fully agree that we should use runtime PM and powerdomains. > >However I don't think 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...

...security: Use bool function return values of true/false not 1/0 > sound: wm5100-tables: Use bool function return values of true/false not 1/0 > > arch/arm/include/asm/dma-mapping.h | 8 ++-- > arch/arm/include/asm/kvm_emulate.h | 2 +- > arch/arm/mach-omap2/powerdomain.c | 14 +++--- > arch/arm64/include/asm/dma-mapping.h | 2 +- > arch/hexagon/include/asm/dma-mapping.h | 2 +- > arch/ia64/include/asm/dma-mapping.h | 2 +- > arch/mips/include/asm/dma-mapping.h | 2 +- > arch/powerpc/include/asm/dcr-nat...

...security: Use bool function return values of true/false not 1/0 > sound: wm5100-tables: Use bool function return values of true/false not 1/0 > > arch/arm/include/asm/dma-mapping.h | 8 ++-- > arch/arm/include/asm/kvm_emulate.h | 2 +- > arch/arm/mach-omap2/powerdomain.c | 14 +++--- > arch/arm64/include/asm/dma-mapping.h | 2 +- > arch/hexagon/include/asm/dma-mapping.h | 2 +- > arch/ia64/include/asm/dma-mapping.h | 2 +- > arch/mips/include/asm/dma-mapping.h | 2 +- > arch/powerpc/include/asm/dcr-nat...