On 05/16/2015 01:12 AM, Benson Leung wrote:
On Fri, May 15, 2015 at 5:07 AM, Bill Huang wrote:
This fixes two things.
- Read the correct IDDQ register
- Check the correct IDDQ bit position
Signed-off-by: Bill Huang
Reviewed-by: Benson Leung
By the way, does it also make sense to do the
On 05/16/2015 01:12 AM, Benson Leung wrote:
On Fri, May 15, 2015 at 5:07 AM, Bill Huang bilhu...@nvidia.com wrote:
This fixes two things.
- Read the correct IDDQ register
- Check the correct IDDQ bit position
Signed-off-by: Bill Huang bilhu...@nvidia.com
Reviewed-by: Benson Leung
On 12/23/2013 01:06 PM, Viresh Kumar wrote:
Ccc'ing Grant and Rob as well.
On 20 December 2013 21:59, Stephen Warren wrote:
No, I definitely don't agree here. The rules for arch/arm64 are: no
platform-specific code. We should immediately start planning for that.
If this means renaming the
On 12/23/2013 01:06 PM, Viresh Kumar wrote:
Ccc'ing Grant and Rob as well.
On 20 December 2013 21:59, Stephen Warren swar...@wwwdotorg.org wrote:
No, I definitely don't agree here. The rules for arch/arm64 are: no
platform-specific code. We should immediately start planning for that.
If this
On 12/20/2013 06:33 PM, Viresh Kumar wrote:
On 20 December 2013 15:55, bilhuang wrote:
Don't you think it worth creating a file here so this can be shared to
arm64?
We will see how to handle virtual devices when we will start getting
arm64 SoCs. Probably we might end up writing a single file
On 12/20/2013 05:31 PM, Viresh Kumar wrote:
On 19 December 2013 16:48, Bill Huang wrote:
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index ce52ed9..22dfc43 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -225,6 +225,18 @@ config
On 12/20/2013 05:31 PM, Viresh Kumar wrote:
On 19 December 2013 16:48, Bill Huang bilhu...@nvidia.com wrote:
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index ce52ed9..22dfc43 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -225,6 +225,18
On 12/20/2013 06:33 PM, Viresh Kumar wrote:
On 20 December 2013 15:55, bilhuang bilhu...@nvidia.com wrote:
Don't you think it worth creating a file here so this can be shared to
arm64?
We will see how to handle virtual devices when we will start getting
arm64 SoCs. Probably we might end up
On 12/19/2013 01:29 PM, Viresh Kumar wrote:
On 19 December 2013 10:56, bilhuang wrote:
I'm not sure virtual regulator for CPU is a good idea, in addition to that,
we don't have a single SoC OPP table, we need several which are speedo-id
and process-id dependant, but generic cpufreq-cpu0
On 12/18/2013 10:39 PM, Viresh Kumar wrote:
On 18 December 2013 17:03, bilhuang wrote:
cpufreq-cpu0 driver will call regulator_set_voltage_tol() directly according
to the pre-defined OPP freq/volt pairs, the regulator drivers could be
shared by other SoC so is not suitable to handle
On 12/18/2013 07:11 PM, Viresh Kumar wrote:
On 17 December 2013 16:22, bilhuang wrote:
Tegra20 DVFS is a little bit complicated due to the fact that we can't scale
VDD_CPU directly, there are constraints or relationship to other power rails
so I don't think it is a good idea to use generic
On 12/18/2013 07:11 PM, Viresh Kumar wrote:
On 17 December 2013 16:22, bilhuang bilhu...@nvidia.com wrote:
Tegra20 DVFS is a little bit complicated due to the fact that we can't scale
VDD_CPU directly, there are constraints or relationship to other power rails
so I don't think it is a good idea
On 12/18/2013 10:39 PM, Viresh Kumar wrote:
On 18 December 2013 17:03, bilhuang bilhu...@nvidia.com wrote:
cpufreq-cpu0 driver will call regulator_set_voltage_tol() directly according
to the pre-defined OPP freq/volt pairs, the regulator drivers could be
shared by other SoC so is not suitable
On 12/19/2013 01:29 PM, Viresh Kumar wrote:
On 19 December 2013 10:56, bilhuang bilhu...@nvidia.com wrote:
I'm not sure virtual regulator for CPU is a good idea, in addition to that,
we don't have a single SoC OPP table, we need several which are speedo-id
and process-id dependant, but generic
On 12/17/2013 02:54 PM, Viresh Kumar wrote:
On 5 December 2013 13:14, Bill Huang wrote:
Re-model Tegra cpufreq driver to support all Tegra series of SoCs.
* Make tegra-cpufreq.c a generic Tegra cpufreq driver.
* Move Tegra20 specific codes into tegra20-cpufreq.c.
* Bind Tegra cpufreq dirver
On 12/17/2013 02:31 PM, Viresh Kumar wrote:
On 5 December 2013 13:14, Bill Huang wrote:
Move the call from module_init to Tegra machine codes so it won't be
called in a multi-platform kernel running on non-Tegra SoCs.
Signed-off-by: Bill Huang
---
arch/arm/mach-tegra/tegra.c |2 ++
On 12/17/2013 02:26 PM, Viresh Kumar wrote:
On 5 December 2013 13:14, Bill Huang wrote:
This patch series remodel Tegra cpufreq driver to make it more easy to
add new SoC support, in addition to that, adding probe function in the
driver to let probe defer can be used to control init sequence
On 12/17/2013 12:58 AM, Stephen Warren wrote:
On 12/16/2013 03:52 AM, bilhuang wrote:
On 12/14/2013 07:21 AM, Stephen Warren wrote:
On 12/12/2013 02:33 AM, Bill Huang wrote:
Re-model Tegra20 cpufreq driver as below.
* Rename tegra-cpufreq.c to tegra20-cpufreq.c since this file supports
On 12/17/2013 02:31 PM, Viresh Kumar wrote:
On 5 December 2013 13:14, Bill Huang bilhu...@nvidia.com wrote:
Move the call from module_init to Tegra machine codes so it won't be
called in a multi-platform kernel running on non-Tegra SoCs.
Signed-off-by: Bill Huang bilhu...@nvidia.com
---
On 12/17/2013 02:26 PM, Viresh Kumar wrote:
On 5 December 2013 13:14, Bill Huang bilhu...@nvidia.com wrote:
This patch series remodel Tegra cpufreq driver to make it more easy to
add new SoC support, in addition to that, adding probe function in the
driver to let probe defer can be used to
On 12/17/2013 12:58 AM, Stephen Warren wrote:
On 12/16/2013 03:52 AM, bilhuang wrote:
On 12/14/2013 07:21 AM, Stephen Warren wrote:
On 12/12/2013 02:33 AM, Bill Huang wrote:
Re-model Tegra20 cpufreq driver as below.
* Rename tegra-cpufreq.c to tegra20-cpufreq.c since this file supports
On 12/17/2013 02:54 PM, Viresh Kumar wrote:
On 5 December 2013 13:14, Bill Huang bilhu...@nvidia.com wrote:
Re-model Tegra cpufreq driver to support all Tegra series of SoCs.
* Make tegra-cpufreq.c a generic Tegra cpufreq driver.
* Move Tegra20 specific codes into tegra20-cpufreq.c.
* Bind
On 12/14/2013 07:21 AM, Stephen Warren wrote:
On 12/12/2013 02:33 AM, Bill Huang wrote:
Re-model Tegra20 cpufreq driver as below.
* Rename tegra-cpufreq.c to tegra20-cpufreq.c since this file supports
only Tegra20.
* Add probe function so defer probe can be used when we're going to
On 12/14/2013 07:21 AM, Stephen Warren wrote:
On 12/12/2013 02:33 AM, Bill Huang wrote:
Re-model Tegra20 cpufreq driver as below.
* Rename tegra-cpufreq.c to tegra20-cpufreq.c since this file supports
only Tegra20.
* Add probe function so defer probe can be used when we're going to
On 12/10/2013 01:32 AM, Stephen Warren wrote:
On 12/09/2013 01:44 AM, bilhuang wrote:
On 12/06/2013 07:04 AM, Stephen Warren wrote:
On 12/05/2013 12:44 AM, Bill Huang wrote:
Re-model Tegra cpufreq driver to support all Tegra series of SoCs.
* Make tegra-cpufreq.c a generic Tegra cpufreq
On 12/10/2013 01:32 AM, Stephen Warren wrote:
On 12/09/2013 01:44 AM, bilhuang wrote:
On 12/06/2013 07:04 AM, Stephen Warren wrote:
On 12/05/2013 12:44 AM, Bill Huang wrote:
Re-model Tegra cpufreq driver to support all Tegra series of SoCs.
* Make tegra-cpufreq.c a generic Tegra cpufreq
On 12/06/2013 07:04 AM, Stephen Warren wrote:
On 12/05/2013 12:44 AM, Bill Huang wrote:
Re-model Tegra cpufreq driver to support all Tegra series of SoCs.
* Make tegra-cpufreq.c a generic Tegra cpufreq driver.
* Move Tegra20 specific codes into tegra20-cpufreq.c.
* Bind Tegra cpufreq dirver
On 12/06/2013 06:54 AM, Stephen Warren wrote:
On 12/05/2013 12:44 AM, Bill Huang wrote:
Move the call from module_init to Tegra machine codes so it won't be
called in a multi-platform kernel running on non-Tegra SoCs.
diff --git a/include/linux/tegra-soc.h b/include/linux/tegra-soc.h
It
On 12/06/2013 06:54 AM, Stephen Warren wrote:
On 12/05/2013 12:44 AM, Bill Huang wrote:
Move the call from module_init to Tegra machine codes so it won't be
called in a multi-platform kernel running on non-Tegra SoCs.
diff --git a/include/linux/tegra-soc.h b/include/linux/tegra-soc.h
It
On 12/06/2013 07:04 AM, Stephen Warren wrote:
On 12/05/2013 12:44 AM, Bill Huang wrote:
Re-model Tegra cpufreq driver to support all Tegra series of SoCs.
* Make tegra-cpufreq.c a generic Tegra cpufreq driver.
* Move Tegra20 specific codes into tegra20-cpufreq.c.
* Bind Tegra cpufreq dirver
30 matches
Mail list logo
