Thank you.
On 27/10/20 12:28 PM, Viresh Kumar wrote:
External email: Use caution opening links or attachments
On 27-10-20, 11:46, Sumit Gupta wrote:
Ping.
I was waiting for 5.10-rc1 to be released before I can start applying stuff for
5.11. Now that it is released, I will apply
written ndiv value from freq_table. Otherwise, print a
warning and return the reconstructed freq.
Signed-off-by: Sumit Gupta
---
Sending only this patch as other patch not required after the change
to convert 'pr_warn' to 'pr_info' in cpufreq core for unlisted freq.
Changelog
v1[2] ->
by switching to pr_info() instead
and print a single message only.
Reviewed-by: Sumit Gupta
Tested-by: Sumit Gupta
Reported-by: Sumit Gupta
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers
ndiv value from freq_table. Otherwise, print a
warning and return the reconstructed freq.
Signed-off-by: Sumit Gupta
---
Sending only this patch as other patch not required after the change
to convert 'pr_warn' to 'pr_info' in cpufreq core for unlisted freq.
Changelog
v1[2] -> v3:
- Removed unwan
entering suspend.
And who does this restoration ?
To fix this, adding online hook to wait till the
current frequency becomes equal or close to the last requested
frequency.
Fixes: df320f89359c ("cpufreq: Add Tegra194 cpufreq driver")
Signed-off-by: Sumit Gupta
---
drivers/cpufre
ndiv value from freq_table. Otherwise, print a
warning and return the reconstructed freq.
Signed-off-by: Sumit Gupta
---
drivers/cpufreq/tegra194-cpufreq.c | 71 +-
1 file changed, 62 insertions(+), 9 deletions(-)
diff --git a/drivers/cpufreq/tegra194
entering suspend. To fix this, adding online hook to wait till the
current frequency becomes equal or close to the last requested
frequency.
Fixes: df320f89359c ("cpufreq: Add Tegra194 cpufreq driver")
Signed-off-by: Sumit Gupta
---
drivers/cpufreq/tegra194-cpuf
ndiv value from freq_table. Otherwise, print a
warning and return the reconstructed freq.
Signed-off-by: Sumit Gupta
---
drivers/cpufreq/tegra194-cpufreq.c | 71 +-
1 file changed, 62 insertions(+), 9 deletions(-)
diff --git a/drivers/cpufreq/tegra194-cpufreq.c
ove comments and reduce debug prints.
- Get freq table from cluster specific data instead of policy.
- Set a freq from freq_table if boot freq is not present in table.
- Add online hook to fix unlisted boot freq warning in hotplug-on.
Sumit Gupta (2):
cpufreq: tegra194: get consistent cpuinfo_cur_f
Warning coming during boot because the boot freq set by bootloader
gets filtered out due to big freq steps while creating freq_table.
Fixing this by setting closest ndiv value from freq_table.
Warning:
cpufreq: cpufreq_online: CPU0: Running at unlisted freq
cpufreq: cpufreq_online:
Warning coming during boot because the boot freq set by bootloader
gets filtered out due to big freq steps while creating freq_table.
Fixing this by setting closest ndiv value from freq_table.
Warning:
cpufreq: cpufreq_online: CPU0: Running at unlisted freq
cpufreq: cpufreq_online: CPU0:
ndiv value from freq_table. Otherwise, print a
warning and return the reconstructed freq.
Signed-off-by: Sumit Gupta
---
drivers/cpufreq/tegra194-cpufreq.c | 66 --
1 file changed, 57 insertions(+), 9 deletions(-)
diff --git a/drivers/cpufreq/tegra194
This patch set has below two changes:
1) get consistent cpuinfo_cur_freq value from freq_table.
2) Fix unlisted boot freq warning by setting closest ndiv value
from freq_table if the boot frequency gets filtered while
creating freq_table in kernel.
Sumit Gupta (2):
cpufreq: tegra194: get
).
Signed-off-by: Sumit Gupta
---
drivers/cpufreq/tegra194-cpufreq.c | 118 ++---
1 file changed, 111 insertions(+), 7 deletions(-)
diff --git a/drivers/cpufreq/tegra194-cpufreq.c
b/drivers/cpufreq/tegra194-cpufreq.c
index d5b608d..c3c058a3 100644
--- a/drivers/cpufreq
ndiv value from freq_table. Otherwise, print a
warning and return the reconstructed freq.
Signed-off-by: Sumit Gupta
---
drivers/cpufreq/tegra194-cpufreq.c | 66 --
1 file changed, 57 insertions(+), 9 deletions(-)
diff --git a/drivers/cpufreq/tegra194-cpufreq.c
ERROR: modpost: "__cpu_logical_map" [drivers/cpufreq/tegra194-cpufreq.ko]
undefined!
ARM64 tegra194-cpufreq driver use cpu_logical_map, export
__cpu_logical_map to fix build issue.
I wonder why like other instances in the drivers, the mpidr is not get
directly from the cpu. The
).
Instead calling read_cpuid_mpidr() to get MPIDR on target cpu.
[1] https://lore.kernel.org/linux-arm-kernel/20200724131059.GB6521@bogus/
Reviewed-by: Sudeep Holla
Signed-off-by: Sumit Gupta
---
drivers/cpufreq/tegra194-cpufreq.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
ERROR: modpost: "__cpu_logical_map" [drivers/cpufreq/tegra194-cpufreq.ko]
undefined!
ARM64 tegra194-cpufreq driver use cpu_logical_map, export
__cpu_logical_map to fix build issue.
I wonder why like other instances in the drivers, the mpidr is not get
directly from the cpu. The
ERROR: modpost: "__cpu_logical_map" [drivers/cpufreq/tegra194-cpufreq.ko]
undefined!
ARM64 tegra194-cpufreq driver use cpu_logical_map, export
__cpu_logical_map to fix build issue.
I wonder why like other instances in the drivers, the mpidr is not get
directly from the cpu. The
Add support for CPU frequency scaling on Tegra194. The frequency
of each core can be adjusted by writing a clock divisor value to
a MSR on the core. The range of valid divisors is queried from
the BPMP.
Signed-off-by: Mikko Perttunen
Signed-off-by: Sumit Gupta
---
drivers/cpufreq/Kconfig.arm
Add support for CPU frequency scaling on Tegra194. The frequency
of each core can be adjusted by writing a clock divisor value to
a MSR on the core. The range of valid divisors is queried from
the BPMP.
Signed-off-by: Mikko Perttunen
Signed-off-by: Sumit Gupta
---
drivers/cpufreq
.
Signed-off-by: Sumit Gupta
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 7c9511a..0abf287 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b
Add support for CPU frequency scaling on Tegra194. The frequency
of each core can be adjusted by writing a clock divisor value to
a MSR on the core. The range of valid divisors is queried from
the BPMP.
Signed-off-by: Mikko Perttunen
Signed-off-by: Sumit Gupta
---
drivers/cpufreq/Kconfig.arm
req_lock mutex from tegra194_cpufreq_set_target [Viresh].
- Remove CPUFREQ_ASYNC_NOTIFICATION flag [Viresh].
- Remove redundant _begin|end() call from tegra194_cpufreq_set_target.
- Rename opp_table to freq_table [Viresh].
Sumit Gupta (3):
dt-bindings: arm: Add NVIDIA Tegra194 CPU Complex binding
arm64: teg
-by: Sumit Gupta
---
.../bindings/arm/nvidia,tegra194-ccplex.yaml | 69 ++
1 file changed, 69 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/nvidia,tegra194-ccplex.yaml
diff --git a/Documentation/devicetree/bindings/arm/nvidia,tegra194-ccplex.yaml
Thank you for the review,
Add support for CPU frequency scaling on Tegra194. The frequency
of each core can be adjusted by writing a clock divisor value to
a MSR on the core. The range of valid divisors is queried from
the BPMP.
Signed-off-by: Mikko Perttunen
Signed-off-by: Sumit Gupta
to BPMP device.
Signed-off-by: Sumit Gupta
---
.../bindings/arm/nvidia,tegra194-ccplex.yaml | 106 +
1 file changed, 106 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/nvidia,tegra194-ccplex.yaml
diff --git a/Documentation/devicetree
The cpus.yaml binding documents what's in 'cpu' nodes, not 'cpus'
node. AIUI, the latter is what you want. You should do your own schema
file here.
Do you mean to change existing file name from 'cpus.yaml' to 'cpu.yaml'
and create new 'cpus.yaml' file?
I think it's better to incorporate the
-by: Sumit Gupta
---
.../bindings/arm/nvidia,tegra194-ccplex.yaml | 106 +
1 file changed, 106 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/nvidia,tegra194-ccplex.yaml
diff --git a/Documentation/devicetree/bindings/arm/nvidia,tegra194
On Mon, Jul 13, 2020 at 07:36:46PM +0530, Sumit Gupta wrote:
To do frequency scaling on all CPUs within T194 CPU Complex, we need
to query BPMP for data on valid operating points. Document a compatible
string under 'cpus' node to represent the CPU Complex for binding drivers
like cpufreq
On 26-06-20, 21:13, Sumit Gupta wrote:
+static int tegra194_cpufreq_probe(struct platform_device *pdev)
+{
+ struct tegra194_cpufreq_data *data;
+ struct tegra_bpmp *bpmp;
+ int err, i;
+
+ data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
+ if (!d
Select ARM_TEGRA194_CPUFREQ by default to enable CPU frequency
scaling support for Tegra194 SOC.
Signed-off-by: Sumit Gupta
---
drivers/soc/tegra/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/soc/tegra/Kconfig b/drivers/soc/tegra/Kconfig
index 2e95809..6955cee 100644
, document a property to point to the BPMP device that can be queried
for all CPUs.
Signed-off-by: Sumit Gupta
---
Documentation/devicetree/bindings/arm/cpus.yaml | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml
b/Documentation/devicetree
.
Signed-off-by: Sumit Gupta
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 7c9511a..0abf287 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b
Add support for CPU frequency scaling on Tegra194. The frequency
of each core can be adjusted by writing a clock divisor value to
a MSR on the core. The range of valid divisors is queried from
the BPMP.
Signed-off-by: Mikko Perttunen
Signed-off-by: Sumit Gupta
---
drivers/cpufreq/Kconfig.arm
ve redundant _begin|end() call from tegra194_cpufreq_set_target.
- Rename opp_table to freq_table [Viresh].
Sumit Gupta (4):
dt-bindings: arm: Add t194 ccplex compatible and bpmp property
arm64: tegra: Add t194 ccplex compatible and bpmp property
cpufreq: Add Tegra194 cpufreq driver
soc/te
.
Signed-off-by: Sumit Gupta
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 7c9511a..0abf287 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b
Enable Tegra194 CPU frequency scaling support by default.
Signed-off-by: Sumit Gupta
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index f9d378d..385bd35 100644
--- a/arch/arm64/configs/defconfig
Add support for CPU frequency scaling on Tegra194. The frequency
of each core can be adjusted by writing a clock divisor value to
a MSR on the core. The range of valid divisors is queried from
the BPMP.
Signed-off-by: Mikko Perttunen
Signed-off-by: Sumit Gupta
---
drivers/cpufreq/Kconfig.arm
, document a property to point to the BPMP device that can be queried
for all CPUs.
Signed-off-by: Sumit Gupta
---
Documentation/devicetree/bindings/arm/cpus.yaml | 9 +
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml
b/Documentation/devicetree
- Rename opp_table to freq_table [Viresh].
Sumit Gupta (4):
dt-bindings: arm: Add t194 ccplex compatible and bpmp property
arm64: tegra: Add t194 ccplex compatible and bpmp property
cpufreq: Add Tegra194 cpufreq driver
arm64: defconfig: Enable CONFIG_ARM_TEGRA194_CPUFREQ
Documentation/d
On 22/06/20 12:52 PM, Viresh Kumar wrote:
External email: Use caution opening links or attachments
On 22-06-20, 03:04, Sumit Gupta wrote:
To do frequency scaling on all CPUs within T194 CPU Complex, we need
to query BPMP for data on valid operating points. Document a compatible
string
Hi Viresh,
Thank you for the review. please find my reply inline.
+++ b/drivers/cpufreq/tegra194-cpufreq.c
@@ -0,0 +1,403 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019, NVIDIA CORPORATION. All rights reserved
2020
+ */
+
+#include
+#include
, document a property to point to the BPMP device that can be queried
for all CPUs.
Signed-off-by: Sumit Gupta
---
Documentation/devicetree/bindings/arm/cpus.yaml | 9 +
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml
b/Documentation/devicetree
.
Signed-off-by: Sumit Gupta
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 7c9511a..0abf287 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b
Add support for CPU frequency scaling on Tegra194. The frequency
of each core can be adjusted by writing a clock divisor value to
a MSR on the core. The range of valid divisors is queried from
the BPMP.
Signed-off-by: Mikko Perttunen
Signed-off-by: Sumit Gupta
---
drivers/cpufreq/Kconfig.arm
Enable Tegra194 CPU frequency scaling support by default.
Signed-off-by: Sumit Gupta
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index f9d378d..385bd35 100644
--- a/arch/arm64/configs/defconfig
target.
- Rename opp_table to freq_table [Viresh].
Sumit Gupta (4):
dt-bindings: arm: Add t194 ccplex compatible and bpmp property
arm64: tegra: Add t194 ccplex compatible and bpmp property
cpufreq: Add Tegra194 cpufreq driver
arm64: defconfig: Enable CONFIG_ARM_TEGRA194_CPUFREQ
Documentation/devi
On 27/04/20 12:48 PM, Thierry Reding wrote:
On Tue, Apr 07, 2020 at 12:05:20PM +0200, Thierry Reding wrote:
On Wed, Dec 04, 2019 at 03:21:38PM +0530, Viresh Kumar wrote:
On 04-12-19, 10:33, Thierry Reding wrote:
Yeah, the code that registers this device is in drivers/base/cpu.c in
00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
ffc324e78700: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc
==
Suggested-by: Hans Verkuil
Signed-off-by: Sumit Gupta
---
v4:
* update ctrl->cluster only when new control
ed-off-by: Sumit Gupta
---
v3:
* update ctrl->cluster only when new control reference is added.
* add new ctrl to handler only if the cluster points to an entry.
v2:
* update ctrl->cluster only when new control reference is added.
* check ctrl->ncontrols to avoid illegal access when c
efore and after this change ?
>
I referred other node "cpufreq" under "cpu" node and that was also not getting
deleted when core goes down.
So, thought the behavior should be similar as entries are only used to read
data and it won't change after boot.
> On 29/08/16 0
efore and after this change ?
>
I referred other node "cpufreq" under "cpu" node and that was also not getting
deleted when core goes down.
So, thought the behavior should be similar as entries are only used to read
data and it won't change after boot.
> On 29/08/16 0
> On Mon, Aug 29, 2016 at 02:32:25PM +0530, Sumit Gupta wrote:
> > Removed restriction of displaying model name for 32 bit tasks only.
> > Because of this Processor details were not displayed in "System
> > setting -> Details" in Ubuntu model name display is gen
> On Mon, Aug 29, 2016 at 02:32:25PM +0530, Sumit Gupta wrote:
> > Removed restriction of displaying model name for 32 bit tasks only.
> > Because of this Processor details were not displayed in "System
> > setting -> Details" in Ubuntu model name display is gen
Removed restriction of displaying model name for 32 bit tasks only.
Because of this Processor details were not displayed in
"System setting -> Details" in Ubuntu model name display is generic
and can be printed for 64 bit also.
model name : ARMv8 Processor rev X (v8l)
Signed-off-by
Removed restriction of displaying model name for 32 bit tasks only.
Because of this Processor details were not displayed in
"System setting -> Details" in Ubuntu model name display is generic
and can be printed for 64 bit also.
model name : ARMv8 Processor rev X (v8l)
Signed-off-by
this warning message
of "parent should not be sleeping" comes during
resume.
Removing the notifier to explicitly add/remove
cache device as CPU and cache device get
added/removed anyway as part of normal suspend
resume sequence.
dpm_resume_end - > dpm_resume -> device_res
this warning message
of "parent should not be sleeping" comes during
resume.
Removing the notifier to explicitly add/remove
cache device as CPU and cache device get
added/removed anyway as part of normal suspend
resume sequence.
dpm_resume_end - > dpm_resume -> device_resume
Sign
into bootmem) or create a new
allocator which can speed up the same thing which is easy to enhance
in future.
I am not sure about this and whether it's good idea or will it be fruitful.
Please suggest and share your opinion.
Thank you in advance for your help.
Regards,
Sumit Gupta
--
To unsubscribe
into bootmem) or create a new
allocator which can speed up the same thing which is easy to enhance
in future.
I am not sure about this and whether it's good idea or will it be fruitful.
Please suggest and share your opinion.
Thank you in advance for your help.
Regards,
Sumit Gupta
--
To unsubscribe
AIN_KERNEL,
},
Regards,
Sumit Gupta
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
,
},
Regards,
Sumit Gupta
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
63 matches
Mail list logo
