* [PATCH 2/3] dt-bindings: pinctrl: mediatek: mt7622: add "antsel" function
From: Rafał Miłecki @ 2024-04-08 9:05 UTC (permalink / raw)
To: Sean Wang, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Matthias Brugger, AngeloGioacchino Del Regno, Hsin-Yi Wang,
linux-mediatek, linux-gpio, devicetree, linux-arm-kernel,
Rafał Miłecki, Chuanhong Guo
In-Reply-To: <20240408090506.21596-1-zajec5@gmail.com>
From: Rafał Miłecki <rafal@milecki.pl>
MT7622 pinctrl has ANTSEL* pins. Linux support for those was added in
the commit 19f599e83ac5 ("pinctrl: mediatek: mt7622: add antsel
pins/groups"). Include them in binding.
Cc: Chuanhong Guo <gch981213@gmail.com>
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
.../pinctrl/mediatek,mt7622-pinctrl.yaml | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml
index 60f30a59f385..a9ab623b2697 100644
--- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml
@@ -75,8 +75,8 @@ patternProperties:
function:
description:
A string containing the name of the function to mux to the group.
- enum: [emmc, eth, i2c, i2s, ir, led, flash, pcie, pmic, pwm, sd,
- spi, tdm, uart, watchdog, wifi]
+ enum: [antsel, emmc, eth, i2c, i2s, ir, led, flash, pcie, pmic, pwm,
+ sd, spi, tdm, uart, watchdog, wifi]
groups:
description:
@@ -90,6 +90,20 @@ patternProperties:
- function
allOf:
+ - if:
+ properties:
+ function:
+ const: antsel
+ then:
+ properties:
+ groups:
+ items:
+ enum: [antsel0, antsel1, antsel2, antsel3, antsel4, antsel5,
+ antsel6, antsel7, antsel8, antsel9, antsel10,
+ antsel11, antsel12, antsel13, antsel14, antsel15,
+ antsel16, antsel17, antsel18, antsel19, antsel20,
+ antsel21, antsel22, antsel23, antsel24, antsel25,
+ antsel26, antsel27, antsel28, antsel29]
- if:
properties:
function:
--
2.35.3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: pinctrl: mediatek: mt7622: fix array properties
From: Rafał Miłecki @ 2024-04-08 9:05 UTC (permalink / raw)
To: Sean Wang, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Matthias Brugger, AngeloGioacchino Del Regno, Hsin-Yi Wang,
linux-mediatek, linux-gpio, devicetree, linux-arm-kernel,
Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
Some properties (function groups & pins) are meant to be arrays and
should allow multiple entries out of enum sets. Use "items" for those.
Mistake was noticed during validation of in-kernel DTS files.
Fixes: b9ffc18c6388 ("dt-bindings: mediatek: convert pinctrl to yaml")
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
.../pinctrl/mediatek,mt7622-pinctrl.yaml | 92 ++++++++++---------
1 file changed, 49 insertions(+), 43 deletions(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml
index bd72a326e6e0..60f30a59f385 100644
--- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml
@@ -97,7 +97,8 @@ patternProperties:
then:
properties:
groups:
- enum: [emmc, emmc_rst]
+ items:
+ enum: [emmc, emmc_rst]
- if:
properties:
function:
@@ -105,8 +106,9 @@ patternProperties:
then:
properties:
groups:
- enum: [esw, esw_p0_p1, esw_p2_p3_p4, rgmii_via_esw,
- rgmii_via_gmac1, rgmii_via_gmac2, mdc_mdio]
+ items:
+ enum: [esw, esw_p0_p1, esw_p2_p3_p4, rgmii_via_esw,
+ rgmii_via_gmac1, rgmii_via_gmac2, mdc_mdio]
- if:
properties:
function:
@@ -123,10 +125,11 @@ patternProperties:
then:
properties:
groups:
- enum: [i2s_in_mclk_bclk_ws, i2s1_in_data, i2s2_in_data,
- i2s3_in_data, i2s4_in_data, i2s_out_mclk_bclk_ws,
- i2s1_out_data, i2s2_out_data, i2s3_out_data,
- i2s4_out_data]
+ items:
+ enum: [i2s_in_mclk_bclk_ws, i2s1_in_data, i2s2_in_data,
+ i2s3_in_data, i2s4_in_data, i2s_out_mclk_bclk_ws,
+ i2s1_out_data, i2s2_out_data, i2s3_out_data,
+ i2s4_out_data]
- if:
properties:
function:
@@ -159,10 +162,11 @@ patternProperties:
then:
properties:
groups:
- enum: [pcie0_0_waken, pcie0_1_waken, pcie1_0_waken,
- pcie0_0_clkreq, pcie0_1_clkreq, pcie1_0_clkreq,
- pcie0_pad_perst, pcie1_pad_perst, pcie_pereset,
- pcie_wake, pcie_clkreq]
+ items:
+ enum: [pcie0_0_waken, pcie0_1_waken, pcie1_0_waken,
+ pcie0_0_clkreq, pcie0_1_clkreq, pcie1_0_clkreq,
+ pcie0_pad_perst, pcie1_pad_perst, pcie_pereset,
+ pcie_wake, pcie_clkreq]
- if:
properties:
function:
@@ -178,11 +182,12 @@ patternProperties:
then:
properties:
groups:
- enum: [pwm_ch1_0, pwm_ch1_1, pwm_ch1_2, pwm_ch2_0, pwm_ch2_1,
- pwm_ch2_2, pwm_ch3_0, pwm_ch3_1, pwm_ch3_2, pwm_ch4_0,
- pwm_ch4_1, pwm_ch4_2, pwm_ch4_3, pwm_ch5_0, pwm_ch5_1,
- pwm_ch5_2, pwm_ch6_0, pwm_ch6_1, pwm_ch6_2, pwm_ch6_3,
- pwm_ch7_0, pwm_0, pwm_1]
+ items:
+ enum: [pwm_ch1_0, pwm_ch1_1, pwm_ch1_2, pwm_ch2_0, pwm_ch2_1,
+ pwm_ch2_2, pwm_ch3_0, pwm_ch3_1, pwm_ch3_2, pwm_ch4_0,
+ pwm_ch4_1, pwm_ch4_2, pwm_ch4_3, pwm_ch5_0, pwm_ch5_1,
+ pwm_ch5_2, pwm_ch6_0, pwm_ch6_1, pwm_ch6_2, pwm_ch6_3,
+ pwm_ch7_0, pwm_0, pwm_1]
- if:
properties:
function:
@@ -260,33 +265,34 @@ patternProperties:
pins:
description:
An array of strings. Each string contains the name of a pin.
- enum: [GPIO_A, I2S1_IN, I2S1_OUT, I2S_BCLK, I2S_WS, I2S_MCLK, TXD0,
- RXD0, SPI_WP, SPI_HOLD, SPI_CLK, SPI_MOSI, SPI_MISO, SPI_CS,
- I2C_SDA, I2C_SCL, I2S2_IN, I2S3_IN, I2S4_IN, I2S2_OUT,
- I2S3_OUT, I2S4_OUT, GPIO_B, MDC, MDIO, G2_TXD0, G2_TXD1,
- G2_TXD2, G2_TXD3, G2_TXEN, G2_TXC, G2_RXD0, G2_RXD1, G2_RXD2,
- G2_RXD3, G2_RXDV, G2_RXC, NCEB, NWEB, NREB, NDL4, NDL5, NDL6,
- NDL7, NRB, NCLE, NALE, NDL0, NDL1, NDL2, NDL3, MDI_TP_P0,
- MDI_TN_P0, MDI_RP_P0, MDI_RN_P0, MDI_TP_P1, MDI_TN_P1,
- MDI_RP_P1, MDI_RN_P1, MDI_RP_P2, MDI_RN_P2, MDI_TP_P2,
- MDI_TN_P2, MDI_TP_P3, MDI_TN_P3, MDI_RP_P3, MDI_RN_P3,
- MDI_RP_P4, MDI_RN_P4, MDI_TP_P4, MDI_TN_P4, PMIC_SCL,
- PMIC_SDA, SPIC1_CLK, SPIC1_MOSI, SPIC1_MISO, SPIC1_CS,
- GPIO_D, WATCHDOG, RTS3_N, CTS3_N, TXD3, RXD3, PERST0_N,
- PERST1_N, WLED_N, EPHY_LED0_N, AUXIN0, AUXIN1, AUXIN2,
- AUXIN3, TXD4, RXD4, RTS4_N, CST4_N, PWM1, PWM2, PWM3, PWM4,
- PWM5, PWM6, PWM7, GPIO_E, TOP_5G_CLK, TOP_5G_DATA,
- WF0_5G_HB0, WF0_5G_HB1, WF0_5G_HB2, WF0_5G_HB3, WF0_5G_HB4,
- WF0_5G_HB5, WF0_5G_HB6, XO_REQ, TOP_RST_N, SYS_WATCHDOG,
- EPHY_LED0_N_JTDO, EPHY_LED1_N_JTDI, EPHY_LED2_N_JTMS,
- EPHY_LED3_N_JTCLK, EPHY_LED4_N_JTRST_N, WF2G_LED_N,
- WF5G_LED_N, GPIO_9, GPIO_10, GPIO_11, GPIO_12, UART1_TXD,
- UART1_RXD, UART1_CTS, UART1_RTS, UART2_TXD, UART2_RXD,
- UART2_CTS, UART2_RTS, SMI_MDC, SMI_MDIO, PCIE_PERESET_N,
- PWM_0, GPIO_0, GPIO_1, GPIO_2, GPIO_3, GPIO_4, GPIO_5,
- GPIO_6, GPIO_7, GPIO_8, UART0_TXD, UART0_RXD, TOP_2G_CLK,
- TOP_2G_DATA, WF0_2G_HB0, WF0_2G_HB1, WF0_2G_HB2, WF0_2G_HB3,
- WF0_2G_HB4, WF0_2G_HB5, WF0_2G_HB6]
+ items:
+ enum: [GPIO_A, I2S1_IN, I2S1_OUT, I2S_BCLK, I2S_WS, I2S_MCLK, TXD0,
+ RXD0, SPI_WP, SPI_HOLD, SPI_CLK, SPI_MOSI, SPI_MISO, SPI_CS,
+ I2C_SDA, I2C_SCL, I2S2_IN, I2S3_IN, I2S4_IN, I2S2_OUT,
+ I2S3_OUT, I2S4_OUT, GPIO_B, MDC, MDIO, G2_TXD0, G2_TXD1,
+ G2_TXD2, G2_TXD3, G2_TXEN, G2_TXC, G2_RXD0, G2_RXD1, G2_RXD2,
+ G2_RXD3, G2_RXDV, G2_RXC, NCEB, NWEB, NREB, NDL4, NDL5, NDL6,
+ NDL7, NRB, NCLE, NALE, NDL0, NDL1, NDL2, NDL3, MDI_TP_P0,
+ MDI_TN_P0, MDI_RP_P0, MDI_RN_P0, MDI_TP_P1, MDI_TN_P1,
+ MDI_RP_P1, MDI_RN_P1, MDI_RP_P2, MDI_RN_P2, MDI_TP_P2,
+ MDI_TN_P2, MDI_TP_P3, MDI_TN_P3, MDI_RP_P3, MDI_RN_P3,
+ MDI_RP_P4, MDI_RN_P4, MDI_TP_P4, MDI_TN_P4, PMIC_SCL,
+ PMIC_SDA, SPIC1_CLK, SPIC1_MOSI, SPIC1_MISO, SPIC1_CS,
+ GPIO_D, WATCHDOG, RTS3_N, CTS3_N, TXD3, RXD3, PERST0_N,
+ PERST1_N, WLED_N, EPHY_LED0_N, AUXIN0, AUXIN1, AUXIN2,
+ AUXIN3, TXD4, RXD4, RTS4_N, CST4_N, PWM1, PWM2, PWM3, PWM4,
+ PWM5, PWM6, PWM7, GPIO_E, TOP_5G_CLK, TOP_5G_DATA,
+ WF0_5G_HB0, WF0_5G_HB1, WF0_5G_HB2, WF0_5G_HB3, WF0_5G_HB4,
+ WF0_5G_HB5, WF0_5G_HB6, XO_REQ, TOP_RST_N, SYS_WATCHDOG,
+ EPHY_LED0_N_JTDO, EPHY_LED1_N_JTDI, EPHY_LED2_N_JTMS,
+ EPHY_LED3_N_JTCLK, EPHY_LED4_N_JTRST_N, WF2G_LED_N,
+ WF5G_LED_N, GPIO_9, GPIO_10, GPIO_11, GPIO_12, UART1_TXD,
+ UART1_RXD, UART1_CTS, UART1_RTS, UART2_TXD, UART2_RXD,
+ UART2_CTS, UART2_RTS, SMI_MDC, SMI_MDIO, PCIE_PERESET_N,
+ PWM_0, GPIO_0, GPIO_1, GPIO_2, GPIO_3, GPIO_4, GPIO_5,
+ GPIO_6, GPIO_7, GPIO_8, UART0_TXD, UART0_RXD, TOP_2G_CLK,
+ TOP_2G_DATA, WF0_2G_HB0, WF0_2G_HB1, WF0_2G_HB2, WF0_2G_HB3,
+ WF0_2G_HB4, WF0_2G_HB5, WF0_2G_HB6]
bias-disable: true
--
2.35.3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/2] serial: imx: Introduce timeout when waiting on transmitter empty
From: Esben Haabendal @ 2024-04-08 8:57 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Greg Kroah-Hartman, Jiri Slaby, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-kernel,
linux-serial, imx, linux-arm-kernel
In-Reply-To: <20240405-amused-cascade-0801f31c674a-mkl@pengutronix.de>
Marc Kleine-Budde <mkl@pengutronix.de> writes:
> On 05.04.2024 19:22:29, Esben Haabendal wrote:
>> Marc Kleine-Budde <mkl@pengutronix.de> writes:
>>
>> > On 05.04.2024 11:25:13, Esben Haabendal wrote:
>> >> By waiting at most 1 second for USR2_TXDC to be set, we avoid a potentital
>> >> deadlock.
>> >>
>> >> In case of the timeout, there is not much we can do, so we simply ignore
>> >> the transmitter state and optimistically try to continue.
>> >>
>> >> Signed-off-by: Esben Haabendal <esben@geanix.com>
>> >> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
>> >
>> > Where's the cover letter and patch 2/2? Have a look at b4 [1], it's a
>> > great tool to help you with sending git patch series.
>>
>> It is left out on purpose.
>>
>> This patch is a stand-alone patch as it is. The other part of the series
>> you are talking about is not going to mainline for now. It needs still
>> quite some work, and will only go in after all the other printk stuff.
>>
>> I hope we can merge this patch as it to mainline now, instead of piling
>> up more than necessary in the rt tree.
>
> Ok, then send it as patch 1/1.
Sure. Sorry about that.
/Esben
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] serial: imx: Introduce timeout when waiting on transmitter empty
From: Esben Haabendal @ 2024-04-08 8:56 UTC (permalink / raw)
To: Fabio Estevam
Cc: Greg Kroah-Hartman, Jiri Slaby, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Marc Kleine-Budde, linux-kernel,
linux-serial, imx, linux-arm-kernel
In-Reply-To: <CAOMZO5Axz7un+9H2uEoQtE0=pYNC0hEyZiNobrSi2m0ajj8N+g@mail.gmail.com>
Fabio Estevam <festevam@gmail.com> writes:
> On Fri, Apr 5, 2024 at 6:25 AM Esben Haabendal <esben@geanix.com> wrote:
>>
>> By waiting at most 1 second for USR2_TXDC to be set, we avoid a potentital
>
> s/potentital/potential
Thanks, fixing.
> Could you elaborate on this deadlock? Have you seen it in practice?
I cannot say for sure if I have seen it. But in some cases, that is
exactly what you would see. Nothing.
If it would occur during shutdown, the console would simply stop/block,
and you would see nothing.
> Should a Fixes tag be added?
Which commit should I add to that tag? The polling without timeout dates
back to at least 2.6.12-rc2.
/Esben
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: stm32: add heartbeat led for stm32mp157c-ed1
From: Alexandre TORGUE @ 2024-04-08 8:54 UTC (permalink / raw)
To: patrice.chotard, robh+dt, Krzysztof Kozlowski
Cc: linux-stm32, linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <20240326075438.2891335-1-patrice.chotard@foss.st.com>
Hi Patrice
On 3/26/24 08:54, patrice.chotard@foss.st.com wrote:
> From: Patrice Chotard <patrice.chotard@foss.st.com>
>
> Add heartbeat led for stm32mp157c-ed1.
>
> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
> ---
>
> V2 changes :
> _ add color and function properties.
>
> arch/arm/boot/dts/st/stm32mp157c-ed1.dts | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/boot/dts/st/stm32mp157c-ed1.dts b/arch/arm/boot/dts/st/stm32mp157c-ed1.dts
> index 66ed5f9921ba..525d9ca7d576 100644
> --- a/arch/arm/boot/dts/st/stm32mp157c-ed1.dts
> +++ b/arch/arm/boot/dts/st/stm32mp157c-ed1.dts
> @@ -10,6 +10,7 @@
> #include "stm32mp15-pinctrl.dtsi"
> #include "stm32mp15xxaa-pinctrl.dtsi"
> #include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/leds/common.h>
> #include <dt-bindings/mfd/st,stpmic1.h>
>
> / {
> @@ -24,6 +25,17 @@ chosen {
> stdout-path = "serial0:115200n8";
> };
>
> + led {
> + compatible = "gpio-leds";
> + led-blue {
> + gpios = <&gpiod 9 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "heartbeat";
> + default-state = "off";
> + function = LED_FUNCTION_HEARTBEAT;
> + color = <LED_COLOR_ID_BLUE>;
> + };
> + };
> +
> memory@c0000000 {
> device_type = "memory";
> reg = <0xC0000000 0x40000000>;
Applied on stm32-next.
thanks
Alex
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: dts: stm32: move can3 node from stm32f746 to stm32f769
From: Alexandre TORGUE @ 2024-04-08 8:46 UTC (permalink / raw)
To: Dario Binacchi, linux-kernel
Cc: linux-amarula, Conor Dooley, Krzysztof Kozlowski, Maxime Coquelin,
Rob Herring, devicetree, linux-arm-kernel, linux-stm32
In-Reply-To: <20240325075635.1382911-1-dario.binacchi@amarulasolutions.com>
Hi Dario
On 3/25/24 08:56, Dario Binacchi wrote:
> According to documents [1], [2] and [3], we have 2 CAN devices on the
> stm32f746 platform and 3 on the stm32f769 platform. So let's move the
> can3 node from stm32f746.dtsi to stm32f769.dtsi.
>
> [1] https://www.st.com/en/microcontrollers-microprocessors/stm32f7-series.html
> [2] RM0385: STM32F75xxx and STM32F74xxx advanced Arm®-based 32-bit MCUs
> [3] RM0410: STM32F76xxx and STM32F77xxx advanced Arm®-based 32-bit MCUs
> Fixes: df362914eead ("ARM: dts: stm32: re-add CAN support on stm32f746")
> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
>
> ---
>
>
Applied on stm32-next.
Cheers
Alex
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFT PATCH v2 10/10] arm64: dts: microchip: sparx5_pcb135: drop duplicated NOR flash
From: Steen Hegelund @ 2024-04-08 8:45 UTC (permalink / raw)
To: Krzysztof Kozlowski, Conor Dooley, Nicolas Ferre, Claudiu Beznea,
Rob Herring, Krzysztof Kozlowski, Lars Povlsen, Daniel Machon,
UNGLinuxDriver, Bjarni Jonasson, David S. Miller,
linux-arm-kernel, devicetree, linux-kernel
Cc: horatiu.vultur
In-Reply-To: <20240405190419.74162-10-krzk@kernel.org>
Hi Krzysztof,
On Fri, 2024-04-05 at 21:04 +0200, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
>
> Since beginning the DTS extended the SPI0 in two places adding two
> SPI
> muxes, each with same SPI NOR flash. Both used exactly the same
> chip-selects, so this was clearly buggy code. Then in commit
> d0f482bb06f9 ("arm64: dts: sparx5: Add the Sparx5 switch node") one
> SPI
> mux was removed, while keeping the SPI NOR flash node.
>
> This still leaves duplicated SPI nodes under same chip select 0,
> reported by dtc W=1 warnings:
>
> sparx5_pcb135_board.dtsi:92.10-96.4: Warning
> (unique_unit_address_if_enabled):
> /axi@600000000/spi@600104000/flash@0: duplicate unit-address (also
> used in node /axi@600000000/spi@600104000/spi@0)
>
> Steen Hegelund confirmed that in fact there is a SPI mux, thus remove
> the duplicated node without the mux.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> ---
>
> Not tested on hardware
>
> Changes in v2:
> 1. Remove SPI node without mux.
> ---
> arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi | 9 ---------
> 1 file changed, 9 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
> b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
> index 20016efb3656..af2f1831f07f 100644
> --- a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
> +++ b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
> @@ -87,15 +87,6 @@ i2cmux_s32: i2cmux-3-pins {
> };
> };
>
> -&spi0 {
> - status = "okay";
> - flash@0 {
> - compatible = "jedec,spi-nor";
> - spi-max-frequency = <8000000>;
> - reg = <0>;
> - };
> -};
> -
> &spi0 {
> status = "okay";
> spi@0 {
> --
> 2.34.1
>
This also works fine on my setup now.
Thanks for the patch series.
For this patch:
Tested-by: Steen Hegelund <Steen.Hegelund@microchip.com>
BR
Steen
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 00/13] Introduce STM32 Firewall framework
From: Alexandre TORGUE @ 2024-04-08 8:42 UTC (permalink / raw)
To: Gatien Chevallier, Oleksii_Moisieiev, gregkh, herbert, davem,
robh+dt, krzysztof.kozlowski+dt, conor+dt, vkoul, jic23,
olivier.moysan, arnaud.pouliquen, mchehab, fabrice.gasnier,
andi.shyti, ulf.hansson, edumazet, kuba, pabeni, hugues.fruchet,
lee, will, catalin.marinas, arnd, richardcochran, Frank Rowand,
peng.fan, lars, rcsekar, wg, mkl
Cc: linux-crypto, devicetree, linux-stm32, linux-arm-kernel,
linux-kernel, dmaengine, linux-i2c, linux-iio, alsa-devel,
linux-media, linux-mmc, netdev, linux-phy, linux-serial,
linux-spi, linux-usb
In-Reply-To: <20240105130404.301172-1-gatien.chevallier@foss.st.com>
Hi Gatien,
On 1/5/24 14:03, Gatien Chevallier wrote:
> Introduce STM32 Firewall framework for STM32MP1x and STM32MP2x
> platforms. STM32MP1x(ETZPC) and STM32MP2x(RIFSC) Firewall controllers
> register to the framework to offer firewall services such as access
> granting.
>
> This series of patches is a new approach on the previous STM32 system
> bus, history is available here:
> https://lore.kernel.org/lkml/20230127164040.1047583/
>
> The need for such framework arises from the fact that there are now
> multiple hardware firewalls implemented across multiple products.
> Drivers are shared between different products, using the same code.
> When it comes to firewalls, the purpose mostly stays the same: Protect
> hardware resources. But the implementation differs, and there are
> multiple types of firewalls: peripheral, memory, ...
>
> Some hardware firewall controllers such as the RIFSC implemented on
> STM32MP2x platforms may require to take ownership of a resource before
> being able to use it, hence the requirement for firewall services to
> take/release the ownership of such resources.
>
> On the other hand, hardware firewall configurations are becoming
> more and more complex. These mecanisms prevent platform crashes
> or other firewall-related incoveniences by denying access to some
> resources.
>
> The stm32 firewall framework offers an API that is defined in
> firewall controllers drivers to best fit the specificity of each
> firewall.
>
> For every peripherals protected by either the ETZPC or the RIFSC, the
> firewall framework checks the firewall controlelr registers to see if
> the peripheral's access is granted to the Linux kernel. If not, the
> peripheral is configured as secure, the node is marked populated,
> so that the driver is not probed for that device.
>
> The firewall framework relies on the access-controller device tree
> binding. It is used by peripherals to reference a domain access
> controller. In this case a firewall controller. The bus uses the ID
> referenced by the access-controller property to know where to look
> in the firewall to get the security configuration for the peripheral.
> This allows a device tree description rather than a hardcoded peripheral
> table in the bus driver.
>
> The STM32 ETZPC device is responsible for filtering accesses based on
> security level, or co-processor isolation for any resource connected
> to it.
>
> The RIFSC is responsible for filtering accesses based on Compartment
> ID / security level / privilege level for any resource connected to
> it.
>
> STM32MP13/15/25 SoC device tree files are updated in this series to
> implement this mecanism.
>
...
After minor cosmetic fixes, series applied on stm32-next.
Seen with Arnd: it will be part on my next PR and will come through
arm-soc tree.
Thanks
Alex
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFT PATCH v2 09/10] arm64: dts: microchip: sparx5_pcb134: drop duplicated NOR flash
From: Steen Hegelund @ 2024-04-08 8:44 UTC (permalink / raw)
To: Krzysztof Kozlowski, Conor Dooley, Nicolas Ferre, Claudiu Beznea,
Rob Herring, Krzysztof Kozlowski, Lars Povlsen, Daniel Machon,
UNGLinuxDriver, Bjarni Jonasson, David S. Miller,
linux-arm-kernel, devicetree, linux-kernel
Cc: horatiu.vultur
In-Reply-To: <20240405190419.74162-9-krzk@kernel.org>
Hi Krzysztof,
On Fri, 2024-04-05 at 21:04 +0200, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
>
> Since beginning the DTS extended the SPI0 in two places adding two
> SPI
> muxes, each with same SPI NOR flash. Both used exactly the same
> chip-selects, so this was clearly buggy code. Then in commit
> d0f482bb06f9 ("arm64: dts: sparx5: Add the Sparx5 switch node") one
> SPI
> mux was removed, while keeping the SPI NOR flash node.
>
> This still leaves duplicated SPI nodes under same chip select 0,
> reported by dtc W=1 warnings:
>
> sparx5_pcb134_board.dtsi:277.10-281.4: Warning
> (unique_unit_address_if_enabled):
> /axi@600000000/spi@600104000/flash@0: duplicate unit-address (also
> used in node /axi@600000000/spi@600104000/spi@0)
>
> Steen Hegelund confirmed that in fact there is a SPI mux, thus remove
> the duplicated node without the mux.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> ---
>
> Not tested on hardware
>
> Changes in v2:
> 1. Remove SPI node without mux.
> ---
> arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi | 9 ---------
> 1 file changed, 9 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
> b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
> index f165a409bc1d..2c5574734c9e 100644
> --- a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
> +++ b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
> @@ -272,15 +272,6 @@ gpio@1 {
> };
> };
>
> -&spi0 {
> - status = "okay";
> - flash@0 {
> - compatible = "jedec,spi-nor";
> - spi-max-frequency = <8000000>;
> - reg = <0>;
> - };
> -};
> -
> &spi0 {
> status = "okay";
> spi@0 {
> --
> 2.34.1
>
This works fine on my setup now.
Thanks for the patch series.
For this patch:
Tested-by: Steen Hegelund <Steen.Hegelund@microchip.com>
For whole series:
Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 3/3] arm64: tlb: Allow range operation for MAX_TLBI_RANGE_PAGES
From: Ryan Roberts @ 2024-04-08 8:43 UTC (permalink / raw)
To: Gavin Shan, linux-arm-kernel, linux-kernel
Cc: catalin.marinas, will, akpm, maz, oliver.upton, apopple, rananta,
mark.rutland, v-songbaohua, yangyicong, shahuang, yihyu,
shan.gavin
In-Reply-To: <20240405035852.1532010-4-gshan@redhat.com>
On 05/04/2024 04:58, Gavin Shan wrote:
> MAX_TLBI_RANGE_PAGES pages is covered by SCALE#3 and NUM#31 and it's
> supported now. Allow TLBI RANGE operation when the number of pages is
> equal to MAX_TLBI_RANGE_PAGES in __flush_tlb_range_nosync().
>
> Suggested-by: Marc Zyngier <maz@kernel.org>
> Signed-off-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
> ---
> arch/arm64/include/asm/tlbflush.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
> index 243d71f7bc1f..95fbc8c05607 100644
> --- a/arch/arm64/include/asm/tlbflush.h
> +++ b/arch/arm64/include/asm/tlbflush.h
> @@ -446,11 +446,11 @@ static inline void __flush_tlb_range_nosync(struct vm_area_struct *vma,
> * When not uses TLB range ops, we can handle up to
> * (MAX_DVM_OPS - 1) pages;
> * When uses TLB range ops, we can handle up to
> - * (MAX_TLBI_RANGE_PAGES - 1) pages.
> + * MAX_TLBI_RANGE_PAGES pages.
> */
> if ((!system_supports_tlb_range() &&
> (end - start) >= (MAX_DVM_OPS * stride)) ||
> - pages >= MAX_TLBI_RANGE_PAGES) {
> + pages > MAX_TLBI_RANGE_PAGES) {
As a further enhancement, I wonder if it might be better to test:
pages * 4 / MAX_TLBI_RANGE_PAGES > MAX_DVM_OPS
Then add an extra loop over __flush_tlb_range_op(), like KVM does.
The math is trying to express that there are a maximum of 4 tlbi range
instructions for MAX_TLBI_RANGE_PAGES pages (1 per scale) and we only need to
fall back to flushing the whole mm if it could generate more than MAX_DVM_OPS ops.
> flush_tlb_mm(vma->vm_mm);
> return;
> }
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v1 0/4] Reduce cost of ptep_get_lockless on arm64
From: David Hildenbrand @ 2024-04-08 8:36 UTC (permalink / raw)
To: Ryan Roberts, Mark Rutland, Catalin Marinas, Will Deacon,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
Andrew Morton, Muchun Song
Cc: linux-arm-kernel, linux-mm, linux-kernel
In-Reply-To: <dbc5083b-bf8c-4869-8dc7-5fbf2c88cce8@arm.com>
On 03.04.24 14:59, Ryan Roberts wrote:
> On 27/03/2024 09:34, David Hildenbrand wrote:
>> On 26.03.24 18:51, Ryan Roberts wrote:
>>> On 26/03/2024 17:39, David Hildenbrand wrote:
>>>> On 26.03.24 18:32, Ryan Roberts wrote:
>>>>> On 26/03/2024 17:04, David Hildenbrand wrote:
>>>>>>>>>>
>>>>>>>>>> Likely, we just want to read "the real deal" on both sides of the
>>>>>>>>>> pte_same()
>>>>>>>>>> handling.
>>>>>>>>>
>>>>>>>>> Sorry I'm not sure I understand? You mean read the full pte including
>>>>>>>>> access/dirty? That's the same as dropping the patch, right? Of course if
>>>>>>>>> we do
>>>>>>>>> that, we still have to keep pte_get_lockless() around for this case. In an
>>>>>>>>> ideal
>>>>>>>>> world we would convert everything over to ptep_get_lockless_norecency() and
>>>>>>>>> delete ptep_get_lockless() to remove the ugliness from arm64.
>>>>>>>>
>>>>>>>> Yes, agreed. Patch #3 does not look too crazy and it wouldn't really affect
>>>>>>>> any
>>>>>>>> architecture.
>>>>>>>>
>>>>>>>> I do wonder if pte_same_norecency() should be defined per architecture
>>>>>>>> and the
>>>>>>>> default would be pte_same(). So we could avoid the mkold etc on all other
>>>>>>>> architectures.
>>>>>>>
>>>>>>> Wouldn't that break it's semantics? The "norecency" of
>>>>>>> ptep_get_lockless_norecency() means "recency information in the returned pte
>>>>>>> may
>>>>>>> be incorrect". But the "norecency" of pte_same_norecency() means "ignore the
>>>>>>> access and dirty bits when you do the comparison".
>>>>>>
>>>>>> My idea was that ptep_get_lockless_norecency() would return the actual
>>>>>> result on
>>>>>> these architectures. So e.g., on x86, there would be no actual change in
>>>>>> generated code.
>>>>>
>>>>> I think this is a bad plan... You'll end up with subtle differences between
>>>>> architectures.
>>>>>
>>>>>>
>>>>>> But yes, the documentation of these functions would have to be improved.
>>>>>>
>>>>>> Now I wonder if ptep_get_lockless_norecency() should actively clear
>>>>>> dirty/accessed bits to more easily find any actual issues where the bits still
>>>>>> matter ...
>>>>>
>>>>> I did a version that took that approach. Decided it was not as good as this way
>>>>> though. Now for the life of me, I can't remember my reasoning.
>>>>
>>>> Maybe because there are some code paths that check accessed/dirty without
>>>> "correctness" implications? For example, if the PTE is already dirty, no need to
>>>> set it dirty etc?
>>>
>>> I think I decided I was penalizing the architectures that don't care because all
>>> their ptep_get_norecency() and ptep_get_lockless_norecency() need to explicitly
>>> clear access/dirty. And I would have needed ptep_get_norecency() from day 1 so
>>> that I could feed its result into pte_same().
>>
>> True. With ptep_get_norecency() you're also penalizing other architectures.
>> Therefore my original thought about making the behavior arch-specific, but the
>> arch has to make sure to get the combination of
>> ptep_get_lockless_norecency()+ptep_same_norecency() is right.
>>
>> So if an arch decide to ignore bits in ptep_get_lockless_norecency(), it must
>> make sure to also ignore them in ptep_same_norecency(), and must be able to
>> handle access/dirty bit changes differently.
>>
>> Maybe one could have one variant for "hw-managed access/dirty" vs. "sw managed
>> accessed or dirty". Only the former would end up ignoring stuff here, the latter
>> would not.
>>
>> But again, just some random thoughts how this affects other architectures and
>> how we could avoid it. The issue I describe in patch #3 would be gone if
>> ptep_same_norecency() would just do a ptep_same() check on other architectures
>> -- and would make it easier to sell :)
>>
>
> I've been thinking some more about this. I think your proposal is the following:
>
>
> // ARM64
> ptep_get_lockless_norecency()
> {
> - returned access/dirty may be incorrect
> - returned access/dirty may be differently incorrect between 2 calls
> }
> pte_same_norecency()
> {
> - ignore access/dirty when doing comparison
> }
> ptep_set_access_flags(ptep, pte)
> {
> - must not assume access/dirty in pte are "more permissive" than
> access/dirty in *ptep
> - must only set access/dirty in *ptep, never clear
> }
>
>
> // Other arches: no change to generated code
> ptep_get_lockless_norecency()
> {
> return ptep_get_lockless();
> }
> pte_same_norecency()
> {
> return pte_same();
> }
> ptep_set_access_flags(ptep, pte)
> {
> - may assume access/dirty in pte are "more permissive" than access/dirty
> in *ptep
> - if no HW access/dirty updates, "*ptep = pte" always results in "more
> permissive" change
> }
>
> An arch either specializes all 3 or none of them.
>
> This would allow us to get rid of ptep_get_lockless().
>
> And it addresses the bug you found with ptep_set_access_flags().
>
>
> BUT, I still have a nagging feeling that there are likely to be other similar
> problems caused by ignoring access/dirty during pte_same_norecency(). I can't
> convince myself that its definitely all safe and robust.
Right, we'd have to identify the other possible cases and document what
an arch + common code must stick to to make it work.
Some rules would be: if an arch implements ptep_get_lockless_norecency():
(1) Passing the result from ptep_get_lockless_norecency() to pte_same()
is wrong.
(2) Checking pte_young()/pte_old/pte_dirty()/pte_clean() after
ptep_get_lockless_norecency() is very likely wrong.
>
> So I'm leaning towards dropping patch 3 and therefore keeping
> ptep_get_lockless() around.
>
> Let me know if you have any insight that might help me change my mind :)
I'm wondering if it would help if we could find a better name (or
concept) for "norecency" here, that expresses that only on some archs
we'd have that fuzzy handling.
Keeping ptep_get_lockless() around for now sounds like the best alternative.
--
Cheers,
David / dhildenb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 1/4] arch_topology: init capacity_freq_ref to 0
From: Vincent Guittot @ 2024-04-08 8:35 UTC (permalink / raw)
To: Beata Michalska
Cc: linux-kernel, linux-arm-kernel, ionela.voinescu, vanshikonda,
sudeep.holla, will, catalin.marinas, sumitg, yang, lihuisong
In-Reply-To: <20240405133319.859813-2-beata.michalska@arm.com>
On Fri, 5 Apr 2024 at 15:33, Beata Michalska <beata.michalska@arm.com> wrote:
>
> From: Ionela Voinescu <ionela.voinescu@arm.com>
>
> It's useful to have capacity_freq_ref initialized to 0 for users of
> arch_scale_freq_ref() to detect when capacity_freq_ref was not
> yet set.
>
> The only scenario affected by this change in the init value is when a
> cpufreq driver is never loaded. As a result, the only setter of a
> cpu scale factor remains the call of topology_normalize_cpu_scale()
> from parse_dt_topology(). There we cannot use the value 0 of
> capacity_freq_ref so we have to compensate for its uninitialized state.
>
> Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com>
> Signed-off-by: Beata Michalska <beata.michalska@arm.com>
Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
> ---
> drivers/base/arch_topology.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
> index 024b78a0cfc1..7d4c92cd2bad 100644
> --- a/drivers/base/arch_topology.c
> +++ b/drivers/base/arch_topology.c
> @@ -27,7 +27,7 @@
> static DEFINE_PER_CPU(struct scale_freq_data __rcu *, sft_data);
> static struct cpumask scale_freq_counters_mask;
> static bool scale_freq_invariant;
> -DEFINE_PER_CPU(unsigned long, capacity_freq_ref) = 1;
> +DEFINE_PER_CPU(unsigned long, capacity_freq_ref) = 0;
> EXPORT_PER_CPU_SYMBOL_GPL(capacity_freq_ref);
>
> static bool supports_scale_freq_counters(const struct cpumask *cpus)
> @@ -292,13 +292,15 @@ void topology_normalize_cpu_scale(void)
>
> capacity_scale = 1;
> for_each_possible_cpu(cpu) {
> - capacity = raw_capacity[cpu] * per_cpu(capacity_freq_ref, cpu);
> + capacity = raw_capacity[cpu] *
> + (per_cpu(capacity_freq_ref, cpu) ?: 1);
> capacity_scale = max(capacity, capacity_scale);
> }
>
> pr_debug("cpu_capacity: capacity_scale=%llu\n", capacity_scale);
> for_each_possible_cpu(cpu) {
> - capacity = raw_capacity[cpu] * per_cpu(capacity_freq_ref, cpu);
> + capacity = raw_capacity[cpu] *
> + (per_cpu(capacity_freq_ref, cpu) ?: 1);
> capacity = div64_u64(capacity << SCHED_CAPACITY_SHIFT,
> capacity_scale);
> topology_set_cpu_scale(cpu, capacity);
> --
> 2.25.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 05/64] i2c: aspeed: reword according to newest specification
From: Wolfram Sang @ 2024-04-08 8:35 UTC (permalink / raw)
To: Andi Shyti
Cc: linux-i2c, Brendan Higgins, Benjamin Herrenschmidt, Joel Stanley,
Andrew Jeffery, openbmc, linux-arm-kernel, linux-aspeed,
linux-kernel
In-Reply-To: <vb4hempklviz6w4gd3eimprplybm4ckefwz2gyy7cp2uww2anv@b4egbq4u4rrg>
[-- Attachment #1.1: Type: text/plain, Size: 1137 bytes --]
> > -static int aspeed_i2c_master_xfer(struct i2c_adapter *adap,
> > +static int aspeed_i2c_xfer(struct i2c_adapter *adap,
> > struct i2c_msg *msgs, int num)
>
> here the alignment goes a bi off.
Thanks, I missed this.
> > #if IS_ENABLED(CONFIG_I2C_SLAVE)
> > /* precondition: bus.lock has been acquired. */
> > -static void __aspeed_i2c_reg_slave(struct aspeed_i2c_bus *bus, u16 slave_addr)
> > +static void __aspeed_i2c_reg_target(struct aspeed_i2c_bus *bus, u16 slave_addr)
>
> We have the word master/slave forgotten here and there, but as
> we are here, /slave_addr/target_addr/
I can do this now. My plan was to convert it when I convert the whole
CONFIG_I2C_SLAVE interface. But "since we are here" can be argued.
> > static const struct i2c_algorithm aspeed_i2c_algo = {
> > - .master_xfer = aspeed_i2c_master_xfer,
> > + .xfer = aspeed_i2c_xfer,
>
> here the alignment goes a bit off.
I also wanted to fix this afterwards together with all the tab-indented
struct declarations in busses/. But maybe I better do the tab-removal
series beforehand? Would you accept such a thing?
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 2/3] arm64: tlb: Improve __TLBI_VADDR_RANGE()
From: Ryan Roberts @ 2024-04-08 8:31 UTC (permalink / raw)
To: Gavin Shan, linux-arm-kernel, linux-kernel
Cc: catalin.marinas, will, akpm, maz, oliver.upton, apopple, rananta,
mark.rutland, v-songbaohua, yangyicong, shahuang, yihyu,
shan.gavin
In-Reply-To: <20240405035852.1532010-3-gshan@redhat.com>
On 05/04/2024 04:58, Gavin Shan wrote:
> The macro returns the operand of TLBI RANGE instruction. A mask needs
> to be applied to each individual field upon producing the operand, to
> avoid the adjacent fields can interfere with each other when invalid
> arguments have been provided. The code looks more tidy at least with
> a mask and FIELD_PREP().
>
> Suggested-by: Marc Zyngier <maz@kernel.org>
> Signed-off-by: Gavin Shan <gshan@redhat.com>
LGTM!
Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
> ---
> arch/arm64/include/asm/tlbflush.h | 29 ++++++++++++++++++-----------
> 1 file changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
> index a75de2665d84..243d71f7bc1f 100644
> --- a/arch/arm64/include/asm/tlbflush.h
> +++ b/arch/arm64/include/asm/tlbflush.h
> @@ -142,17 +142,24 @@ static inline unsigned long get_trans_granule(void)
> * EL1, Inner Shareable".
> *
> */
> -#define __TLBI_VADDR_RANGE(baddr, asid, scale, num, ttl) \
> - ({ \
> - unsigned long __ta = (baddr); \
> - unsigned long __ttl = (ttl >= 1 && ttl <= 3) ? ttl : 0; \
> - __ta &= GENMASK_ULL(36, 0); \
> - __ta |= __ttl << 37; \
> - __ta |= (unsigned long)(num) << 39; \
> - __ta |= (unsigned long)(scale) << 44; \
> - __ta |= get_trans_granule() << 46; \
> - __ta |= (unsigned long)(asid) << 48; \
> - __ta; \
> +#define TLBIR_ASID_MASK GENMASK_ULL(63, 48)
> +#define TLBIR_TG_MASK GENMASK_ULL(47, 46)
> +#define TLBIR_SCALE_MASK GENMASK_ULL(45, 44)
> +#define TLBIR_NUM_MASK GENMASK_ULL(43, 39)
> +#define TLBIR_TTL_MASK GENMASK_ULL(38, 37)
> +#define TLBIR_BADDR_MASK GENMASK_ULL(36, 0)
> +
> +#define __TLBI_VADDR_RANGE(baddr, asid, scale, num, ttl) \
> + ({ \
> + unsigned long __ta = 0; \
> + unsigned long __ttl = (ttl >= 1 && ttl <= 3) ? ttl : 0; \
> + __ta |= FIELD_PREP(TLBIR_BADDR_MASK, baddr); \
> + __ta |= FIELD_PREP(TLBIR_TTL_MASK, __ttl); \
> + __ta |= FIELD_PREP(TLBIR_NUM_MASK, num); \
> + __ta |= FIELD_PREP(TLBIR_SCALE_MASK, scale); \
> + __ta |= FIELD_PREP(TLBIR_TG_MASK, get_trans_granule()); \
> + __ta |= FIELD_PREP(TLBIR_ASID_MASK, asid); \
> + __ta; \
> })
>
> /* These macros are used by the TLBI RANGE feature. */
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH 00/17] HSI2, UFS & UFS phy support for Tensor GS101
From: Alim Akhtar @ 2024-04-08 8:30 UTC (permalink / raw)
To: 'Peter Griffin', mturquette, sboyd, robh, krzk+dt,
conor+dt, vkoul, kishon, avri.altman, bvanassche, s.nawrocki,
cw00.choi, jejb, martin.petersen, chanho61.park, ebiggers
Cc: linux-scsi, linux-phy, devicetree, linux-clk, linux-samsung-soc,
linux-kernel, linux-arm-kernel, tudor.ambarus, andre.draszik,
saravanak, willmcvicker
In-Reply-To: <20240404122559.898930-1-peter.griffin@linaro.org>
Hi Peter
> -----Original Message-----
> From: Peter Griffin <peter.griffin@linaro.org>
> Sent: Thursday, April 4, 2024 5:56 PM
> To: mturquette@baylibre.com; sboyd@kernel.org; robh@kernel.org;
> krzk+dt@kernel.org; conor+dt@kernel.org; vkoul@kernel.org;
> kishon@kernel.org; alim.akhtar@samsung.com; avri.altman@wdc.com;
> bvanassche@acm.org; s.nawrocki@samsung.com; cw00.choi@samsung.com;
> jejb@linux.ibm.com; martin.petersen@oracle.com;
> chanho61.park@samsung.com; ebiggers@kernel.org
> Cc: linux-scsi@vger.kernel.org; linux-phy@lists.infradead.org;
> devicetree@vger.kernel.org; linux-clk@vger.kernel.org; linux-samsung-
> soc@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; tudor.ambarus@linaro.org;
> andre.draszik@linaro.org; saravanak@google.com;
> willmcvicker@google.com; Peter Griffin <peter.griffin@linaro.org>
> Subject: [PATCH 00/17] HSI2, UFS & UFS phy support for Tensor GS101
>
> Hi folks,
>
>
> Question
> ========
>
> Currently the link comes up in Gear 3 due to ufshcd_init_host_params()
> host_params initialisation. If I update that to use UFS_HS_G4 for
negotiation
> then the link come up in Gear 4. I propose (in a future patch) to use VER
> register offset 0x8 to determine whether to set G4 capability or not (if
major
> version is >= 3).
>
> The bitfield of VER register in gs101 docs is
>
> RSVD [31:16] Reserved
> MJR [15:8] Major version number
> MNR [7:4] Minor version number
> VS [3:0] Version Suffix
>
> Can anyone confirm if other Exynos platforms supported by this driver have
> the same register, and if it conforms to the bitfield described above?
>
VER (offset 0x8) is standard UFS HCI spec, so all vendor need to have this
(unless something really wrong with the HW)
Yes, Exynos and FSD SoC has these bitfield implemented.
>
> 2.44.0.478.gd926399ef9-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 1/3] arm64: tlb: Fix TLBI RANGE operand
From: Ryan Roberts @ 2024-04-08 8:29 UTC (permalink / raw)
To: Gavin Shan, linux-arm-kernel, linux-kernel
Cc: catalin.marinas, will, akpm, maz, oliver.upton, apopple, rananta,
mark.rutland, v-songbaohua, yangyicong, shahuang, yihyu,
shan.gavin
In-Reply-To: <20240405035852.1532010-2-gshan@redhat.com>
On 05/04/2024 04:58, Gavin Shan wrote:
> KVM/arm64 relies on TLBI RANGE feature to flush TLBs when the dirty
> pages are collected by VMM and the page table entries become write
> protected during live migration. Unfortunately, the operand passed
> to the TLBI RANGE instruction isn't correctly sorted out due to the
> commit 117940aa6e5f ("KVM: arm64: Define kvm_tlb_flush_vmid_range()").
> It leads to crash on the destination VM after live migration because
> TLBs aren't flushed completely and some of the dirty pages are missed.
>
> For example, I have a VM where 8GB memory is assigned, starting from
> 0x40000000 (1GB). Note that the host has 4KB as the base page size.
> In the middile of migration, kvm_tlb_flush_vmid_range() is executed
> to flush TLBs. It passes MAX_TLBI_RANGE_PAGES as the argument to
> __kvm_tlb_flush_vmid_range() and __flush_s2_tlb_range_op(). SCALE#3
> and NUM#31, corresponding to MAX_TLBI_RANGE_PAGES, isn't supported
> by __TLBI_RANGE_NUM(). In this specific case, -1 has been returned
> from __TLBI_RANGE_NUM() for SCALE#3/2/1/0 and rejected by the loop
> in the __flush_tlb_range_op() until the variable @scale underflows
> and becomes -9, 0xffff708000040000 is set as the operand. The operand
> is wrong since it's sorted out by __TLBI_VADDR_RANGE() according to
> invalid @scale and @num.
>
> Fix it by extending __TLBI_RANGE_NUM() to support the combination of
> SCALE#3 and NUM#31. With the changes, [-1 31] instead of [-1 30] can
> be returned from the macro, meaning the TLBs for 0x200000 pages in the
> above example can be flushed in one shoot with SCALE#3 and NUM#31. The
> macro TLBI_RANGE_MASK is dropped since no one uses it any more. The
> comments are also adjusted accordingly.
Perhaps I'm being overly pedantic, but I don't think the bug is
__TLBI_RANGE_NUM() not being able to return 31; It is clearly documented that it
can only return in the range [-1, 30] and a maximum of (MAX_TLBI_RANGE_PAGES -
1) pages are supported.
The bug is in the kvm caller, which tries to call __flush_tlb_range_op() with
MAX_TLBI_RANGE_PAGES; clearly out-of-bounds.
So personally, I would prefer to fix the bug first. Then separately enhance the
infrastructure to support NUM=31.
>
> Fixes: 117940aa6e5f ("KVM: arm64: Define kvm_tlb_flush_vmid_range()")
I would argue that the bug was actually introduced by commit 360839027a6e
("arm64: tlb: Refactor the core flush algorithm of __flush_tlb_range"), which
separated the tlbi loop from the range size validation in __flush_tlb_range().
Before this, all calls would have to go through __flush_tlb_range() and
therefore anything bigger than (MAX_TLBI_RANGE_PAGES - 1) pages would cause the
whole mm to be flushed. Although I get that bisect will lead to this one, so
that's probably the right one to highlight.
I get why it was split, but perhaps it should have been split at a higher level;
If tlbi range is not supported, then KVM will flush the whole vmid. Would it be
better for KVM to follow the same pattern as __flush_tlb_range_nosync() and
issue per-block tlbis upto a max of MAX_DVM_OPS before falling back to the whole
vmid? And if tlbi range is supported, KVM uses it regardless of the size of the
range, whereas __flush_tlb_range_nosync() falls back to flush_tlb_mm() at a
certain size. It's not clear why this divergence is useful?
> Cc: stable@kernel.org # v6.6+
> Reported-by: Yihuang Yu <yihyu@redhat.com>
> Suggested-by: Marc Zyngier <maz@kernel.org>
> Signed-off-by: Gavin Shan <gshan@redhat.com>
Anyway, the implementation looks correct, so:
Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
> ---
> arch/arm64/include/asm/tlbflush.h | 20 +++++++++++---------
> 1 file changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
> index 3b0e8248e1a4..a75de2665d84 100644
> --- a/arch/arm64/include/asm/tlbflush.h
> +++ b/arch/arm64/include/asm/tlbflush.h
> @@ -161,12 +161,18 @@ static inline unsigned long get_trans_granule(void)
> #define MAX_TLBI_RANGE_PAGES __TLBI_RANGE_PAGES(31, 3)
>
> /*
> - * Generate 'num' values from -1 to 30 with -1 rejected by the
> - * __flush_tlb_range() loop below.
> + * Generate 'num' values from -1 to 31 with -1 rejected by the
> + * __flush_tlb_range() loop below. Its return value is only
> + * significant for a maximum of MAX_TLBI_RANGE_PAGES pages. If
> + * 'pages' is more than that, you must iterate over the overall
> + * range.
> */
> -#define TLBI_RANGE_MASK GENMASK_ULL(4, 0)
> -#define __TLBI_RANGE_NUM(pages, scale) \
> - ((((pages) >> (5 * (scale) + 1)) & TLBI_RANGE_MASK) - 1)
> +#define __TLBI_RANGE_NUM(pages, scale) \
> + ({ \
> + int __pages = min((pages), \
> + __TLBI_RANGE_PAGES(31, (scale))); \
> + (__pages >> (5 * (scale) + 1)) - 1; \
> + })
>
> /*
> * TLB Invalidation
> @@ -379,10 +385,6 @@ static inline void arch_tlbbatch_flush(struct arch_tlbflush_unmap_batch *batch)
> * 3. If there is 1 page remaining, flush it through non-range operations. Range
> * operations can only span an even number of pages. We save this for last to
> * ensure 64KB start alignment is maintained for the LPA2 case.
> - *
> - * Note that certain ranges can be represented by either num = 31 and
> - * scale or num = 0 and scale + 1. The loop below favours the latter
> - * since num is limited to 30 by the __TLBI_RANGE_NUM() macro.
> */
> #define __flush_tlb_range_op(op, start, pages, stride, \
> asid, tlb_level, tlbi_user, lpa2) \
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v2 1/5] clk: meson: axg: move reset controller's code to separate module
From: Philipp Zabel @ 2024-04-08 8:21 UTC (permalink / raw)
To: Stephen Boyd, Jan Dakinevich, Jerome Brunet
Cc: Neil Armstrong, Michael Turquette, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kevin Hilman,
Martin Blumenstingl, linux-amlogic, linux-clk, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <e3a85852b911fdf16dd9ae158f42b3ef.sboyd@kernel.org>
On So, 2024-04-07 at 19:39 -0700, Stephen Boyd wrote:
> Quoting Jerome Brunet (2024-04-02 07:52:38)
> >
> > On Thu 28 Mar 2024 at 04:08, Jan Dakinevich <jan.dakinevich@salutedevices.com> wrote:
> >
> > > This code will by reused by A1 SoC.
> >
> > Could expand a bit please ?
> >
> > >
> > > Signed-off-by: Jan Dakinevich <jan.dakinevich@salutedevices.com>
> >
> > In general, I like the idea.
> >
> > We do have a couple a reset registers lost in middle of clocks and this
> > change makes it possible to re-use the code instead duplicating it.
> >
> > The exported function would be used by audio clock controllers, but the
> > module created would be purely about reset.
> >
> > One may wonder how it ended up in the clock tree, especially since the
> > kernel as a reset tree too.
> >
> > I'm not sure if this should move to the reset framework or if it would
> > be an unnecessary churn. Stephen, Philipp, do you have an opinion on
> > this ?
> >
>
> I'd prefer it be made into an auxiliary device and the driver put in
> drivers/reset/ so we can keep reset code in the reset directory.
Seconded, the clk-mpfs/reset-mpfs and clk-starfive-jh7110-sys/reset-
starfive-jh7110 drivers are examples of this.
> The auxiliary device creation function can also be in the
> drivers/reset/ directory so that the clk driver calls some function
> to create and register the device.
I'm undecided about this, do you think mpfs_reset_controller_register()
and jh7110_reset_controller_register() should rather live with the
reset aux drivers in drivers/reset/ ?
regards
Philipp
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: arm_pmuv3: Correctly extract and check the PMUVer
From: Yicong Yang @ 2024-04-08 8:11 UTC (permalink / raw)
To: will, mark.rutland, catalin.marinas, broonie, linux-arm-kernel,
linux-kernel
Cc: jonathan.cameron, prime.zeng, linuxarm, yangyicong
From: Yicong Yang <yangyicong@hisilicon.com>
Currently we're using "sbfx" to extract the PMUVer from ID_AA64DFR0_EL1
and skip the init/reset if no PMU present when the extracted PMUVer is
negative or is zero. However for PMUv3p8 the PMUVer will be 0b1000 and
PMUVer extracted by "sbfx" will always be negative and we'll skip the
init/reset in __init_el2_debug/reset_pmuserenr_el0 unexpectedly.
So this patch use "ubfx" instead of "sbfx" to extract the PMUVer. If
the PMUVer is implementation defined (0b1111) then reset it to zero
and skip the reset/init. Previously we'll also skip the init/reset
if the PMUVer is higher than the version we known (currently PMUv3p9),
with this patch we'll only skip if the PMU is not implemented or
implementation defined. This keeps consistence with how we probe
the PMU in the driver with pmuv3_implemented().
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
---
arch/arm64/include/asm/assembler.h | 5 ++++-
arch/arm64/include/asm/el2_setup.h | 5 ++++-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index ab8b396428da..3b7373d6c565 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -480,7 +480,10 @@ alternative_endif
*/
.macro reset_pmuserenr_el0, tmpreg
mrs \tmpreg, id_aa64dfr0_el1
- sbfx \tmpreg, \tmpreg, #ID_AA64DFR0_EL1_PMUVer_SHIFT, #4
+ ubfx \tmpreg, \tmpreg, #ID_AA64DFR0_EL1_PMUVer_SHIFT, #4
+ cmp \tmpreg, #ID_AA64DFR0_EL1_PMUVer_IMP_DEF
+ csel \tmpreg, xzr, \tmpreg, eq // If PMU's IMP_DEF, regard it
+ // as not implemented and skip
cmp \tmpreg, #1 // Skip if no PMU present
b.lt 9000f
msr pmuserenr_el0, xzr // Disable PMU access from EL0
diff --git a/arch/arm64/include/asm/el2_setup.h b/arch/arm64/include/asm/el2_setup.h
index b7afaa026842..2438e12b60c5 100644
--- a/arch/arm64/include/asm/el2_setup.h
+++ b/arch/arm64/include/asm/el2_setup.h
@@ -59,7 +59,10 @@
.macro __init_el2_debug
mrs x1, id_aa64dfr0_el1
- sbfx x0, x1, #ID_AA64DFR0_EL1_PMUVer_SHIFT, #4
+ ubfx x0, x1, #ID_AA64DFR0_EL1_PMUVer_SHIFT, #4
+ cmp x0, #ID_AA64DFR0_EL1_PMUVer_IMP_DEF
+ csel x0, xzr, x0, eq // If PMU's IMP_DEF, regard it
+ // as not implemented and skip
cmp x0, #1
b.lt .Lskip_pmu_\@ // Skip if no PMU present
mrs x0, pmcr_el0 // Disable debug access traps
--
2.24.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3 0/3] arm64: dts: hi3798cv200: fix GICR size, add cache info, maintenance irq and GICH, GICV spaces
From: Wei Xu @ 2024-04-08 8:09 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jiancheng Xue, Alex Elder, Peter Griffin,
Yang Xiwen
Cc: linux-arm-kernel, devicetree, linux-kernel, stable
In-Reply-To: <171256140981.12523.5652563259173425537.b4-ty@linaro.org>
Hi Krzysztof,
On 2024/4/8 15:31, Krzysztof Kozlowski wrote:
>
> On Mon, 19 Feb 2024 23:05:25 +0800, Yang Xiwen wrote:
>> The patchset fixes some warnings reported by the kernel during boot.
>>
>> The cache size info is from Processor_Datasheet_v2XX.pdf [1], Section
>> 2.2.1 Master Processor.
>>
>> The cache line size and the set-associative info are from Cortex-A53
>> Documentation [2].
>>
>> [...]
>
> It's rc3 and almost one month after last ping/talk, so apparently these got
> lost. I'll take them, but let me know if this should go via different tree.
>
>
> Applied, thanks!
Thanks!
Fine to me.
Best Regards,
Wei
>
> [1/3] arm64: dts: hi3798cv200: fix the size of GICR
> https://git.kernel.org/krzk/linux-dt/c/428a575dc9038846ad259466d5ba109858c0a023
> [2/3] arm64: dts: hi3798cv200: add GICH, GICV register space and irq
> https://git.kernel.org/krzk/linux-dt/c/f00a6b9644a5668e25ad9ca5aff53b6de4b0aaf6
> [3/3] arm64: dts: hi3798cv200: add cache info
> https://git.kernel.org/krzk/linux-dt/c/c7a3ad884d1dc1302dcc3295baa18917180b8bec
>
> Best regards,
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 2/2] arm64: dts: mediatek: add Kontron 3.5"-SBC-i1200
From: Michael Walle @ 2024-04-08 8:08 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Sean Wang, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Michael Walle
In-Reply-To: <20240408080816.4134370-1-mwalle@kernel.org>
Add basic support for the Kontron 3.5" single board computer featuring a
Mediatek i1200 SoC (MT8395/MT8195).
Signed-off-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
v4:
- rebase to latest next
v3:
- add vsys regulator
- correct the LDO input of the mt6360 regulator
- add missing interrupt-cells
- no underscores in node names
- dropped regulator-compatible everywhere and use the correc node name
instead
- reordered mmc0 properties
- split mmc1 pinctrl properties, add no-mmc
- removed all MTK_DRIVE_8mA
- add i2c0 and i2c1
- add comments for spi and i2c busses
- add firmware-name property for scp (this should probably go into the
base dtsi?!)
- add missing tpm compatible
- renamed thermal zones to something more meaningful
- add correct bias-pull-up to (some) i2c busses
- moved reset handling into the PHY node, also added a compatible string
for the PHY.
Mh, my memory is hazy, but IIRC I run into the same problem which was
discussed on netdev some time ago. That is, the PHY driver cannot be
probed unless it is taken out of reset. Which will only happen if you
probe it. And the workaround/advise was to use the compatible string in
that case, which is unfortunate.
Just wanted to point out, that it is *not* the same as snps,reset-*
because the latter will work just fine without the compatible. I'll
go with the compatible for now.
I did *not* add the vbus to the USB ports, not even on the front port.
That is because of:
dependencies:
connector: [ usb-role-switch ]
and we just have a simple USB3.2 USB-A connector, no dual roles. IMHO
that is a bug in the driver, which should handle the vbus supply as
optional.
v2:
- none
---
arch/arm64/boot/dts/mediatek/Makefile | 1 +
.../mediatek/mt8395-kontron-3-5-sbc-i1200.dts | 1127 +++++++++++++++++
2 files changed, 1128 insertions(+)
create mode 100644 arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dts
diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index cae5fcc7ca0c..0072ed142550 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -78,5 +78,6 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8195-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8365-evk.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8395-genio-1200-evk.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8390-genio-700-evk.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8395-kontron-3-5-sbc-i1200.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8395-radxa-nio-12l.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8516-pumpkin.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dts b/arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dts
new file mode 100644
index 000000000000..e4b2af9489a8
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dts
@@ -0,0 +1,1127 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2024 Kontron Europe GmbH
+ *
+ * Author: Michael Walle <mwalle@kernel.org>
+ */
+/dts-v1/;
+
+#include "mt8195.dtsi"
+#include "mt6359.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/mt8195-pinfunc.h>
+#include <dt-bindings/regulator/mediatek,mt6360-regulator.h>
+#include <dt-bindings/spmi/spmi.h>
+
+/ {
+ model = "Kontron 3.5\"-SBC-i1200";
+ compatible = "kontron,3-5-sbc-i1200", "mediatek,mt8395", "mediatek,mt8195";
+
+ aliases {
+ mmc0 = &mmc0;
+ mmc1 = &mmc1;
+ serial0 = &uart1;
+ serial1 = &uart2;
+ serial2 = &uart3;
+ serial3 = &uart4;
+ serial4 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ firmware {
+ optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio_keys_pins>;
+
+ key-0 {
+ gpios = <&pio 106 GPIO_ACTIVE_LOW>;
+ label = "volume_up";
+ linux,code = <KEY_VOLUMEUP>;
+ wakeup-source;
+ debounce-interval = <15>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_pins>;
+
+ led-0 {
+ gpios = <&pio 107 GPIO_ACTIVE_HIGH>;
+ default-state = "keep";
+ function = LED_FUNCTION_POWER;
+ color = <LED_COLOR_ID_GREEN>;
+ };
+ };
+
+ memory@40000000 {
+ device_type = "memory";
+ reg = <0 0x40000000 0x0 0x80000000>;
+ };
+
+ vsys: regulator-vsys {
+ compatible = "regulator-fixed";
+ regulator-name = "vsys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /*
+ * 12 MiB reserved for OP-TEE (BL32)
+ * +-----------------------+ 0x43e0_0000
+ * | SHMEM 2MiB |
+ * +-----------------------+ 0x43c0_0000
+ * | | TA_RAM 8MiB |
+ * + TZDRAM +--------------+ 0x4340_0000
+ * | | TEE_RAM 2MiB |
+ * +-----------------------+ 0x4320_0000
+ */
+ optee_reserved: optee@43200000 {
+ no-map;
+ reg = <0 0x43200000 0 0x00c00000>;
+ };
+
+ scp_mem: memory@50000000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x50000000 0 0x2900000>;
+ no-map;
+ };
+
+ vpu_mem: memory@53000000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x53000000 0 0x1400000>; /* 20 MB */
+ };
+
+ /* 2 MiB reserved for ARM Trusted Firmware (BL31) */
+ bl31_secmon_mem: memory@54600000 {
+ no-map;
+ reg = <0 0x54600000 0x0 0x200000>;
+ };
+
+ snd_dma_mem: memory@60000000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x60000000 0 0x1100000>;
+ no-map;
+ };
+
+ apu_mem: memory@62000000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x62000000 0 0x1400000>; /* 20 MB */
+ };
+ };
+
+ thermal_sensor0: thermal-sensor-0 {
+ compatible = "generic-adc-thermal";
+ #thermal-sensor-cells = <0>;
+ io-channels = <&auxadc 0>;
+ io-channel-names = "sensor-channel";
+ temperature-lookup-table = <(-25000) 1474
+ (-20000) 1374
+ (-15000) 1260
+ (-10000) 1134
+ (-5000) 1004
+ 0 874
+ 5000 750
+ 10000 635
+ 15000 532
+ 20000 443
+ 25000 367
+ 30000 303
+ 35000 250
+ 40000 206
+ 45000 170
+ 50000 141
+ 55000 117
+ 60000 97
+ 65000 81
+ 70000 68
+ 75000 57
+ 80000 48
+ 85000 41
+ 90000 35
+ 95000 30
+ 100000 25
+ 105000 22
+ 110000 19
+ 115000 16
+ 120000 14
+ 125000 12
+ 130000 10
+ 135000 9
+ 140000 8
+ 145000 7
+ 150000 6>;
+ };
+
+ thermal_sensor1: thermal-sensor-1 {
+ compatible = "generic-adc-thermal";
+ #thermal-sensor-cells = <0>;
+ io-channels = <&auxadc 1>;
+ io-channel-names = "sensor-channel";
+ temperature-lookup-table = <(-25000) 1474
+ (-20000) 1374
+ (-15000) 1260
+ (-10000) 1134
+ (-5000) 1004
+ 0 874
+ 5000 750
+ 10000 635
+ 15000 532
+ 20000 443
+ 25000 367
+ 30000 303
+ 35000 250
+ 40000 206
+ 45000 170
+ 50000 141
+ 55000 117
+ 60000 97
+ 65000 81
+ 70000 68
+ 75000 57
+ 80000 48
+ 85000 41
+ 90000 35
+ 95000 30
+ 100000 25
+ 105000 22
+ 110000 19
+ 115000 16
+ 120000 14
+ 125000 12
+ 130000 10
+ 135000 9
+ 140000 8
+ 145000 7
+ 150000 6>;
+ };
+
+ thermal_sensor2: thermal-sensor-2 {
+ compatible = "generic-adc-thermal";
+ #thermal-sensor-cells = <0>;
+ io-channels = <&auxadc 2>;
+ io-channel-names = "sensor-channel";
+ temperature-lookup-table = <(-25000) 1474
+ (-20000) 1374
+ (-15000) 1260
+ (-10000) 1134
+ (-5000) 1004
+ 0 874
+ 5000 750
+ 10000 635
+ 15000 532
+ 20000 443
+ 25000 367
+ 30000 303
+ 35000 250
+ 40000 206
+ 45000 170
+ 50000 141
+ 55000 117
+ 60000 97
+ 65000 81
+ 70000 68
+ 75000 57
+ 80000 48
+ 85000 41
+ 90000 35
+ 95000 30
+ 100000 25
+ 105000 22
+ 110000 19
+ 115000 16
+ 120000 14
+ 125000 12
+ 130000 10
+ 135000 9
+ 140000 8
+ 145000 7
+ 150000 6>;
+ };
+};
+
+&auxadc {
+ status = "okay";
+};
+
+ð {
+ phy-mode ="rgmii-id";
+ phy-handle = <ðernet_phy0>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <ð_default_pins>;
+ pinctrl-1 = <ð_sleep_pins>;
+ status = "okay";
+
+ mdio {
+ ethernet_phy0: ethernet-phy@1 {
+ compatible = "ethernet-phy-id001c.c916";
+ reg = <0x1>;
+ interrupts-extended = <&pio 94 IRQ_TYPE_LEVEL_LOW>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <80000>;
+ reset-gpios = <&pio 93 GPIO_ACTIVE_HIGH>;
+ };
+ };
+};
+
+&gpu {
+ status = "okay";
+ mali-supply = <&mt6315_7_vbuck1>;
+};
+
+/* CSI1/CSI2 connector */
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+ clock-frequency = <100000>;
+ status = "okay";
+};
+
+/* CSI3 connector */
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins>;
+ clock-frequency = <100000>;
+ status = "okay";
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins>;
+ clock-frequency = <400000>;
+ status = "okay";
+
+ /* LVDS bridge @f */
+};
+
+/* Touch panel connector */
+&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c3_pins>;
+ clock-frequency = <100000>;
+ status = "okay";
+};
+
+/* B2B connector */
+&i2c4 {
+ clock-frequency = <100000>;
+ pinctrl-0 = <&i2c4_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&i2c6 {
+ clock-frequency = <400000>;
+ pinctrl-0 = <&i2c6_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ mt6360: pmic@34 {
+ compatible = "mediatek,mt6360";
+ reg = <0x34>;
+ interrupt-controller;
+ interrupts-extended = <&pio 101 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-names = "IRQB";
+ #interrupt-cells = <1>;
+
+ regulator {
+ compatible = "mediatek,mt6360-regulator";
+ LDO_VIN1-supply = <&vsys>;
+ LDO_VIN2-supply = <&vsys>;
+ LDO_VIN3-supply = <&vsys>;
+
+ mt6360_buck1: BUCK1 {
+ regulator-name = "emi_vdd2";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-allowed-modes = <MT6360_OPMODE_NORMAL
+ MT6360_OPMODE_LP
+ MT6360_OPMODE_ULP>;
+ regulator-always-on;
+ };
+
+ mt6360_buck2: BUCK2 {
+ regulator-name = "emi_vddq";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-allowed-modes = <MT6360_OPMODE_NORMAL
+ MT6360_OPMODE_LP
+ MT6360_OPMODE_ULP>;
+ regulator-always-on;
+ };
+
+ mt6360_ldo1: LDO1 {
+ regulator-name = "mt6360_ldo1"; /* Test point */
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3600000>;
+ regulator-allowed-modes = <MT6360_OPMODE_NORMAL
+ MT6360_OPMODE_LP>;
+ };
+
+ mt6360_ldo2: LDO2 {
+ regulator-name = "panel1_p1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-allowed-modes = <MT6360_OPMODE_NORMAL
+ MT6360_OPMODE_LP>;
+ };
+
+ mt6360_ldo3: LDO3 {
+ regulator-name = "vmc_pmu";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-allowed-modes = <MT6360_OPMODE_NORMAL
+ MT6360_OPMODE_LP>;
+ };
+
+ mt6360_ldo5: LDO5 {
+ regulator-name = "vmch_pmu";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-allowed-modes = <MT6360_OPMODE_NORMAL
+ MT6360_OPMODE_LP>;
+ };
+
+ mt6360_ldo6: LDO6 {
+ regulator-name = "mt6360_ldo6"; /* Test point */
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <2100000>;
+ regulator-allowed-modes = <MT6360_OPMODE_NORMAL
+ MT6360_OPMODE_LP>;
+ };
+
+ mt6360_ldo7: LDO7 {
+ regulator-name = "emi_vmddr_en";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-allowed-modes = <MT6360_OPMODE_NORMAL
+ MT6360_OPMODE_LP>;
+ regulator-always-on;
+ };
+ };
+ };
+};
+
+&mmc0 {
+ pinctrl-names = "default", "state_uhs";
+ pinctrl-0 = <&mmc0_default_pins>;
+ pinctrl-1 = <&mmc0_uhs_pins>;
+ bus-width = <8>;
+ max-frequency = <200000000>;
+ hs400-ds-delay = <0x14c11>;
+ cap-mmc-highspeed;
+ cap-mmc-hw-reset;
+ mmc-hs200-1_8v;
+ mmc-hs400-1_8v;
+ no-sdio;
+ no-sd;
+ non-removable;
+ vmmc-supply = <&mt6359_vemc_1_ldo_reg>;
+ vqmmc-supply = <&mt6359_vufs_ldo_reg>;
+ status = "okay";
+};
+
+&mmc1 {
+ pinctrl-names = "default", "state_uhs";
+ pinctrl-0 = <&mmc1_default_pins>, <&mmc1_detect_pins>;
+ pinctrl-1 = <&mmc1_default_pins>;
+ cd-gpios = <&pio 129 GPIO_ACTIVE_LOW>;
+ bus-width = <4>;
+ max-frequency = <200000000>;
+ cap-sd-highspeed;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ no-mmc;
+ vmmc-supply = <&mt6360_ldo5>;
+ vqmmc-supply = <&mt6360_ldo3>;
+ status = "okay";
+};
+
+&mt6359_vbbck_ldo_reg {
+ regulator-always-on;
+};
+
+&mt6359_vcore_buck_reg {
+ regulator-always-on;
+};
+
+&mt6359_vgpu11_buck_reg {
+ regulator-always-on;
+};
+
+&mt6359_vproc1_buck_reg {
+ regulator-always-on;
+};
+
+&mt6359_vproc2_buck_reg {
+ regulator-always-on;
+};
+
+&mt6359_vpu_buck_reg {
+ regulator-always-on;
+};
+
+&mt6359_vrf12_ldo_reg {
+ regulator-always-on;
+};
+
+&mt6359_vsram_md_ldo_reg {
+ regulator-always-on;
+};
+
+&mt6359_vsram_others_ldo_reg {
+ regulator-always-on;
+};
+
+&nor_flash {
+ pinctrl-names = "default";
+ pinctrl-0 = <&nor_pins_default>;
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <52000000>;
+ spi-rx-bus-width = <2>;
+ spi-tx-bus-width = <2>;
+ };
+};
+
+&pcie0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie0_pins_default>;
+ status = "okay";
+};
+
+&pcie1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie1_pins_default>;
+ status = "okay";
+};
+
+&pciephy {
+ status = "okay";
+};
+
+&pio {
+ eth_default_pins: eth-default-pins {
+ pins-txd {
+ pinmux = <PINMUX_GPIO77__FUNC_GBE_TXD3>,
+ <PINMUX_GPIO78__FUNC_GBE_TXD2>,
+ <PINMUX_GPIO79__FUNC_GBE_TXD1>,
+ <PINMUX_GPIO80__FUNC_GBE_TXD0>;
+ drive-strength = <8>;
+ };
+
+ pins-rxd {
+ pinmux = <PINMUX_GPIO81__FUNC_GBE_RXD3>,
+ <PINMUX_GPIO82__FUNC_GBE_RXD2>,
+ <PINMUX_GPIO83__FUNC_GBE_RXD1>,
+ <PINMUX_GPIO84__FUNC_GBE_RXD0>;
+ };
+
+ pins-cc {
+ pinmux = <PINMUX_GPIO85__FUNC_GBE_TXC>,
+ <PINMUX_GPIO86__FUNC_GBE_RXC>,
+ <PINMUX_GPIO87__FUNC_GBE_RXDV>,
+ <PINMUX_GPIO88__FUNC_GBE_TXEN>;
+ drive-strength = <8>;
+ };
+
+ pins-mdio {
+ pinmux = <PINMUX_GPIO89__FUNC_GBE_MDC>,
+ <PINMUX_GPIO90__FUNC_GBE_MDIO>;
+ input-enable;
+ };
+
+ pins-power {
+ pinmux = <PINMUX_GPIO91__FUNC_GPIO91>,
+ <PINMUX_GPIO92__FUNC_GPIO92>;
+ output-high;
+ };
+
+ pins-reset {
+ pinmux = <PINMUX_GPIO93__FUNC_GPIO93>;
+ output-high;
+ };
+
+ pins-interrupt {
+ pinmux = <PINMUX_GPIO94__FUNC_GPIO94>;
+ input-enable;
+ };
+ };
+
+ eth_sleep_pins: eth-sleep-pins {
+ pins-txd {
+ pinmux = <PINMUX_GPIO77__FUNC_GPIO77>,
+ <PINMUX_GPIO78__FUNC_GPIO78>,
+ <PINMUX_GPIO79__FUNC_GPIO79>,
+ <PINMUX_GPIO80__FUNC_GPIO80>;
+ };
+
+ pins-cc {
+ pinmux = <PINMUX_GPIO85__FUNC_GPIO85>,
+ <PINMUX_GPIO88__FUNC_GPIO88>,
+ <PINMUX_GPIO87__FUNC_GPIO87>,
+ <PINMUX_GPIO86__FUNC_GPIO86>;
+ };
+
+ pins-rxd {
+ pinmux = <PINMUX_GPIO81__FUNC_GPIO81>,
+ <PINMUX_GPIO82__FUNC_GPIO82>,
+ <PINMUX_GPIO83__FUNC_GPIO83>,
+ <PINMUX_GPIO84__FUNC_GPIO84>;
+ };
+
+ pins-mdio {
+ pinmux = <PINMUX_GPIO89__FUNC_GPIO89>,
+ <PINMUX_GPIO90__FUNC_GPIO90>;
+ input-disable;
+ bias-disable;
+ };
+ };
+
+ gpio_keys_pins: gpio-keys-pins {
+ pins {
+ pinmux = <PINMUX_GPIO106__FUNC_GPIO106>;
+ input-enable;
+ };
+ };
+
+ i2c0_pins: i2c0-pins {
+ pins {
+ pinmux = <PINMUX_GPIO8__FUNC_SDA0>,
+ <PINMUX_GPIO9__FUNC_SCL0>;
+ bias-pull-up = <MTK_PULL_SET_RSEL_111>;
+ drive-strength-microamp = <1000>;
+ };
+ };
+
+ i2c1_pins: i2c1-pins {
+ pins {
+ pinmux = <PINMUX_GPIO10__FUNC_SDA1>,
+ <PINMUX_GPIO11__FUNC_SCL1>;
+ bias-pull-up = <MTK_PULL_SET_RSEL_111>;
+ drive-strength-microamp = <1000>;
+ };
+ };
+
+ i2c2_pins: i2c2-default-pins {
+ pins-bus {
+ pinmux = <PINMUX_GPIO12__FUNC_SDA2>,
+ <PINMUX_GPIO13__FUNC_SCL2>;
+ bias-pull-up = <MTK_PULL_SET_RSEL_111>;
+ drive-strength-microamp = <1000>;
+ };
+ };
+
+ i2c3_pins: i2c3-pins {
+ pins {
+ pinmux = <PINMUX_GPIO14__FUNC_SDA3>,
+ <PINMUX_GPIO15__FUNC_SCL3>;
+ bias-pull-up = <MTK_PULL_SET_RSEL_111>;
+ drive-strength-microamp = <1000>;
+ };
+ };
+
+ i2c4_pins: i2c4-pins {
+ pins {
+ pinmux = <PINMUX_GPIO16__FUNC_SDA4>,
+ <PINMUX_GPIO17__FUNC_SCL4>;
+ bias-pull-up = <MTK_PULL_SET_RSEL_111>;
+ drive-strength-microamp = <1000>;
+ };
+ };
+
+ i2c6_pins: i2c6-pins {
+ pins {
+ pinmux = <PINMUX_GPIO25__FUNC_SDA6>,
+ <PINMUX_GPIO26__FUNC_SCL6>;
+ bias-pull-up;
+ drive-strength-microamp = <1000>;
+ };
+ };
+
+ mmc0_default_pins: mmc0-default-pins {
+ pins-clk {
+ pinmux = <PINMUX_GPIO122__FUNC_MSDC0_CLK>;
+ drive-strength = <6>;
+ bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
+ };
+
+ pins-cmd-dat {
+ pinmux = <PINMUX_GPIO126__FUNC_MSDC0_DAT0>,
+ <PINMUX_GPIO125__FUNC_MSDC0_DAT1>,
+ <PINMUX_GPIO124__FUNC_MSDC0_DAT2>,
+ <PINMUX_GPIO123__FUNC_MSDC0_DAT3>,
+ <PINMUX_GPIO119__FUNC_MSDC0_DAT4>,
+ <PINMUX_GPIO118__FUNC_MSDC0_DAT5>,
+ <PINMUX_GPIO117__FUNC_MSDC0_DAT6>,
+ <PINMUX_GPIO116__FUNC_MSDC0_DAT7>,
+ <PINMUX_GPIO121__FUNC_MSDC0_CMD>;
+ input-enable;
+ drive-strength = <6>;
+ bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
+ };
+
+ pins-rst {
+ pinmux = <PINMUX_GPIO120__FUNC_MSDC0_RSTB>;
+ drive-strength = <6>;
+ bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
+ };
+ };
+
+ mmc0_uhs_pins: mmc0-uhs-pins {
+ pins-clk {
+ pinmux = <PINMUX_GPIO122__FUNC_MSDC0_CLK>;
+ drive-strength = <8>;
+ bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
+ };
+
+ pins-cmd-dat {
+ pinmux = <PINMUX_GPIO126__FUNC_MSDC0_DAT0>,
+ <PINMUX_GPIO125__FUNC_MSDC0_DAT1>,
+ <PINMUX_GPIO124__FUNC_MSDC0_DAT2>,
+ <PINMUX_GPIO123__FUNC_MSDC0_DAT3>,
+ <PINMUX_GPIO119__FUNC_MSDC0_DAT4>,
+ <PINMUX_GPIO118__FUNC_MSDC0_DAT5>,
+ <PINMUX_GPIO117__FUNC_MSDC0_DAT6>,
+ <PINMUX_GPIO116__FUNC_MSDC0_DAT7>,
+ <PINMUX_GPIO121__FUNC_MSDC0_CMD>;
+ input-enable;
+ drive-strength = <8>;
+ bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
+ };
+
+ pins-ds {
+ pinmux = <PINMUX_GPIO127__FUNC_MSDC0_DSL>;
+ drive-strength = <8>;
+ bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
+ };
+
+ pins-rst {
+ pinmux = <PINMUX_GPIO120__FUNC_MSDC0_RSTB>;
+ drive-strength = <8>;
+ bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
+ };
+ };
+
+ mmc1_default_pins: mmc1-default-pins {
+ pins-clk {
+ pinmux = <PINMUX_GPIO111__FUNC_MSDC1_CLK>;
+ drive-strength = <8>;
+ bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
+ };
+
+ pins-cmd-dat {
+ pinmux = <PINMUX_GPIO110__FUNC_MSDC1_CMD>,
+ <PINMUX_GPIO112__FUNC_MSDC1_DAT0>,
+ <PINMUX_GPIO113__FUNC_MSDC1_DAT1>,
+ <PINMUX_GPIO114__FUNC_MSDC1_DAT2>,
+ <PINMUX_GPIO115__FUNC_MSDC1_DAT3>;
+ input-enable;
+ drive-strength = <8>;
+ bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
+ };
+ };
+
+ mmc1_detect_pins: mmc1-detect-pins {
+ pins-insert {
+ pinmux = <PINMUX_GPIO129__FUNC_GPIO129>;
+ bias-pull-up;
+ };
+ };
+
+ nor_pins_default: nor-default-pins {
+ pins-ck-io {
+ pinmux = <PINMUX_GPIO142__FUNC_SPINOR_IO0>,
+ <PINMUX_GPIO141__FUNC_SPINOR_CK>,
+ <PINMUX_GPIO143__FUNC_SPINOR_IO1>;
+ drive-strength = <6>;
+ bias-pull-down;
+ };
+
+ pins-cs {
+ pinmux = <PINMUX_GPIO140__FUNC_SPINOR_CS>;
+ drive-strength = <6>;
+ bias-pull-up;
+ };
+ };
+
+ pcie0_pins_default: pcie0-default-pins {
+ pins-bus {
+ pinmux = <PINMUX_GPIO19__FUNC_WAKEN>,
+ <PINMUX_GPIO20__FUNC_PERSTN>,
+ <PINMUX_GPIO21__FUNC_CLKREQN>;
+ bias-pull-up;
+ };
+ };
+
+ pcie1_pins_default: pcie1-default-pins {
+ pins-bus {
+ pinmux = <PINMUX_GPIO0__FUNC_PERSTN_1>,
+ <PINMUX_GPIO1__FUNC_CLKREQN_1>,
+ <PINMUX_GPIO2__FUNC_WAKEN_1>;
+ bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
+ };
+ };
+
+ led_pins: led-pins {
+ pins-power-en {
+ pinmux = <PINMUX_GPIO107__FUNC_GPIO107>;
+ output-high;
+ };
+ };
+
+ spi0_pins: spi0-default-pins {
+ pins-cs-mosi-clk {
+ pinmux = <PINMUX_GPIO132__FUNC_SPIM0_CSB>,
+ <PINMUX_GPIO134__FUNC_SPIM0_MO>,
+ <PINMUX_GPIO133__FUNC_SPIM0_CLK>;
+ bias-disable;
+ };
+
+ pins-miso {
+ pinmux = <PINMUX_GPIO135__FUNC_SPIM0_MI>;
+ bias-pull-down;
+ };
+ };
+
+ spi1_pins: spi1-default-pins {
+ pins-cs-mosi-clk {
+ pinmux = <PINMUX_GPIO136__FUNC_SPIM1_CSB>,
+ <PINMUX_GPIO138__FUNC_SPIM1_MO>,
+ <PINMUX_GPIO137__FUNC_SPIM1_CLK>;
+ bias-disable;
+ };
+
+ pins-miso {
+ pinmux = <PINMUX_GPIO139__FUNC_SPIM1_MI>;
+ bias-pull-down;
+ };
+ };
+
+ uart0_pins: uart0-pins {
+ pins-rx {
+ pinmux = <PINMUX_GPIO99__FUNC_URXD0>;
+ input-enable;
+ bias-pull-up;
+ };
+
+ pins-tx {
+ pinmux = <PINMUX_GPIO98__FUNC_UTXD0>;
+ };
+ };
+
+ uart1_pins: uart1-pins {
+ pins-rx {
+ pinmux = <PINMUX_GPIO103__FUNC_URXD1>;
+ input-enable;
+ bias-pull-up;
+ };
+
+ pins-tx {
+ pinmux = <PINMUX_GPIO102__FUNC_UTXD1>;
+ };
+
+ pins-rts {
+ pinmux = <PINMUX_GPIO100__FUNC_URTS1>;
+ };
+
+ pins-cts {
+ pinmux = <PINMUX_GPIO101__FUNC_UCTS1>;
+ input-enable;
+ };
+ };
+
+ uart2_pins: uart2-pins {
+ pins-rx {
+ pinmux = <PINMUX_GPIO68__FUNC_URXD2>;
+ input-enable;
+ bias-pull-up;
+ };
+
+ pins-tx {
+ pinmux = <PINMUX_GPIO67__FUNC_UTXD2>;
+ };
+
+ pins-rts {
+ pinmux = <PINMUX_GPIO66__FUNC_URTS2>;
+ };
+
+ pins-cts {
+ pinmux = <PINMUX_GPIO65__FUNC_UCTS2>;
+ input-enable;
+ };
+ };
+
+ uart3_pins: uart3-pins {
+ pins-rx {
+ pinmux = <PINMUX_GPIO5__FUNC_URXD3>;
+ input-enable;
+ bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
+ };
+
+ pins-tx {
+ pinmux = <PINMUX_GPIO4__FUNC_UTXD3>;
+ };
+ };
+
+ uart4_pins: uart4-pins {
+ pins-rx {
+ pinmux = <PINMUX_GPIO7__FUNC_URXD4>;
+ input-enable;
+ bias-pull-up;
+ };
+
+ pins-tx {
+ pinmux = <PINMUX_GPIO6__FUNC_UTXD4>;
+ };
+ };
+};
+
+&pmic {
+ interrupts-extended = <&pio 222 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&scp {
+ memory-region = <&scp_mem>;
+ firmware-name = "mediatek/mt8195/scp.img";
+ status = "okay";
+};
+
+&spmi {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ mt6315@6 {
+ compatible = "mediatek,mt6315-regulator";
+ reg = <0x6 SPMI_USID>;
+
+ regulators {
+ mt6315_6_vbuck1: vbuck1 {
+ regulator-name = "Vbcpu";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1193750>;
+ regulator-enable-ramp-delay = <256>;
+ regulator-ramp-delay = <6250>;
+ regulator-allowed-modes = <0 1 2>;
+ regulator-always-on;
+ };
+ };
+ };
+
+ mt6315@7 {
+ compatible = "mediatek,mt6315-regulator";
+ reg = <0x7 SPMI_USID>;
+
+ regulators {
+ mt6315_7_vbuck1: vbuck1 {
+ regulator-name = "Vgpu";
+ regulator-min-microvolt = <625000>;
+ regulator-max-microvolt = <1193750>;
+ regulator-enable-ramp-delay = <256>;
+ regulator-ramp-delay = <6250>;
+ regulator-allowed-modes = <0 1 2>;
+ regulator-always-on;
+ };
+ };
+ };
+};
+
+/* USB3.2 front port */
+&ssusb0 {
+ dr_mode = "host";
+ vusb33-supply = <&mt6359_vusb_ldo_reg>;
+ status = "okay";
+};
+
+/* USB2.0 M.2 Key-E */
+&ssusb2 {
+ vusb33-supply = <&mt6359_vusb_ldo_reg>;
+ status = "okay";
+};
+
+/* USB2.0 to on-board usb hub */
+&ssusb3 {
+ vusb33-supply = <&mt6359_vusb_ldo_reg>;
+ status = "okay";
+};
+
+&spi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_pins>;
+ mediatek,pad-select = <0>;
+ status = "okay";
+
+ tpm: tpm@0 {
+ compatible = "infineon,slb9670", "tcg,tpm_tis-spi";
+ reg = <0>;
+ spi-max-frequency = <18500000>;
+ };
+};
+
+/* B2B connector */
+&spi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi1_pins>;
+ mediatek,pad-select = <0>;
+ status = "okay";
+};
+
+&thermal_zones {
+ cpu-thermal {
+ polling-delay = <1000>; /* milliseconds */
+ polling-delay-passive = <0>; /* milliseconds */
+ thermal-sensors = <&thermal_sensor0>;
+
+ trips {
+ trip-alert {
+ temperature = <85000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ trip-crit {
+ temperature = <95000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+
+ pcb-top-thermal {
+ polling-delay = <1000>; /* milliseconds */
+ polling-delay-passive = <0>; /* milliseconds */
+ thermal-sensors = <&thermal_sensor1>;
+
+ trips {
+ trip-alert {
+ temperature = <75000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ trip-crit {
+ temperature = <85000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+
+ pcb-bottom-thermal {
+ polling-delay = <1000>; /* milliseconds */
+ polling-delay-passive = <0>; /* milliseconds */
+ thermal-sensors = <&thermal_sensor2>;
+
+ trips {
+ trip-alert {
+ temperature = <75000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ trip-crit {
+ temperature = <85000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>;
+ uart-has-rtscts;
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2_pins>;
+ uart-has-rtscts;
+ status = "okay";
+};
+
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart3_pins>;
+ status = "okay";
+};
+
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart4_pins>;
+ status = "okay";
+};
+
+/* USB3 */
+&u3phy0 {
+ status = "okay";
+};
+
+/* PCIe1/USB2 */
+&u3phy1 {
+ status = "okay";
+};
+
+/* USB2 */
+&u3phy2 {
+ status = "okay";
+};
+
+/* USB2 */
+&u3phy3 {
+ status = "okay";
+};
+
+/* USB3.2 front port */
+&xhci0 {
+ status = "okay";
+};
+
+/* USB2.0 M.2 Key-B */
+&xhci1 {
+ vusb33-supply = <&mt6359_vusb_ldo_reg>;
+ mediatek,u3p-dis-msk = <0x01>;
+ status = "okay";
+};
+
+/* USB2.0 M.2 Key-E */
+&xhci2 {
+ status = "okay";
+};
+
+/* USB2.0 to on-board usb hub */
+&xhci3 {
+ status = "okay";
+};
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 1/2] dt-bindings: arm64: mediatek: add Kontron 3.5"-SBC-i1200
From: Michael Walle @ 2024-04-08 8:08 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Sean Wang, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Michael Walle, Conor Dooley
Add the compatible string for the Kontron 3.5"-SBC-i1200 single board
computer.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
v4:
- rebase to latest next
v3:
- drop description and add to mt8395 existing entry
v2:
- convert enum to const as there is only one specific board
---
Documentation/devicetree/bindings/arm/mediatek.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index d986b160fed1..72be45853fe0 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -359,6 +359,7 @@ properties:
- const: mediatek,mt8188
- items:
- enum:
+ - kontron,3-5-sbc-i1200
- mediatek,mt8395-evk
- radxa,nio-12l
- const: mediatek,mt8395
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2] ASoC: dt-bindings: imx-audio-spdif: convert to YAML
From: Shengjiu Wang @ 2024-04-08 8:01 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Shengjiu Wang, lgirdwood, broonie, robh+dt,
krzysztof.kozlowski+dt, conor+dt, linux-sound, devicetree,
linux-kernel, shawnguo, s.hauer, kernel, festevam, imx,
linux-arm-kernel
In-Reply-To: <01734d96-bed2-4f7e-bbba-7068f14c822b@linaro.org>
On Mon, Apr 8, 2024 at 3:55 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 08/04/2024 09:27, Shengjiu Wang wrote:
> > Convert the imx-audio-spdif binding to YAML.
> >
> > When testing dtbs_check, found below compatible strings
> > are not listed in document:
> >
> > fsl,imx-sabreauto-spdif
> > fsl,imx6sx-sdb-spdif
> >
> > So add them in yaml file to pass the test.
> >
> > Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> > ---
> > changes in v2:
> > - change file name to imx-spdif.yaml
>
> How does your compatible look like? fsl,imx-audio-spdif, so use that.
Oh, it seems I misunderstood your meaning. you think the name should
be the same as compatible string...
>
> > - remove |
> > - add anyof for spdif-in and spdif-out requirement
> > - change example name to sound
> >
>
> > diff --git a/Documentation/devicetree/bindings/sound/imx-spdif.yaml b/Documentation/devicetree/bindings/sound/imx-spdif.yaml
> > new file mode 100644
> > index 000000000000..beb214b51a50
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/sound/imx-spdif.yaml
> > @@ -0,0 +1,70 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/sound/imx-spdif.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Freescale i.MX audio complex with S/PDIF transceiver
> > +
> > +maintainers:
> > + - Shengjiu Wang <shengjiu.wang@nxp.com>
> > +
> > +properties:
> > + compatible:
> > + oneOf:
> > + - items:
> > + - enum:
> > + - fsl,imx-audio-spdif> + - enum:
> > + - fsl,imx-sabreauto-spdif
> > + - fsl,imx6sx-sdb-spdif
>
> This does not make much sense. You have mixed fallback with specific
> compatible. I suggest you to fix your DTS and submit proper bindings.
ok.
>
> > + - enum:
> > + - fsl,imx-audio-spdif
> > +
> > + model:
> > + $ref: /schemas/types.yaml#/definitions/string
> > + description: User specified audio sound card name
> > +
> > + spdif-controller:
> > + $ref: /schemas/types.yaml#/definitions/phandle
> > + description: The phandle of the i.MX S/PDIF controller
> > +
> > + spdif-out:
> > + type: boolean
> > + description:
> > + If present, the transmitting function of S/PDIF will be enabled,
> > + indicating there's a physical S/PDIF out connector or jack on the
> > + board or it's connecting to some other IP block, such as an HDMI
> > + encoder or display-controller.
> > +
> > + spdif-in:
> > + type: boolean
> > + description:
> > + If present, the receiving function of S/PDIF will be enabled,
> > + indicating there is a physical S/PDIF in connector/jack on the board.
> > +
> > +required:
> > + - compatible
> > + - model
> > + - spdif-controller
> > +
> > +anyOf:
> > + - required:
> > + - spdif-in
> > + - required:
> > + - spdif-out
> > + - required:
> > + - spdif-out
> > + - spdif-in
>
> Do you need the last required block?
Yes, one of them or both are required.
>
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + sound {
>
> That's a random change...
>
> Instead of sending two patches per day, please carefully address the
> feedback.
In v1 you suggest to change it to spdif? but spdif may conflict
with the fsl,spdif.yaml. so which name I should use?
best regards
wang shengjiu
>
> > + compatible = "fsl,imx-audio-spdif";
> > + model = "imx-spdif";
> > + spdif-controller = <&spdif>;
> > + spdif-out;
> > + spdif-in;
> > + };
>
> Best regards,
> Krzysztof
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 1/2] media: dt-bindings: nxp,imx8-jpeg:: Add clocks entries
From: Mirela Rabulea @ 2024-04-08 7:58 UTC (permalink / raw)
To: shawnguo, robh+dt, krzysztof.kozlowski+dt, festevam, festevam,
alexander.stein, Frank.li, ming.qian
Cc: conor+dt, devicetree, linux-arm-kernel, s.hauer, kernel, mchehab,
hverkuil, linux-media, imx, linux-kernel
From: Fabio Estevam <festevam@gmail.com>
The JPEG decoder/encoder present in iMX8QXP and iMX8QM SoCs need
the PER and IPG clocks to be functional, so add the clock entries.
This also fixes the following schema warning:
imx8qm-apalis-eval.dtb: jpegdec@58400000: 'assigned-clock-rates', 'assigned-clocks', 'clock-names', 'clocks' do not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/media/nxp,imx8-jpeg.yaml#
Signed-off-by: Fabio Estevam <festevam@denx.de>
Signed-off-by: Mirela Rabulea <mirela.rabulea@nxp.com>
---
Changes since v4:
- Remove redundant description and update subject prefix (per Krzysztof's feddback)
Changes since v3:
- Add items for clocks (per Krzysztof's feddback)
- Add description for clocks (per Conor's feddback to the other similar patch from Alexander)
- Add "media:" to the subject
- Add Mirela's signed-off
- For the similar patches that were sent for this issue, should Co-developed-by/Signed-off-by be added? Alexander Stein? Frank Li?
Changes since v2:
- Remove clock-names. (Mirela)
.../devicetree/bindings/media/nxp,imx8-jpeg.yaml | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml b/Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml
index 3d9d1db37040..2be30c5fdc83 100644
--- a/Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml
+++ b/Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml
@@ -31,6 +31,11 @@ properties:
reg:
maxItems: 1
+ clocks:
+ items:
+ - description: AXI DMA engine clock for fetching JPEG bitstream from memory (per)
+ - description: IP bus clock for register access (ipg)
+
interrupts:
description: |
There are 4 slots available in the IP, which the driver may use
@@ -49,6 +54,7 @@ properties:
required:
- compatible
- reg
+ - clocks
- interrupts
- power-domains
@@ -56,12 +62,15 @@ additionalProperties: false
examples:
- |
+ #include <dt-bindings/clock/imx8-lpcg.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/firmware/imx/rsrc.h>
jpegdec: jpegdec@58400000 {
compatible = "nxp,imx8qxp-jpgdec";
reg = <0x58400000 0x00050000 >;
+ clocks = <&img_jpeg_dec_lpcg IMX_LPCG_CLK_0>,
+ <&img_jpeg_dec_lpcg IMX_LPCG_CLK_4>;
interrupts = <GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH>,
@@ -76,6 +85,8 @@ examples:
jpegenc: jpegenc@58450000 {
compatible = "nxp,imx8qm-jpgenc", "nxp,imx8qxp-jpgenc";
reg = <0x58450000 0x00050000 >;
+ clocks = <&img_jpeg_enc_lpcg IMX_LPCG_CLK_0>,
+ <&img_jpeg__lpcg IMX_LPCG_CLK_4>;
interrupts = <GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 306 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 307 IRQ_TYPE_LEVEL_HIGH>,
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] dt-bindings: pwm: mediatek,pwm-disp: Document power-domains property
From: Uwe Kleine-König @ 2024-04-08 7:56 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: robh, krzysztof.kozlowski+dt, conor+dt, matthias.bgg, jitao.shi,
thierry.reding, miles.chen, xinlei.lee, linux-pwm, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, wenst, kernel
In-Reply-To: <20240404081808.92199-1-angelogioacchino.delregno@collabora.com>
[-- Attachment #1.1: Type: text/plain, Size: 846 bytes --]
Hello,
On Thu, Apr 04, 2024 at 10:18:08AM +0200, AngeloGioacchino Del Regno wrote:
> Allow the power-domains property to the PWM_DISP block as on some SoCs
> this does need at most one power domain.
>
> Fixes: b09b179bac0a ("dt-bindings: pwm: Convert pwm-mtk-disp.txt to mediatek,pwm-disp.yaml format")
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
applied to
https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git pwm/for-next
.
While that is a fix I wouldn't consider this urgent enough to send it to
Linus before v6.9. However if another urgent fix comes in, I'll send it
along.
Best regards and thanks,
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] ASoC: dt-bindings: imx-audio-spdif: convert to YAML
From: Krzysztof Kozlowski @ 2024-04-08 7:55 UTC (permalink / raw)
To: Shengjiu Wang, lgirdwood, broonie, robh+dt,
krzysztof.kozlowski+dt, conor+dt, shengjiu.wang, linux-sound,
devicetree, linux-kernel, shawnguo, s.hauer, kernel, festevam,
imx, linux-arm-kernel
In-Reply-To: <1712561233-27250-1-git-send-email-shengjiu.wang@nxp.com>
On 08/04/2024 09:27, Shengjiu Wang wrote:
> Convert the imx-audio-spdif binding to YAML.
>
> When testing dtbs_check, found below compatible strings
> are not listed in document:
>
> fsl,imx-sabreauto-spdif
> fsl,imx6sx-sdb-spdif
>
> So add them in yaml file to pass the test.
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> ---
> changes in v2:
> - change file name to imx-spdif.yaml
How does your compatible look like? fsl,imx-audio-spdif, so use that.
> - remove |
> - add anyof for spdif-in and spdif-out requirement
> - change example name to sound
>
> diff --git a/Documentation/devicetree/bindings/sound/imx-spdif.yaml b/Documentation/devicetree/bindings/sound/imx-spdif.yaml
> new file mode 100644
> index 000000000000..beb214b51a50
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/imx-spdif.yaml
> @@ -0,0 +1,70 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/imx-spdif.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Freescale i.MX audio complex with S/PDIF transceiver
> +
> +maintainers:
> + - Shengjiu Wang <shengjiu.wang@nxp.com>
> +
> +properties:
> + compatible:
> + oneOf:
> + - items:
> + - enum:
> + - fsl,imx-audio-spdif> + - enum:
> + - fsl,imx-sabreauto-spdif
> + - fsl,imx6sx-sdb-spdif
This does not make much sense. You have mixed fallback with specific
compatible. I suggest you to fix your DTS and submit proper bindings.
> + - enum:
> + - fsl,imx-audio-spdif
> +
> + model:
> + $ref: /schemas/types.yaml#/definitions/string
> + description: User specified audio sound card name
> +
> + spdif-controller:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: The phandle of the i.MX S/PDIF controller
> +
> + spdif-out:
> + type: boolean
> + description:
> + If present, the transmitting function of S/PDIF will be enabled,
> + indicating there's a physical S/PDIF out connector or jack on the
> + board or it's connecting to some other IP block, such as an HDMI
> + encoder or display-controller.
> +
> + spdif-in:
> + type: boolean
> + description:
> + If present, the receiving function of S/PDIF will be enabled,
> + indicating there is a physical S/PDIF in connector/jack on the board.
> +
> +required:
> + - compatible
> + - model
> + - spdif-controller
> +
> +anyOf:
> + - required:
> + - spdif-in
> + - required:
> + - spdif-out
> + - required:
> + - spdif-out
> + - spdif-in
Do you need the last required block?
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + sound {
That's a random change...
Instead of sending two patches per day, please carefully address the
feedback.
> + compatible = "fsl,imx-audio-spdif";
> + model = "imx-spdif";
> + spdif-controller = <&spdif>;
> + spdif-out;
> + spdif-in;
> + };
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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