* Re: [PATCH v5 02/10] dt-bindings: mailbox: Add mboxes property for CMDQ secure driver
From: Conor Dooley @ 2024-04-04 14:52 UTC (permalink / raw)
To: Jason-JH Lin (林睿祥)
Cc: Shawn Sung (宋孝謙),
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
Houlong Wei (魏厚龙),
devicetree@vger.kernel.org, CK Hu (胡俊光),
conor+dt@kernel.org, robh@kernel.org,
linux-arm-kernel@lists.infradead.org,
krzysztof.kozlowski+dt@linaro.org, matthias.bgg@gmail.com,
jassisinghbrar@gmail.com, angelogioacchino.delregno@collabora.com
In-Reply-To: <9b9707a4a0e285a12741fe4140680ad2578d8d2b.camel@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 2253 bytes --]
On Thu, Apr 04, 2024 at 04:31:06AM +0000, Jason-JH Lin (林睿祥) wrote:
> Hi Conor,
>
> Thanks for the reviews.
>
> On Wed, 2024-04-03 at 16:46 +0100, Conor Dooley wrote:
> > On Wed, Apr 03, 2024 at 06:25:54PM +0800, Shawn Sung wrote:
> > > From: "Jason-JH.Lin" <jason-jh.lin@mediatek.com>
> > >
> > > Add mboxes to define a GCE loopping thread as a secure irq handler.
> > > This property is only required if CMDQ secure driver is supported.
> > >
> > > Signed-off-by: Jason-JH.Lin <jason-jh.lin@mediatek.com>
> > > Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com>
> > > ---
> > > .../bindings/mailbox/mediatek,gce-mailbox.yaml | 10
> > > ++++++++++
> > > 1 file changed, 10 insertions(+)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/mailbox/mediatek,gce-
> > > mailbox.yaml
> > > b/Documentation/devicetree/bindings/mailbox/mediatek,gce-
> > > mailbox.yaml
> > > index cef9d76013985..c0d80cc770899 100644
> > > --- a/Documentation/devicetree/bindings/mailbox/mediatek,gce-
> > > mailbox.yaml
> > > +++ b/Documentation/devicetree/bindings/mailbox/mediatek,gce-
> > > mailbox.yaml
> > > @@ -49,6 +49,16 @@ properties:
> > > items:
> > > - const: gce
> > >
> > > + mediatek,gce-events:
> > > + description:
> > > + The event id which is mapping to the specific hardware event
> > > signal
> > > + to gce. The event id is defined in the gce header
> > > + include/dt-bindings/gce/<chip>-gce.h of each chips.
> >
> > Missing any info here about when this should be used, hint - you have
> > it
> > in the commit message.
> >
> > > + $ref: /schemas/types.yaml#/definitions/uint32-arrayi
> >
> > Why is the ID used by the CMDQ service not fixed for each SoC?
> >
> I forgot to sync with Shawn about this:
> https://lore.kernel.org/all/20240124011459.12204-1-jason-
> jh.lin@mediatek.com
>
> I'll fix it at the next version.
When I say "fixed" I don't mean "this is wrong, please fix it", I mean
"why is the value not static for a particular SoC". This needs to be
explained in the patch (and the description for the event here needs to
explain what the gce-mailbox is reserving an event for).
Thanks,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: rockchip: add Protonic MECSBC device-tree
From: Andrew Lunn @ 2024-04-04 15:10 UTC (permalink / raw)
To: Sascha Hauer
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
David Jander
In-Reply-To: <20240404-protonic-mecsbc-v1-2-ad5b42ade6c6@pengutronix.de>
> +&gmac1 {
> + assigned-clocks = <&cru SCLK_GMAC1_RX_TX>, <&cru SCLK_GMAC1>;
> + assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>, <&cru CLK_MAC1_2TOP>;
> + phy-handle = <&rgmii_phy1>;
> + phy-mode = "rgmii";
> + clock_in_out = "output";
> + pinctrl-names = "default";
> + pinctrl-0 = <&gmac1m1_miim
> + &gmac1m1_tx_bus2
> + &gmac1m1_rx_bus2
> + &gmac1m1_rgmii_clk
> + &gmac1m1_clkinout
> + &gmac1m1_rgmii_bus>;
> + status = "okay";
> + tx_delay = <0x30>;
> + rx_delay = <0x10>;
> +};
There was a discussion about phy-mode = "rgmii"; and these
tx/rx_delays last month. Please could you go read that discussion and
them make use of rgmii-id, and change the delays.
Also, where did you copy this from? If possible, it would be good to
fix the example everybody copies into new DT blobs.
Andrew
^ permalink raw reply
* Re: [PATCH v2 15/15] arm64: dts: mediatek: mt8188: add default thermal zones
From: Daniel Lezcano @ 2024-04-04 15:16 UTC (permalink / raw)
To: Nicolas Pitre, linux-pm, linux-mediatek, devicetree
Cc: Nicolas Pitre, AngeloGioacchino Del Regno
In-Reply-To: <20240402032729.2736685-16-nico@fluxnic.net>
Hi Nico,
a few comments about this description.
On 02/04/2024 05:25, Nicolas Pitre wrote:
> From: Nicolas Pitre <npitre@baylibre.com>
>
> Inspired by the vendor kernel but adapted to the upstream thermal
> driver version.
[ ... ]
> + thermal_zones: thermal-zones {
> + cpu-little0-thermal {
> + polling-delay = <1000>;
Except if I'm wrong, the driver supports the interrupt mode, so it not
necessary to poll constantly when there is no mitigation. You can remove
the line and everywhere else.
> + polling-delay-passive = <250>;
As little CPU, 200ms or 150ms may be more adequate.
> + thermal-sensors = <&lvts_mcu MT8188_MCU_LITTLE_CPU0>;
> +
> + trips {
> + cpu_little0_alert: trip-alert {
> + temperature = <85000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
You may want to add a 'hot' trip point in between, so the userspace can
be notified and take an action before reaching 'critical' (like
unplugging a CPU)
> + cpu_little0_crit: trip-crit {
> + temperature = <100000>;
> + hysteresis = <2000>;
critical is a point of no return. Hysteresis does not make sense.
These comments apply to all thermal zones.
[ .. ]
> + cpu_big0-thermal {
> + polling-delay = <1000>;
> + polling-delay-passive = <250>;
Same comments as the little but may be an even lower value. eg. 100ms.
> + thermal-sensors = <&lvts_mcu MT8188_MCU_BIG_CPU0>;
> +
> + trips {
> + cpu_big0_alert: trip-alert {
> + temperature = <85000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> +
> + cpu_big0_crit: trip-crit {
> + temperature = <100000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> +
> + cooling-maps {
> + map0 {
> + trip = <&cpu_big0_alert>;
> + cooling-device = <&cpu6 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <&cpu7 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> + };
> + };
> + };
[ ... ]
> + gpu1-thermal {
> + polling-delay = <1000>;
> + polling-delay-passive = <250>;
> + thermal-sensors = <&lvts_ap MT8188_AP_GPU1>;
> +
> + trips {
> + gpu1_alert: trip-alert {
> + temperature = <85000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> +
> + gpu1_crit: trip-crit {
> + temperature = <100000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
> +
> + gpu2-thermal {
> + polling-delay = <1000>;
> + polling-delay-passive = <250>;
> + thermal-sensors = <&lvts_ap MT8188_AP_GPU2>;
> +
> + trips {
> + gpu2_alert: trip-alert {
> + temperature = <85000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> +
> + gpu2_crit: trip-crit {
> + temperature = <100000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
You can add a devfreq cooling device for the GPU here.
[ ... ]
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: rockchip: add Protonic MECSBC device-tree
From: Diederik de Haas @ 2024-04-04 15:26 UTC (permalink / raw)
To: Sascha Hauer
Cc: linux-rockchip, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, David Jander, Andrew Lunn
In-Reply-To: <9d325b4e-031c-4f6c-9788-fa5a68470efa@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 970 bytes --]
On Thursday, 4 April 2024 17:10:41 CEST Andrew Lunn wrote:
> > +&gmac1 {
> > + assigned-clocks = <&cru SCLK_GMAC1_RX_TX>, <&cru SCLK_GMAC1>;
> > + assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>, <&cru
> > CLK_MAC1_2TOP>; + phy-handle = <&rgmii_phy1>;
> > + phy-mode = "rgmii";
> > + clock_in_out = "output";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&gmac1m1_miim
> > + &gmac1m1_tx_bus2
> > + &gmac1m1_rx_bus2
> > + &gmac1m1_rgmii_clk
> > + &gmac1m1_clkinout
> > + &gmac1m1_rgmii_bus>;
> > + status = "okay";
> > + tx_delay = <0x30>;
> > + rx_delay = <0x10>;
> > +};
>
> There was a discussion about phy-mode = "rgmii"; and these
> tx/rx_delays last month. Please could you go read that discussion and
> them make use of rgmii-id, and change the delays.
https://lore.kernel.org/linux-rockchip/20240304084612.711678-2-ukleinek@debian.org/
titled "[PATCH] arm64: dts: rockchip: qnap-ts433: Simplify network PHY connection"
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: qcom: msm8998: set qcom,no-msa-ready-indicator for wifi
From: Kalle Valo @ 2024-04-04 15:28 UTC (permalink / raw)
To: Marc Gonzalez
Cc: Dmitry Baryshkov, Konrad Dybcio, Krzysztof Kozlowski,
Jeff Johnson, ath10k, wireless, DT, MSM, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Pierre-Hugues Husson,
Arnaud Vrac, Bjorn Andersson, Jami Kettunen, Jeffrey Hugo
In-Reply-To: <e804b257-4dc0-45f1-a5c5-66bda51cf296@freebox.fr>
Marc Gonzalez <mgonzalez@freebox.fr> writes:
> On 04/04/2024 13:57, Kalle Valo wrote:
>
>> Dmitry Baryshkov wrote:
>>
>>> I'd say, we should take a step back and actually verify how this was
>>> handled in the vendor kernel.
>>
>> One comment related to this: usually vendor driver and firmware branches
>> go "hand in hand", meaning that a version of driver supports only one
>> specific firmware branch. And there can be a lot of branches. So even if
>> one branch might have a check for something specific, there are no
>> guarantees what the other N+1 branches do :/
>
> The consequences and ramifications of the above comment are not clear to me.
>
> Does this mean:
> "It is pointless to analyze a given version (or even several versions)
> of the vendor driver downstream, because there are exist a large number
> of variations of the code." ?
I was trying to say that because the design philosophy between vendor
drivers and upstream drivers is very different, we can't 100% trust
vendor drivers. It's a very good idea to check what vendor drivers do
but we just need to be careful before making any conclusions. Testing
real hardware (and corresponding firmware) is the most reliable way to
know how different products/firmware work, unfortunately.
> And thus, "it is nonsensical to try to "align" the mainline driver to
> "the" vendor driver, as there is no single "vendor driver"" ?
No no, I'm not saying that. I have suffered this "N+1 different firmware
branches behaving slighly differently" problem since ath6kl days so for
me this is business as usual, sadly. I'm sure we can find a solution for
ath10k.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH v2 1/3] dt-bindings: arm64: marvell: add solidrun cn9130 som based boards
From: Josua Mayer @ 2024-04-04 15:35 UTC (permalink / raw)
To: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Rob Herring
Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel,
Josua Mayer
In-Reply-To: <20240404-cn9130-som-v2-0-3af2229c7d2d@solid-run.com>
Add bindings for SolidRun boards based on CN9130 SoM.
Three boards are added in total:
- Clearfog Base
- Clearfog Pro
- SolidWAN
The Clearfog boards are identical to the older Armada 388 based boards,
upgraded with a new SoM and SoC.
However the feature set and performance characteristics are different,
therefore compatible strings from armada 388 versions are not included.
SolidWAN uses the same SoM adding a southbridge on the carrier.
Since 2019 there are bindings in-tree for two boards based on cn9130 and
9131. These are extremely verbose by listing cn9132, cn9131, cn9130,
ap807-quad, ap807 for the SoC alone.
CN9130 SoC combines an application processor (ap807) and a
communication processor (cp115) in a single package.
The communication processor (short CP) is also available separately as a
southbridge. It only functions in combination with the CN9130 SoC.
Complete systems adding one or two southbridges are by convention called
CN9131 and CN9132 respectively.
Despite different naming all systems are built around the same SoC.
Therefore marvell,cn9131 and marvell,cn9132 can be omitted. The number
of CPs is part of a board's BoM and can be reflected in the board
compatible string instead.
Existing bindings also describe cn9130 as a specialisation of
ap807-quad. Usually board-level compatibles stop at the SoC without
going into silicon versions or individual dies.
There is no programming model at this layer, and in particular not for
parts of an SoC. Therefore the ap compatibles can also be omitted.
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
.../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
index 16d2e132d3d1..74d935ea279c 100644
--- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
@@ -82,4 +82,14 @@ properties:
- const: marvell,armada-ap807-quad
- const: marvell,armada-ap807
+ - description:
+ SolidRun CN9130 SoM based single-board computers
+ items:
+ - enum:
+ - solidrun,cn9130-clearfog-base
+ - solidrun,cn9130-clearfog-pro
+ - solidrun,cn9131-solidwan
+ - const: solidrun,cn9130-sr-som
+ - const: marvell,cn9130
+
additionalProperties: true
--
2.35.3
^ permalink raw reply related
* [PATCH v2 0/3] arm64: dts: add description for solidrun cn9130 som and clearfog boards
From: Josua Mayer @ 2024-04-04 15:35 UTC (permalink / raw)
To: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Rob Herring
Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel,
Josua Mayer
SolidRun CN9130 SoM is a mostly pin-comptible replacement for Armada 388
SoM used in Clearfog and Clearfog Pro boards.
1. Add new binding for compatible strings closely matching the original.
2. Add device-tree includes for SoM and carrier shared design.
3. Add device-tree for both Clearfog Base and Pro.
While dtbs_check is happy with LED descriptions behind dsa switch,
functionally they require supporting code by Andrew Lunn:
https://lore.kernel.org/r/20240401-v6-8-0-net-next-mv88e6xxx-leds-v4-v3-0-221b3fa55f78@lunn.ch
NOTICE IN CASE ANYBODY WANTS TO SELF-UPGRADE:
CN9130 SoM has a different footprint from Armada 388 SoM.
Components on the carrier board below the SoM may collide causing
damage, such as on Clearfog Base.
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
Changes in v2:
- rewrote dt bindings dropping unnecessary compatibles
(Reported-By: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>)
- added bindings for two additional boards (cn9131/9132)
support planned for the coming weeks, mostly serves
illustrational purposes, to understand cn913x variants
- cf-pro: add description for LEDs behind DSA switch
- cf-base: add description for LEDs behind PHYs
(Reported-By: Andrew Lunn <andrew@lunn.ch>)
- Link to v1: https://lore.kernel.org/r/20240321-cn9130-som-v1-0-711127a409ae@solid-run.com
---
Josua Mayer (3):
dt-bindings: arm64: marvell: add solidrun cn9130 som based boards
dt-bindings: arm64: marvell: add solidrun cn9132 CEX-7 evaluation board
arm64: dts: add description for solidrun cn9130 som and clearfog boards
.../bindings/arm/marvell/armada-7k-8k.yaml | 18 +
arch/arm64/boot/dts/marvell/Makefile | 2 +
arch/arm64/boot/dts/marvell/cn9130-cf-base.dts | 178 ++++++++++
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dts | 367 +++++++++++++++++++++
arch/arm64/boot/dts/marvell/cn9130-cf.dtsi | 193 +++++++++++
arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi | 159 +++++++++
6 files changed, 917 insertions(+)
---
base-commit: 4cece764965020c22cff7665b18a012006359095
change-id: 20240318-cn9130-som-848e86acb0ac
Sincerely,
--
Josua Mayer <josua@solid-run.com>
^ permalink raw reply
* [PATCH v2 2/3] dt-bindings: arm64: marvell: add solidrun cn9132 CEX-7 evaluation board
From: Josua Mayer @ 2024-04-04 15:35 UTC (permalink / raw)
To: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Rob Herring
Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel,
Josua Mayer
In-Reply-To: <20240404-cn9130-som-v2-0-3af2229c7d2d@solid-run.com>
Add bindings for the SolidRun CN9132 COM-Express Type 7 evaluation board.
The CEX is based on CN9130 SoC and includes two southbridges.
Because CN9132 and 9131 are just names for different designs around the
same SoC, there no soc compatibles beside marvell,cn9130 are needed.
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
index 74d935ea279c..538d91be8857 100644
--- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
@@ -92,4 +92,12 @@ properties:
- const: solidrun,cn9130-sr-som
- const: marvell,cn9130
+ - description:
+ SolidRun CN9132 COM-Express Type 7 based single-board computers
+ items:
+ - enum:
+ - solidrun,cn9132-clearfog
+ - const: solidrun,cn9132-sr-cex7
+ - const: marvell,cn9130
+
additionalProperties: true
--
2.35.3
^ permalink raw reply related
* [PATCH v2 3/3] arm64: dts: add description for solidrun cn9130 som and clearfog boards
From: Josua Mayer @ 2024-04-04 15:35 UTC (permalink / raw)
To: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Rob Herring
Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel,
Josua Mayer
In-Reply-To: <20240404-cn9130-som-v2-0-3af2229c7d2d@solid-run.com>
Add description for the SolidRun CN9130 SoM, and Clearfog Base / Pro
reference boards.
The SoM has been designed as a pin-compatible replacement for the older
Armada 388 based SoM. Therefore it supports the same boards and a
similar feature set.
Most notable upgrades:
- 4x Cortex-A72
- 10Gbps SFP
- Both eMMC and SD supported at the same time
The developer first supporting this product at SolidRun decided to use
different filenames for the DTBs: Armada 388 uses the full
"clearfog" string while cn9130 uses the abbreviation "cf".
This name is already hard-coded in pre-installed vendor u-boot and can
not be changed easily.
NOTICE IN CASE ANYBODY WANTS TO SELF-UPGRADE:
CN9130 SoM has a different footprint from Armada 388 SoM.
Components on the carrier board below the SoM may collide causing
damage, such as on Clearfog Base.
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
arch/arm64/boot/dts/marvell/Makefile | 2 +
arch/arm64/boot/dts/marvell/cn9130-cf-base.dts | 178 ++++++++++++
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dts | 367 +++++++++++++++++++++++++
arch/arm64/boot/dts/marvell/cn9130-cf.dtsi | 193 +++++++++++++
arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi | 159 +++++++++++
5 files changed, 899 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile
index 99b8cb3c49e1..019f2251d696 100644
--- a/arch/arm64/boot/dts/marvell/Makefile
+++ b/arch/arm64/boot/dts/marvell/Makefile
@@ -28,3 +28,5 @@ dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-A.dtb
dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-B.dtb
dtb-$(CONFIG_ARCH_MVEBU) += ac5x-rd-carrier-cn9131.dtb
dtb-$(CONFIG_ARCH_MVEBU) += ac5-98dx35xx-rd.dtb
+dtb-$(CONFIG_ARCH_MVEBU) += cn9130-cf-base.dtb
+dtb-$(CONFIG_ARCH_MVEBU) += cn9130-cf-pro.dtb
diff --git a/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts b/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts
new file mode 100644
index 000000000000..788a5c302b17
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts
@@ -0,0 +1,178 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2024 Josua Mayer <josua@solid-run.com>
+ *
+ * DTS for SolidRun CN9130 Clearfog Base.
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+
+#include "cn9130.dtsi"
+#include "cn9130-sr-som.dtsi"
+#include "cn9130-cf.dtsi"
+
+/ {
+ model = "SolidRun CN9130 Clearfog Base";
+ compatible = "solidrun,cn9130-clearfog-base",
+ "solidrun,cn9130-sr-som", "marvell,cn9130";
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-0 = <&rear_button_pins>;
+ pinctrl-names = "default";
+
+ button-0 {
+ /* The rear SW3 button */
+ label = "Rear Button";
+ gpios = <&cp0_gpio1 31 GPIO_ACTIVE_LOW>;
+ linux,can-disable;
+ linux,code = <BTN_0>;
+ };
+ };
+
+ rfkill-m2-gnss {
+ compatible = "rfkill-gpio";
+ label = "m.2 GNSS";
+ radio-type = "gps";
+ /* rfkill-gpio inverts internally */
+ shutdown-gpios = <&expander0 9 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* M.2 is B-keyed, so w-disable is for WWAN */
+ rfkill-m2-wwan {
+ compatible = "rfkill-gpio";
+ label = "m.2 WWAN";
+ radio-type = "wwan";
+ /* rfkill-gpio inverts internally */
+ shutdown-gpios = <&expander0 8 GPIO_ACTIVE_HIGH>;
+ };
+};
+
+/* SRDS #3 - SGMII 1GE */
+&cp0_eth1 {
+ phy = <&phy1>;
+ phys = <&cp0_comphy3 1>;
+ phy-mode = "sgmii";
+ status = "okay";
+};
+
+&cp0_eth2_phy {
+ /*
+ * Configure LEDs default behaviour:
+ * - LED[0]: link/activity: On/blink (green)
+ * - LED[1]: link is 100/1000Mbps: On (yellow)
+ * - LED[2]: high impedance (floating)
+ */
+ marvell,reg-init = <3 16 0xf000 0x0a61>;
+
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_WAN;
+ default-state = "keep";
+ };
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_YELLOW>;
+ function = LED_FUNCTION_WAN;
+ default-state = "keep";
+ };
+ };
+};
+
+&cp0_gpio1 {
+ sim-select-hog {
+ gpio-hog;
+ gpios = <27 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "sim-select";
+ };
+};
+
+&cp0_mdio {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ /*
+ * Configure LEDs default behaviour:
+ * - LED[0]: link/activity: On/blink (green)
+ * - LED[1]: link is 100/1000Mbps: On (yellow)
+ * - LED[2]: high impedance (floating)
+ *
+ * Configure LEDs electrical polarity
+ * - on-state: low
+ * - off-state: high (not hi-z, to avoid residual glow)
+ */
+ marvell,reg-init = <3 16 0xf000 0x0a61>,
+ <3 17 0x003f 0x000a>;
+
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ default-state = "keep";
+ };
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_YELLOW>;
+ function = LED_FUNCTION_LAN;
+ default-state = "keep";
+ };
+ };
+ };
+};
+
+&cp0_pinctrl {
+ pinctrl-0 = <&sim_select_pins>;
+ pintrl-names = "default";
+
+ rear_button_pins: cp0-rear-button-pins {
+ marvell,pins = "mpp31";
+ marvell,function = "gpio";
+ };
+
+ sim_select_pins: cp0-sim-select-pins {
+ marvell,pins = "mpp27";
+ marvell,function = "gpio";
+ };
+};
+
+/*
+ * SRDS #4 - USB 3.0 host on M.2 connector
+ * USB-2.0 Host on Type-A connector
+ */
+&cp0_usb3_1 {
+ phys = <&cp0_comphy4 1>, <&cp0_utmi1>;
+ phy-names = "comphy", "utmi";
+ dr_mode = "host";
+ status = "okay";
+};
+
+&expander0 {
+ m2-full-card-power-off-hog {
+ gpio-hog;
+ gpios = <2 GPIO_ACTIVE_LOW>;
+ output-low;
+ line-name = "m2-full-card-power-off";
+ };
+
+ m2-reset-hog {
+ gpio-hog;
+ gpios = <10 GPIO_ACTIVE_LOW>;
+ output-low;
+ line-name = "m2-reset";
+ };
+};
diff --git a/arch/arm64/boot/dts/marvell/cn9130-cf-pro.dts b/arch/arm64/boot/dts/marvell/cn9130-cf-pro.dts
new file mode 100644
index 000000000000..0b95d5f7acfd
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/cn9130-cf-pro.dts
@@ -0,0 +1,367 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2024 Josua Mayer <josua@solid-run.com>
+ *
+ * DTS for SolidRun CN9130 Clearfog Pro.
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+
+#include "cn9130.dtsi"
+#include "cn9130-sr-som.dtsi"
+#include "cn9130-cf.dtsi"
+
+/ {
+ model = "SolidRun CN9130 Clearfog Pro";
+ compatible = "solidrun,cn9130-clearfog-pro",
+ "solidrun,cn9130-sr-som", "marvell,cn9130";
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-0 = <&rear_button_pins>;
+ pinctrl-names = "default";
+
+ button-0 {
+ /* The rear SW3 button */
+ label = "Rear Button";
+ gpios = <&cp0_gpio2 0 GPIO_ACTIVE_LOW>;
+ linux,can-disable;
+ linux,code = <BTN_0>;
+ };
+ };
+};
+
+/* SRDS #3 - SGMII 1GE to L2 switch */
+&cp0_eth1 {
+ phys = <&cp0_comphy3 1>;
+ phy-mode = "sgmii";
+ status = "okay";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
+
+&cp0_eth2_phy {
+ /*
+ * Configure LEDs default behaviour similar to switch ports:
+ * - LED[0]: link/activity: On/blink (green)
+ * - LED[1]: link is 100/1000Mbps: On (red)
+ * - LED[2]: high impedance (floating)
+ *
+ * Switch port defaults:
+ * - LED0: link/activity: On/blink (green)
+ * - LED1: link is 1000Mbps: On (red)
+ *
+ * Identical configuration is impossible with hardware offload.
+ */
+ marvell,reg-init = <3 16 0xf000 0x0a61>;
+
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_WAN;
+ label = "LED2";
+ default-state = "keep";
+ };
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_RED>;
+ function = LED_FUNCTION_WAN;
+ label = "LED1";
+ default-state = "keep";
+ };
+ };
+};
+
+&cp0_mdio {
+ ethernet-switch@4 {
+ compatible = "marvell,mv88e6085";
+ reg = <4>;
+ pinctrl-0 = <&dsa_clk_pins &dsa_pins>;
+ pinctrl-names = "default";
+ reset-gpios = <&cp0_gpio1 27 GPIO_ACTIVE_LOW>;
+ interrupt-parent = <&cp0_gpio1>;
+ interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-port@0 {
+ reg = <0>;
+ label = "lan5";
+ phy = <&switch0phy0>;
+
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ label = "LED12";
+ default-state = "keep";
+ };
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_RED>;
+ function = LED_FUNCTION_LAN;
+ label = "LED11";
+ default-state = "keep";
+ };
+ };
+ };
+
+ ethernet-port@1 {
+ reg = <1>;
+ label = "lan4";
+ phy = <&switch0phy1>;
+
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ label = "LED10";
+ default-state = "keep";
+ };
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_RED>;
+ function = LED_FUNCTION_LAN;
+ label = "LED9";
+ default-state = "keep";
+ };
+ };
+ };
+
+ ethernet-port@2 {
+ reg = <2>;
+ label = "lan3";
+ phy = <&switch0phy2>;
+
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ label = "LED8";
+ default-state = "keep";
+ };
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_RED>;
+ function = LED_FUNCTION_LAN;
+ label = "LED7";
+ default-state = "keep";
+ };
+ };
+ };
+
+ ethernet-port@3 {
+ reg = <3>;
+ label = "lan2";
+ phy = <&switch0phy3>;
+
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ label = "LED6";
+ default-state = "keep";
+ };
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_RED>;
+ function = LED_FUNCTION_LAN;
+ label = "LED5";
+ default-state = "keep";
+ };
+ };
+ };
+
+ ethernet-port@4 {
+ reg = <4>;
+ label = "lan1";
+ phy = <&switch0phy4>;
+
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ label = "LED4";
+ default-state = "keep";
+ };
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_RED>;
+ function = LED_FUNCTION_LAN;
+ label = "LED3";
+ default-state = "keep";
+ };
+ };
+ };
+
+ ethernet-port@5 {
+ reg = <5>;
+ label = "cpu";
+ ethernet = <&cp0_eth1>;
+ phy-mode = "sgmii";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+
+ ethernet-port@6 {
+ reg = <6>;
+ label = "lan6";
+ phy-mode = "rgmii";
+
+ /*
+ * Because of mdio address conflict the
+ * external phy is not readable.
+ * Force a fixed link instead.
+ */
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ };
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch0phy0: ethernet-phy@0 {
+ reg = <0x0>;
+ };
+
+ switch0phy1: ethernet-phy@1 {
+ reg = <0x1>;
+ /*
+ * Indirectly configure default behaviour
+ * for port lan6 leds behind external phy.
+ * Internal PHYs are not using page 3,
+ * therefore writing to it is safe.
+ */
+ marvell,reg-init = <3 16 0xf000 0x0a61>;
+ };
+
+ switch0phy2: ethernet-phy@2 {
+ reg = <0x2>;
+ };
+
+ switch0phy3: ethernet-phy@3 {
+ reg = <0x3>;
+ };
+
+ switch0phy4: ethernet-phy@4 {
+ reg = <0x4>;
+ };
+ };
+
+ /*
+ * There is an external phy on the switch mdio bus.
+ * Because its mdio address collides with internal phys,
+ * it is not readable.
+ *
+ * mdio-external {
+ * compatible = "marvell,mv88e6xxx-mdio-external";
+ * #address-cells = <1>;
+ * #size-cells = <0>;
+ *
+ * ethernet-phy@1 {
+ * reg = <0x1>;
+ * };
+ * };
+ */
+ };
+};
+
+/* SRDS #4 - miniPCIe (CON2) */
+&cp0_pcie1 {
+ num-lanes = <1>;
+ phys = <&cp0_comphy4 1>;
+ /* dw-pcie inverts internally */
+ reset-gpios = <&expander0 2 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+};
+
+&cp0_pinctrl {
+ dsa_clk_pins: cp0-dsa-clk-pins {
+ marvell,pins = "mpp40";
+ marvell,function = "synce1";
+ };
+
+ dsa_pins: cp0-dsa-pins {
+ marvell,pins = "mpp27", "mpp29";
+ marvell,function = "gpio";
+ };
+
+ rear_button_pins: cp0-rear-button-pins {
+ marvell,pins = "mpp32";
+ marvell,function = "gpio";
+ };
+};
+
+/*
+ * USB-2.0 Host on Type-A connector
+ */
+&cp0_usb3_1 {
+ phys = <&cp0_utmi1>;
+ phy-names = "utmi";
+ dr_mode = "host";
+ status = "okay";
+};
+
+&expander0 {
+ /* CON2 */
+ pcie1-0-clkreq-hog {
+ gpio-hog;
+ gpios = <4 GPIO_ACTIVE_LOW>;
+ input;
+ line-name = "pcie1.0-clkreq";
+ };
+
+ /* CON2 */
+ pcie1-0-w-disable-hog {
+ gpio-hog;
+ gpios = <7 GPIO_ACTIVE_LOW>;
+ output-low;
+ line-name = "pcie1.0-w-disable";
+ };
+};
diff --git a/arch/arm64/boot/dts/marvell/cn9130-cf.dtsi b/arch/arm64/boot/dts/marvell/cn9130-cf.dtsi
new file mode 100644
index 000000000000..53aedddf0e26
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/cn9130-cf.dtsi
@@ -0,0 +1,193 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2024 Josua Mayer <josua@solid-run.com>
+ *
+ * DTS for common base of SolidRun CN9130 Clearfog Base and Pro.
+ *
+ */
+
+/ {
+ aliases {
+ i2c1 = &cp0_i2c1;
+ mmc1 = &cp0_sdhci0;
+ };
+
+ reg_usb3_vbus0: regulator-usb3-vbus0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vbus0";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&expander0 6 GPIO_ACTIVE_LOW>;
+ };
+
+ sfp: sfp {
+ compatible = "sff,sfp";
+ i2c-bus = <&cp0_i2c1>;
+ los-gpios = <&expander0 12 GPIO_ACTIVE_HIGH>;
+ mod-def0-gpios = <&expander0 15 GPIO_ACTIVE_LOW>;
+ tx-disable-gpios = <&expander0 14 GPIO_ACTIVE_HIGH>;
+ tx-fault-gpios = <&expander0 13 GPIO_ACTIVE_HIGH>;
+ maximum-power-milliwatt = <2000>;
+ };
+};
+
+/* SRDS #2 - SFP+ 10GE */
+&cp0_eth0 {
+ managed = "in-band-status";
+ phys = <&cp0_comphy2 0>;
+ phy-mode = "10gbase-r";
+ sfp = <&sfp>;
+ status = "okay";
+};
+
+&cp0_i2c0 {
+ expander0: gpio-expander@20 {
+ compatible = "nxp,pca9555";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ pinctrl-0 = <&expander0_pins>;
+ pinctrl-names = "default";
+ interrupt-parent = <&cp0_gpio1>;
+ interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
+
+ /* CON3 */
+ pcie2-0-clkreq-hog {
+ gpio-hog;
+ gpios = <0 GPIO_ACTIVE_LOW>;
+ input;
+ line-name = "pcie2.0-clkreq";
+ };
+
+ /* CON3 */
+ pcie2-0-w-disable-hog {
+ gpio-hog;
+ gpios = <3 GPIO_ACTIVE_LOW>;
+ output-low;
+ line-name = "pcie2.0-w-disable";
+ };
+
+ usb3-ilimit-hog {
+ gpio-hog;
+ gpios = <5 GPIO_ACTIVE_LOW>;
+ input;
+ line-name = "usb3-current-limit";
+ };
+
+ m2-devslp-hog {
+ gpio-hog;
+ gpios = <11 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "m.2 devslp";
+ };
+ };
+
+ /* The MCP3021 supports standard and fast modes */
+ adc@4c {
+ compatible = "microchip,mcp3021";
+ reg = <0x4c>;
+ };
+
+ carrier_eeprom: eeprom@52 {
+ compatible = "atmel,24c02";
+ reg = <0x52>;
+ pagesize = <8>;
+ };
+};
+
+&cp0_i2c1 {
+ /*
+ * Routed to SFP, M.2, mikrobus, and miniPCIe
+ * SFP limits this to 100kHz, and requires an AT24C01A/02/04 with
+ * address pins tied low, which takes addresses 0x50 and 0x51.
+ * Mikrobus doesn't specify beyond an I2C bus being present.
+ * PCIe uses ARP to assign addresses, or 0x63-0x64.
+ */
+ clock-frequency = <100000>;
+ pinctrl-0 = <&cp0_i2c1_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+/* SRDS #5 - miniPCIe (CON3) */
+&cp0_pcie2 {
+ num-lanes = <1>;
+ phys = <&cp0_comphy5 2>;
+ /* dw-pcie inverts internally */
+ reset-gpios = <&expander0 1 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+};
+
+&cp0_pinctrl {
+ cp0_i2c1_pins: cp0-i2c1-pins {
+ marvell,pins = "mpp35", "mpp36";
+ marvell,function = "i2c1";
+ };
+
+ cp0_mmc0_pins: cp0-mmc0-pins {
+ marvell,pins = "mpp43", "mpp56", "mpp57", "mpp58",
+ "mpp59", "mpp60", "mpp61";
+ marvell,function = "sdio";
+ };
+
+ mikro_spi_pins: cp0-spi1-cs1-pins {
+ marvell,pins = "mpp12";
+ marvell,function = "spi1";
+ };
+
+ mikro_uart_pins: cp0-uart-pins {
+ marvell,pins = "mpp2", "mpp3";
+ marvell,function = "uart1";
+ };
+
+ expander0_pins: cp0-expander0-pins {
+ marvell,pins = "mpp4";
+ marvell,function = "gpio";
+ };
+};
+
+/* SRDS #0 - SATA on M.2 connector */
+&cp0_sata0 {
+ phys = <&cp0_comphy0 1>;
+ status = "okay";
+
+ /* only port 1 is available */
+ /delete-node/ sata-port@0;
+};
+
+/* microSD */
+&cp0_sdhci0 {
+ pinctrl-0 = <&cp0_mmc0_pins>;
+ pinctrl-names = "default";
+ bus-width = <4>;
+ no-1-8-v;
+ status = "okay";
+};
+
+&cp0_spi1 {
+ /* CS1 for mikrobus */
+ pinctrl-0 = <&cp0_spi1_pins &mikro_spi_pins>;
+};
+
+/*
+ * SRDS #1 - 3.0 Host on Type-A connector
+ * USB-2.0 Host on mPCI-e connector (CON3)
+ */
+&cp0_usb3_0 {
+ phys = <&cp0_comphy1 0>, <&cp0_utmi0>;
+ phy-names = "comphy", "utmi";
+ vbus-supply = <®_usb3_vbus0>;
+ dr_mode = "host";
+ status = "okay";
+};
+
+&cp0_utmi {
+ status = "okay";
+};
+
+/* mikrobus uart */
+&cp0_uart0 {
+ pinctrl-0 = <&mikro_uart_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi b/arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi
new file mode 100644
index 000000000000..ec08066fb6e8
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi
@@ -0,0 +1,159 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2024 Josua Mayer <josua@solid-run.com>
+ *
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ model = "SolidRun CN9130 SoM";
+ compatible = "solidrun,cn9130-sr-som", "marvell,cn9130";
+
+ aliases {
+ /* label nics like armada-388 som */
+ ethernet0 = &cp0_eth2;
+ ethernet1 = &cp0_eth1;
+ ethernet2 = &cp0_eth0;
+ i2c0 = &cp0_i2c0;
+ mmc0 = &ap_sdhci0;
+ rtc0 = &cp0_rtc;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ v_1_8: regulator-1-8 {
+ compatible = "regulator-fixed";
+ regulator-name = "1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ /* requires assembly of R9307 */
+ vhv: regulator-vhv-1-8 {
+ compatible = "regulator-fixed";
+ regulator-name = "vhv-1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ pinctrl-0 = <&cp0_reg_vhv_pins>;
+ pinctrl-names = "default";
+ gpio = <&cp0_gpio2 9 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+};
+
+&ap_pinctrl {
+ ap_mmc0_pins: ap-mmc0-pins {
+ marvell,pins = "mpp0", "mpp1", "mpp2", "mpp3", "mpp4", "mpp5",
+ "mpp6", "mpp7", "mpp8", "mpp9", "mpp10", "mpp12";
+ marvell,function = "sdio";
+ /*
+ * mpp12 is emmc reset, function should be sdio (hw_rst),
+ * but pinctrl-mvebu does not support this.
+ *
+ * From pinctrl-mvebu.h:
+ * "The name will be used to switch to this setting in DT description, e.g.
+ * marvell,function = "uart2". subname is only for debugging purposes."
+ */
+ };
+};
+
+&ap_sdhci0 {
+ bus-width = <8>;
+ pinctrl-0 = <&ap_mmc0_pins>;
+ pinctrl-names = "default";
+ vqmmc-supply = <&v_1_8>;
+ status = "okay";
+};
+
+&cp0_ethernet {
+ status = "okay";
+};
+
+/* for assembly with phy */
+&cp0_eth2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&cp0_eth2_pins>;
+ phy-mode = "rgmii-id";
+ phy = <&cp0_eth2_phy>;
+ status = "okay";
+};
+
+&cp0_i2c0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&cp0_i2c0_pins>;
+ clock-frequency = <100000>;
+ status = "okay";
+
+ som_eeprom: eeprom@53 {
+ compatible = "atmel,24c02";
+ reg = <0x53>;
+ pagesize = <8>;
+ };
+};
+
+&cp0_mdio {
+ status = "okay";
+ pinctrl-0 = <&cp0_mdio_pins>;
+
+ /* assembly option */
+ cp0_eth2_phy: ethernet-phy@0 {
+ reg = <0>;
+ };
+};
+
+&cp0_spi1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&cp0_spi1_pins>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <10000000>;
+ };
+};
+
+&cp0_syscon0 {
+ cp0_pinctrl: pinctrl {
+ compatible = "marvell,cp115-standalone-pinctrl";
+
+ cp0_eth2_pins: cp0-ge2-rgmii-pins {
+ marvell,pins = "mpp44", "mpp45", "mpp46", "mpp47",
+ "mpp48", "mpp49", "mpp50", "mpp51",
+ "mpp52", "mpp53", "mpp54", "mpp55";
+ /* docs call it "ge2", but cp110-pinctrl "ge1" */
+ marvell,function = "ge1";
+ };
+
+ cp0_i2c0_pins: cp0-i2c0-pins {
+ marvell,pins = "mpp37", "mpp38";
+ marvell,function = "i2c0";
+ };
+
+ cp0_mdio_pins: cp0-mdio-pins {
+ marvell,pins = "mpp40", "mpp41";
+ marvell,function = "ge";
+ };
+
+ cp0_spi1_pins: cp0-spi1-pins {
+ marvell,pins = "mpp13", "mpp14", "mpp15", "mpp16";
+ marvell,function = "spi1";
+ };
+
+ cp0_reg_vhv_pins: cp0-reg-vhv-pins {
+ marvell,pins = "mpp41";
+ marvell,function = "gpio";
+ };
+ };
+};
+
+/* AP default console */
+&uart0 {
+ pinctrl-0 = <&uart0_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
--
2.35.3
^ permalink raw reply related
* Re: [PATCH v5 4/5] PCI: Add PCIE_MSG_CODE_PME_TURN_OFF message macro
From: Manivannan Sadhasivam @ 2024-04-04 15:53 UTC (permalink / raw)
To: Frank Li
Cc: Bjorn Helgaas, Jingoo Han, Gustavo Pimentel, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, imx, linux-pci, linux-kernel, devicetree
In-Reply-To: <20240319-pme_msg-v5-4-af9ffe57f432@nxp.com>
On Tue, Mar 19, 2024 at 12:07:14PM -0400, Frank Li wrote:
> Add PCIE_MSG_CODE_PME_TURN_OFF macros to enable a PCIe host driver to send
> PME_Turn_Off messages.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> drivers/pci/pci.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> index ffd066c15f3bb..989681a0d6057 100644
> --- a/drivers/pci/pci.h
> +++ b/drivers/pci/pci.h
> @@ -40,6 +40,8 @@
> #define PCIE_MSG_CODE_DEASSERT_INTC 0x26
> #define PCIE_MSG_CODE_DEASSERT_INTD 0x27
>
> +#define PCIE_MSG_CODE_PME_TURN_OFF 0x19
> +
I think this could be moved before INTx to keep the codes sorted.
- Mani
> extern const unsigned char pcie_link_speed[];
> extern bool pci_early_dump;
>
>
> --
> 2.34.1
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH V2 RESEND 6/6] arm64: dts: qcom: sm8650: Add video and camera clock controllers
From: Dmitry Baryshkov @ 2024-04-04 16:05 UTC (permalink / raw)
To: Jagadeesh Kona
Cc: Bjorn Andersson, Konrad Dybcio, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vladimir Zapolskiy, linux-arm-msm, linux-clk, devicetree,
linux-kernel, Taniya Das, Satya Priya Kakitapalli, Ajit Pandey,
Imran Shaik
In-Reply-To: <8a5a3cf8-5b4f-487f-ad91-00499509f8ec@quicinc.com>
On Thu, 4 Apr 2024 at 13:06, Jagadeesh Kona <quic_jkona@quicinc.com> wrote:
>
>
>
> On 4/4/2024 11:00 AM, Dmitry Baryshkov wrote:
> > On Thu, 4 Apr 2024 at 08:13, Jagadeesh Kona <quic_jkona@quicinc.com> wrote:
> >>
> >>
> >>
> >> On 4/3/2024 9:24 PM, Dmitry Baryshkov wrote:
> >>> On Wed, 3 Apr 2024 at 10:16, Jagadeesh Kona <quic_jkona@quicinc.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 3/25/2024 11:38 AM, Jagadeesh Kona wrote:
> >>>>>
> >>>>>
> >>>>> On 3/21/2024 6:43 PM, Dmitry Baryshkov wrote:
> >>>>>> On Thu, 21 Mar 2024 at 11:27, Jagadeesh Kona <quic_jkona@quicinc.com>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Add device nodes for video and camera clock controllers on Qualcomm
> >>>>>>> SM8650 platform.
> >>>>>>>
> >>>>>>> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com>
> >>>>>>> ---
> >>>>>>> arch/arm64/boot/dts/qcom/sm8650.dtsi | 28 ++++++++++++++++++++++++++++
> >>>>>>> 1 file changed, 28 insertions(+)
> >>>>>>>
> >>>>>>> diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi
> >>>>>>> b/arch/arm64/boot/dts/qcom/sm8650.dtsi
> >>>>>>> index 32c0a7b9aded..d862aa6be824 100644
> >>>>>>> --- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
> >>>>>>> +++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
> >>>>>>> @@ -4,6 +4,8 @@
> >>>>>>> */
> >>>>>>>
> >>>>>>> #include <dt-bindings/clock/qcom,rpmh.h>
> >>>>>>> +#include <dt-bindings/clock/qcom,sm8450-videocc.h>
> >>>>>>> +#include <dt-bindings/clock/qcom,sm8650-camcc.h>
> >>>>>>> #include <dt-bindings/clock/qcom,sm8650-dispcc.h>
> >>>>>>> #include <dt-bindings/clock/qcom,sm8650-gcc.h>
> >>>>>>> #include <dt-bindings/clock/qcom,sm8650-gpucc.h>
> >>>>>>> @@ -3110,6 +3112,32 @@ opp-202000000 {
> >>>>>>> };
> >>>>>>> };
> >>>>>>>
> >>>>>>> + videocc: clock-controller@aaf0000 {
> >>>>>>> + compatible = "qcom,sm8650-videocc";
> >>>>>>> + reg = <0 0x0aaf0000 0 0x10000>;
> >>>>>>> + clocks = <&bi_tcxo_div2>,
> >>>>>>> + <&gcc GCC_VIDEO_AHB_CLK>;
> >>>>>>> + power-domains = <&rpmhpd RPMHPD_MMCX>;
> >>>>>>> + required-opps = <&rpmhpd_opp_low_svs>;
> >>>>>>
> >>>>>> The required-opps should no longer be necessary.
> >>>>>>
> >>>>>
> >>>>> Sure, will check and remove this if not required.
> >>>>
> >>>>
> >>>> I checked further on this and without required-opps, if there is no vote
> >>>> on the power-domain & its peer from any other consumers, when runtime
> >>>> get is called on device, it enables the power domain just at the minimum
> >>>> non-zero level. But in some cases, the minimum non-zero level of
> >>>> power-domain could be just retention and is not sufficient for clock
> >>>> controller to operate, hence required-opps property is needed to specify
> >>>> the minimum level required on power-domain for this clock controller.
> >>>
> >>> In which cases? If it ends up with the retention vote, it is a bug
> >>> which must be fixed.
> >>>
> >>
> >> The minimum non-zero level(configured from bootloaders) of MMCX is
> >> retention on few chipsets but it can vary across the chipsets. Hence to
> >> be on safer side from our end, it is good to have required-opps in DT to
> >> specify the minimum level required for this clock controller.
> >
> > We are discussing sm8650, not some abstract chipset. Does it list
> > retention or low_svs as a minimal level for MMCX?
> >
>
> Actually, the minimum level for MMCX is external to the clock
> controllers.
Yes, it comes from cmd-db
> But the clock controller requires MMCX to be atleast at
> lowsvs for it to be functional.
Correct
> Hence we need to keep required-opps to
> ensure the same without relying on the actual minimum level for MMCX.
And this is not correct. There is no need for the DT to be redundant.
I plan to send patches removing the existing required-opps when they
are not required.
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH v2] dt-bindings: omap-mcpdm: Convert to DT schema
From: Mighty @ 2024-04-04 16:06 UTC (permalink / raw)
Cc: Mithil Bavishi, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, alsa-devel, devicetree,
linux-kernel
From: Mithil Bavishi <bavishimithil@gmail.com>
Convert the OMAP4+ McPDM bindings to DT schema.
Signed-off-by: Mighty <bavishimithil@gmail.com>
---
.../devicetree/bindings/sound/omap-mcpdm.txt | 30 ----------
.../bindings/sound/ti,omap-mcpdm.yaml | 59 +++++++++++++++++++
2 files changed, 59 insertions(+), 30 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/sound/omap-mcpdm.txt
create mode 100644 Documentation/devicetree/bindings/sound/ti,omap-mcpdm.yaml
diff --git a/Documentation/devicetree/bindings/sound/omap-mcpdm.txt b/Documentation/devicetree/bindings/sound/omap-mcpdm.txt
deleted file mode 100644
index ff98a0cb5..000000000
--- a/Documentation/devicetree/bindings/sound/omap-mcpdm.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-* Texas Instruments OMAP4+ McPDM
-
-Required properties:
-- compatible: "ti,omap4-mcpdm"
-- reg: Register location and size as an array:
- <MPU access base address, size>,
- <L3 interconnect address, size>;
-- interrupts: Interrupt number for McPDM
-- ti,hwmods: Name of the hwmod associated to the McPDM
-- clocks: phandle for the pdmclk provider, likely <&twl6040>
-- clock-names: Must be "pdmclk"
-
-Example:
-
-mcpdm: mcpdm@40132000 {
- compatible = "ti,omap4-mcpdm";
- reg = <0x40132000 0x7f>, /* MPU private access */
- <0x49032000 0x7f>; /* L3 Interconnect */
- interrupts = <0 112 0x4>;
- interrupt-parent = <&gic>;
- ti,hwmods = "mcpdm";
-};
-
-In board DTS file the pdmclk needs to be added:
-
-&mcpdm {
- clocks = <&twl6040>;
- clock-names = "pdmclk";
- status = "okay";
-};
diff --git a/Documentation/devicetree/bindings/sound/ti,omap-mcpdm.yaml b/Documentation/devicetree/bindings/sound/ti,omap-mcpdm.yaml
new file mode 100644
index 000000000..4d5d37e98
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,omap-mcpdm.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/ti,omap-mcpdm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OMAP McPDM
+
+maintainers:
+ - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+description:
+ OMAP ALSA SoC DAI driver using McPDM port used by TWL6040
+
+properties:
+ compatible:
+ const: ti,omap4-mcpdm
+
+ reg:
+ description:
+ Register location and size as an array
+ <MPU access base address, size>,
+ <L3 interconnect address, size>;
+
+ interrupts:
+ maxItems: 1
+
+ ti,hwmods:
+ maxItems: 1
+
+ clocks:
+ description: phandle for the pdmclk provider, likely <&twl6040>
+
+ clock-names:
+ description: Must be "pdmclk"
+
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - ti,hwmods
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ mcpdm@0 {
+ compatible = "ti,omap4-mcpdm";
+ reg = <0x40132000 0x7f>, /* MPU private access */
+ <0x49032000 0x7f>; /* L3 Interconnect */
+ interrupts = <0 112 0x4>;
+ interrupt-parent = <&gic>;
+ ti,hwmods = "mcpdm";
+ clocks = <&twl6040>;
+ clock-names = "pdmclk";
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH 1/1] arm64: dts: imx8qxp-mek: add cm40_i2c, wm8960/wm8962 and sai[0,1,4,5]
From: Frank Li @ 2024-04-04 16:19 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
imx8qxp-mek use two kind audio codec, wm8960 and wm8962. Using dummy gpio
i2c bus mux to connect both i2c devices. One will probe failure and other
will probe success when devices driver check whoami. So one dtb can cover
both board configuration.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 210 ++++++++++++++++++
1 file changed, 210 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
index 8360bb851ac03..adff87c7cf305 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
+++ b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
@@ -30,6 +30,13 @@ reg_usdhc2_vmmc: usdhc2-vmmc {
enable-active-high;
};
+ reg_audio: regulator-wm8962 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3_aud";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
gpio-sbu-mux {
compatible = "nxp,cbdtu02043", "gpio-sbu-mux";
pinctrl-names = "default";
@@ -44,6 +51,105 @@ usb3_data_ss: endpoint {
};
};
};
+
+ sound-wm8960 {
+ compatible = "fsl,imx-audio-wm8960";
+ model = "wm8960-audio";
+ audio-cpu = <&sai1>;
+ audio-codec = <&wm8960>;
+ hp-det-gpio = <&lsio_gpio1 0 GPIO_ACTIVE_HIGH>;
+ audio-routing =
+ "Headphone Jack", "HP_L",
+ "Headphone Jack", "HP_R",
+ "Ext Spk", "SPK_LP",
+ "Ext Spk", "SPK_LN",
+ "Ext Spk", "SPK_RP",
+ "Ext Spk", "SPK_RN",
+ "LINPUT1", "Mic Jack",
+ "Mic Jack", "MICB";
+ };
+
+ sound-wm8962 {
+ compatible = "fsl,imx-audio-wm8962";
+ model = "wm8962-audio";
+ audio-cpu = <&sai1>;
+ audio-codec = <&wm8962>;
+ hp-det-gpio = <&lsio_gpio1 0 GPIO_ACTIVE_HIGH>;
+ audio-routing =
+ "Headphone Jack", "HPOUTL",
+ "Headphone Jack", "HPOUTR",
+ "Ext Spk", "SPKOUTL",
+ "Ext Spk", "SPKOUTR",
+ "AMIC", "MICBIAS",
+ "IN3R", "AMIC",
+ "IN1R", "AMIC";
+ };
+
+ /*
+ * This dummy i2c mux. GPIO actually will not impact selection. At actual boards, only 1
+ * device connectted. I2C client driver will check ID when probe. Only matched ID's driver
+ * probe successfully.
+ */
+ i2cvmux: i2cmux {
+ compatible = "i2c-mux-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ mux-gpios = <&lsio_gpio5 0 GPIO_ACTIVE_HIGH>; /* use an unused gpio */
+ i2c-parent = <&cm40_i2c>;
+
+ i2c@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* WCPU boards SCH-54536 */
+ wm8962: wm8962@1a {
+ compatible = "wlf,wm8962";
+ reg = <0x1a>;
+ clocks = <&mclkout0_lpcg IMX_LPCG_CLK_0>;
+ assigned-clocks = <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_PLL>,
+ <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_SLV_BUS>,
+ <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_MST_BUS>,
+ <&mclkout0_lpcg IMX_LPCG_CLK_0>;
+ assigned-clock-rates = <786432000>,
+ <49152000>,
+ <12288000>,
+ <12288000>;
+ DCVDD-supply = <®_audio>;
+ DBVDD-supply = <®_audio>;
+ AVDD-supply = <®_audio>;
+ CPVDD-supply = <®_audio>;
+ MICVDD-supply = <®_audio>;
+ PLLVDD-supply = <®_audio>;
+ SPKVDD1-supply = <®_audio>;
+ SPKVDD2-supply = <®_audio>;
+ };
+ };
+
+ i2c@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ wm8960: wm8960@1a {
+ compatible = "wlf,wm8960";
+ reg = <0x1a>;
+ clocks = <&mclkout0_lpcg IMX_LPCG_CLK_0>;
+ clock-names = "mclk";
+ wlf,shared-lrclk;
+ wlf,hp-cfg = <2 2 3>;
+ wlf,gpio-cfg = <1 3>;
+ assigned-clocks = <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_PLL>,
+ <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_SLV_BUS>,
+ <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_MST_BUS>,
+ <&mclkout0_lpcg IMX_LPCG_CLK_0>;
+ assigned-clock-rates = <786432000>,
+ <49152000>,
+ <12288000>,
+ <12288000>;
+ };
+ };
+ };
};
&dsp {
@@ -188,6 +294,29 @@ typec_con_ss: endpoint {
};
+&cm40_i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <100000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_cm40_i2c>;
+ pinctrl-1 = <&pinctrl_cm40_i2c_gpio>;
+ scl-gpios = <&lsio_gpio1 10 GPIO_ACTIVE_HIGH>;
+ sda-gpios = <&lsio_gpio1 9 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+
+ pca6416: gpio@20 {
+ compatible = "ti,tca6416";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+};
+
+&cm40_intmux {
+ status = "okay";
+};
+
&lpuart0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_lpuart0>;
@@ -218,6 +347,53 @@ &scu_key {
status = "okay";
};
+&sai0 {
+ #sound-dai-cells = <0>;
+ assigned-clocks = <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_PLL>,
+ <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_SLV_BUS>,
+ <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_MST_BUS>,
+ <&sai0_lpcg IMX_LPCG_CLK_0>;
+ assigned-clock-rates = <786432000>, <49152000>, <12288000>, <49152000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sai0>;
+ status = "okay";
+};
+
+&sai1 {
+ assigned-clocks = <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_PLL>,
+ <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_SLV_BUS>,
+ <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_MST_BUS>,
+ <&sai1_lpcg IMX_LPCG_CLK_0>;
+ assigned-clock-rates = <786432000>, <49152000>, <12288000>, <49152000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sai1>;
+ status = "okay";
+};
+
+&sai4 {
+ assigned-clocks = <&acm IMX_ADMA_ACM_SAI4_MCLK_SEL>,
+ <&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_PLL>,
+ <&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_SLV_BUS>,
+ <&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_MST_BUS>,
+ <&sai4_lpcg IMX_LPCG_CLK_0>;
+ assigned-clock-parents = <&aud_pll_div1_lpcg IMX_LPCG_CLK_0>;
+ assigned-clock-rates = <0>, <786432000>, <98304000>, <12288000>, <98304000>;
+ fsl,sai-asynchronous;
+ status = "okay";
+};
+
+&sai5 {
+ assigned-clocks = <&acm IMX_ADMA_ACM_SAI5_MCLK_SEL>,
+ <&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_PLL>,
+ <&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_SLV_BUS>,
+ <&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_MST_BUS>,
+ <&sai5_lpcg IMX_LPCG_CLK_0>;
+ assigned-clock-parents = <&aud_pll_div1_lpcg IMX_LPCG_CLK_0>;
+ assigned-clock-rates = <0>, <786432000>, <98304000>, <12288000>, <98304000>;
+ fsl,sai-asynchronous;
+ status = "okay";
+};
+
&thermal_zones {
pmic-thermal {
polling-delay-passive = <250>;
@@ -314,6 +490,21 @@ &vpu_core1 {
};
&iomuxc {
+
+ pinctrl_cm40_i2c: cm40i2cgrp {
+ fsl,pins = <
+ IMX8QXP_ADC_IN1_M40_I2C0_SDA 0x0600004c
+ IMX8QXP_ADC_IN0_M40_I2C0_SCL 0x0600004c
+ >;
+ };
+
+ pinctrl_cm40_i2c_gpio: cm40i2cgpio-grp {
+ fsl,pins = <
+ IMX8QXP_ADC_IN1_LSIO_GPIO1_IO09 0xc600004c
+ IMX8QXP_ADC_IN0_LSIO_GPIO1_IO10 0xc600004c
+ >;
+ };
+
pinctrl_fec1: fec1grp {
fsl,pins = <
IMX8QXP_ENET0_MDC_CONN_ENET0_MDC 0x06000020
@@ -385,6 +576,25 @@ IMX8QXP_ENET0_REFCLK_125M_25M_LSIO_GPIO5_IO09 0x60
>;
};
+ pinctrl_sai0: sai0grp {
+ fsl,pins = <
+ IMX8QXP_SAI0_TXD_ADMA_SAI0_TXD 0x06000060
+ IMX8QXP_SAI0_RXD_ADMA_SAI0_RXD 0x06000040
+ IMX8QXP_SAI0_TXC_ADMA_SAI0_TXC 0x06000040
+ IMX8QXP_SAI0_TXFS_ADMA_SAI0_TXFS 0x06000040
+ >;
+ };
+
+ pinctrl_sai1: sai1grp {
+ fsl,pins = <
+ IMX8QXP_SAI1_RXD_ADMA_SAI1_RXD 0x06000040
+ IMX8QXP_SAI1_RXC_ADMA_SAI1_TXC 0x06000040
+ IMX8QXP_SAI1_RXFS_ADMA_SAI1_TXFS 0x06000040
+ IMX8QXP_SPI0_CS1_ADMA_SAI1_TXD 0x06000060
+ IMX8QXP_SPI2_CS0_LSIO_GPIO1_IO00 0x06000040
+ >;
+ };
+
pinctrl_usdhc1: usdhc1grp {
fsl,pins = <
IMX8QXP_EMMC0_CLK_CONN_EMMC0_CLK 0x06000041
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2] arm64: dts: ti: k3-am62p: use eFuse MAC Address for CPSW3G Port 1
From: Andrew Davis @ 2024-04-04 16:28 UTC (permalink / raw)
To: Krzysztof Kozlowski, Siddharth Vadapalli
Cc: nm, vigneshr, kristo, robh, krzk+dt, conor+dt, devicetree,
linux-kernel, linux-arm-kernel, srk
In-Reply-To: <903ad855-ab26-4ef3-80bd-249917056188@linaro.org>
On 4/4/24 5:00 AM, Krzysztof Kozlowski wrote:
> On 04/04/2024 11:12, Siddharth Vadapalli wrote:
>> On Thu, Apr 04, 2024 at 10:43:04AM +0200, Krzysztof Kozlowski wrote:
>>> On 04/04/2024 10:18, Siddharth Vadapalli wrote:
>>>> Add the "cpsw-mac-efuse" node within "wkup_conf" node corresponding to the
>>>> CTRLMMR_MAC_IDx registers within the CTRL_MMR space. Assign the compatible
>>>> "ti,am62p-cpsw-mac-efuse" to enable "syscon_regmap" operations on these
>>>> registers. The MAC Address programmed in the eFuse is accessible through
>>>> the CTRLMMR_MAC_IDx registers. The "ti,syscon-efuse" device-tree property
>>>> points to the CTRLMMR_MAC_IDx registers, allowing the CPSW driver to fetch
>>>> the MAC Address and assign it to the network interface associated with
>>>> CPSW3G MAC Port 1.
>>>>
>>>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
>>>> ---
>>>>
>>>> This patch is based on linux-next tagged next-20240404.
>>>> Patch depends on:
>>>> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20240402105708.4114146-1-s-vadapalli@ti.com/
>>>> for the newly added "ti,am62p-cpsw-mac-efuse" compatible.
>>>>
>>>> v1:
>>>> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20240402094200.4036076-1-s-vadapalli@ti.com/
>>>> Changes since v1:
>>>> - Since "wkup_conf" is modelled as a "simple-bus" rather than being
>>>
>>> And maybe the hardware representation is not correct? What bus is it?
>>
>> I will let Andrew comment on it. Andrew had posted a patch at:
>> https://lore.kernel.org/r/20240124184722.150615-10-afd@ti.com/
>> to convert an equivalent "main_conf" node for AM62 SoC to "simple-bus"
>> from the existing "syscon".
>>
>>>
>>>> modelled as a System Controller node with the "syscon" compatible,
>>>> directly passing the reference to the "wkup_conf" node using the
>>>> "ti,syscon-efuse" device-tree property will not work.
>>>> Therefore, I posted the patch at:
>>>> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20240402105708.4114146-1-s-vadapalli@ti.com/
>>>> in order to add a new compatible to be used for modelling the
>>>> CTRLMMR_MAC_IDx registers as System Controller nodes, thereby
>>>> allowing the existing "ti,syscon-efuse" property to be used.
>>>> Now, "ti,syscon-efuse" points to the "cpsw_mac_efuse" node within
>>>> "wkup_conf" node, with "cpsw_mac_efuse" being a "syscon" node.
>>>>
>>>> Logs verifying that the CPSW driver assigns the MAC Address from the
>>>> eFuse based on the CTRLMMR_MAC_IDx registers at 0x43000200 and 0x43000204
>>>> to the interface eth0 corresponding to CPSW3G MAC Port 1:
>>>> https://gist.github.com/Siddharth-Vadapalli-at-TI/9982c6f13bf9b8cfaf97e8517e7dea13
>>>>
>>>> Regards,
>>>> Siddharth.
>>>>
>>>> arch/arm64/boot/dts/ti/k3-am62p-main.dtsi | 1 +
>>>> arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi | 5 +++++
>>>> 2 files changed, 6 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
>>>> index 7337a9e13535..848ca454a411 100644
>>>> --- a/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
>>>> +++ b/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
>>>> @@ -696,6 +696,7 @@ cpsw_port1: port@1 {
>>>> label = "port1";
>>>> phys = <&phy_gmii_sel 1>;
>>>> mac-address = [00 00 00 00 00 00];
>>>> + ti,syscon-efuse = <&cpsw_mac_efuse 0x0>;
>>>
>>> Why this is not nvmem cell, like or efuses?
>>
>> Since it belongs to the MMIO register set. You had recommended *not*
>> using nvmem for such MMIO registers at:
>> https://lore.kernel.org/r/48902771-5d3b-448a-8a74-ac18fb4f1a86@linaro.org/
>> "nvmem is for non-volatile memory, like OCOTP and eFUSE. This is not for
>> accessing regular MMIO registers of system-controller..."
>>
>> Despite the "ti,syscon-efuse" property containing the term "efuse" in its
>> name, it is reading the CTRLMMR_MAC_IDx MMIO registers. So I assumed that
>> the existing approach which has been used on all K3 SoCs apart from this
>> one, will be suitable for this SoC as well.
>
> OK, I totally forgot we discussed this.
>
Discussed but never finalized, here is the last message[0] but with
no response.
You even asked above, "Why this is not nvmem cell", you should trust
your instincts, this *should* be a NVMEM cell. That is how everyone else
handles eFused MACs, no clue why you want us to use syscon?? We would
have no way forward in removing all our DT check warnings with syscon.
Syscon is a hacky dead-end filled with custom compatible strings like
"ti,am62p-cpsw-mac-efuse" and custom properties like "ti,syscon-efuse".
NVMEM is a standard, forcing us to use TI custom syscon properties will
prevent our DT from working on anything other than Linux (unless we go
manually add support for every TI custom property to every DT using SW,
defeats the whole purpose DT).
Andrew
[0] https://lore.kernel.org/all/e7114cb4-e24f-4e78-a89f-4e2e2e704b8a@ti.com/
>>
>>>
>>>> };
>>>>
>>>> cpsw_port2: port@2 {
>>>> diff --git a/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi
>>>> index a84756c336d0..df9d40f64e3b 100644
>>>> --- a/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi
>>>> +++ b/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi
>>>> @@ -18,6 +18,11 @@ chipid: chipid@14 {
>>>> reg = <0x14 0x4>;
>>>> bootph-all;
>>>> };
>>>> +
>>>> + cpsw_mac_efuse: cpsw-mac-efuse@200 {
>>>
>>> Node names should be generic. See also an explanation and list of
>>> examples (not exhaustive) in DT specification:
>>> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
>>
>> I was following the convention that other mfd-syscon compatible nodes
>> seemed to be using:
>> https://github.com/torvalds/linux/blob/41bccc98fb7931d63d03f326a746ac4d429c1dd3/arch/arm64/boot/dts/ti/k3-am65-main.dtsi#L502
>> The node is:
>> dss_oldi_io_ctrl: dss-oldi-io-ctrl@41e0
>> corresponding to the compatible:
>> "ti,am654-dss-oldi-io-ctrl"
>> which was added by commit:
>> https://github.com/torvalds/linux/commit/cb523495ee2a5938fbdd30b8a35094d386c55c12
>
> So if that one was wrong, then what? I don't know really what type of
> device is it, but just because one contributor called it that way, does
> not mean you should keep going. Maybe investigate why that contributor
> did not decide to follow Devicetree spec recommendation?
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* [PATCH] dt-bindings: usb: Document the Microchip USB2514 hub
From: Fabio Estevam @ 2024-04-04 16:41 UTC (permalink / raw)
To: gregkh; +Cc: robh, krzk+dt, conor+dt, linux-usb, devicetree, Fabio Estevam
From: Fabio Estevam <festevam@denx.de>
Document the Microchip USB2514, USB2412, and USB2417 USB hubs.
Signed-off-by: Fabio Estevam <festevam@denx.de>
---
.../bindings/usb/microchip,usb2514.yaml | 53 +++++++++++++++++++
1 file changed, 53 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/microchip,usb2514.yaml
diff --git a/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml b/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml
new file mode 100644
index 000000000000..8df7a5adfbe8
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/microchip,usb2514.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip USB2514 Hub Controller
+
+maintainers:
+ - Fabio Estevam <festevam@gmail.com>
+
+properties:
+ compatible:
+ enum:
+ - usb424,2412
+ - usb424,2514
+ - usb424,2417
+
+ reg: true
+
+ reset-gpios:
+ description: GPIO connected to the RESET_N pin.
+
+ vdd-supply:
+ description: 3.3V power supply.
+
+ clocks:
+ description: External 24MHz clock connected to the CLKIN pin.
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: true
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx6qdl-clock.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ usb {
+ dr_mode = "host";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hub@1 {
+ compatible = "usb424,2514";
+ reg = <1>;
+ clocks = <&clks IMX6QDL_CLK_CKO>;
+ reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
+ vdd-supply = <®_3v3_hub>;
+ };
+ };
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 1/3] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Add gpio child node
From: Florian Fainelli @ 2024-04-04 16:46 UTC (permalink / raw)
To: bcm-kernel-feedback-list, Laurent Pinchart, devicetree,
linux-rpi-kernel, linux-arm-kernel
Cc: Florian Fainelli, Dave Stevenson, Naushir Patuck,
Bartosz Golaszewski, Conor Dooley, Krzysztof Kozlowski,
Linus Walleij, Ray Jui, Rob Herring, Scott Branden, Stefan Wahren
In-Reply-To: <20240326195807.15163-2-laurent.pinchart@ideasonboard.com>
From: Florian Fainelli <f.fainelli@gmail.com>
On Tue, 26 Mar 2024 21:58:05 +0200, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> Unlike the other child nodes of the raspberrypi,bcm2835-firmware device,
> the gpio child is documented in a legacy text-based binding in
> gpio/raspberrypi,firmware-gpio.txt. This causes DT validation failures:
>
> arch/arm64/boot/dts/broadcom/bcm2711-rpi-4-b.dtb: 'gpio' does not match any of the regexes: 'pinctrl-[0-9]+'
> from schema $id: http://devicetree.org/schemas/arm/bcm/raspberrypi,bcm2835-firmware.yaml#
>
> Convert the binding to YAML and move it to
> raspberrypi,bcm2835-firmware.yaml.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> ---
Applied to https://github.com/Broadcom/stblinux/commits/devicetree/next, thanks!
--
Florian
^ permalink raw reply
* Re: [PATCH v2 2/3] firmware: raspberrypi: Use correct device for DMA mappings
From: Florian Fainelli @ 2024-04-04 16:46 UTC (permalink / raw)
To: bcm-kernel-feedback-list, Laurent Pinchart, devicetree,
linux-rpi-kernel, linux-arm-kernel
Cc: Florian Fainelli, Dave Stevenson, Naushir Patuck, Conor Dooley,
Krzysztof Kozlowski, Nicolas Saenz Julienne, Ray Jui, Rob Herring,
Scott Branden, Stefan Wahren
In-Reply-To: <20240326195807.15163-3-laurent.pinchart@ideasonboard.com>
From: Florian Fainelli <f.fainelli@gmail.com>
On Tue, 26 Mar 2024 21:58:06 +0200, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> The buffer used to transfer data over the mailbox interface is mapped
> using the client's device. This is incorrect, as the device performing
> the DMA transfer is the mailbox itself. Fix it by using the mailbox
> controller device instead.
>
> This requires including the mailbox_controller.h header to dereference
> the mbox_chan and mbox_controller structures. The header is not meant to
> be included by clients. This could be fixed by extending the client API
> with a function to access the controller's device.
>
> Fixes: 4e3d60656a72 ("ARM: bcm2835: Add the Raspberry Pi firmware driver")
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
Applied to https://github.com/Broadcom/stblinux/commits/devicetree/next, thanks!
--
Florian
^ permalink raw reply
* Re: [PATCH v2 3/3] ARM: dts: bcm283x: Drop unneeded properties in the bcm2835-firmware node
From: Florian Fainelli @ 2024-04-04 16:47 UTC (permalink / raw)
To: bcm-kernel-feedback-list, Laurent Pinchart, devicetree,
linux-rpi-kernel, linux-arm-kernel
Cc: Florian Fainelli, Dave Stevenson, Naushir Patuck, Conor Dooley,
Krzysztof Kozlowski, Nicolas Saenz Julienne, Ray Jui, Rob Herring,
Scott Branden, Stefan Wahren
In-Reply-To: <20240326195807.15163-4-laurent.pinchart@ideasonboard.com>
From: Florian Fainelli <f.fainelli@gmail.com>
On Tue, 26 Mar 2024 21:58:07 +0200, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> The firmware node contains a "dma-ranges" property to enable usage of
> the DMA mapping API with its child devices, along with "#address-cells"
> and "#size-cells" properties to support the dma-ranges. This was needed
> due to usage of the incorrect device to perform the DMA mapping in
> drivers. Now that this has been fixed, drop the properties.
>
> This effectively reverts commits be08d278eb09 ("ARM: dts: bcm283x: Add
> cells encoding format to firmware bus") and 55c7c0621078 ("ARM: dts:
> bcm283x: Fix vc4's firmware bus DMA limitations").
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
Applied to https://github.com/Broadcom/stblinux/commits/devicetree/next, thanks!
--
Florian
^ permalink raw reply
* Re: [RESEND v7 06/37] sh: kernel/setup Update DT support.
From: Rob Herring @ 2024-04-04 16:48 UTC (permalink / raw)
To: Yoshinori Sato
Cc: linux-sh, Damien Le Moal, Niklas Cassel, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
David Airlie, Daniel Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Thomas Gleixner, Bjorn Helgaas,
Lorenzo Pieralisi, Krzysztof Wilczyński, Greg Kroah-Hartman,
Jiri Slaby, Magnus Damm, Daniel Lezcano, Rich Felker,
John Paul Adrian Glaubitz, Lee Jones, Helge Deller,
Heiko Stuebner, Shawn Guo, Sebastian Reichel, Chris Morgan,
Linus Walleij, Arnd Bergmann, David Rientjes, Hyeonggon Yoo,
Vlastimil Babka, Baoquan He, Andrew Morton, Guenter Roeck,
Kefeng Wang, Stephen Rothwell, Javier Martinez Canillas, Guo Ren,
Azeem Shaikh, Max Filippov, Jonathan Corbet, Jacky Huang,
Herve Codina, Manikanta Guntupalli, Anup Patel, Biju Das,
Uwe Kleine-König, Sam Ravnborg, Sergey Shtylyov,
Laurent Pinchart, linux-ide, devicetree, linux-kernel,
linux-renesas-soc, linux-clk, dri-devel, linux-pci, linux-serial,
linux-fbdev
In-Reply-To: <a4ce7771faec761b9bbb91ff6694a99e5bc293b6.1712207606.git.ysato@users.sourceforge.jp>
On Thu, Apr 4, 2024 at 12:15 AM Yoshinori Sato
<ysato@users.sourceforge.jp> wrote:
>
> Fix extrnal fdt initialize and bootargs.
What is the problem you are trying to solve?
And a typo.
>
> Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
> ---
> arch/sh/Kconfig | 23 +++++++++++------------
> arch/sh/include/asm/setup.h | 1 +
> arch/sh/kernel/setup.c | 36 +++++++++++++++++++++++-------------
> 3 files changed, 35 insertions(+), 25 deletions(-)
>
> diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
> index 6711cde0d973..242cf30e704d 100644
> --- a/arch/sh/Kconfig
> +++ b/arch/sh/Kconfig
> @@ -708,17 +708,22 @@ config ROMIMAGE_MMCIF
> first part of the romImage which in turn loads the rest the kernel
> image to RAM using the MMCIF hardware block.
>
> +config CMDLINE
> + string "Kernel command line arguments string"
> + default "console=ttySC1,115200"
> +
> choice
> prompt "Kernel command line"
> - optional
> - default CMDLINE_OVERWRITE
> - depends on !OF || USE_BUILTIN_DTB
> + default CMDLINE_BOOTLOADER
> +
> +config CMDLINE_BOOTLOADER
> + bool "Use bootloader kernel arguments"
This should be the preferred, normal, default way. So why is it a user
visible option?
> help
> - Setting this option allows the kernel command line arguments
> - to be set.
> + Uses the command-line options passed by the boot loader.
> + If boot loader dosen't provide kernel argments, Use built-in argments.
typos
bootloader in some spots, "boot loader" in others. Go with the former.
>
> config CMDLINE_OVERWRITE
> - bool "Overwrite bootloader kernel arguments"
> + bool "Overwrite built-in kernel arguments"
The original made more sense to me. The default should be to use
bootloader args. Any built-in kernel command line should be prepend,
append (extend), or overwrite/replace.
Rob
^ permalink raw reply
* Re: [PATCH v12 2/7] clk: meson: add vclk driver
From: Neil Armstrong @ 2024-04-04 16:59 UTC (permalink / raw)
To: Jerome Brunet
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Martin Blumenstingl, Kevin Hilman, Michael Turquette,
Stephen Boyd, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Jagan Teki, Nicolas Belin,
devicetree, linux-kernel, linux-amlogic, linux-clk,
linux-arm-kernel, dri-devel
In-Reply-To: <1jmsq9pmgd.fsf@starbuckisacylon.baylibre.com>
On 04/04/2024 10:13, Jerome Brunet wrote:
>
> On Wed 03 Apr 2024 at 09:46, Neil Armstrong <neil.armstrong@linaro.org> wrote:
>
>> The VCLK and VCLK_DIV clocks have supplementary bits.
>>
>> The VCLK gate has a "SOFT RESET" bit to toggle after the whole
>> VCLK sub-tree rate has been set, this is implemented in
>> the gate enable callback.
>>
>> The VCLK_DIV clocks as enable and reset bits used to disable
>> and reset the divider, associated with CLK_SET_RATE_GATE it ensures
>> the rate is set while the divider is disabled and in reset mode.
>>
>> The VCLK_DIV enable bit isn't implemented as a gate since it's part
>> of the divider logic and vendor does this exact sequence to ensure
>> the divider is correctly set.
>
> The checkpatch warning is still there. Is it a choice or a mistake ?
>
> Documentation says "GPL v2" exists for historic reason which seems to
> hint "GPL" is preferred, and I suppose this is why checkpatch warns for
> it.
Well I didn't see this warning, this is what I fixed:
$ scripts/checkpatch.pl --strict drivers/clk/meson/vclk.c
CHECK: Alignment should match open parenthesis
#63: FILE: drivers/clk/meson/vclk.c:63:
+static unsigned long meson_vclk_div_recalc_rate(struct clk_hw *hw,
+ unsigned long prate)
CHECK: Alignment should match open parenthesis
#73: FILE: drivers/clk/meson/vclk.c:73:
+static int meson_vclk_div_determine_rate(struct clk_hw *hw,
+ struct clk_rate_request *req)
CHECK: Alignment should match open parenthesis
#83: FILE: drivers/clk/meson/vclk.c:83:
+static int meson_vclk_div_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
<snip>
It seems that checking a commit triggers an extra check....
$ scripts/checkpatch.pl --strict -G 1bac9f6aa3c3
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#58:
new file mode 100644
<snip>
WARNING: Prefer "GPL" over "GPL v2" - see commit bf7fbeeae6db ("module: Cure the MODULE_LICENSE "GPL" vs. "GPL v2" bogosity")
#203: FILE: drivers/clk/meson/vclk.c:141:
+MODULE_LICENSE("GPL v2");
<snip>
Neil
>
>>
>> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
>> ---
>> drivers/clk/meson/Kconfig | 4 ++
>> drivers/clk/meson/Makefile | 1 +
>> drivers/clk/meson/vclk.c | 141 +++++++++++++++++++++++++++++++++++++++++++++
>> drivers/clk/meson/vclk.h | 51 ++++++++++++++++
>> 4 files changed, 197 insertions(+)
>>
>> diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
>> index 29ffd14d267b..8a9823789fa3 100644
>> --- a/drivers/clk/meson/Kconfig
>> +++ b/drivers/clk/meson/Kconfig
>> @@ -30,6 +30,10 @@ config COMMON_CLK_MESON_VID_PLL_DIV
>> tristate
>> select COMMON_CLK_MESON_REGMAP
>>
>> +config COMMON_CLK_MESON_VCLK
>> + tristate
>> + select COMMON_CLK_MESON_REGMAP
>> +
>> config COMMON_CLK_MESON_CLKC_UTILS
>> tristate
>>
>> diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
>> index 9ee4b954c896..9ba43fe7a07a 100644
>> --- a/drivers/clk/meson/Makefile
>> +++ b/drivers/clk/meson/Makefile
>> @@ -12,6 +12,7 @@ obj-$(CONFIG_COMMON_CLK_MESON_PLL) += clk-pll.o
>> obj-$(CONFIG_COMMON_CLK_MESON_REGMAP) += clk-regmap.o
>> obj-$(CONFIG_COMMON_CLK_MESON_SCLK_DIV) += sclk-div.o
>> obj-$(CONFIG_COMMON_CLK_MESON_VID_PLL_DIV) += vid-pll-div.o
>> +obj-$(CONFIG_COMMON_CLK_MESON_VCLK) += vclk.o
>>
>> # Amlogic Clock controllers
>>
>> diff --git a/drivers/clk/meson/vclk.c b/drivers/clk/meson/vclk.c
>> new file mode 100644
>> index 000000000000..45dc216941ea
>> --- /dev/null
>> +++ b/drivers/clk/meson/vclk.c
>> @@ -0,0 +1,141 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (c) 2024 Neil Armstrong <neil.armstrong@linaro.org>
>> + */
>> +
>> +#include <linux/module.h>
>> +#include "vclk.h"
>> +
>> +/* The VCLK gate has a supplementary reset bit to pulse after ungating */
>> +
>> +static inline struct meson_vclk_gate_data *
>> +clk_get_meson_vclk_gate_data(struct clk_regmap *clk)
>> +{
>> + return (struct meson_vclk_gate_data *)clk->data;
>> +}
>> +
>> +static int meson_vclk_gate_enable(struct clk_hw *hw)
>> +{
>> + struct clk_regmap *clk = to_clk_regmap(hw);
>> + struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
>> +
>> + meson_parm_write(clk->map, &vclk->enable, 1);
>> +
>> + /* Do a reset pulse */
>> + meson_parm_write(clk->map, &vclk->reset, 1);
>> + meson_parm_write(clk->map, &vclk->reset, 0);
>> +
>> + return 0;
>> +}
>> +
>> +static void meson_vclk_gate_disable(struct clk_hw *hw)
>> +{
>> + struct clk_regmap *clk = to_clk_regmap(hw);
>> + struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
>> +
>> + meson_parm_write(clk->map, &vclk->enable, 0);
>> +}
>> +
>> +static int meson_vclk_gate_is_enabled(struct clk_hw *hw)
>> +{
>> + struct clk_regmap *clk = to_clk_regmap(hw);
>> + struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
>> +
>> + return meson_parm_read(clk->map, &vclk->enable);
>> +}
>> +
>> +const struct clk_ops meson_vclk_gate_ops = {
>> + .enable = meson_vclk_gate_enable,
>> + .disable = meson_vclk_gate_disable,
>> + .is_enabled = meson_vclk_gate_is_enabled,
>> +};
>> +EXPORT_SYMBOL_GPL(meson_vclk_gate_ops);
>> +
>> +/* The VCLK Divider has supplementary reset & enable bits */
>> +
>> +static inline struct meson_vclk_div_data *
>> +clk_get_meson_vclk_div_data(struct clk_regmap *clk)
>> +{
>> + return (struct meson_vclk_div_data *)clk->data;
>> +}
>> +
>> +static unsigned long meson_vclk_div_recalc_rate(struct clk_hw *hw,
>> + unsigned long prate)
>> +{
>> + struct clk_regmap *clk = to_clk_regmap(hw);
>> + struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
>> +
>> + return divider_recalc_rate(hw, prate, meson_parm_read(clk->map, &vclk->div),
>> + vclk->table, vclk->flags, vclk->div.width);
>> +}
>> +
>> +static int meson_vclk_div_determine_rate(struct clk_hw *hw,
>> + struct clk_rate_request *req)
>> +{
>> + struct clk_regmap *clk = to_clk_regmap(hw);
>> + struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
>> +
>> + return divider_determine_rate(hw, req, vclk->table, vclk->div.width,
>> + vclk->flags);
>> +}
>> +
>> +static int meson_vclk_div_set_rate(struct clk_hw *hw, unsigned long rate,
>> + unsigned long parent_rate)
>> +{
>> + struct clk_regmap *clk = to_clk_regmap(hw);
>> + struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
>> + int ret;
>> +
>> + ret = divider_get_val(rate, parent_rate, vclk->table, vclk->div.width,
>> + vclk->flags);
>> + if (ret < 0)
>> + return ret;
>> +
>> + meson_parm_write(clk->map, &vclk->div, ret);
>> +
>> + return 0;
>> +};
>> +
>> +static int meson_vclk_div_enable(struct clk_hw *hw)
>> +{
>> + struct clk_regmap *clk = to_clk_regmap(hw);
>> + struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
>> +
>> + /* Unreset the divider when ungating */
>> + meson_parm_write(clk->map, &vclk->reset, 0);
>> + meson_parm_write(clk->map, &vclk->enable, 1);
>> +
>> + return 0;
>> +}
>> +
>> +static void meson_vclk_div_disable(struct clk_hw *hw)
>> +{
>> + struct clk_regmap *clk = to_clk_regmap(hw);
>> + struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
>> +
>> + /* Reset the divider when gating */
>> + meson_parm_write(clk->map, &vclk->enable, 0);
>> + meson_parm_write(clk->map, &vclk->reset, 1);
>> +}
>> +
>> +static int meson_vclk_div_is_enabled(struct clk_hw *hw)
>> +{
>> + struct clk_regmap *clk = to_clk_regmap(hw);
>> + struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
>> +
>> + return meson_parm_read(clk->map, &vclk->enable);
>> +}
>> +
>> +const struct clk_ops meson_vclk_div_ops = {
>> + .recalc_rate = meson_vclk_div_recalc_rate,
>> + .determine_rate = meson_vclk_div_determine_rate,
>> + .set_rate = meson_vclk_div_set_rate,
>> + .enable = meson_vclk_div_enable,
>> + .disable = meson_vclk_div_disable,
>> + .is_enabled = meson_vclk_div_is_enabled,
>> +};
>> +EXPORT_SYMBOL_GPL(meson_vclk_div_ops);
>> +
>> +MODULE_DESCRIPTION("Amlogic vclk clock driver");
>> +MODULE_AUTHOR("Neil Armstrong <neil.armstrong@linaro.org>");
>> +MODULE_LICENSE("GPL v2");
>> diff --git a/drivers/clk/meson/vclk.h b/drivers/clk/meson/vclk.h
>> new file mode 100644
>> index 000000000000..20b0b181db09
>> --- /dev/null
>> +++ b/drivers/clk/meson/vclk.h
>> @@ -0,0 +1,51 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * Copyright (c) 2024 Neil Armstrong <neil.armstrong@linaro.org>
>> + */
>> +
>> +#ifndef __VCLK_H
>> +#define __VCLK_H
>> +
>> +#include "clk-regmap.h"
>> +#include "parm.h"
>> +
>> +/**
>> + * struct meson_vclk_gate_data - vclk_gate regmap backed specific data
>> + *
>> + * @enable: vclk enable field
>> + * @reset: vclk reset field
>> + * @flags: hardware-specific flags
>> + *
>> + * Flags:
>> + * Same as clk_gate except CLK_GATE_HIWORD_MASK which is ignored
>> + */
>> +struct meson_vclk_gate_data {
>> + struct parm enable;
>> + struct parm reset;
>> + u8 flags;
>> +};
>> +
>> +extern const struct clk_ops meson_vclk_gate_ops;
>> +
>> +/**
>> + * struct meson_vclk_div_data - vclk_div regmap back specific data
>> + *
>> + * @div: divider field
>> + * @enable: vclk divider enable field
>> + * @reset: vclk divider reset field
>> + * @table: array of value/divider pairs, last entry should have div = 0
>> + *
>> + * Flags:
>> + * Same as clk_divider except CLK_DIVIDER_HIWORD_MASK which is ignored
>> + */
>> +struct meson_vclk_div_data {
>> + struct parm div;
>> + struct parm enable;
>> + struct parm reset;
>> + const struct clk_div_table *table;
>> + u8 flags;
>> +};
>> +
>> +extern const struct clk_ops meson_vclk_div_ops;
>> +
>> +#endif /* __VCLK_H */
>
>
^ permalink raw reply
* Re: [PATCH v2 0/2] Enable JPEG encoding on rk3588
From: Nicolas Dufresne @ 2024-04-04 17:41 UTC (permalink / raw)
To: Emmanuel Gil Peyrot, linux-kernel
Cc: Ezequiel Garcia, Philipp Zabel, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Joerg Roedel, Will Deacon, Robin Murphy, Sebastian Reichel,
Cristian Ciocaltea, Dragan Simic, Shreeya Patel, Chris Morgan,
Andy Yan, Nicolas Frattaroli, linux-media, linux-rockchip,
devicetree, linux-arm-kernel, iommu
In-Reply-To: <20240327134115.424846-1-linkmauve@linkmauve.fr>
Hi,
Le mercredi 27 mars 2024 à 14:41 +0100, Emmanuel Gil Peyrot a écrit :
> Only the JPEG encoder is available for now, although there are patches
> for the undocumented VP8 encoder floating around[0].
[0] seems like a broken link. The VP8 encoder RFC is for RK3399 (and Hantro H1
posted by ST more recently). The TRM says "VEPU121(JPEG encoder only)", which
suggest that the H.264 and VP8 encoders usually found on the VEPU121 are
removed. As Rockchip have remove the synthesize register while modifying the H1
IP, it is difficult to verify. Confusingly the H.264 specific registers are
documented in the TRM around VEPU121.
>
> This has been tested on a rock-5b, resulting in four /dev/video*
> encoders. The userspace program I’ve been using to test them is
> Onix[1], using the jpeg-encoder example, it will pick one of these four
> at random (but displays the one it picked):
> % ffmpeg -i <input image> -pix_fmt yuvj420p temp.yuv
> % jpeg-encoder temp.yuv <width> <height> NV12 <quality> output.jpeg
I don't like that we exposing each identical cores a separate video nodes. I
think we should aim for 1 device, and then multi-plex and schedule de cores from
inside the Linux kernel.
Not doing this now means we'll never have an optimal hardware usage
distribution. Just consider two userspace software wanting to do jpeg encoding.
If they both take a guess, they may endup using a single core. Where with proper
scheduling in V4L2, the kernel will be able to properly distribute the load. I
insist on this, since if we merge you changes it becomes an ABI and we can't
change it anymore.
I understand that this impose a rework of the mem2mem framework so that we can
run multiple jobs, but this will be needed anyway on RK3588, since the rkvdec2,
which we don't have a driver yet is also multi-core, but you need to use 2 cores
when the resolution is close to 8K.
Nicolas
>
> [0] https://patchwork.kernel.org/project/linux-rockchip/list/?series=789885
> [1] https://crates.io/crates/onix
>
> Changes since v1:
> - Dropped patches 1 and 4.
> - Use the proper compatible form, since this device should be fully
> compatible with the VEPU of rk356x.
> - Describe where the VEPU121 name comes from, and list other encoders
> and decoders present in this SoC.
> - Properly test the device tree changes, I previously couldn’t since I
> was using a too recent version of python-jsonschema…
>
> Emmanuel Gil Peyrot (2):
> media: dt-binding: media: Document rk3588’s VEPU121
> arm64: dts: rockchip: Add VEPU121 to rk3588
>
> .../bindings/media/rockchip,rk3568-vepu.yaml | 8 +-
> arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 80 +++++++++++++++++++
> 2 files changed, 86 insertions(+), 2 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v2 1/2] media: dt-binding: media: Document rk3588’s VEPU121
From: Nicolas Dufresne @ 2024-04-04 17:47 UTC (permalink / raw)
To: Conor Dooley, Emmanuel Gil Peyrot
Cc: linux-kernel, Ezequiel Garcia, Philipp Zabel,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Joerg Roedel, Will Deacon,
Robin Murphy, Sebastian Reichel, Cristian Ciocaltea, Dragan Simic,
Shreeya Patel, Chris Morgan, Andy Yan, Nicolas Frattaroli,
linux-media, linux-rockchip, devicetree, linux-arm-kernel, iommu
In-Reply-To: <20240327-doze-uncheck-475f3feaee57@spud>
Le mercredi 27 mars 2024 à 17:23 +0000, Conor Dooley a écrit :
> On Wed, Mar 27, 2024 at 02:41:11PM +0100, Emmanuel Gil Peyrot wrote:
> > This encoder-only device is present four times on this SoC, and should
> > support everything the rk3568 vepu supports (so JPEG, H.264 and VP8
> > encoding).
> >
> > According to the TRM[1], there is also the VEPU580 encoder which
> > supports H.264 and H.265, and various VDPU* decoders, of which only the
> > VDPU981 is currently supported. This patch describes only the VEPU121.
> >
> > [1] https://github.com/FanX-Tek/rk3588-TRM-and-Datasheet
> >
> > Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
I'd like to prevent this change until we fix the driver. It should not expose 1
video device per core, it should instead do schedule around these cores.
Nicolas
>
> Thanks,
> Conor.
>
> > ---
> > .../devicetree/bindings/media/rockchip,rk3568-vepu.yaml | 8 ++++++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml b/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml
> > index 9d90d8d0565a..4c6cb21da041 100644
> > --- a/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml
> > +++ b/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml
> > @@ -15,8 +15,12 @@ description:
> >
> > properties:
> > compatible:
> > - enum:
> > - - rockchip,rk3568-vepu
> > + oneOf:
> > + - const: rockchip,rk3568-vepu
> > + - items:
> > + - enum:
> > + - rockchip,rk3588-vepu121
> > + - const: rockchip,rk3568-vepu
> >
> > reg:
> > maxItems: 1
> > --
> > 2.44.0
> >
^ permalink raw reply
* Re: [PATCH] media: mediatek: vcodec: fix the error sizeimage for 10bit bitstream
From: Nicolas Dufresne @ 2024-04-04 18:28 UTC (permalink / raw)
To: Yunfei Dong, Nícolas F . R . A . Prado, Sebastian Fricke,
Hans Verkuil, AngeloGioacchino Del Regno, Benjamin Gaignard,
Nathan Hebert
Cc: Hsin-Yi Wang, Fritz Koenig, Daniel Vetter, Steve Cho, linux-media,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group
In-Reply-To: <20240403093018.13168-1-yunfei.dong@mediatek.com>
Hi,
Le mercredi 03 avril 2024 à 17:30 +0800, Yunfei Dong a écrit :
> The sizeimage of each plane are calculated the same way for 8bit and
> 10bit bitstream. Need to enlarge the sizeimage with simeimage*5/4 for
> 10bit bitstream when try and set fmt.
Can we stop adding more layers of custom code and port to v4l2-common helpers
please.
regards,
Nicolas
>
> Fixes: 9d86be9bda6c ("media: mediatek: vcodec: Add driver to support 10bit")
> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> ---
> .../mediatek/vcodec/decoder/mtk_vcodec_dec.c | 47 ++++++++++++++-----
> 1 file changed, 34 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
> index 9107707de6c4..45209894f1fe 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
> @@ -259,6 +259,7 @@ static int vidioc_try_fmt(struct mtk_vcodec_dec_ctx *ctx, struct v4l2_format *f,
> pix_fmt_mp->num_planes = 1;
> pix_fmt_mp->plane_fmt[0].bytesperline = 0;
> } else if (f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
> + unsigned int dram_y, dram_c, dram_y_10bit, dram_c_10bit;
> int tmp_w, tmp_h;
>
> /*
> @@ -280,22 +281,42 @@ static int vidioc_try_fmt(struct mtk_vcodec_dec_ctx *ctx, struct v4l2_format *f,
> (pix_fmt_mp->height + 64) <= frmsize->max_height)
> pix_fmt_mp->height += 64;
>
> - mtk_v4l2_vdec_dbg(0, ctx,
> - "before resize wxh=%dx%d, after resize wxh=%dx%d, sizeimage=%d",
> - tmp_w, tmp_h, pix_fmt_mp->width, pix_fmt_mp->height,
> - pix_fmt_mp->width * pix_fmt_mp->height);
> + dram_y = pix_fmt_mp->width * pix_fmt_mp->height;
> + dram_c = dram_y / 2;
> +
> + dram_y_10bit = dram_y * 5 / 4;
> + dram_c_10bit = dram_y_10bit / 2;
>
> pix_fmt_mp->num_planes = fmt->num_planes;
> - pix_fmt_mp->plane_fmt[0].sizeimage =
> - pix_fmt_mp->width * pix_fmt_mp->height;
> - pix_fmt_mp->plane_fmt[0].bytesperline = pix_fmt_mp->width;
> -
> - if (pix_fmt_mp->num_planes == 2) {
> - pix_fmt_mp->plane_fmt[1].sizeimage =
> - (pix_fmt_mp->width * pix_fmt_mp->height) / 2;
> - pix_fmt_mp->plane_fmt[1].bytesperline =
> - pix_fmt_mp->width;
> + if (pix_fmt_mp->num_planes == 1) {
> + if (ctx->is_10bit_bitstream) {
> + pix_fmt_mp->plane_fmt[0].bytesperline = pix_fmt_mp->width * 5 / 4;
> + pix_fmt_mp->plane_fmt[0].sizeimage = dram_y_10bit + dram_c_10bit;
> + } else {
> + pix_fmt_mp->plane_fmt[0].bytesperline = pix_fmt_mp->width;
> + pix_fmt_mp->plane_fmt[0].sizeimage = dram_y + dram_c;
> + }
> + } else {
> + if (ctx->is_10bit_bitstream) {
> + pix_fmt_mp->plane_fmt[0].bytesperline = pix_fmt_mp->width * 5 / 4;
> + pix_fmt_mp->plane_fmt[1].bytesperline = pix_fmt_mp->width * 5 / 4;
> +
> + pix_fmt_mp->plane_fmt[0].sizeimage = dram_y_10bit;
> + pix_fmt_mp->plane_fmt[1].sizeimage = dram_c_10bit;
> + } else {
> + pix_fmt_mp->plane_fmt[0].bytesperline = pix_fmt_mp->width;
> + pix_fmt_mp->plane_fmt[1].bytesperline = pix_fmt_mp->width;
> +
> + pix_fmt_mp->plane_fmt[0].sizeimage = dram_y;
> + pix_fmt_mp->plane_fmt[1].sizeimage = dram_c;
> + }
> }
> +
> + mtk_v4l2_vdec_dbg(0, ctx,
> + "before resize:%dx%d, after resize:%dx%d, sizeimage=0x%x_0x%x",
> + tmp_w, tmp_h, pix_fmt_mp->width, pix_fmt_mp->height,
> + pix_fmt_mp->plane_fmt[0].sizeimage,
> + pix_fmt_mp->plane_fmt[1].sizeimage);
> }
>
> pix_fmt_mp->flags = 0;
^ permalink raw reply
* [PATCH] arm64: dts: ti: k3-am625-phyboard-lyra-rdk: Add Audio Codec
From: Garrett Giordano @ 2024-04-04 18:42 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzysztof.kozlowski+dt, conor+dt,
w.egorov
Cc: linux-arm-kernel, devicetree, linux-kernel, upstream
The Audio Codec runs over the MCASP (Multichannel Audio Serial Port).
Add pinmux for the Audio Reference Clock and MCASP2.
Add DT nodes for Audio Codec, MCASP2, VCC 1v8 and VCC 3v3 regulators.
Additionally, create a sound node that connects our sound card and the
MCASP2.
Signed-off-by: Garrett Giordano <ggiordano@phytec.com>
---
.../dts/ti/k3-am625-phyboard-lyra-rdk.dts | 99 +++++++++++++++++++
1 file changed, 99 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts b/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts
index a83a90497857..dfc78995d30a 100644
--- a/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts
@@ -66,6 +66,35 @@ key-menu {
};
};
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "phyBOARD-Lyra";
+ simple-audio-card,widgets =
+ "Microphone", "Mic Jack",
+ "Headphone", "Headphone Jack",
+ "Speaker", "External Speaker";
+ simple-audio-card,routing =
+ "MIC3R", "Mic Jack",
+ "Mic Jack", "Mic Bias",
+ "Headphone Jack", "HPLOUT",
+ "Headphone Jack", "HPROUT",
+ "External Speaker", "SPOP",
+ "External Speaker", "SPOM";
+ simple-audio-card,format = "dsp_b";
+ simple-audio-card,bitclock-master = <&sound_master>;
+ simple-audio-card,frame-master = <&sound_master>;
+ simple-audio-card,bitclock-inversion;
+
+ simple-audio-card,cpu {
+ sound-dai = <&mcasp2>;
+ };
+
+ sound_master: simple-audio-card,codec {
+ sound-dai = <&audio_codec>;
+ clocks = <&audio_refclk1>;
+ };
+ };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -82,6 +111,15 @@ led-2 {
};
};
+ vcc_1v8: regulator-vcc-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
vcc_3v3_mmc: regulator-vcc-3v3-mmc {
compatible = "regulator-fixed";
regulator-name = "VCC_3V3_MMC";
@@ -90,9 +128,24 @@ vcc_3v3_mmc: regulator-vcc-3v3-mmc {
regulator-always-on;
regulator-boot-on;
};
+
+ vcc_3v3_sw: regulator-vcc-3v3-sw {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_3V3_SW";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
};
&main_pmx0 {
+ audio_ext_refclk1_pins_default: audio-ext-refclk1-default-pins {
+ pinctrl-single,pins = <
+ AM62X_IOPAD(0x0a0, PIN_OUTPUT, 1) /* (K25) GPMC0_WPn.AUDIO_EXT_REFCLK1 */
+ >;
+ };
+
gpio_keys_pins_default: gpio-keys-default-pins {
pinctrl-single,pins = <
AM62X_IOPAD(0x1d4, PIN_INPUT, 7) /* (B15) UART0_RTSn.GPIO1_23 */
@@ -150,6 +203,15 @@ AM62X_IOPAD(0x1d8, PIN_OUTPUT, 0) /* (C15) MCAN0_TX */
>;
};
+ main_mcasp2_pins_default: main-mcasp2-default-pins {
+ pinctrl-single,pins = <
+ AM62X_IOPAD(0x070, PIN_INPUT, 3) /* (T24) GPMC0_AD13.MCASP2_ACLKX */
+ AM62X_IOPAD(0x06c, PIN_INPUT, 3) /* (T22) GPMC0_AD12.MCASP2_AFSX */
+ AM62X_IOPAD(0x064, PIN_OUTPUT, 3) /* (T25) GPMC0_AD10.MCASP2_AXR2 */
+ AM62X_IOPAD(0x068, PIN_INPUT, 3) /* (R21) GPMC0_AD11.MCASP2_AXR3 */
+ >;
+ };
+
main_mmc1_pins_default: main-mmc1-default-pins {
pinctrl-single,pins = <
AM62X_IOPAD(0x23c, PIN_INPUT_PULLUP, 0) /* (A21) MMC1_CMD */
@@ -254,6 +316,21 @@ &main_i2c1 {
clock-frequency = <100000>;
status = "okay";
+ audio_codec: audio-codec@18 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&audio_ext_refclk1_pins_default>;
+
+ #sound-dai-cells = <0>;
+ compatible = "ti,tlv320aic3007";
+ reg = <0x18>;
+ ai3x-micbias-vg = <2>;
+
+ AVDD-supply = <&vcc_3v3_sw>;
+ IOVDD-supply = <&vcc_3v3_sw>;
+ DRVDD-supply = <&vcc_3v3_sw>;
+ DVDD-supply = <&vcc_1v8>;
+ };
+
gpio_exp: gpio-expander@21 {
pinctrl-names = "default";
pinctrl-0 = <&gpio_exp_int_pins_default>;
@@ -329,6 +406,28 @@ &main_uart1 {
status = "okay";
};
+&mcasp2 {
+ status = "okay";
+ #sound-dai-cells = <0>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_mcasp2_pins_default>;
+
+ /* MCASP_IIS_MODE */
+ op-mode = <0>;
+ tdm-slots = <2>;
+
+ /* 0: INACTIVE, 1: TX, 2: RX */
+ serial-dir = <
+ 0 0 1 2
+ 0 0 0 0
+ 0 0 0 0
+ 0 0 0 0
+ >;
+ tx-num-evt = <32>;
+ rx-num-evt = <32>;
+};
+
&sdhci1 {
vmmc-supply = <&vcc_3v3_mmc>;
vqmmc-supply = <&vddshv5_sdio>;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v2] arm64: dts: qcom: qcs6490-rb3gen2: Enable UFS
From: Konrad Dybcio @ 2024-04-04 18:50 UTC (permalink / raw)
To: Bjorn Andersson, Bjorn Andersson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20240327-rb3gen2-ufs-v2-1-3de6b5dd78dd@quicinc.com>
On 3/28/24 03:01, Bjorn Andersson wrote:
> The rb3gen2 has UFS memory, adjust the necessary supply voltage and add
> the controller and phy nodes to enable this.
>
> Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Konrad
^ 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