* Re: [PATCH 1/2] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Add missing properties
From: Stefan Wahren @ 2024-03-26 11:47 UTC (permalink / raw)
To: Krzysztof Kozlowski, Laurent Pinchart, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-gpio, Dave Stevenson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Linus Walleij, Bartosz Golaszewski
In-Reply-To: <6cc81b1a-12e6-4d81-b6c4-6297c213d5c9@linaro.org>
[add Dave since he's working on DMA for Raspberry Pi 4 and maybe have a
opinion about this]
[drop Emma Anholt old address since she is not involved anymore]
Am 26.03.24 um 08:06 schrieb Krzysztof Kozlowski:
> On 26/03/2024 01:49, Laurent Pinchart wrote:
>> The raspberrypi,bcm2835-firmware devices requires a dma-ranges property,
>> and, as a result, also needs to specify #address-cells and #size-cells.
>> Those properties have been added to thebcm2835-rpi.dtsi in commits
>> be08d278eb09 ("ARM: dts: bcm283x: Add cells encoding format to firmware
>> bus") and 55c7c0621078 ("ARM: dts: bcm283x: Fix vc4's firmware bus DMA
>> limitations"), but the DT bindings haven't been updated, resulting in
>> validation errors:
>>
>> arch/arm64/boot/dts/broadcom/bcm2711-rpi-4-b.dtb: firmware: '#address-cells', '#size-cells', 'dma-ranges', 'gpio' do not match any of the regexes: 'pinctrl-[0-9]+'
>> from schema $id: http://devicetree.org/schemas/arm/bcm/raspberrypi,bcm2835-firmware.yaml#
>>
>> Fix this by adding the properties to the bindings.
>>
>> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Children do not perform any IO on their own, because everything is
> handled by parent. It is really odd to see dma-ranges without ranges.
> Referenced commits might be also wrong.
>
> Best regards,
> Krzysztof
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 0/8] cpufreq: sun50i: Add Allwinner H616 support
From: Andre Przywara @ 2024-03-26 11:47 UTC (permalink / raw)
To: Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Rafael J . Wysocki
Cc: linux-pm, devicetree, linux-sunxi, linux-arm-kernel,
Brandon Cheo Fusi, Martin Botka, Martin Botka, Chris Morgan,
Ryan Walklin, Mark Rutland, Lorenzo Pieralisi, Sudeep Holla
This series adds cpufreq support to the Allwinner H616 SoC.
v3 has seen only little changes compared to v2, which contained quite
some rework of Martin's original series from about half a year ago[1].
Thanks for the comments on the list, I adjusted the OPP nodes as
suggested. See below for a changelog.
=================
The various H616 chips seem to be qualified by production batches, and
there is a table that translates from some efuses values to actual speed
bin indexes. Also the die revision has a say here: we can derive this
from the SoC ID, already provided by TF-A through the SMCCC SoC ID
interface.
So while the H6 had explicit speed bin indexes in the efuses, this is
conceptually not that different, and after refactoring patch 4/8 this
can be neatly integrated into the existing (H6) sun50i-cpufreq-nvmem
driver.
On top of that, not all chips are qualified to reach the full 1.5GHz,
and the BSP kernel describes different OPPs for each speedbin. This
requires to add support for the opp-supported-hw DT property, to be
able to describe those requirements properly.
Patch 1/8 exports the SoC ID function, so that we can call it from our
driver. Patch 2/8 blocks the affected SoCs from the generic DT cpufreq
driver, patch 3/8 adds the DT binding documentation.
Patch 4/8 refactors the existing speedbin determination for the H6, to
be able to plug in the H616 version later more easily.
Patch 5/8 adds support for the opp-supported-hw property. This is done
in a generic way, so it's usable for other SoCs as well, and the code
will figure out if the current DT requires use of this feature.
Patch 6/8 then eventually adds the H616 bits to the driver, and ties
that to the new compatible string.
Patch 7/8 add the CPU OPP table as a .dtsi to the DT directory, the
values in there were taken from the BSP source.
Patch 8/8 then enables the OPPs for all boards we have DTs for.
Based on v6.9-rc1.
Please have a look!
Cheers,
Andre
[1] https://lore.kernel.org/linux-sunxi/20230904-cpufreq-h616-v1-0-b8842e525c43@somainline.org/T/#u
Changelog v2 .. v3:
- rebased on top of v6.9-rc1
- drop node name suffix from DT bindings
- drop multiple nodes per frequency in DT bindings example
- add H700 nvmem value and OPPs
- print warning for unknown nvmem values
- add #cooling-cells properties to CPU DT nodes
- use one DT node per frequency for OPP table entries
- include OPP table for newly added Longan board
Changelog v1 .. v2:
- extend commit messages
- add H618/H700 SoC IDs
- fix binding compatible enum
- fix binding documentation
- allow additional suffix to OPP node name
- shorten existing DT binding example
- add another (opp-supported-hw) binding example
- move speed bin decoding refactoring to separate patch (Brandon)
- move opp-supported-hw support to separate patch
- merge opp-supported-hw and microvolt suffix handling
- rewrite OPP tables without opp-microvolt-speed suffix
Andre Przywara (2):
cpufreq: sun50i: Add support for opp_supported_hw
arm64: dts: allwinner: h616: enable DVFS for all boards
Brandon Cheo Fusi (1):
cpufreq: sun50i: Refactor speed bin decoding
Martin Botka (5):
firmware: smccc: Export revision soc_id function
cpufreq: dt-platdev: Blocklist Allwinner H616/618 SoCs
dt-bindings: opp: Describe H616 OPPs and opp-supported-hw
cpufreq: sun50i: Add H616 support
arm64: dts: allwinner: h616: Add CPU OPPs table
.../allwinner,sun50i-h6-operating-points.yaml | 86 ++++----
.../sun50i-h616-bigtreetech-cb1.dtsi | 5 +
.../dts/allwinner/sun50i-h616-cpu-opp.dtsi | 125 +++++++++++
.../allwinner/sun50i-h616-orangepi-zero2.dts | 5 +
.../dts/allwinner/sun50i-h616-x96-mate.dts | 5 +
.../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 8 +
.../sun50i-h618-longan-module-3h.dtsi | 5 +
.../allwinner/sun50i-h618-orangepi-zero2w.dts | 5 +
.../allwinner/sun50i-h618-orangepi-zero3.dts | 5 +
.../sun50i-h618-transpeed-8k618-t.dts | 5 +
drivers/cpufreq/cpufreq-dt-platdev.c | 3 +
drivers/cpufreq/sun50i-cpufreq-nvmem.c | 197 +++++++++++++++---
drivers/firmware/smccc/smccc.c | 1 +
13 files changed, 378 insertions(+), 77 deletions(-)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-cpu-opp.dtsi
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 1/8] firmware: smccc: Export revision soc_id function
From: Andre Przywara @ 2024-03-26 11:47 UTC (permalink / raw)
To: Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Rafael J . Wysocki, Mark Rutland,
Lorenzo Pieralisi, Sudeep Holla
Cc: linux-pm, devicetree, linux-sunxi, linux-arm-kernel,
Brandon Cheo Fusi, Martin Botka, Martin Botka, Chris Morgan,
Ryan Walklin
In-Reply-To: <20240326114743.712167-1-andre.przywara@arm.com>
From: Martin Botka <martin.botka@somainline.org>
The "SoC ID revision" as provided via the SMCCC SOCID interface can be
valuable information for drivers, when certain functionality depends
on a die revision, for instance.
One example is the sun50i-cpufreq-nvmem driver, which needs this
information to determine the speed bin of the SoC.
Export the arm_smccc_get_soc_id_revision() function so that it can be
called by any driver.
Signed-off-by: Martin Botka <martin.botka@somainline.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
drivers/firmware/smccc/smccc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/firmware/smccc/smccc.c b/drivers/firmware/smccc/smccc.c
index db818f9dcb8ee..d670635914ecb 100644
--- a/drivers/firmware/smccc/smccc.c
+++ b/drivers/firmware/smccc/smccc.c
@@ -69,6 +69,7 @@ s32 arm_smccc_get_soc_id_revision(void)
{
return smccc_soc_id_revision;
}
+EXPORT_SYMBOL_GPL(arm_smccc_get_soc_id_revision);
static int __init smccc_devices_init(void)
{
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 2/8] cpufreq: dt-platdev: Blocklist Allwinner H616/618 SoCs
From: Andre Przywara @ 2024-03-26 11:47 UTC (permalink / raw)
To: Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Rafael J . Wysocki
Cc: linux-pm, devicetree, linux-sunxi, linux-arm-kernel,
Brandon Cheo Fusi, Martin Botka, Martin Botka, Chris Morgan,
Ryan Walklin
In-Reply-To: <20240326114743.712167-1-andre.przywara@arm.com>
From: Martin Botka <martin.botka@somainline.org>
The AllWinner H616 SoC will use the (extended) H6 OPP driver, so add
them to the cpufreq-dt blocklist, to not create the device twice.
This also affects the closely related sibling SoCs H618 and H700.
Signed-off-by: Martin Botka <martin.botka@somainline.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
drivers/cpufreq/cpufreq-dt-platdev.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index b993a498084bc..86d8baa816795 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -104,6 +104,9 @@ static const struct of_device_id allowlist[] __initconst = {
*/
static const struct of_device_id blocklist[] __initconst = {
{ .compatible = "allwinner,sun50i-h6", },
+ { .compatible = "allwinner,sun50i-h616", },
+ { .compatible = "allwinner,sun50i-h618", },
+ { .compatible = "allwinner,sun50i-h700", },
{ .compatible = "apple,arm-platform", },
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 3/8] dt-bindings: opp: Describe H616 OPPs and opp-supported-hw
From: Andre Przywara @ 2024-03-26 11:47 UTC (permalink / raw)
To: Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Rafael J . Wysocki
Cc: linux-pm, devicetree, linux-sunxi, linux-arm-kernel,
Brandon Cheo Fusi, Martin Botka, Martin Botka, Chris Morgan,
Ryan Walklin
In-Reply-To: <20240326114743.712167-1-andre.przywara@arm.com>
From: Martin Botka <martin.botka@somainline.org>
Compared to the existing Allwinner H6 OPP scheme, the H616 uses a
similar NVMEM based mechanism to determine the silicon revision, which
is required to select the right frequency / voltage pair for the OPPs.
However it limits the maximum frequency for some speed bins, also seems
to not support all frequencies in all speed bins, which requires us to
introduce the opp-supported-hw property.
Add this property to the list of allowed properties, also drop the
requirement for the revision specific opp-microvolt properties, since
they might not be needed if using opp-supported-hw.
Also use to opportunity to adjust some wording, and drop a sentence
referring to the Linux driver and the OPP subsystem.
Shorten the existing example and add another example, showcasing the
opp-supported-hw property.
Signed-off-by: Martin Botka <martin.botka@somainline.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
.../allwinner,sun50i-h6-operating-points.yaml | 86 +++++++++----------
1 file changed, 42 insertions(+), 44 deletions(-)
diff --git a/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml b/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
index 51f62c3ae1947..d679b2e4a7199 100644
--- a/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
+++ b/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
@@ -13,25 +13,25 @@ maintainers:
description: |
For some SoCs, the CPU frequency subset and voltage value of each
OPP varies based on the silicon variant in use. Allwinner Process
- Voltage Scaling Tables defines the voltage and frequency value based
- on the speedbin blown in the efuse combination. The
- sun50i-cpufreq-nvmem driver reads the efuse value from the SoC to
- provide the OPP framework with required information.
+ Voltage Scaling Tables define the voltage and frequency values based
+ on the speedbin blown in the efuse combination.
allOf:
- $ref: opp-v2-base.yaml#
properties:
compatible:
- const: allwinner,sun50i-h6-operating-points
+ enum:
+ - allwinner,sun50i-h6-operating-points
+ - allwinner,sun50i-h616-operating-points
nvmem-cells:
description: |
A phandle pointing to a nvmem-cells node representing the efuse
- registers that has information about the speedbin that is used
+ register that has information about the speedbin that is used
to select the right frequency/voltage value pair. Please refer
- the for nvmem-cells bindings
- Documentation/devicetree/bindings/nvmem/nvmem.txt and also
+ to the nvmem-cells bindings in
+ Documentation/devicetree/bindings/nvmem/nvmem.yaml and also the
examples below.
opp-shared: true
@@ -47,15 +47,17 @@ patternProperties:
properties:
opp-hz: true
clock-latency-ns: true
+ opp-microvolt: true
+ opp-supported-hw:
+ description: |
+ A single 32 bit bitmap value, representing compatible HW, one
+ bit per speed bin index.
patternProperties:
"^opp-microvolt-speed[0-9]$": true
required:
- opp-hz
- - opp-microvolt-speed0
- - opp-microvolt-speed1
- - opp-microvolt-speed2
unevaluatedProperties: false
@@ -77,58 +79,54 @@ examples:
opp-microvolt-speed2 = <800000>;
};
- opp-720000000 {
+ opp-1080000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
- opp-hz = /bits/ 64 <720000000>;
+ opp-hz = /bits/ 64 <1080000000>;
- opp-microvolt-speed0 = <880000>;
- opp-microvolt-speed1 = <820000>;
- opp-microvolt-speed2 = <800000>;
+ opp-microvolt-speed0 = <1060000>;
+ opp-microvolt-speed1 = <880000>;
+ opp-microvolt-speed2 = <840000>;
};
- opp-816000000 {
+ opp-1488000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
- opp-hz = /bits/ 64 <816000000>;
+ opp-hz = /bits/ 64 <1488000000>;
- opp-microvolt-speed0 = <880000>;
- opp-microvolt-speed1 = <820000>;
- opp-microvolt-speed2 = <800000>;
+ opp-microvolt-speed0 = <1160000>;
+ opp-microvolt-speed1 = <1000000>;
+ opp-microvolt-speed2 = <960000>;
};
+ };
- opp-888000000 {
- clock-latency-ns = <244144>; /* 8 32k periods */
- opp-hz = /bits/ 64 <888000000>;
-
- opp-microvolt-speed0 = <940000>;
- opp-microvolt-speed1 = <820000>;
- opp-microvolt-speed2 = <800000>;
- };
+ - |
+ opp-table {
+ compatible = "allwinner,sun50i-h616-operating-points";
+ nvmem-cells = <&speedbin_efuse>;
+ opp-shared;
- opp-1080000000 {
+ opp-480000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
- opp-hz = /bits/ 64 <1080000000>;
+ opp-hz = /bits/ 64 <480000000>;
- opp-microvolt-speed0 = <1060000>;
- opp-microvolt-speed1 = <880000>;
- opp-microvolt-speed2 = <840000>;
+ opp-microvolt = <900000>;
+ opp-supported-hw = <0x1f>;
};
- opp-1320000000 {
+ opp-792000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
- opp-hz = /bits/ 64 <1320000000>;
+ opp-hz = /bits/ 64 <792000000>;
- opp-microvolt-speed0 = <1160000>;
- opp-microvolt-speed1 = <940000>;
- opp-microvolt-speed2 = <900000>;
+ opp-microvolt-speed1 = <900000>;
+ opp-microvolt-speed4 = <940000>;
+ opp-supported-hw = <0x12>;
};
- opp-1488000000 {
+ opp-1512000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
- opp-hz = /bits/ 64 <1488000000>;
+ opp-hz = /bits/ 64 <1512000000>;
- opp-microvolt-speed0 = <1160000>;
- opp-microvolt-speed1 = <1000000>;
- opp-microvolt-speed2 = <960000>;
+ opp-microvolt = <1100000>;
+ opp-supported-hw = <0x0a>;
};
};
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 4/8] cpufreq: sun50i: Refactor speed bin decoding
From: Andre Przywara @ 2024-03-26 11:47 UTC (permalink / raw)
To: Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Rafael J . Wysocki
Cc: linux-pm, devicetree, linux-sunxi, linux-arm-kernel,
Brandon Cheo Fusi, Martin Botka, Martin Botka, Chris Morgan,
Ryan Walklin
In-Reply-To: <20240326114743.712167-1-andre.przywara@arm.com>
From: Brandon Cheo Fusi <fusibrandon13@gmail.com>
Make converting the speed bin value into a speed grade generic and
determined by a platform specific callback. Also change the prototypes
involved to encode the speed bin directly in the return value.
This allows to extend the driver more easily to support more SoCs.
Signed-off-by: Brandon Cheo Fusi <fusibrandon13@gmail.com>
[Andre: merge output into return value]
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
drivers/cpufreq/sun50i-cpufreq-nvmem.c | 74 +++++++++++++++++---------
1 file changed, 49 insertions(+), 25 deletions(-)
diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
index 32a9c88f8ff6d..7b44f3b13e7d2 100644
--- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
+++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
@@ -25,19 +25,52 @@
static struct platform_device *cpufreq_dt_pdev, *sun50i_cpufreq_pdev;
+struct sunxi_cpufreq_data {
+ u32 (*efuse_xlate)(u32 speedbin);
+};
+
+static u32 sun50i_h6_efuse_xlate(u32 speedbin)
+{
+ u32 efuse_value;
+
+ efuse_value = (speedbin >> NVMEM_SHIFT) & NVMEM_MASK;
+
+ /*
+ * We treat unexpected efuse values as if the SoC was from
+ * the slowest bin. Expected efuse values are 1-3, slowest
+ * to fastest.
+ */
+ if (efuse_value >= 1 && efuse_value <= 3)
+ return efuse_value - 1;
+ else
+ return 0;
+}
+
+static struct sunxi_cpufreq_data sun50i_h6_cpufreq_data = {
+ .efuse_xlate = sun50i_h6_efuse_xlate,
+};
+
+static const struct of_device_id cpu_opp_match_list[] = {
+ { .compatible = "allwinner,sun50i-h6-operating-points",
+ .data = &sun50i_h6_cpufreq_data,
+ },
+ {}
+};
+
/**
* sun50i_cpufreq_get_efuse() - Determine speed grade from efuse value
- * @versions: Set to the value parsed from efuse
*
- * Returns 0 if success.
+ * Returns non-negative speed bin index on success, a negative error
+ * value otherwise.
*/
-static int sun50i_cpufreq_get_efuse(u32 *versions)
+static int sun50i_cpufreq_get_efuse(void)
{
struct nvmem_cell *speedbin_nvmem;
struct device_node *np;
struct device *cpu_dev;
- u32 *speedbin, efuse_value;
- size_t len;
+ const struct of_device_id *match;
+ const struct sunxi_cpufreq_data *opp_data;
+ u32 *speedbin;
int ret;
cpu_dev = get_cpu_device(0);
@@ -48,12 +81,12 @@ static int sun50i_cpufreq_get_efuse(u32 *versions)
if (!np)
return -ENOENT;
- ret = of_device_is_compatible(np,
- "allwinner,sun50i-h6-operating-points");
- if (!ret) {
+ match = of_match_node(cpu_opp_match_list, np);
+ if (!match) {
of_node_put(np);
return -ENOENT;
}
+ opp_data = match->data;
speedbin_nvmem = of_nvmem_cell_get(np, NULL);
of_node_put(np);
@@ -61,25 +94,16 @@ static int sun50i_cpufreq_get_efuse(u32 *versions)
return dev_err_probe(cpu_dev, PTR_ERR(speedbin_nvmem),
"Could not get nvmem cell\n");
- speedbin = nvmem_cell_read(speedbin_nvmem, &len);
+ speedbin = nvmem_cell_read(speedbin_nvmem, NULL);
nvmem_cell_put(speedbin_nvmem);
if (IS_ERR(speedbin))
return PTR_ERR(speedbin);
- efuse_value = (*speedbin >> NVMEM_SHIFT) & NVMEM_MASK;
-
- /*
- * We treat unexpected efuse values as if the SoC was from
- * the slowest bin. Expected efuse values are 1-3, slowest
- * to fastest.
- */
- if (efuse_value >= 1 && efuse_value <= 3)
- *versions = efuse_value - 1;
- else
- *versions = 0;
+ ret = opp_data->efuse_xlate(*speedbin);
kfree(speedbin);
- return 0;
+
+ return ret;
};
static int sun50i_cpufreq_nvmem_probe(struct platform_device *pdev)
@@ -87,7 +111,7 @@ static int sun50i_cpufreq_nvmem_probe(struct platform_device *pdev)
int *opp_tokens;
char name[MAX_NAME_LEN];
unsigned int cpu;
- u32 speed = 0;
+ int speed;
int ret;
opp_tokens = kcalloc(num_possible_cpus(), sizeof(*opp_tokens),
@@ -95,10 +119,10 @@ static int sun50i_cpufreq_nvmem_probe(struct platform_device *pdev)
if (!opp_tokens)
return -ENOMEM;
- ret = sun50i_cpufreq_get_efuse(&speed);
- if (ret) {
+ speed = sun50i_cpufreq_get_efuse();
+ if (speed < 0) {
kfree(opp_tokens);
- return ret;
+ return speed;
}
snprintf(name, MAX_NAME_LEN, "speed%d", speed);
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 6/8] cpufreq: sun50i: Add H616 support
From: Andre Przywara @ 2024-03-26 11:47 UTC (permalink / raw)
To: Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Rafael J . Wysocki
Cc: linux-pm, devicetree, linux-sunxi, linux-arm-kernel,
Brandon Cheo Fusi, Martin Botka, Martin Botka, Chris Morgan,
Ryan Walklin, Mark Rutland, Lorenzo Pieralisi, Sudeep Holla
In-Reply-To: <20240326114743.712167-1-andre.przywara@arm.com>
From: Martin Botka <martin.botka@somainline.org>
The Allwinner H616/H618 SoCs have different OPP tables per SoC version
and die revision. The SoC version is stored in NVMEM, as before, though
encoded differently. The die revision is in a different register, in the
SRAM controller. Firmware already exports that value in a standardised
way, through the SMCCC SoCID mechanism. We need both values, as some chips
have the same SoC version, but they don't support the same frequencies and
they get differentiated by the die revision.
Add the new compatible string and tie the new translation function to
it. This mechanism not only covers the original H616 SoC, but also its
very close sibling SoCs H618 and H700, so add them to the list as well.
Signed-off-by: Martin Botka <martin.botka@somainline.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
drivers/cpufreq/sun50i-cpufreq-nvmem.c | 61 ++++++++++++++++++++++++++
1 file changed, 61 insertions(+)
diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
index bd170611c7906..f9e9fc340f848 100644
--- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
+++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
@@ -10,6 +10,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#include <linux/arm-smccc.h>
#include <linux/cpu.h>
#include <linux/module.h>
#include <linux/nvmem-consumer.h>
@@ -46,14 +47,71 @@ static u32 sun50i_h6_efuse_xlate(u32 speedbin)
return 0;
}
+/*
+ * Judging by the OPP tables in the vendor BSP, the quality order of the
+ * returned speedbin index is 4 -> 0/2 -> 3 -> 1, from worst to best.
+ * 0 and 2 seem identical from the OPP tables' point of view.
+ */
+static u32 sun50i_h616_efuse_xlate(u32 speedbin)
+{
+ int ver_bits = arm_smccc_get_soc_id_revision();
+ u32 value = 0;
+
+ switch (speedbin & 0xffff) {
+ case 0x2000:
+ value = 0;
+ break;
+ case 0x2400:
+ case 0x7400:
+ case 0x2c00:
+ case 0x7c00:
+ if (ver_bits != SMCCC_RET_NOT_SUPPORTED && ver_bits <= 1) {
+ /* ic version A/B */
+ value = 1;
+ } else {
+ /* ic version C and later version */
+ value = 2;
+ }
+ break;
+ case 0x5000:
+ case 0x5400:
+ case 0x6000:
+ value = 3;
+ break;
+ case 0x5c00:
+ value = 4;
+ break;
+ case 0x5d00:
+ value = 0;
+ break;
+ case 0x6c00:
+ value = 5;
+ break;
+ default:
+ pr_warn("sun50i-cpufreq-nvmem: unknown speed bin 0x%x, using default bin 0\n",
+ speedbin & 0xffff);
+ value = 0;
+ break;
+ }
+
+ return value;
+}
+
static struct sunxi_cpufreq_data sun50i_h6_cpufreq_data = {
.efuse_xlate = sun50i_h6_efuse_xlate,
};
+static struct sunxi_cpufreq_data sun50i_h616_cpufreq_data = {
+ .efuse_xlate = sun50i_h616_efuse_xlate,
+};
+
static const struct of_device_id cpu_opp_match_list[] = {
{ .compatible = "allwinner,sun50i-h6-operating-points",
.data = &sun50i_h6_cpufreq_data,
},
+ { .compatible = "allwinner,sun50i-h616-operating-points",
+ .data = &sun50i_h616_cpufreq_data,
+ },
{}
};
@@ -230,6 +288,9 @@ static struct platform_driver sun50i_cpufreq_driver = {
static const struct of_device_id sun50i_cpufreq_match_list[] = {
{ .compatible = "allwinner,sun50i-h6" },
+ { .compatible = "allwinner,sun50i-h616" },
+ { .compatible = "allwinner,sun50i-h618" },
+ { .compatible = "allwinner,sun50i-h700" },
{}
};
MODULE_DEVICE_TABLE(of, sun50i_cpufreq_match_list);
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 5/8] cpufreq: sun50i: Add support for opp_supported_hw
From: Andre Przywara @ 2024-03-26 11:47 UTC (permalink / raw)
To: Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Rafael J . Wysocki
Cc: linux-pm, devicetree, linux-sunxi, linux-arm-kernel,
Brandon Cheo Fusi, Martin Botka, Martin Botka, Chris Morgan,
Ryan Walklin
In-Reply-To: <20240326114743.712167-1-andre.przywara@arm.com>
The opp_supported_hw DT property allows the DT to specify a mask of chip
revisions that a certain OPP is eligible for. This allows for easy
limiting of maximum frequencies, for instance.
Add support for that in the sun50i-cpufreq-nvmem driver. We support both
the existing opp-microvolt suffix properties as well as the
opp-supported-hw property, the generic code figures out which is needed
automatically.
However if none of the DT OPP nodes contain an opp-supported-hw
property, the core code will ignore all OPPs and the driver will fail
probing. So check the DT's eligibility first before using that feature.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
drivers/cpufreq/sun50i-cpufreq-nvmem.c | 62 ++++++++++++++++++++++----
1 file changed, 54 insertions(+), 8 deletions(-)
diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
index 7b44f3b13e7d2..bd170611c7906 100644
--- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
+++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
@@ -57,6 +57,41 @@ static const struct of_device_id cpu_opp_match_list[] = {
{}
};
+/**
+ * dt_has_supported_hw() - Check if any OPPs use opp-supported-hw
+ *
+ * If we ask the cpufreq framework to use the opp-supported-hw feature, it
+ * will ignore every OPP node without that DT property. If none of the OPPs
+ * have it, the driver will fail probing, due to the lack of OPPs.
+ *
+ * Returns true if we have at least one OPP with the opp-supported-hw property.
+ */
+static bool dt_has_supported_hw(void)
+{
+ bool has_opp_supported_hw = false;
+ struct device_node *np, *opp;
+ struct device *cpu_dev;
+
+ cpu_dev = get_cpu_device(0);
+ if (!cpu_dev)
+ return -ENODEV;
+
+ np = dev_pm_opp_of_get_opp_desc_node(cpu_dev);
+ if (!np)
+ return -ENOENT;
+
+ for_each_child_of_node(np, opp) {
+ if (of_find_property(opp, "opp-supported-hw", NULL)) {
+ has_opp_supported_hw = true;
+ break;
+ }
+ }
+
+ of_node_put(np);
+
+ return has_opp_supported_hw;
+}
+
/**
* sun50i_cpufreq_get_efuse() - Determine speed grade from efuse value
*
@@ -110,7 +145,8 @@ static int sun50i_cpufreq_nvmem_probe(struct platform_device *pdev)
{
int *opp_tokens;
char name[MAX_NAME_LEN];
- unsigned int cpu;
+ unsigned int cpu, supported_hw;
+ struct dev_pm_opp_config config = {};
int speed;
int ret;
@@ -125,7 +161,18 @@ static int sun50i_cpufreq_nvmem_probe(struct platform_device *pdev)
return speed;
}
+ /*
+ * We need at least one OPP with the "opp-supported-hw" property,
+ * or else the upper layers will ignore every OPP and will bail out.
+ */
+ if (dt_has_supported_hw()) {
+ supported_hw = 1U << speed;
+ config.supported_hw = &supported_hw;
+ config.supported_hw_count = 1;
+ }
+
snprintf(name, MAX_NAME_LEN, "speed%d", speed);
+ config.prop_name = name;
for_each_possible_cpu(cpu) {
struct device *cpu_dev = get_cpu_device(cpu);
@@ -135,12 +182,11 @@ static int sun50i_cpufreq_nvmem_probe(struct platform_device *pdev)
goto free_opp;
}
- opp_tokens[cpu] = dev_pm_opp_set_prop_name(cpu_dev, name);
- if (opp_tokens[cpu] < 0) {
- ret = opp_tokens[cpu];
- pr_err("Failed to set prop name\n");
+ ret = dev_pm_opp_set_config(cpu_dev, &config);
+ if (ret < 0)
goto free_opp;
- }
+
+ opp_tokens[cpu] = ret;
}
cpufreq_dt_pdev = platform_device_register_simple("cpufreq-dt", -1,
@@ -155,7 +201,7 @@ static int sun50i_cpufreq_nvmem_probe(struct platform_device *pdev)
free_opp:
for_each_possible_cpu(cpu)
- dev_pm_opp_put_prop_name(opp_tokens[cpu]);
+ dev_pm_opp_clear_config(opp_tokens[cpu]);
kfree(opp_tokens);
return ret;
@@ -169,7 +215,7 @@ static void sun50i_cpufreq_nvmem_remove(struct platform_device *pdev)
platform_device_unregister(cpufreq_dt_pdev);
for_each_possible_cpu(cpu)
- dev_pm_opp_put_prop_name(opp_tokens[cpu]);
+ dev_pm_opp_clear_config(opp_tokens[cpu]);
kfree(opp_tokens);
}
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 7/8] arm64: dts: allwinner: h616: Add CPU OPPs table
From: Andre Przywara @ 2024-03-26 11:47 UTC (permalink / raw)
To: Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Rafael J . Wysocki
Cc: linux-pm, devicetree, linux-sunxi, linux-arm-kernel,
Brandon Cheo Fusi, Martin Botka, Martin Botka, Chris Morgan,
Ryan Walklin
In-Reply-To: <20240326114743.712167-1-andre.przywara@arm.com>
From: Martin Botka <martin.botka@somainline.org>
Add an Operating Performance Points table for the CPU cores to enable
Dynamic Voltage & Frequency Scaling (DVFS) on the H616.
The values were taken from the BSP sources. The (newer) H700 chips we
have seen seem to use a separate speed bin, its OPP values were taken
from a live system and added to the mix.
Also add the needed cpu_speed_grade nvmem cell and the cooling cells
properties, to enable passive cooling.
Signed-off-by: Martin Botka <martin.botka@somainline.org>
[Andre: rework to minimise opp-microvolt properties]
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
.../dts/allwinner/sun50i-h616-cpu-opp.dtsi | 125 ++++++++++++++++++
.../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 8 ++
2 files changed, 133 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-cpu-opp.dtsi
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-cpu-opp.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616-cpu-opp.dtsi
new file mode 100644
index 0000000000000..6073fdf672592
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-cpu-opp.dtsi
@@ -0,0 +1,125 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+// Copyright (C) 2023 Martin Botka <martin@somainline.org>
+
+/ {
+ cpu_opp_table: opp-table-cpu {
+ compatible = "allwinner,sun50i-h616-operating-points";
+ nvmem-cells = <&cpu_speed_grade>;
+ opp-shared;
+
+ opp-480000000 {
+ opp-hz = /bits/ 64 <480000000>;
+ opp-microvolt = <900000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-supported-hw = <0x3f>;
+ };
+
+ opp-600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-microvolt = <900000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-supported-hw = <0x12>;
+ };
+
+ opp-720000000 {
+ opp-hz = /bits/ 64 <720000000>;
+ opp-microvolt = <900000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-supported-hw = <0x2d>;
+ };
+
+ opp-792000000 {
+ opp-hz = /bits/ 64 <792000000>;
+ opp-microvolt-speed1 = <900000>;
+ opp-microvolt-speed4 = <940000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-supported-hw = <0x12>;
+ };
+
+ opp-936000000 {
+ opp-hz = /bits/ 64 <936000000>;
+ opp-microvolt = <900000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-supported-hw = <0x0d>;
+ };
+
+ opp-1008000000 {
+ opp-hz = /bits/ 64 <1008000000>;
+ opp-microvolt-speed0 = <950000>;
+ opp-microvolt-speed1 = <940000>;
+ opp-microvolt-speed2 = <950000>;
+ opp-microvolt-speed3 = <950000>;
+ opp-microvolt-speed4 = <1020000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-supported-hw = <0x1f>;
+ };
+
+ opp-10320000 {
+ opp-hz = /bits/ 64 <1032000000>;
+ opp-microvolt = <900000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-supported-hw = <0x20>;
+ };
+
+ opp-1104000000 {
+ opp-hz = /bits/ 64 <1104000000>;
+ opp-microvolt-speed0 = <1000000>;
+ opp-microvolt-speed2 = <1000000>;
+ opp-microvolt-speed3 = <1000000>;
+ opp-microvolt-speed5 = <950000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-supported-hw = <0x2d>;
+ };
+
+ opp-1200000000 {
+ opp-hz = /bits/ 64 <1200000000>;
+ opp-microvolt-speed0 = <1050000>;
+ opp-microvolt-speed1 = <1020000>;
+ opp-microvolt-speed2 = <1050000>;
+ opp-microvolt-speed3 = <1050000>;
+ opp-microvolt-speed4 = <1100000>;
+ opp-microvolt-speed5 = <1020000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-supported-hw = <0x3f>;
+ };
+
+ opp-1320000000 {
+ opp-hz = /bits/ 64 <1320000000>;
+ opp-microvolt = <1100000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-supported-hw = <0x1d>;
+ };
+
+ opp-1416000000 {
+ opp-hz = /bits/ 64 <1416000000>;
+ opp-microvolt = <1100000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-supported-hw = <0x2d>;
+ };
+
+ opp-1512000000 {
+ opp-hz = /bits/ 64 <1512000000>;
+ opp-microvolt-speed1 = <1100000>;
+ opp-microvolt-speed3 = <1100000>;
+ opp-microvolt-speed5 = <1160000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ opp-supported-hw = <0x2a>;
+ };
+ };
+};
+
+&cpu0 {
+ operating-points-v2 = <&cpu_opp_table>;
+};
+
+&cpu1 {
+ operating-points-v2 = <&cpu_opp_table>;
+};
+
+&cpu2 {
+ operating-points-v2 = <&cpu_opp_table>;
+};
+
+&cpu3 {
+ operating-points-v2 = <&cpu_opp_table>;
+};
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
index b2e85e52d1a12..c0fa466fa9f07 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
@@ -26,6 +26,7 @@ cpu0: cpu@0 {
reg = <0>;
enable-method = "psci";
clocks = <&ccu CLK_CPUX>;
+ #cooling-cells = <2>;
};
cpu1: cpu@1 {
@@ -34,6 +35,7 @@ cpu1: cpu@1 {
reg = <1>;
enable-method = "psci";
clocks = <&ccu CLK_CPUX>;
+ #cooling-cells = <2>;
};
cpu2: cpu@2 {
@@ -42,6 +44,7 @@ cpu2: cpu@2 {
reg = <2>;
enable-method = "psci";
clocks = <&ccu CLK_CPUX>;
+ #cooling-cells = <2>;
};
cpu3: cpu@3 {
@@ -50,6 +53,7 @@ cpu3: cpu@3 {
reg = <3>;
enable-method = "psci";
clocks = <&ccu CLK_CPUX>;
+ #cooling-cells = <2>;
};
};
@@ -156,6 +160,10 @@ sid: efuse@3006000 {
ths_calibration: thermal-sensor-calibration@14 {
reg = <0x14 0x8>;
};
+
+ cpu_speed_grade: cpu-speed-grade@0 {
+ reg = <0x0 2>;
+ };
};
watchdog: watchdog@30090a0 {
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 8/8] arm64: dts: allwinner: h616: enable DVFS for all boards
From: Andre Przywara @ 2024-03-26 11:47 UTC (permalink / raw)
To: Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Rafael J . Wysocki
Cc: linux-pm, devicetree, linux-sunxi, linux-arm-kernel,
Brandon Cheo Fusi, Martin Botka, Martin Botka, Chris Morgan,
Ryan Walklin
In-Reply-To: <20240326114743.712167-1-andre.przywara@arm.com>
With the DT bindings now describing the format of the CPU OPP tables, we
can include the OPP table in each board's .dts file, and specify the CPU
power supply.
This allows to enable DVFS, and get up to 50% of performance benefit in
the highest OPP, or up to 60% power savings in the lowest OPP, compared
to the fixed 1GHz @ 1.0V OPP we are running in by default at the moment.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
.../boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi | 5 +++++
arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts | 5 +++++
arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts | 5 +++++
.../boot/dts/allwinner/sun50i-h618-longan-module-3h.dtsi | 5 +++++
.../arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero2w.dts | 5 +++++
arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts | 5 +++++
.../boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts | 5 +++++
7 files changed, 35 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi
index af421ba24ce0c..d12b01c5f41b6 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-bigtreetech-cb1.dtsi
@@ -6,6 +6,7 @@
/dts-v1/;
#include "sun50i-h616.dtsi"
+#include "sun50i-h616-cpu-opp.dtsi"
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
@@ -62,6 +63,10 @@ wifi_pwrseq: wifi-pwrseq {
};
};
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
&mmc0 {
vmmc-supply = <®_dldo1>;
/* Card detection pin is not connected */
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
index b5d713926a341..a360d8567f955 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
@@ -6,12 +6,17 @@
/dts-v1/;
#include "sun50i-h616-orangepi-zero.dtsi"
+#include "sun50i-h616-cpu-opp.dtsi"
/ {
model = "OrangePi Zero2";
compatible = "xunlong,orangepi-zero2", "allwinner,sun50i-h616";
};
+&cpu0 {
+ cpu-supply = <®_dcdca>;
+};
+
&emac0 {
allwinner,rx-delay-ps = <3100>;
allwinner,tx-delay-ps = <700>;
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts b/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
index 959b6fd18483b..26d25b5b59e0f 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
@@ -6,6 +6,7 @@
/dts-v1/;
#include "sun50i-h616.dtsi"
+#include "sun50i-h616-cpu-opp.dtsi"
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
@@ -32,6 +33,10 @@ reg_vcc5v: vcc5v {
};
};
+&cpu0 {
+ cpu-supply = <®_dcdca>;
+};
+
&ehci0 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h618-longan-module-3h.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h618-longan-module-3h.dtsi
index 8c1263a3939e7..e92d150aaf1c1 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h618-longan-module-3h.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h618-longan-module-3h.dtsi
@@ -4,6 +4,11 @@
*/
#include "sun50i-h616.dtsi"
+#include "sun50i-h616-cpu-opp.dtsi"
+
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
&mmc2 {
pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero2w.dts b/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero2w.dts
index 21ca1977055d9..6a4f0da972330 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero2w.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero2w.dts
@@ -6,6 +6,7 @@
/dts-v1/;
#include "sun50i-h616.dtsi"
+#include "sun50i-h616-cpu-opp.dtsi"
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
@@ -53,6 +54,10 @@ reg_vcc3v3: vcc3v3 {
};
};
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
&ehci1 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts
index b3b1b8692125f..e1cd7572a14ce 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts
@@ -6,12 +6,17 @@
/dts-v1/;
#include "sun50i-h616-orangepi-zero.dtsi"
+#include "sun50i-h616-cpu-opp.dtsi"
/ {
model = "OrangePi Zero3";
compatible = "xunlong,orangepi-zero3", "allwinner,sun50i-h618";
};
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
&emac0 {
allwinner,tx-delay-ps = <700>;
phy-mode = "rgmii-rxid";
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts b/arch/arm64/boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts
index ac0a2b7ea6f31..a6458b7a86713 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h618-transpeed-8k618-t.dts
@@ -6,6 +6,7 @@
/dts-v1/;
#include "sun50i-h616.dtsi"
+#include "sun50i-h616-cpu-opp.dtsi"
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
@@ -51,6 +52,10 @@ wifi_pwrseq: wifi_pwrseq {
};
};
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
&ehci0 {
status = "okay";
};
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 3/5] firmware: arm_scmi: Add message dump traces for bad and unexpected replies
From: Cristian Marussi @ 2024-03-26 11:57 UTC (permalink / raw)
To: Sudeep Holla; +Cc: linux-kernel, linux-arm-kernel
In-Reply-To: <ZgKwdhLQeYDd9SAl@bogus>
On Tue, Mar 26, 2024 at 11:24:38AM +0000, Sudeep Holla wrote:
> On Mon, Mar 25, 2024 at 08:46:18PM +0000, Cristian Marussi wrote:
> > Trace also late-timed-out, out-of-order and unexpected/spurious messages.
> >
> > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> > ---
> > drivers/firmware/arm_scmi/driver.c | 10 ++++++++++
> > drivers/firmware/arm_scmi/mailbox.c | 4 +++-
> > 2 files changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> > index 7fc1c5b1a2a4..207ed1a52d69 100644
> > --- a/drivers/firmware/arm_scmi/driver.c
> > +++ b/drivers/firmware/arm_scmi/driver.c
> > @@ -861,6 +861,9 @@ scmi_xfer_command_acquire(struct scmi_chan_info *cinfo, u32 msg_hdr)
> > "Message for %d type %d is not expected!\n",
> > xfer_id, msg_type);
> > spin_unlock_irqrestore(&minfo->xfer_lock, flags);
> > +
> > + scmi_bad_message_trace(cinfo, msg_hdr, MSG_UNEXPECTED);
> > +
> > return xfer;
> > }
> > refcount_inc(&xfer->users);
> > @@ -885,6 +888,9 @@ scmi_xfer_command_acquire(struct scmi_chan_info *cinfo, u32 msg_hdr)
> > dev_err(cinfo->dev,
> > "Invalid message type:%d for %d - HDR:0x%X state:%d\n",
> > msg_type, xfer_id, msg_hdr, xfer->state);
> > +
> > + scmi_bad_message_trace(cinfo, msg_hdr, MSG_INVALID);
> > +
> > /* On error the refcount incremented above has to be dropped */
> > __scmi_xfer_put(minfo, xfer);
> > xfer = ERR_PTR(-EINVAL);
> > @@ -921,6 +927,9 @@ static void scmi_handle_notification(struct scmi_chan_info *cinfo,
> > if (IS_ERR(xfer)) {
> > dev_err(dev, "failed to get free message slot (%ld)\n",
> > PTR_ERR(xfer));
> > +
> > + scmi_bad_message_trace(cinfo, msg_hdr, MSG_NOMEM);
> > +
> > scmi_clear_channel(info, cinfo);
> > return;
> > }
> > @@ -1040,6 +1049,7 @@ void scmi_rx_callback(struct scmi_chan_info *cinfo, u32 msg_hdr, void *priv)
> > break;
> > default:
> > WARN_ONCE(1, "received unknown msg_type:%d\n", msg_type);
> > + scmi_bad_message_trace(cinfo, msg_hdr, MSG_UNKNOWN);
> > break;
> > }
> > }
> > diff --git a/drivers/firmware/arm_scmi/mailbox.c b/drivers/firmware/arm_scmi/mailbox.c
> > index b8d470417e8f..fb0824af7180 100644
> > --- a/drivers/firmware/arm_scmi/mailbox.c
> > +++ b/drivers/firmware/arm_scmi/mailbox.c
> > @@ -56,7 +56,9 @@ static void rx_callback(struct mbox_client *cl, void *m)
> > */
> > if (cl->knows_txdone && !shmem_channel_free(smbox->shmem)) {
> > dev_warn(smbox->cinfo->dev, "Ignoring spurious A2P IRQ !\n");
> > - return;
> > + return scmi_bad_message_trace(smbox->cinfo,
> > + shmem_read_header(smbox->shmem),
> > + MSG_MBOX_SPURIOUS);
>
> From previous patch, IIUC scmi_bad_message_trace is a void func and doesn't
> return anything. Did you not get any build error/warning for this ?
>
No...I am building with W=1....but note that the caller itself here
rx_callback() is supposed to return a void...
...in V3 I may just split this into 2 lines and leave the return; alone on its
own line to avoid any confusion...
Thanks,
Cristian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V8 00/12] soc: imx8mp: Add support for HDMI
From: Tommaso Merciai @ 2024-03-26 12:00 UTC (permalink / raw)
To: Adam Ford
Cc: Laurent Pinchart, linux-arm-kernel, marex, alexander.stein,
frieder.schrempf, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Philipp Zabel, Vinod Koul, Kishon Vijay Abraham I,
Catalin Marinas, Will Deacon, Liu Ying, Ulf Hansson, Lucas Stach,
dri-devel, devicetree, linux-kernel, linux-phy, linux-pm
In-Reply-To: <CAHCN7xKWUQwfNmTB_bu4Kqm-b6PSPBHvyf8yfRbL53rB20-=DQ@mail.gmail.com>
Hi Adam,
On Tue, Mar 26, 2024 at 06:43:26AM -0500, Adam Ford wrote:
> On Tue, Mar 26, 2024 at 2:46 AM Tommaso Merciai <tomm.merciai@gmail.com> wrote:
> >
> > Hi Laurent,
> >
> > On Tue, Mar 26, 2024 at 12:03:38AM +0200, Laurent Pinchart wrote:
> > > Hi Tommaso,
> > >
> > > On Mon, Mar 25, 2024 at 10:48:56PM +0100, Tommaso Merciai wrote:
> > > > Hi Adam, Lucas,
> > > > Thanks for this series.
> > > >
> > > > This series make HDMI work on evk.
> > > > All is working properly on my side.
> > > >
> > > > Tested on: Linux imx8mp-lpddr4-evk 6.9.0-rc1.
> > > > Hope this help.
> > > >
> > > > Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
> > >
> > > The DRM side has been merged already. The only missing patches are for
> > > the PHY, and the latest version can be found in
> > > https://lore.kernel.org/linux-phy/20240227220444.77566-1-aford173@gmail.com/.
> > > You can test that series and send a Tested-by tag. I'm crossing my
> > > fingers and hoping it will be merged in v6.10.
> > (same here :) )
> >
> > Thanks for sharing! :)
> >
> > To be honest I test all this series rebasing my alvium next branch on top of media_stage/master (6.9.0-rc1)
> > All is working properly on my side.
> > I found v8 into the commit msg here: https://patches.linaro.org/project/linux-pm/patch/20240203165307.7806-9-aford173@gmail.com/
> > then I'm thinking this is the latest.
> >
> > I'm going to switch to your suggestion that looks more recent :)
>
> Sorry about the confusion. I was confused by the versioning too when
> I pulled from different parts of Lucas' stuff. Since varying
> components were applied at different times, and the remaining part was
> based on the wrong starting point and not applied, I reverted back to
> the versioning of the PHY which was the only remaining part other than
> device tree stuff.
No problem, thanks for clarify :)
Thanks & Regards,
Tommaso
>
> adam
> >
> > Thanks again,
> > Tommaso
> >
> > >
> > > > On Sat, Feb 03, 2024 at 10:52:40AM -0600, Adam Ford wrote:
> > > > > The i.MX8M Plus has an HDMI controller, but it depends on two
> > > > > other systems, the Parallel Video Interface (PVI) and the
> > > > > HDMI PHY from Samsung. The LCDIF controller generates the display
> > > > > and routes it to the PVI which converts passes the parallel video
> > > > > to the HDMI bridge. The HDMI system has a corresponding power
> > > > > domain controller whose driver was partially written, but the
> > > > > device tree for it was never applied, so some changes to the
> > > > > power domain should be harmless because they've not really been
> > > > > used yet.
> > > > >
> > > > > This series is adapted from multiple series from Lucas Stach with
> > > > > edits and suggestions from feedback from various series, but it
> > > > > since it's difficult to use and test them independently,
> > > > > I merged them into on unified series. The version history is a
> > > > > bit ambiguous since different components were submitted at different
> > > > > times and had different amount of retries. In an effort to merge them
> > > > > I used the highest version attempt.
> > > > >
> > > > > Adam Ford (3):
> > > > > dt-bindings: soc: imx: add missing clock and power-domains to
> > > > > imx8mp-hdmi-blk-ctrl
> > > > > pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add fdcc clock to hdmimix
> > > > > domain
> > > > > arm64: defconfig: Enable DRM_IMX8MP_DW_HDMI_BRIDGE as module
> > > > >
> > > > > Lucas Stach (9):
> > > > > dt-bindings: phy: add binding for the i.MX8MP HDMI PHY
> > > > > phy: freescale: add Samsung HDMI PHY
> > > > > arm64: dts: imx8mp: add HDMI power-domains
> > > > > arm64: dts: imx8mp: add HDMI irqsteer
> > > > > dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI
> > > > > drm/bridge: imx: add driver for HDMI TX Parallel Video Interface
> > > > > dt-bindings: display: imx: add binding for i.MX8MP HDMI TX
> > > > > drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI
> > > > > arm64: dts: imx8mp: add HDMI display pipeline
> > > > >
> > > > > .../display/bridge/fsl,imx8mp-hdmi-tx.yaml | 102 ++
> > > > > .../display/imx/fsl,imx8mp-hdmi-pvi.yaml | 84 ++
> > > > > .../bindings/phy/fsl,imx8mp-hdmi-phy.yaml | 62 +
> > > > > .../soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml | 22 +-
> > > > > arch/arm64/boot/dts/freescale/imx8mp.dtsi | 145 +++
> > > > > arch/arm64/configs/defconfig | 1 +
> > > > > drivers/gpu/drm/bridge/imx/Kconfig | 18 +
> > > > > drivers/gpu/drm/bridge/imx/Makefile | 2 +
> > > > > drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c | 207 ++++
> > > > > drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c | 154 +++
> > > > > drivers/phy/freescale/Kconfig | 6 +
> > > > > drivers/phy/freescale/Makefile | 1 +
> > > > > drivers/phy/freescale/phy-fsl-samsung-hdmi.c | 1075 +++++++++++++++++
> > > > > drivers/pmdomain/imx/imx8mp-blk-ctrl.c | 10 +-
> > > > > 14 files changed, 1876 insertions(+), 13 deletions(-)
> > > > > create mode 100644 Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> > > > > create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
> > > > > create mode 100644 Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml
> > > > > create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> > > > > create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
> > > > > create mode 100644 drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > >
> > > --
> > > Regards,
> > >
> > > Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/5] arm64: dts: Add device tree source for the Au-Zone Maivin Starter Kit
From: Krzysztof Kozlowski @ 2024-03-26 12:01 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, imx, linux-arm-kernel, Trevor Zaharichuk, Greg Lytle,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <20240326091100.GA17454@pendragon.ideasonboard.com>
On 26/03/2024 10:11, Laurent Pinchart wrote:
> Hi Krzysztof,
>
> On Tue, Mar 26, 2024 at 08:12:45AM +0100, Krzysztof Kozlowski wrote:
>> On 25/03/2024 21:32, Laurent Pinchart wrote:
>>> The Maivin board is an AI vision starter kit sold by Au-Zone
>>> Technologies, developed in collaboration with Toradex and Vision
>>> Components. It is based on a Toradex Verdin i.MX8MP SoM.
>>>
>>> Add a device tree that covers the base set the peripherals found on the
>>> board:
>>
>> Please use subject prefixes matching the subsystem. You can get them for
>> example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
>> your patch is touching.
>> And drop redundant parts.
>> arm64: dts: imx8mp-maivin: Add Au-Zone Maivin Starter Kit board
>
> Including in the command line the name of the dts that is being added
> doesn't seem to be a very common practice. See for instance
>
> 6d382d51d979 arm64: dts: freescale: Add SKOV IMX8MP CPU revB board
>
> I can use
>
> arm64: dts: freescale Add Au-Zone Maivin Starter Kit
>
> if you prefer.
It's also fine (plus missing : after freescale).
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/5] firmware: arm_scmi: Add message dump traces for bad and unexpected replies
From: Sudeep Holla @ 2024-03-26 12:06 UTC (permalink / raw)
To: Cristian Marussi; +Cc: linux-kernel, linux-arm-kernel
In-Reply-To: <ZgK4I32LHbmqrhCN@pluto>
On Tue, Mar 26, 2024 at 11:57:23AM +0000, Cristian Marussi wrote:
> On Tue, Mar 26, 2024 at 11:24:38AM +0000, Sudeep Holla wrote:
> > On Mon, Mar 25, 2024 at 08:46:18PM +0000, Cristian Marussi wrote:
> > > Trace also late-timed-out, out-of-order and unexpected/spurious messages.
> > >
> > > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> > > ---
> > > drivers/firmware/arm_scmi/driver.c | 10 ++++++++++
> > > drivers/firmware/arm_scmi/mailbox.c | 4 +++-
> > > 2 files changed, 13 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> > > index 7fc1c5b1a2a4..207ed1a52d69 100644
> > > --- a/drivers/firmware/arm_scmi/driver.c
> > > +++ b/drivers/firmware/arm_scmi/driver.c
> > > @@ -861,6 +861,9 @@ scmi_xfer_command_acquire(struct scmi_chan_info *cinfo, u32 msg_hdr)
> > > "Message for %d type %d is not expected!\n",
> > > xfer_id, msg_type);
> > > spin_unlock_irqrestore(&minfo->xfer_lock, flags);
> > > +
> > > + scmi_bad_message_trace(cinfo, msg_hdr, MSG_UNEXPECTED);
> > > +
> > > return xfer;
> > > }
> > > refcount_inc(&xfer->users);
> > > @@ -885,6 +888,9 @@ scmi_xfer_command_acquire(struct scmi_chan_info *cinfo, u32 msg_hdr)
> > > dev_err(cinfo->dev,
> > > "Invalid message type:%d for %d - HDR:0x%X state:%d\n",
> > > msg_type, xfer_id, msg_hdr, xfer->state);
> > > +
> > > + scmi_bad_message_trace(cinfo, msg_hdr, MSG_INVALID);
> > > +
> > > /* On error the refcount incremented above has to be dropped */
> > > __scmi_xfer_put(minfo, xfer);
> > > xfer = ERR_PTR(-EINVAL);
> > > @@ -921,6 +927,9 @@ static void scmi_handle_notification(struct scmi_chan_info *cinfo,
> > > if (IS_ERR(xfer)) {
> > > dev_err(dev, "failed to get free message slot (%ld)\n",
> > > PTR_ERR(xfer));
> > > +
> > > + scmi_bad_message_trace(cinfo, msg_hdr, MSG_NOMEM);
> > > +
> > > scmi_clear_channel(info, cinfo);
> > > return;
> > > }
> > > @@ -1040,6 +1049,7 @@ void scmi_rx_callback(struct scmi_chan_info *cinfo, u32 msg_hdr, void *priv)
> > > break;
> > > default:
> > > WARN_ONCE(1, "received unknown msg_type:%d\n", msg_type);
> > > + scmi_bad_message_trace(cinfo, msg_hdr, MSG_UNKNOWN);
> > > break;
> > > }
> > > }
> > > diff --git a/drivers/firmware/arm_scmi/mailbox.c b/drivers/firmware/arm_scmi/mailbox.c
> > > index b8d470417e8f..fb0824af7180 100644
> > > --- a/drivers/firmware/arm_scmi/mailbox.c
> > > +++ b/drivers/firmware/arm_scmi/mailbox.c
> > > @@ -56,7 +56,9 @@ static void rx_callback(struct mbox_client *cl, void *m)
> > > */
> > > if (cl->knows_txdone && !shmem_channel_free(smbox->shmem)) {
> > > dev_warn(smbox->cinfo->dev, "Ignoring spurious A2P IRQ !\n");
> > > - return;
> > > + return scmi_bad_message_trace(smbox->cinfo,
> > > + shmem_read_header(smbox->shmem),
> > > + MSG_MBOX_SPURIOUS);
> >
> > From previous patch, IIUC scmi_bad_message_trace is a void func and doesn't
> > return anything. Did you not get any build error/warning for this ?
> >
>
> No...I am building with W=1....but note that the caller itself here
> rx_callback() is supposed to return a void...
>
> ...in V3 I may just split this into 2 lines and leave the return; alone on its
> own line to avoid any confusion...
Not need to respin unless I find something that needs reposting, can fix this
myself.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: arm: qcom: Add Motorola Moto G (2013)
From: Stanislav Jakubek @ 2024-03-26 12:10 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-arm-kernel, phone-devel,
linux-kernel
Document the Motorola Moto G (2013), which is a smartphone based
on the Qualcomm MSM8226 SoC.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Stanislav Jakubek <stano.jakubek@gmail.com>
---
Changes in V2:
- collect Krzysztof's A-b
Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 66beaac60e1d..d2910982ae86 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -137,6 +137,7 @@ properties:
- microsoft,dempsey
- microsoft,makepeace
- microsoft,moneypenny
+ - motorola,falcon
- samsung,s3ve3g
- const: qcom,msm8226
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/2] ARM: dts: qcom: Add support for Motorola Moto G (2013)
From: Stanislav Jakubek @ 2024-03-26 12:11 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-arm-kernel, phone-devel,
linux-kernel
In-Reply-To: <32c507337ab80c550fb1df08f7014d1e31eb4c32.1711454680.git.stano.jakubek@gmail.com>
Add a device tree for the Motorola Moto G (2013) smartphone based
on the Qualcomm MSM8226 SoC.
Initially supported features:
- Buttons (Volume Down/Up, Power)
- eMMC
- Hall Effect Sensor
- SimpleFB display
- TMP108 temperature sensor
- Vibrator
Note: the dhob and shob reserved-memory regions are seemingly a part of some
Motorola specific (firmware?) mechanism, see [1].
[1] https://github.com/LineageOS/android_kernel_motorola_msm8226/blob/cm-14.1/Documentation/devicetree/bindings/misc/hob_ram.txt
Signed-off-by: Stanislav Jakubek <stano.jakubek@gmail.com>
---
Changes in V2:
- split hob-ram reserved-memory region into dhob and shob
- add a note and a link to downstream documentation with more
information about these regions
arch/arm/boot/dts/qcom/Makefile | 1 +
.../boot/dts/qcom/msm8226-motorola-falcon.dts | 359 ++++++++++++++++++
2 files changed, 360 insertions(+)
create mode 100644 arch/arm/boot/dts/qcom/msm8226-motorola-falcon.dts
diff --git a/arch/arm/boot/dts/qcom/Makefile b/arch/arm/boot/dts/qcom/Makefile
index 6478a39b3be5..3eacbf5c0785 100644
--- a/arch/arm/boot/dts/qcom/Makefile
+++ b/arch/arm/boot/dts/qcom/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
dtb-$(CONFIG_ARCH_QCOM) += \
+ msm8226-motorola-falcon.dtb \
qcom-apq8016-sbc.dtb \
qcom-apq8026-asus-sparrow.dtb \
qcom-apq8026-huawei-sturgeon.dtb \
diff --git a/arch/arm/boot/dts/qcom/msm8226-motorola-falcon.dts b/arch/arm/boot/dts/qcom/msm8226-motorola-falcon.dts
new file mode 100644
index 000000000000..029e1b1659c9
--- /dev/null
+++ b/arch/arm/boot/dts/qcom/msm8226-motorola-falcon.dts
@@ -0,0 +1,359 @@
+// SPDX-License-Identifier: BSD-3-Clause
+
+/dts-v1/;
+
+#include "qcom-msm8226.dtsi"
+#include "pm8226.dtsi"
+
+/delete-node/ &smem_region;
+
+/ {
+ model = "Motorola Moto G (2013)";
+ compatible = "motorola,falcon", "qcom,msm8226";
+ chassis-type = "handset";
+
+ aliases {
+ mmc0 = &sdhc_1;
+ };
+
+ chosen {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ framebuffer@3200000 {
+ compatible = "simple-framebuffer";
+ reg = <0x03200000 0x800000>;
+ width = <720>;
+ height = <1280>;
+ stride = <(720 * 3)>;
+ format = "r8g8b8";
+ vsp-supply = <®_lcd_pos>;
+ vsn-supply = <®_lcd_neg>;
+ vddio-supply = <&vddio_disp_vreg>;
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ event-hall-sensor {
+ label = "Hall Effect Sensor";
+ gpios = <&tlmm 51 GPIO_ACTIVE_LOW>;
+ linux,input-type = <EV_SW>;
+ linux,code = <SW_LID>;
+ linux,can-disable;
+ };
+
+ key-volume-up {
+ label = "Volume Up";
+ gpios = <&tlmm 106 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_VOLUMEUP>;
+ debounce-interval = <15>;
+ };
+ };
+
+ vddio_disp_vreg: regulator-vddio-disp {
+ compatible = "regulator-fixed";
+ regulator-name = "vddio_disp";
+ gpio = <&tlmm 34 GPIO_ACTIVE_HIGH>;
+ vin-supply = <&pm8226_l8>;
+ startup-delay-us = <300>;
+ enable-active-high;
+ regulator-boot-on;
+ };
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ framebuffer@3200000 {
+ reg = <0x03200000 0x800000>;
+ no-map;
+ };
+
+ dhob@f500000 {
+ reg = <0x0f500000 0x40000>;
+ no-map;
+ };
+
+ shob@f540000 {
+ reg = <0x0f540000 0x2000>;
+ no-map;
+ };
+
+ smem_region: smem@fa00000 {
+ reg = <0x0fa00000 0x100000>;
+ no-map;
+ };
+
+ /* Actually <0x0fa00000 0x500000>, but first 100000 is smem */
+ reserved@fb00000 {
+ reg = <0x0fb00000 0x400000>;
+ no-map;
+ };
+ };
+};
+
+&blsp1_i2c3 {
+ status = "okay";
+
+ regulator@3e {
+ compatible = "ti,tps65132";
+ reg = <0x3e>;
+ pinctrl-0 = <®_lcd_default>;
+ pinctrl-names = "default";
+
+ reg_lcd_pos: outp {
+ regulator-name = "outp";
+ regulator-min-microvolt = <4000000>;
+ regulator-max-microvolt = <6000000>;
+ regulator-active-discharge = <1>;
+ regulator-boot-on;
+ enable-gpios = <&tlmm 31 GPIO_ACTIVE_HIGH>;
+ };
+
+ reg_lcd_neg: outn {
+ regulator-name = "outn";
+ regulator-min-microvolt = <4000000>;
+ regulator-max-microvolt = <6000000>;
+ regulator-active-discharge = <1>;
+ regulator-boot-on;
+ enable-gpios = <&tlmm 33 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ temperature-sensor@48 {
+ compatible = "ti,tmp108";
+ reg = <0x48>;
+ interrupts-extended = <&tlmm 13 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&temp_alert_default>;
+ pinctrl-names = "default";
+ #thermal-sensor-cells = <0>;
+ };
+};
+
+&pm8226_resin {
+ linux,code = <KEY_VOLUMEDOWN>;
+ status = "okay";
+};
+
+&pm8226_vib {
+ status = "okay";
+};
+
+&rpm_requests {
+ regulators {
+ compatible = "qcom,rpm-pm8226-regulators";
+
+ pm8226_s3: s3 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1300000>;
+ };
+
+ pm8226_s4: s4 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2200000>;
+ };
+
+ pm8226_s5: s5 {
+ regulator-min-microvolt = <1150000>;
+ regulator-max-microvolt = <1150000>;
+ };
+
+ pm8226_l1: l1 {
+ regulator-min-microvolt = <1225000>;
+ regulator-max-microvolt = <1225000>;
+ };
+
+ pm8226_l2: l2 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ pm8226_l3: l3 {
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1337500>;
+ };
+
+ pm8226_l4: l4 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ pm8226_l5: l5 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ pm8226_l6: l6 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-allow-set-load;
+ };
+
+ pm8226_l7: l7 {
+ regulator-min-microvolt = <1850000>;
+ regulator-max-microvolt = <1850000>;
+ };
+
+ pm8226_l8: l8 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ pm8226_l9: l9 {
+ regulator-min-microvolt = <2050000>;
+ regulator-max-microvolt = <2050000>;
+ };
+
+ pm8226_l10: l10 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ pm8226_l12: l12 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ pm8226_l14: l14 {
+ regulator-min-microvolt = <2750000>;
+ regulator-max-microvolt = <2750000>;
+ };
+
+ pm8226_l15: l15 {
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+
+ pm8226_l16: l16 {
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3350000>;
+ };
+
+ pm8226_l17: l17 {
+ regulator-min-microvolt = <2950000>;
+ regulator-max-microvolt = <2950000>;
+ };
+
+ pm8226_l18: l18 {
+ regulator-min-microvolt = <2950000>;
+ regulator-max-microvolt = <2950000>;
+ };
+
+ pm8226_l19: l19 {
+ regulator-min-microvolt = <2850000>;
+ regulator-max-microvolt = <2850000>;
+ };
+
+ pm8226_l20: l20 {
+ regulator-min-microvolt = <3075000>;
+ regulator-max-microvolt = <3075000>;
+ };
+
+ pm8226_l21: l21 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2950000>;
+ regulator-allow-set-load;
+ };
+
+ pm8226_l22: l22 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2950000>;
+ };
+
+ pm8226_l23: l23 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2950000>;
+ };
+
+ pm8226_l24: l24 {
+ regulator-min-microvolt = <1300000>;
+ regulator-max-microvolt = <1350000>;
+ };
+
+ pm8226_l25: l25 {
+ regulator-min-microvolt = <1775000>;
+ regulator-max-microvolt = <2125000>;
+ };
+
+ pm8226_l26: l26 {
+ regulator-min-microvolt = <1225000>;
+ regulator-max-microvolt = <1225000>;
+ };
+
+ pm8226_l27: l27 {
+ regulator-min-microvolt = <2050000>;
+ regulator-max-microvolt = <2050000>;
+ };
+
+ pm8226_l28: l28 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ };
+
+ pm8226_lvs1: lvs1 {
+ regulator-always-on;
+ };
+ };
+};
+
+&sdhc_1 {
+ vmmc-supply = <&pm8226_l17>;
+ vqmmc-supply = <&pm8226_l6>;
+
+ bus-width = <8>;
+ non-removable;
+
+ status = "okay";
+};
+
+&smbb {
+ qcom,fast-charge-safe-current = <2000000>;
+ qcom,fast-charge-current-limit = <1900000>;
+ qcom,fast-charge-safe-voltage = <4400000>;
+ qcom,minimum-input-voltage = <4300000>;
+
+ status = "okay";
+};
+
+&tlmm {
+ reg_lcd_default: reg-lcd-default-state {
+ pins = "gpio31", "gpio33";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ output-high;
+ };
+
+ reg_vddio_disp_default: reg-vddio-disp-default-state {
+ pins = "gpio34";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ output-high;
+ };
+
+ temp_alert_default: temp-alert-default-state {
+ pins = "gpio13";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ output-disable;
+ };
+};
+
+&usb {
+ extcon = <&smbb>;
+ dr_mode = "peripheral";
+ status = "okay";
+};
+
+&usb_hs_phy {
+ extcon = <&smbb>;
+ v1p8-supply = <&pm8226_l10>;
+ v3p3-supply = <&pm8226_l20>;
+};
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH net-next v5 07/10] net: ti: icssg-prueth: Adjust the number of TX channels for SR1.0
From: Diogo Ivo @ 2024-03-26 11:06 UTC (permalink / raw)
To: danishanwar, rogerq, davem, edumazet, kuba, pabeni, andrew,
hkallweit1, linux-arm-kernel, netdev
Cc: Diogo Ivo, jan.kiszka
In-Reply-To: <20240326110709.26165-1-diogo.ivo@siemens.com>
As SR1.0 uses the current higher priority channel to send commands to
the firmware, take this into account when setting/getting the number
of channels to/from the user.
Based on the work of Roger Quadros in TI's 5.10 SDK [1].
[1]: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/?h=ti-linux-5.10.y
Co-developed-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Diogo Ivo <diogo.ivo@siemens.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: MD Danish Anwar <danishanwar@ti.com>
---
Changes in v5:
- Restrict number of TX channels to 1 to avoid timeouts
- Added Reviewed-by tag from Danish
Changes in v4:
- Add Reviewed-by from Roger
Changes in v3:
- Address Roger's comments on SR1.0 handling
drivers/net/ethernet/ti/icssg/icssg_ethtool.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/net/ethernet/ti/icssg/icssg_ethtool.c b/drivers/net/ethernet/ti/icssg/icssg_ethtool.c
index 9a7dd7efcf69..ca20325d4d3e 100644
--- a/drivers/net/ethernet/ti/icssg/icssg_ethtool.c
+++ b/drivers/net/ethernet/ti/icssg/icssg_ethtool.c
@@ -142,6 +142,9 @@ static int emac_set_channels(struct net_device *ndev,
emac->tx_ch_num = ch->tx_count;
+ if (emac->is_sr1)
+ emac->tx_ch_num++;
+
return 0;
}
@@ -152,8 +155,17 @@ static void emac_get_channels(struct net_device *ndev,
ch->max_rx = 1;
ch->max_tx = PRUETH_MAX_TX_QUEUES;
+
+ /* Disable multiple TX channels due to timeouts
+ * when using more than one queue */
+ if (emac->is_sr1)
+ ch->max_tx = 1;
+
ch->rx_count = 1;
ch->tx_count = emac->tx_ch_num;
+
+ if (emac->is_sr1)
+ ch->tx_count--;
}
static const struct ethtool_rmon_hist_range emac_rmon_ranges[] = {
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH net-next v5 08/10] net: ti: icssg-prueth: Add functions to configure SR1.0 packet classifier
From: Diogo Ivo @ 2024-03-26 11:06 UTC (permalink / raw)
To: danishanwar, rogerq, davem, edumazet, kuba, pabeni, andrew,
dan.carpenter, linux-arm-kernel, netdev
Cc: Diogo Ivo, jan.kiszka
In-Reply-To: <20240326110709.26165-1-diogo.ivo@siemens.com>
Add the functions to configure the SR1.0 packet classifier.
Based on the work of Roger Quadros in TI's 5.10 SDK [1].
[1]: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/?h=ti-linux-5.10.y
Co-developed-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Diogo Ivo <diogo.ivo@siemens.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: MD Danish Anwar <danishanwar@ti.com>
---
Changes in v5:
- Added Reviewed-by tags from Danish and Roger
Changes in v4:
- Fix reverse xmastree in icssg_class_ft1_add_mcast()
Changes in v3:
- Replace local variables in icssg_class_add_mcast_sr1()
with eth_reserved_addr_base and eth_ipv4_mcast_addr_base
.../net/ethernet/ti/icssg/icssg_classifier.c | 113 ++++++++++++++++--
drivers/net/ethernet/ti/icssg/icssg_prueth.c | 2 +-
drivers/net/ethernet/ti/icssg/icssg_prueth.h | 6 +-
3 files changed, 110 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/ti/icssg/icssg_classifier.c b/drivers/net/ethernet/ti/icssg/icssg_classifier.c
index 6df53ab17fbc..79ba47bb3602 100644
--- a/drivers/net/ethernet/ti/icssg/icssg_classifier.c
+++ b/drivers/net/ethernet/ti/icssg/icssg_classifier.c
@@ -274,6 +274,16 @@ static void rx_class_set_or(struct regmap *miig_rt, int slice, int n,
regmap_write(miig_rt, offset, data);
}
+static u32 rx_class_get_or(struct regmap *miig_rt, int slice, int n)
+{
+ u32 offset, val;
+
+ offset = RX_CLASS_N_REG(slice, n, RX_CLASS_OR_EN);
+ regmap_read(miig_rt, offset, &val);
+
+ return val;
+}
+
void icssg_class_set_host_mac_addr(struct regmap *miig_rt, const u8 *mac)
{
regmap_write(miig_rt, MAC_INTERFACE_0, (u32)(mac[0] | mac[1] << 8 |
@@ -288,6 +298,26 @@ void icssg_class_set_mac_addr(struct regmap *miig_rt, int slice, u8 *mac)
regmap_write(miig_rt, offs[slice].mac1, (u32)(mac[4] | mac[5] << 8));
}
+static void icssg_class_ft1_add_mcast(struct regmap *miig_rt, int slice,
+ int slot, const u8 *addr, const u8 *mask)
+{
+ u32 val;
+ int i;
+
+ WARN(slot >= FT1_NUM_SLOTS, "invalid slot: %d\n", slot);
+
+ rx_class_ft1_set_da(miig_rt, slice, slot, addr);
+ rx_class_ft1_set_da_mask(miig_rt, slice, slot, mask);
+ rx_class_ft1_cfg_set_type(miig_rt, slice, slot, FT1_CFG_TYPE_EQ);
+
+ /* Enable the FT1 slot in OR enable for all classifiers */
+ for (i = 0; i < ICSSG_NUM_CLASSIFIERS_IN_USE; i++) {
+ val = rx_class_get_or(miig_rt, slice, i);
+ val |= RX_CLASS_FT_FT1_MATCH(slot);
+ rx_class_set_or(miig_rt, slice, i, val);
+ }
+}
+
/* disable all RX traffic */
void icssg_class_disable(struct regmap *miig_rt, int slice)
{
@@ -331,30 +361,95 @@ void icssg_class_disable(struct regmap *miig_rt, int slice)
regmap_write(miig_rt, offs[slice].rx_class_cfg2, 0);
}
-void icssg_class_default(struct regmap *miig_rt, int slice, bool allmulti)
+void icssg_class_default(struct regmap *miig_rt, int slice, bool allmulti,
+ bool is_sr1)
{
+ int num_classifiers = is_sr1 ? ICSSG_NUM_CLASSIFIERS_IN_USE : 1;
u32 data;
+ int n;
/* defaults */
icssg_class_disable(miig_rt, slice);
/* Setup Classifier */
- /* match on Broadcast or MAC_PRU address */
- data = RX_CLASS_FT_BC | RX_CLASS_FT_DA_P;
+ for (n = 0; n < num_classifiers; n++) {
+ /* match on Broadcast or MAC_PRU address */
+ data = RX_CLASS_FT_BC | RX_CLASS_FT_DA_P;
- /* multicast */
- if (allmulti)
- data |= RX_CLASS_FT_MC;
+ /* multicast */
+ if (allmulti)
+ data |= RX_CLASS_FT_MC;
- rx_class_set_or(miig_rt, slice, 0, data);
+ rx_class_set_or(miig_rt, slice, n, data);
- /* set CFG1 for OR_OR_AND for classifier */
- rx_class_sel_set_type(miig_rt, slice, 0, RX_CLASS_SEL_TYPE_OR_OR_AND);
+ /* set CFG1 for OR_OR_AND for classifier */
+ rx_class_sel_set_type(miig_rt, slice, n,
+ RX_CLASS_SEL_TYPE_OR_OR_AND);
+ }
/* clear CFG2 */
regmap_write(miig_rt, offs[slice].rx_class_cfg2, 0);
}
+void icssg_class_promiscuous_sr1(struct regmap *miig_rt, int slice)
+{
+ u32 data, offset;
+ int n;
+
+ /* defaults */
+ icssg_class_disable(miig_rt, slice);
+
+ /* Setup Classifier */
+ for (n = 0; n < ICSSG_NUM_CLASSIFIERS_IN_USE; n++) {
+ /* set RAW_MASK to bypass filters */
+ offset = RX_CLASS_GATES_N_REG(slice, n);
+ regmap_read(miig_rt, offset, &data);
+ data |= RX_CLASS_GATES_RAW_MASK;
+ regmap_write(miig_rt, offset, data);
+ }
+}
+
+void icssg_class_add_mcast_sr1(struct regmap *miig_rt, int slice,
+ struct net_device *ndev)
+{
+ u8 mask_addr[6] = { 0, 0, 0, 0, 0, 0xff };
+ struct netdev_hw_addr *ha;
+ int slot = 2;
+
+ rx_class_ft1_set_start_len(miig_rt, slice, 0, 6);
+ /* reserve first 2 slots for
+ * 1) 01-80-C2-00-00-XX Known Service Ethernet Multicast addresses
+ * 2) 01-00-5e-00-00-XX Local Network Control Block
+ * (224.0.0.0 - 224.0.0.255 (224.0.0/24))
+ */
+ icssg_class_ft1_add_mcast(miig_rt, slice, 0,
+ eth_reserved_addr_base, mask_addr);
+ icssg_class_ft1_add_mcast(miig_rt, slice, 1,
+ eth_ipv4_mcast_addr_base, mask_addr);
+ mask_addr[5] = 0;
+ netdev_for_each_mc_addr(ha, ndev) {
+ /* skip addresses matching reserved slots */
+ if (!memcmp(eth_reserved_addr_base, ha->addr, 5) ||
+ !memcmp(eth_ipv4_mcast_addr_base, ha->addr, 5)) {
+ netdev_dbg(ndev, "mcast skip %pM\n", ha->addr);
+ continue;
+ }
+
+ if (slot >= FT1_NUM_SLOTS) {
+ netdev_dbg(ndev,
+ "can't add more than %d MC addresses, enabling allmulti\n",
+ FT1_NUM_SLOTS);
+ icssg_class_default(miig_rt, slice, 1, true);
+ break;
+ }
+
+ netdev_dbg(ndev, "mcast add %pM\n", ha->addr);
+ icssg_class_ft1_add_mcast(miig_rt, slice, slot,
+ ha->addr, mask_addr);
+ slot++;
+ }
+}
+
/* required for SAV check */
void icssg_ft1_set_mac_addr(struct regmap *miig_rt, int slice, u8 *mac_addr)
{
diff --git a/drivers/net/ethernet/ti/icssg/icssg_prueth.c b/drivers/net/ethernet/ti/icssg/icssg_prueth.c
index e6eac01f9f99..7d9db9683e18 100644
--- a/drivers/net/ethernet/ti/icssg/icssg_prueth.c
+++ b/drivers/net/ethernet/ti/icssg/icssg_prueth.c
@@ -437,7 +437,7 @@ static int emac_ndo_open(struct net_device *ndev)
icssg_class_set_mac_addr(prueth->miig_rt, slice, emac->mac_addr);
icssg_ft1_set_mac_addr(prueth->miig_rt, slice, emac->mac_addr);
- icssg_class_default(prueth->miig_rt, slice, 0);
+ icssg_class_default(prueth->miig_rt, slice, 0, false);
/* Notify the stack of the actual queue counts. */
ret = netif_set_real_num_tx_queues(ndev, num_data_chn);
diff --git a/drivers/net/ethernet/ti/icssg/icssg_prueth.h b/drivers/net/ethernet/ti/icssg/icssg_prueth.h
index c5632a2388a1..21bdb219736a 100644
--- a/drivers/net/ethernet/ti/icssg/icssg_prueth.h
+++ b/drivers/net/ethernet/ti/icssg/icssg_prueth.h
@@ -283,7 +283,11 @@ extern const struct dev_pm_ops prueth_dev_pm_ops;
void icssg_class_set_mac_addr(struct regmap *miig_rt, int slice, u8 *mac);
void icssg_class_set_host_mac_addr(struct regmap *miig_rt, const u8 *mac);
void icssg_class_disable(struct regmap *miig_rt, int slice);
-void icssg_class_default(struct regmap *miig_rt, int slice, bool allmulti);
+void icssg_class_default(struct regmap *miig_rt, int slice, bool allmulti,
+ bool is_sr1);
+void icssg_class_promiscuous_sr1(struct regmap *miig_rt, int slice);
+void icssg_class_add_mcast_sr1(struct regmap *miig_rt, int slice,
+ struct net_device *ndev);
void icssg_ft1_set_mac_addr(struct regmap *miig_rt, int slice, u8 *mac_addr);
/* config helpers */
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/4] arm64: dts: ti: k3-j7*: Add missing ESM and watchdog nodes
From: Neha Malcom Francis @ 2024-03-26 12:27 UTC (permalink / raw)
To: robh, conor+dt, krzysztof.kozlowski+dt, vigneshr, nm
Cc: linux-arm-kernel, devicetree, linux-kernel, kristo, u-kumar1,
n-francis
Add missing ESM and watchdog nodes for the sake of devicetree completion
of hardware description w.r.t Linux and ESM and WDT enablement on
U-Boot. This patch series adds the missing nodes for J721E and J7200.
Boot logs:
https://gist.github.com/nehamalcom/5dc94ab60f57df5d515d0a6d0da6e0d1
Neha Malcom Francis (4):
arm64: dts: ti: k3-j721e-mcu: Add the WKUP ESM instance
arm64: dts: ti: k3-j721e-mcu: Add the MCU domain watchdog instances
arm64: dts: ti: k3-j721e-main: Add the MAIN domain watchdog instances
arm64: dts: ti: k3-j7200-main: Add the MAIN domain watchdog instances
arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 27 ++++++
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 93 +++++++++++++++++++
.../boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 31 +++++++
3 files changed, 151 insertions(+)
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/4] arm64: dts: ti: k3-j721e-mcu: Add the WKUP ESM instance
From: Neha Malcom Francis @ 2024-03-26 12:27 UTC (permalink / raw)
To: robh, conor+dt, krzysztof.kozlowski+dt, vigneshr, nm
Cc: linux-arm-kernel, devicetree, linux-kernel, kristo, u-kumar1,
n-francis
In-Reply-To: <20240326122723.2329402-1-n-francis@ti.com>
Add the WKUP ESM instance for J721E. It has three instances in total,
one in the MAIN domain (main_esm) and two in the MCU-WKUP domain
(mcu_esm and wkup_esm).
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
---
arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
index 4618b697fbc4..b0f41e9829cc 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
@@ -689,4 +689,9 @@ mcu_esm: esm@40800000 {
ti,esm-pins = <95>;
bootph-pre-ram;
};
+
+ wkup_esm: esm@42080000 {
+ compatible = "ti,j721e-esm";
+ reg = <0x00 0x42080000 0x00 0x1000>;
+ };
};
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/4] arm64: dts: ti: k3-j721e-main: Add the MAIN domain watchdog instances
From: Neha Malcom Francis @ 2024-03-26 12:27 UTC (permalink / raw)
To: robh, conor+dt, krzysztof.kozlowski+dt, vigneshr, nm
Cc: linux-arm-kernel, devicetree, linux-kernel, kristo, u-kumar1,
n-francis
In-Reply-To: <20240326122723.2329402-1-n-francis@ti.com>
There are 10 watchdog instances in the MAIN domain:
* one each for the 2 A72 cores
* one for the GPU core
* one for the C7x core
* one each for the 2 C66x cores
* one each for the 4 R5F cores
Currently, the devicetree only describes watchdog instances for the A72
cores and enables them. Describe the remaining but reserve them as they
will be used by their respective firmware.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
---
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 93 +++++++++++++++++++++++
1 file changed, 93 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
index c7eafbc862f9..d8930b8ea8ec 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
@@ -2157,6 +2157,99 @@ watchdog1: watchdog@2210000 {
assigned-clock-parents = <&k3_clks 253 5>;
};
+ /*
+ * The following RTI instances are coupled with MCU R5Fs, c7x and
+ * GPU so keeping them reserved as these will be used by their
+ * respective firmware
+ */
+ watchdog2: watchdog@22f0000 {
+ compatible = "ti,j7-rti-wdt";
+ reg = <0x00 0x22f0000 0x00 0x100>;
+ clocks = <&k3_clks 257 1>;
+ power-domains = <&k3_pds 257 TI_SCI_PD_EXCLUSIVE>;
+ assigned-clocks = <&k3_clks 257 1>;
+ assigned-clock-parents = <&k3_clks 257 5>;
+ /* reserved for GPU */
+ status = "reserved";
+ };
+
+ watchdog3: watchdog@2300000 {
+ compatible = "ti,j7-rti-wdt";
+ reg = <0x00 0x2300000 0x00 0x100>;
+ clocks = <&k3_clks 256 1>;
+ power-domains = <&k3_pds 256 TI_SCI_PD_EXCLUSIVE>;
+ assigned-clocks = <&k3_clks 256 1>;
+ assigned-clock-parents = <&k3_clks 256 5>;
+ /* reserved for C7X */
+ status = "reserved";
+ };
+
+ watchdog4: watchdog@2380000 {
+ compatible = "ti,j7-rti-wdt";
+ reg = <0x00 0x2380000 0x00 0x100>;
+ clocks = <&k3_clks 254 1>;
+ power-domains = <&k3_pds 254 TI_SCI_PD_EXCLUSIVE>;
+ assigned-clocks = <&k3_clks 254 1>;
+ assigned-clock-parents = <&k3_clks 254 5>;
+ /* reserved for C66X_0 */
+ status = "reserved";
+ };
+
+ watchdog5: watchdog@2390000 {
+ compatible = "ti,j7-rti-wdt";
+ reg = <0x00 0x2390000 0x00 0x100>;
+ clocks = <&k3_clks 255 1>;
+ power-domains = <&k3_pds 255 TI_SCI_PD_EXCLUSIVE>;
+ assigned-clocks = <&k3_clks 255 1>;
+ assigned-clock-parents = <&k3_clks 255 5>;
+ /* reserved for C66X_1 */
+ status = "reserved";
+ };
+
+ watchdog6: watchdog@23c0000 {
+ compatible = "ti,j7-rti-wdt";
+ reg = <0x00 0x23c0000 0x00 0x100>;
+ clocks = <&k3_clks 258 1>;
+ power-domains = <&k3_pds 258 TI_SCI_PD_EXCLUSIVE>;
+ assigned-clocks = <&k3_clks 258 1>;
+ assigned-clock-parents = <&k3_clks 258 5>;
+ /* reserved for MAIN_R5F0_0 */
+ status = "reserved";
+ };
+
+ watchdog7: watchdog@23d0000 {
+ compatible = "ti,j7-rti-wdt";
+ reg = <0x00 0x23d0000 0x00 0x100>;
+ clocks = <&k3_clks 259 1>;
+ power-domains = <&k3_pds 259 TI_SCI_PD_EXCLUSIVE>;
+ assigned-clocks = <&k3_clks 259 1>;
+ assigned-clock-parents = <&k3_clks 259 5>;
+ /* reserved for MAIN_R5F0_1 */
+ status = "reserved";
+ };
+
+ watchdog8: watchdog@23e0000 {
+ compatible = "ti,j7-rti-wdt";
+ reg = <0x00 0x23e0000 0x00 0x100>;
+ clocks = <&k3_clks 260 1>;
+ power-domains = <&k3_pds 260 TI_SCI_PD_EXCLUSIVE>;
+ assigned-clocks = <&k3_clks 260 1>;
+ assigned-clock-parents = <&k3_clks 260 5>;
+ /* reserved for MAIN_R5F1_0 */
+ status = "reserved";
+ };
+
+ watchdog9: watchdog@23f0000 {
+ compatible = "ti,j7-rti-wdt";
+ reg = <0x00 0x23f0000 0x00 0x100>;
+ clocks = <&k3_clks 261 1>;
+ power-domains = <&k3_pds 261 TI_SCI_PD_EXCLUSIVE>;
+ assigned-clocks = <&k3_clks 261 1>;
+ assigned-clock-parents = <&k3_clks 261 5>;
+ /* reserved for MAIN_R5F1_1 */
+ status = "reserved";
+ };
+
main_r5fss0: r5fss@5c00000 {
compatible = "ti,j721e-r5fss";
ti,cluster-mode = <1>;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 4/4] arm64: dts: ti: k3-j7200-main: Add the MAIN domain watchdog instances
From: Neha Malcom Francis @ 2024-03-26 12:27 UTC (permalink / raw)
To: robh, conor+dt, krzysztof.kozlowski+dt, vigneshr, nm
Cc: linux-arm-kernel, devicetree, linux-kernel, kristo, u-kumar1,
n-francis
In-Reply-To: <20240326122723.2329402-1-n-francis@ti.com>
There are 4 watchdog instances in the MAIN domain:
* one each for the 2 A72 cores
* one each for the 2 R5F cores
Currently, the devicetree only describes watchdog instances for the A72
cores and enables them. Describe the remaining but reserve them as they
will be used by their respective firmware.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
---
arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 27 +++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
index 657f9cc9f4ea..c448c2218e23 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
@@ -1254,6 +1254,33 @@ watchdog1: watchdog@2210000 {
assigned-clock-parents = <&k3_clks 253 5>;
};
+ /*
+ * The following RTI instances are coupled with MCU R5Fs so
+ * keeping them reserved as these will be used by their respective
+ * firmware
+ */
+ watchdog2: watchdog@23c0000 {
+ compatible = "ti,j7-rti-wdt";
+ reg = <0x00 0x23c0000 0x00 0x100>;
+ clocks = <&k3_clks 258 1>;
+ power-domains = <&k3_pds 258 TI_SCI_PD_EXCLUSIVE>;
+ assigned-clocks = <&k3_clks 258 1>;
+ assigned-clock-parents = <&k3_clks 258 5>;
+ /* reserved for MAIN_R5F0_0 */
+ status = "reserved";
+ };
+
+ watchdog3: watchdog@23d0000 {
+ compatible = "ti,j7-rti-wdt";
+ reg = <0x00 0x23d0000 0x00 0x100>;
+ clocks = <&k3_clks 259 1>;
+ power-domains = <&k3_pds 259 TI_SCI_PD_EXCLUSIVE>;
+ assigned-clocks = <&k3_clks 259 1>;
+ assigned-clock-parents = <&k3_clks 259 5>;
+ /* reserved for MAIN_R5F0_1 */
+ status = "reserved";
+ };
+
main_timer0: timer@2400000 {
compatible = "ti,am654-timer";
reg = <0x00 0x2400000 0x00 0x400>;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/4] arm64: dts: ti: k3-j721e-mcu: Add the MCU domain watchdog instances
From: Neha Malcom Francis @ 2024-03-26 12:27 UTC (permalink / raw)
To: robh, conor+dt, krzysztof.kozlowski+dt, vigneshr, nm
Cc: linux-arm-kernel, devicetree, linux-kernel, kristo, u-kumar1,
n-francis
In-Reply-To: <20240326122723.2329402-1-n-francis@ti.com>
There are 2 watchdog instances in the MCU domain. These instances are
coupled with the MCU domain R55 instances. Reserve them as they are not
used by A72.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
---
.../boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 26 +++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
index b0f41e9829cc..867f307909be 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
@@ -694,4 +694,30 @@ wkup_esm: esm@42080000 {
compatible = "ti,j721e-esm";
reg = <0x00 0x42080000 0x00 0x1000>;
};
+
+ /*
+ * The 2 RTI instances are couple with MCU R5Fs so keeping them
+ * reserved as these will be used by their respective firmware
+ */
+ mcu_watchdog0: watchdog@40600000 {
+ compatible = "ti,j7-rti-wdt";
+ reg = <0x00 0x40600000 0x00 0x100>;
+ clocks = <&k3_clks 262 1>;
+ power-domains = <&k3_pds 262 TI_SCI_PD_EXCLUSIVE>;
+ assigned-clocks = <&k3_clks 262 1>;
+ assigned-clock-parents = <&k3_clks 262 5>;
+ /* reserved for MCU_R5F0_0 */
+ status = "reserved";
+ };
+
+ mcu_watchdog1: watchdog@40610000 {
+ compatible = "ti,j7-rti-wdt";
+ reg = <0x00 0x40610000 0x00 0x100>;
+ clocks = <&k3_clks 263 1>;
+ power-domains = <&k3_pds 263 TI_SCI_PD_EXCLUSIVE>;
+ assigned-clocks = <&k3_clks 263 1>;
+ assigned-clock-parents = <&k3_clks 263 5>;
+ /* reserved for MCU_R5F0_1 */
+ status = "reserved";
+ };
};
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v1 00/13] regulator: convert to use maple tree register cache
From: Mark Brown @ 2024-03-26 12:39 UTC (permalink / raw)
To: support.opensource, lgirdwood, matthias.bgg,
angelogioacchino.delregno, jagan, Bo Liu
Cc: linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20240320085740.4604-1-liubo03@inspur.com>
On Wed, 20 Mar 2024 04:57:27 -0400, Bo Liu wrote:
> The maple tree register cache is based on a much more modern data structure
> than the rbtree cache and makes optimisation choices which are probably
> more appropriate for modern systems than those made by the rbtree cache.
>
> Bo Liu (13):
> regulator: da9121: convert to use maple tree register cache
> regulator: da9211: convert to use maple tree register cache
> regulator: isl9305: convert to use maple tree register cache
> regulator: max8973: convert to use maple tree register cache
> regulator: mt6311: convert to use maple tree register cache
> regulator: pca9450: convert to use maple tree register cache
> regulator: pf8x00: convert to use maple tree register cache
> regulator: pfuze100: convert to use maple tree register cache
> regulator: rtmv20: convert to use maple tree register cache
> regulator: rtq6752: convert to use maple tree register cache
> regulator: tps51632: convert to use maple tree register cache
> regulator: tps62360: convert to use maple tree register cache
> regulator: rpi-panel-attiny: convert to use maple tree register cache
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
Thanks!
[01/13] regulator: da9121: convert to use maple tree register cache
commit: d92eb7c333c5ac8d8add10d5a211ac9c405e4393
[02/13] regulator: da9211: convert to use maple tree register cache
commit: 03ddbcbe2f1ca9fac2759849be6714d8e82aa331
[03/13] regulator: isl9305: convert to use maple tree register cache
commit: 66a4ead5ed9393d250105fcbe6e3525e1cdd977a
[04/13] regulator: max8973: convert to use maple tree register cache
commit: 36649db5b216a85cfd7937a289c4cdd0b4b69126
[05/13] regulator: mt6311: convert to use maple tree register cache
commit: bc125125125c10ec14764d153227c95ad0fd0b48
[06/13] regulator: pca9450: convert to use maple tree register cache
commit: 0b03e9cb8b137490f4adedf07482384ffeee7145
[07/13] regulator: pf8x00: convert to use maple tree register cache
commit: cea065dced280306ff5a4f7adfeb3773c49b2818
[08/13] regulator: pfuze100: convert to use maple tree register cache
commit: 0332f074f5c3d8c2a32db24c9dcc3c3f13056cef
[09/13] regulator: rtmv20: convert to use maple tree register cache
commit: 43edba6b670bc4f5426e77873b400fe91f8d3c75
[10/13] regulator: rtq6752: convert to use maple tree register cache
commit: 81c180e77d60755ca5ff217786e2f427ccab04e0
[11/13] regulator: tps51632: convert to use maple tree register cache
commit: 9500d38e50d0cfd33536454a204dedb9d47d84a3
[12/13] regulator: tps62360: convert to use maple tree register cache
commit: fe258f54c0a85c1bfc0e836e20c3e4e52f1a8318
[13/13] regulator: rpi-panel-attiny: convert to use maple tree register cache
commit: ab470abe58c09b2fbe2c1478e67a904fd803e84f
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/3] spi: pxa2xx: Clean up linux/spi/pxa2xx_spi.h
From: Mark Brown @ 2024-03-26 12:39 UTC (permalink / raw)
To: Arnd Bergmann, linux-spi, linux-kernel, linux-arm-kernel,
Andy Shevchenko
Cc: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King
In-Reply-To: <20240307195056.4059864-1-andriy.shevchenko@linux.intel.com>
On Thu, 07 Mar 2024 21:47:44 +0200, Andy Shevchenko wrote:
> A couple of cleanups against linux/spi/pxa2xx_spi.h.
>
> I'm sending this as v3 to land in the SPI subsystem. Meanwhile I'm
> preparing an update to make linux/spi/pxa2xx_spi.h private to the
> subsystem (PXA2xx driver). But the second part will be presented later
> on (likely after v6.9-rc1). That said, this can be routed either via
> SoC tree or SPI, up to respective maintainers.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/3] spi: pxa2xx: Kill pxa2xx_set_spi_info()
commit: 7fd54c205f104317b853fc417ac7e9d0b9531ddb
[2/3] spi: pxa2xx: Make num_chipselect 8-bit in the struct pxa2xx_spi_controller
commit: e3f209e269d32ebc0ba7f497f5d2af21ed4f0dd0
[3/3] spi: pxa2xx: Use proper SSP header in soc/pxa/ssp.c
commit: b5867a5c0d7a6bf36f59f3d472c7aed33ca4d02c
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox