On 2 January 2014 16:38, bilhuang wrote:
> Actually, I don't have plan or resource on doing this, would it be better
> that you help to do that instead? Thanks.
Point taken. I am there to help if required. So, initially you can just make
Tegra work according to the new file we were talking
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 2 January 2014 16:38, bilhuang bilhu...@nvidia.com wrote:
Actually, I don't have plan or resource on doing this, would it be better
that you help to do that instead? Thanks.
Point taken. I am there to help if required. So, initially you can just make
Tegra work according to the new file we
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 file that creates the virtual device from
>
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 means renaming the file that creates the
On 12/20/2013 03:42 AM, bilhuang wrote:
> 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
>>
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 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 in cpufreq,
if required, that will create
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 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 ARM_TEGRA_CPUFREQ
> help
>
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 @@ config ARM_TEGRA_CPUFREQ
help
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 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 writing a single file in cpufreq,
if required,
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/20/2013 03:42 AM, bilhuang wrote:
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
On 12/19/2013 04:18 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
> support DVFS.
> * Create a fake cpufreq
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
support DVFS.
* Create a fake cpufreq platform device with its name being
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
support DVFS.
* Create a fake cpufreq platform device with its name being
On 12/19/2013 04:18 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
support DVFS.
* Create a fake cpufreq platform
20 matches
Mail list logo
