* [PATCH v5 08/13] ARM: dts: imx6ull-colibri: Add sleep mode to fec
From: Philippe Schenker @ 2019-08-27 13:18 UTC (permalink / raw)
To: Marcel Ziswiler, Max Krummenacher, stefan @ agner . ch,
devicetree @ vger . kernel . org, Rob Herring, Shawn Guo,
Mark Rutland, Michal Vokáč, Fabio Estevam
Cc: Sascha Hauer, linux-kernel@vger.kernel.org, Oleksandr Suvorov,
Philippe Schenker, NXP Linux Team, Pengutronix Kernel Team,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190827131806.6816-1-philippe.schenker@toradex.com>
Do not change the clock as the power for this phy is switched
with that clock.
Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
---
Changes in v5:
- Added Olek's Reviewed-by
Changes in v4:
- Add Marcel Ziswiler's Ack
Changes in v3: None
Changes in v2: None
arch/arm/boot/dts/imx6ull-colibri.dtsi | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6ull-colibri.dtsi b/arch/arm/boot/dts/imx6ull-colibri.dtsi
index d56728f03c35..1019ce69a242 100644
--- a/arch/arm/boot/dts/imx6ull-colibri.dtsi
+++ b/arch/arm/boot/dts/imx6ull-colibri.dtsi
@@ -62,8 +62,9 @@
};
&fec2 {
- pinctrl-names = "default";
+ pinctrl-names = "default", "sleep";
pinctrl-0 = <&pinctrl_enet2>;
+ pinctrl-1 = <&pinctrl_enet2_sleep>;
phy-mode = "rmii";
phy-handle = <ðphy1>;
status = "okay";
@@ -220,6 +221,21 @@
>;
};
+ pinctrl_enet2_sleep: enet2sleepgrp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO06__GPIO1_IO06 0x0
+ MX6UL_PAD_GPIO1_IO07__GPIO1_IO07 0x0
+ MX6UL_PAD_ENET2_RX_DATA0__GPIO2_IO08 0x0
+ MX6UL_PAD_ENET2_RX_DATA1__GPIO2_IO09 0x0
+ MX6UL_PAD_ENET2_RX_EN__GPIO2_IO10 0x0
+ MX6UL_PAD_ENET2_RX_ER__GPIO2_IO15 0x0
+ MX6UL_PAD_ENET2_TX_CLK__ENET2_REF_CLK2 0x4001b031
+ MX6UL_PAD_ENET2_TX_DATA0__GPIO2_IO11 0x0
+ MX6UL_PAD_ENET2_TX_DATA1__GPIO2_IO12 0x0
+ MX6UL_PAD_ENET2_TX_EN__GPIO2_IO13 0x0
+ >;
+ };
+
pinctrl_ecspi1_cs: ecspi1-cs-grp {
fsl,pins = <
MX6UL_PAD_LCD_DATA21__GPIO3_IO26 0x000a0
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/6] Revert "arm64: Remove unnecessary ISBs from set_{pte, pmd, pud}"
From: Will Deacon @ 2019-08-27 13:18 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-arch, Mark Rutland, Peter Zijlstra, Catalin Marinas, stable,
Marc Zyngier, Will Deacon
In-Reply-To: <20190827131818.14724-1-will@kernel.org>
This reverts commit 24fe1b0efad4fcdd32ce46cffeab297f22581707.
Commit 24fe1b0efad4fcdd ("arm64: Remove unnecessary ISBs from
set_{pte,pmd,pud}") removed ISB instructions immediately following updates
to the page table, on the grounds that they are not required by the
architecture and a DSB alone is sufficient to ensure that subsequent data
accesses use the new translation:
DDI0487E_a, B2-128:
| ... no instruction that appears in program order after the DSB
| instruction can alter any state of the system or perform any part of
| its functionality until the DSB completes other than:
|
| * Being fetched from memory and decoded
| * Reading the general-purpose, SIMD and floating-point,
| Special-purpose, or System registers that are directly or indirectly
| read without causing side-effects.
However, the same document also states the following:
DDI0487E_a, B2-125:
| DMB and DSB instructions affect reads and writes to the memory system
| generated by Load/Store instructions and data or unified cache
| maintenance instructions being executed by the PE. Instruction fetches
| or accesses caused by a hardware translation table access are not
| explicit accesses.
which appears to claim that the DSB alone is insufficient. Unfortunately,
some CPU designers have followed the second clause above, whereas in Linux
we've been relying on the first. This means that our mapping sequence:
MOV X0, <valid pte>
STR X0, [Xptep] // Store new PTE to page table
DSB ISHST
LDR X1, [X2] // Translates using the new PTE
can actually raise a translation fault on the load instruction because the
translation can be performed speculatively before the page table update and
then marked as "faulting" by the CPU. For user PTEs, this is ok because we
can handle the spurious fault, but for kernel PTEs and intermediate table
entries this results in a panic().
Revert the offending commit to reintroduce the missing barriers.
Cc: <stable@vger.kernel.org>
Fixes: 24fe1b0efad4fcdd ("arm64: Remove unnecessary ISBs from set_{pte,pmd,pud}")
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/include/asm/pgtable.h | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 5fdcfe237338..feda7294320c 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -220,8 +220,10 @@ static inline void set_pte(pte_t *ptep, pte_t pte)
* Only if the new pte is valid and kernel, otherwise TLB maintenance
* or update_mmu_cache() have the necessary barriers.
*/
- if (pte_valid_not_user(pte))
+ if (pte_valid_not_user(pte)) {
dsb(ishst);
+ isb();
+ }
}
extern void __sync_icache_dcache(pte_t pteval);
@@ -481,8 +483,10 @@ static inline void set_pmd(pmd_t *pmdp, pmd_t pmd)
WRITE_ONCE(*pmdp, pmd);
- if (pmd_valid(pmd))
+ if (pmd_valid(pmd)) {
dsb(ishst);
+ isb();
+ }
}
static inline void pmd_clear(pmd_t *pmdp)
@@ -540,8 +544,10 @@ static inline void set_pud(pud_t *pudp, pud_t pud)
WRITE_ONCE(*pudp, pud);
- if (pud_valid(pud))
+ if (pud_valid(pud)) {
dsb(ishst);
+ isb();
+ }
}
static inline void pud_clear(pud_t *pudp)
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/6] arm64: tlb: Ensure we execute an ISB following walk cache invalidation
From: Will Deacon @ 2019-08-27 13:18 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-arch, Mark Rutland, Peter Zijlstra, Catalin Marinas, stable,
Marc Zyngier, Will Deacon
In-Reply-To: <20190827131818.14724-1-will@kernel.org>
05f2d2f83b5a ("arm64: tlbflush: Introduce __flush_tlb_kernel_pgtable")
added a new TLB invalidation helper which is used when freeing
intermediate levels of page table used for kernel mappings, but is
missing the required ISB instruction after completion of the TLBI
instruction.
Add the missing barrier.
Cc: <stable@vger.kernel.org>
Fixes: 05f2d2f83b5a ("arm64: tlbflush: Introduce __flush_tlb_kernel_pgtable")
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/include/asm/tlbflush.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
index 8af7a85f76bd..bc3949064725 100644
--- a/arch/arm64/include/asm/tlbflush.h
+++ b/arch/arm64/include/asm/tlbflush.h
@@ -251,6 +251,7 @@ static inline void __flush_tlb_kernel_pgtable(unsigned long kaddr)
dsb(ishst);
__tlbi(vaae1is, addr);
dsb(ish);
+ isb();
}
#endif
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 07/13] ARM: dts: imx6-colibri: Add missing pinmuxing to Toradex eval board
From: Philippe Schenker @ 2019-08-27 13:18 UTC (permalink / raw)
To: Marcel Ziswiler, Max Krummenacher, stefan @ agner . ch,
devicetree @ vger . kernel . org, Rob Herring, Shawn Guo,
Mark Rutland, Michal Vokáč, Fabio Estevam
Cc: Sascha Hauer, linux-kernel@vger.kernel.org, Oleksandr Suvorov,
Philippe Schenker, NXP Linux Team, Pengutronix Kernel Team,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190827131806.6816-1-philippe.schenker@toradex.com>
This patch adds some missing pinmuxing that is in the colibri
standard to the dts.
Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
---
Changes in v5:
- Added Olek's Reviewed-by
Changes in v4:
- Add Marcel Ziswiler's Ack
Changes in v3: None
Changes in v2:
- Commit title
arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts b/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
index 5e9d844d78f2..cd075621de52 100644
--- a/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
+++ b/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
@@ -191,6 +191,14 @@
};
&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &pinctrl_weim_gpio_1 &pinctrl_weim_gpio_2
+ &pinctrl_weim_gpio_3 &pinctrl_weim_gpio_4
+ &pinctrl_weim_gpio_5 &pinctrl_weim_gpio_6
+ &pinctrl_usbh_oc_1 &pinctrl_usbc_id_1
+ >;
+
pinctrl_pcap_1: pcap1grp {
fsl,pins = <
MX6QDL_PAD_GPIO_9__GPIO1_IO09 0x1b0b0 /* SODIMM 28 */
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 06/13] ARM: dts: imx6-apalis: Add touchscreens used on Toradex eval boards
From: Philippe Schenker @ 2019-08-27 13:18 UTC (permalink / raw)
To: Marcel Ziswiler, Max Krummenacher, stefan @ agner . ch,
devicetree @ vger . kernel . org, Rob Herring, Shawn Guo,
Mark Rutland, Michal Vokáč, Fabio Estevam
Cc: Sascha Hauer, linux-kernel@vger.kernel.org, Oleksandr Suvorov,
Philippe Schenker, NXP Linux Team, Pengutronix Kernel Team,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190827131806.6816-1-philippe.schenker@toradex.com>
This commit adds the touchscreen from Toradex so one can enable it.
It is disabled by default because the pins are also used for PWM<B>,
PWM<C>, aka pwm2, pwm3 which is the standard use for colibri boards.
Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
---
Changes in v5:
- Adjusted commit message
- Switched to consistent naming: pinctrl_xxx: xxxgrp
- Added Olek's Reviewed-by
Changes in v4:
- Add Marcel Ziswiler's Ack
Changes in v3:
- Fix commit title to "...imx6-apalis:..."
Changes in v2:
- Deleted touchrevolution downstream stuff
- Use generic node name
- Put a better comment in there
arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts | 31 +++++++++++++++++++
arch/arm/boot/dts/imx6q-apalis-eval.dts | 13 ++++++++
arch/arm/boot/dts/imx6q-apalis-ixora-v1.1.dts | 13 ++++++++
arch/arm/boot/dts/imx6q-apalis-ixora.dts | 13 ++++++++
4 files changed, 70 insertions(+)
diff --git a/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts b/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
index 9a5d6c94cca4..5e9d844d78f2 100644
--- a/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
+++ b/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
@@ -168,6 +168,21 @@
&i2c3 {
status = "okay";
+ /*
+ * Touchscreen is using SODIMM 28/30, also used for PWM<B>, PWM<C>,
+ * aka pwm2, pwm3. so if you enable touchscreen, disable the pwms
+ */
+ touchscreen@4a {
+ compatible = "atmel,maxtouch";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pcap_1>;
+ reg = <0x4a>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <9 IRQ_TYPE_EDGE_FALLING>; /* SODIMM 28 */
+ reset-gpios = <&gpio2 10 GPIO_ACTIVE_HIGH>; /* SODIMM 30 */
+ status = "disabled";
+ };
+
/* M41T0M6 real time clock on carrier board */
rtc_i2c: rtc@68 {
compatible = "st,m41t0";
@@ -175,6 +190,22 @@
};
};
+&iomuxc {
+ pinctrl_pcap_1: pcap1grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_9__GPIO1_IO09 0x1b0b0 /* SODIMM 28 */
+ MX6QDL_PAD_SD4_DAT2__GPIO2_IO10 0x1b0b0 /* SODIMM 30 */
+ >;
+ };
+
+ pinctrl_mxt_ts: mxttsgrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_CS1__GPIO2_IO24 0x130b0 /* SODIMM 107 */
+ MX6QDL_PAD_SD2_DAT1__GPIO1_IO14 0x130b0 /* SODIMM 106 */
+ >;
+ };
+};
+
&ipu1_di0_disp0 {
remote-endpoint = <&lcd_display_in>;
};
diff --git a/arch/arm/boot/dts/imx6q-apalis-eval.dts b/arch/arm/boot/dts/imx6q-apalis-eval.dts
index 0edd3043d9c1..4665e15b196d 100644
--- a/arch/arm/boot/dts/imx6q-apalis-eval.dts
+++ b/arch/arm/boot/dts/imx6q-apalis-eval.dts
@@ -167,6 +167,19 @@
&i2c1 {
status = "okay";
+ /*
+ * Touchscreen is using SODIMM 28/30, also used for PWM<B>, PWM<C>,
+ * aka pwm2, pwm3. so if you enable touchscreen, disable the pwms
+ */
+ touchscreen@4a {
+ compatible = "atmel,maxtouch";
+ reg = <0x4a>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <10 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&gpio6 9 GPIO_ACTIVE_HIGH>; /* SODIMM 13 */
+ status = "disabled";
+ };
+
pcie-switch@58 {
compatible = "plx,pex8605";
reg = <0x58>;
diff --git a/arch/arm/boot/dts/imx6q-apalis-ixora-v1.1.dts b/arch/arm/boot/dts/imx6q-apalis-ixora-v1.1.dts
index b94bb687be6b..a3fa04a97d81 100644
--- a/arch/arm/boot/dts/imx6q-apalis-ixora-v1.1.dts
+++ b/arch/arm/boot/dts/imx6q-apalis-ixora-v1.1.dts
@@ -172,6 +172,19 @@
&i2c1 {
status = "okay";
+ /*
+ * Touchscreen is using SODIMM 28/30, also used for PWM<B>, PWM<C>,
+ * aka pwm2, pwm3. so if you enable touchscreen, disable the pwms
+ */
+ touchscreen@4a {
+ compatible = "atmel,maxtouch";
+ reg = <0x4a>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <10 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&gpio6 9 GPIO_ACTIVE_HIGH>; /* SODIMM 13 */
+ status = "disabled";
+ };
+
/* M41T0M6 real time clock on carrier board */
rtc_i2c: rtc@68 {
compatible = "st,m41t0";
diff --git a/arch/arm/boot/dts/imx6q-apalis-ixora.dts b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
index 302fd6adc8a7..5ba49d0f4880 100644
--- a/arch/arm/boot/dts/imx6q-apalis-ixora.dts
+++ b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
@@ -171,6 +171,19 @@
&i2c1 {
status = "okay";
+ /*
+ * Touchscreen is using SODIMM 28/30, also used for PWM<B>, PWM<C>,
+ * aka pwm2, pwm3. so if you enable touchscreen, disable the pwms
+ */
+ touchscreen@4a {
+ compatible = "atmel,maxtouch";
+ reg = <0x4a>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <10 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&gpio6 9 GPIO_ACTIVE_HIGH>; /* SODIMM 13 */
+ status = "disabled";
+ };
+
eeprom@50 {
compatible = "atmel,24c02";
reg = <0x50>;
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 05/13] ARM: dts: imx6qdl-apalis: Add sleep state to can interfaces
From: Philippe Schenker @ 2019-08-27 13:18 UTC (permalink / raw)
To: Marcel Ziswiler, Max Krummenacher, stefan @ agner . ch,
devicetree @ vger . kernel . org, Rob Herring, Shawn Guo,
Mark Rutland, Michal Vokáč, Fabio Estevam
Cc: Sascha Hauer, linux-kernel@vger.kernel.org, Philippe Schenker,
NXP Linux Team, Pengutronix Kernel Team,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190827131806.6816-1-philippe.schenker@toradex.com>
This patch prepares the devicetree for the new Ixora V1.2 where we are
able to turn off the supply of the can transceiver. This implies to use
a sleep state on transmission pins in order to prevent backfeeding.
Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---
Changes in v5: None
Changes in v4:
- Add Marcel Ziswiler's Ack
Changes in v3: None
Changes in v2:
- Changed commit title to '...imx6qdl-apalis:...'
arch/arm/boot/dts/imx6qdl-apalis.dtsi | 27 +++++++++++++++++++++------
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
index 7c4ad541c3f5..59ed2e4a1fd1 100644
--- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
@@ -148,14 +148,16 @@
};
&can1 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_flexcan1>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&pinctrl_flexcan1_default>;
+ pinctrl-1 = <&pinctrl_flexcan1_sleep>;
status = "disabled";
};
&can2 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_flexcan2>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&pinctrl_flexcan2_default>;
+ pinctrl-1 = <&pinctrl_flexcan2_sleep>;
status = "disabled";
};
@@ -599,19 +601,32 @@
>;
};
- pinctrl_flexcan1: flexcan1grp {
+ pinctrl_flexcan1_default: flexcan1defgrp {
fsl,pins = <
MX6QDL_PAD_GPIO_7__FLEXCAN1_TX 0x1b0b0
MX6QDL_PAD_GPIO_8__FLEXCAN1_RX 0x1b0b0
>;
};
- pinctrl_flexcan2: flexcan2grp {
+ pinctrl_flexcan1_sleep: flexcan1slpgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_7__GPIO1_IO07 0x0
+ MX6QDL_PAD_GPIO_8__GPIO1_IO08 0x0
+ >;
+ };
+
+ pinctrl_flexcan2_default: flexcan2defgrp {
fsl,pins = <
MX6QDL_PAD_KEY_COL4__FLEXCAN2_TX 0x1b0b0
MX6QDL_PAD_KEY_ROW4__FLEXCAN2_RX 0x1b0b0
>;
};
+ pinctrl_flexcan2_sleep: flexcan2slpgrp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL4__GPIO4_IO14 0x0
+ MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x0
+ >;
+ };
pinctrl_gpio_bl_on: gpioblon {
fsl,pins = <
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 04/13] ARM: dts: imx6qdl-colibri: Add missing pin declaration in iomuxc
From: Philippe Schenker @ 2019-08-27 13:18 UTC (permalink / raw)
To: Marcel Ziswiler, Max Krummenacher, stefan @ agner . ch,
devicetree @ vger . kernel . org, Rob Herring, Shawn Guo,
Mark Rutland, Michal Vokáč, Fabio Estevam
Cc: Sascha Hauer, linux-kernel@vger.kernel.org, Philippe Schenker,
NXP Linux Team, Pengutronix Kernel Team,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190827131806.6816-1-philippe.schenker@toradex.com>
This adds the muxing for the optional pins usb-oc (overcurrent) and
usb-id.
Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---
Changes in v5:
- change group name
- Add pinmux to iomuxc
Changes in v4:
- Add Marcel Ziswiler's Ack
Changes in v3: None
Changes in v2: None
arch/arm/boot/dts/imx6qdl-colibri.dtsi | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-colibri.dtsi b/arch/arm/boot/dts/imx6qdl-colibri.dtsi
index 1beac22266ed..07379d3d2f4e 100644
--- a/arch/arm/boot/dts/imx6qdl-colibri.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-colibri.dtsi
@@ -415,6 +415,9 @@
};
&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbh_oc_1>;
+
pinctrl_audmux: audmuxgrp {
fsl,pins = <
MX6QDL_PAD_KEY_COL0__AUD5_TXC 0x130b0
@@ -604,6 +607,13 @@
>;
};
+ pinctrl_usbh_oc_1: usbhoc1grp {
+ fsl,pins = <
+ /* USBH_OC */
+ MX6QDL_PAD_EIM_D30__GPIO3_IO30 0x1b0b0
+ >;
+ };
+
pinctrl_spdif: spdifgrp {
fsl,pins = <
MX6QDL_PAD_GPIO_17__SPDIF_OUT 0x1b0b0
@@ -670,6 +680,13 @@
>;
};
+ pinctrl_usbc_id_1: usbc_id-1 {
+ fsl,pins = <
+ /* USBC_ID */
+ MX6QDL_PAD_NANDF_D2__GPIO2_IO02 0x1b0b0
+ >;
+ };
+
pinctrl_usdhc1: usdhc1grp {
fsl,pins = <
MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17071
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 03/13] ARM: dts: imx7-colibri: Add touch controllers
From: Philippe Schenker @ 2019-08-27 13:18 UTC (permalink / raw)
To: Marcel Ziswiler, Max Krummenacher, stefan @ agner . ch,
devicetree @ vger . kernel . org, Rob Herring, Shawn Guo,
Mark Rutland, Michal Vokáč, Fabio Estevam
Cc: Sascha Hauer, linux-kernel@vger.kernel.org, Oleksandr Suvorov,
Philippe Schenker, NXP Linux Team, Pengutronix Kernel Team,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190827131806.6816-1-philippe.schenker@toradex.com>
Add touch controller that is connected over an I2C bus.
It is disabled by default because the pins are also used for PWM,
which is the standard use for colibri boards.
Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
---
Changes in v5:
- Add note in commit message about disabled status
- Added Olek's reviewed-by
Changes in v4:
- Add Marcel Ziswiler's Ack
Changes in v3:
- Fix commit message
Changes in v2:
- Deleted touchrevolution downstream stuff
- Use generic node name
- Better comment
arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi | 24 +++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
index 45c4e721115a..6aa123cbdadb 100644
--- a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
@@ -145,6 +145,21 @@
&i2c4 {
status = "okay";
+ /*
+ * Touchscreen is using SODIMM 28/30, also used for PWM<B>, PWM<C>,
+ * aka pwm2, pwm3. so if you enable touchscreen, disable the pwms
+ */
+ touchscreen@4a {
+ compatible = "atmel,maxtouch";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpiotouch>;
+ reg = <0x4a>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <9 IRQ_TYPE_EDGE_FALLING>; /* SODIMM 28 */
+ reset-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>; /* SODIMM 30 */
+ status = "disabled";
+ };
+
/* M41T0M6 real time clock on carrier board */
rtc: m41t0m6@68 {
compatible = "st,m41t0";
@@ -200,3 +215,12 @@
vmmc-supply = <®_3v3>;
status = "okay";
};
+
+&iomuxc {
+ pinctrl_gpiotouch: touchgpios {
+ fsl,pins = <
+ MX7D_PAD_GPIO1_IO09__GPIO1_IO9 0x74
+ MX7D_PAD_GPIO1_IO10__GPIO1_IO10 0x14
+ >;
+ };
+};
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 02/13] ARM: dts: imx7-colibri: fix 1.8V/UHS support
From: Philippe Schenker @ 2019-08-27 13:18 UTC (permalink / raw)
To: Marcel Ziswiler, Max Krummenacher, stefan @ agner . ch,
devicetree @ vger . kernel . org, Rob Herring, Shawn Guo,
Mark Rutland, Michal Vokáč, Fabio Estevam
Cc: Stefan Agner, Sascha Hauer, linux-kernel@vger.kernel.org,
Philippe Schenker, NXP Linux Team, Pengutronix Kernel Team,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190827131806.6816-1-philippe.schenker@toradex.com>
From: Stefan Agner <stefan.agner@toradex.com>
Add pinmuxing and do not specify voltage restrictions for the usdhc
instance available on the modules edge connector. This allows to use
SD-cards with higher transfer modes if supported by the carrier board.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---
Changes in v5: None
Changes in v4:
- Add Marcel Ziswiler's Ack
Changes in v3:
- Add new commit message from Stefan's proposal on ML
Changes in v2: None
arch/arm/boot/dts/imx7-colibri.dtsi | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index b72940e7d00b..cbcb97886e80 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -304,7 +304,6 @@
&usdhc1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usdhc1 &pinctrl_cd_usdhc1>;
- no-1-8-v;
cd-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>;
disable-wp;
vqmmc-supply = <®_LDO2>;
@@ -612,6 +611,28 @@
>;
};
+ pinctrl_usdhc1_100mhz: usdhc1grp_100mhz {
+ fsl,pins = <
+ MX7D_PAD_SD1_CMD__SD1_CMD 0x5a
+ MX7D_PAD_SD1_CLK__SD1_CLK 0x1a
+ MX7D_PAD_SD1_DATA0__SD1_DATA0 0x5a
+ MX7D_PAD_SD1_DATA1__SD1_DATA1 0x5a
+ MX7D_PAD_SD1_DATA2__SD1_DATA2 0x5a
+ MX7D_PAD_SD1_DATA3__SD1_DATA3 0x5a
+ >;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1grp_200mhz {
+ fsl,pins = <
+ MX7D_PAD_SD1_CMD__SD1_CMD 0x5b
+ MX7D_PAD_SD1_CLK__SD1_CLK 0x1b
+ MX7D_PAD_SD1_DATA0__SD1_DATA0 0x5b
+ MX7D_PAD_SD1_DATA1__SD1_DATA1 0x5b
+ MX7D_PAD_SD1_DATA2__SD1_DATA2 0x5b
+ MX7D_PAD_SD1_DATA3__SD1_DATA3 0x5b
+ >;
+ };
+
pinctrl_usdhc3: usdhc3grp {
fsl,pins = <
MX7D_PAD_SD3_CMD__SD3_CMD 0x59
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 01/13] ARM: dts: imx7-colibri: add GPIO wakeup key
From: Philippe Schenker @ 2019-08-27 13:18 UTC (permalink / raw)
To: Marcel Ziswiler, Max Krummenacher, stefan @ agner . ch,
devicetree @ vger . kernel . org, Rob Herring, Shawn Guo,
Mark Rutland, Michal Vokáč, Fabio Estevam
Cc: Stefan Agner, Sascha Hauer, linux-kernel@vger.kernel.org,
Philippe Schenker, NXP Linux Team, Pengutronix Kernel Team,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190827131806.6816-1-philippe.schenker@toradex.com>
From: Stefan Agner <stefan.agner@toradex.com>
Add wakeup GPIO key which is able to wake the system from sleep
modes (e.g. Suspend-to-Memory).
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---
Changes in v5:
- changed legacy gpio-key,wakeup to wakeup-source
Changes in v4:
- Add Marcel Ziswiler's Ack
Changes in v3: None
Changes in v2: None
arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi | 14 ++++++++++++++
arch/arm/boot/dts/imx7-colibri.dtsi | 7 ++++++-
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
index 3f2746169181..45c4e721115a 100644
--- a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
@@ -52,6 +52,20 @@
clock-frequency = <16000000>;
};
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpiokeys>;
+
+ power {
+ label = "Wake-Up";
+ gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_WAKEUP>;
+ debounce-interval = <10>;
+ wakeup-source;
+ };
+ };
+
panel: panel {
compatible = "edt,et057090dhu";
backlight = <&bl>;
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index 895fbde4d433..b72940e7d00b 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -682,12 +682,17 @@
pinctrl_gpio_lpsr: gpio1-grp {
fsl,pins = <
- MX7D_PAD_LPSR_GPIO1_IO01__GPIO1_IO1 0x59
MX7D_PAD_LPSR_GPIO1_IO02__GPIO1_IO2 0x59
MX7D_PAD_LPSR_GPIO1_IO03__GPIO1_IO3 0x59
>;
};
+ pinctrl_gpiokeys: gpiokeysgrp {
+ fsl,pins = <
+ MX7D_PAD_LPSR_GPIO1_IO01__GPIO1_IO1 0x19
+ >;
+ };
+
pinctrl_i2c1: i2c1-grp {
fsl,pins = <
MX7D_PAD_LPSR_GPIO1_IO05__I2C1_SDA 0x4000007f
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 00/13] Common patches from downstream development
From: Philippe Schenker @ 2019-08-27 13:18 UTC (permalink / raw)
To: Marcel Ziswiler, Max Krummenacher, stefan @ agner . ch,
devicetree @ vger . kernel . org, Rob Herring, Shawn Guo,
Mark Rutland, Michal Vokáč, Fabio Estevam
Cc: Sascha Hauer, linux-kernel@vger.kernel.org, Philippe Schenker,
NXP Linux Team, Pengutronix Kernel Team,
linux-arm-kernel@lists.infradead.org
This patchset holds some common changes that were never upstreamed.
With latest downstream kernel upgrade, I took the aproach to select
mainline devicetrees and atomically add missing stuff for downstream.
These patches I send here are separated out with changes that also
have a benefit for mainline.
--------------------- Update version 4 and later -----------------------
Patches that got pulled in an earlier patchset version got dropped in
this patchset.
------------------------------------------------------------------------
Philippe
Changes in v5:
- changed legacy gpio-key,wakeup to wakeup-source
- Add note in commit message about disabled status
- Added Olek's reviewed-by
- change group name
- Add pinmux to iomuxc
- Adjusted commit message
- Switched to consistent naming: pinctrl_xxx: xxxgrp
- Added Olek's Reviewed-by
- Added Olek's Reviewed-by
- Added Olek's Reviewed-by
- Added Olek's Reviewd-by
- Added Olek's Reviewed-by
- Add Olek's Reviewed-by
- Added note to commit message about disabled status
- Add Olek's Reviewed-by
Changes in v4:
- Add Marcel Ziswiler's Ack
- Add Marcel Ziswiler's Ack
- Add Marcel Ziswiler's Ack
- Add Marcel Ziswiler's Ack
- Add Marcel Ziswiler's Ack
- Add Marcel Ziswiler's Ack
- Add Marcel Ziswiler's Ack
- Add Marcel Ziswiler's Ack
- Add Marcel Ziswiler's Ack
- Add Marcel Ziswiler's Ack
- Move can nodes to module deviceteree include imx6ull-colibri.dtsi
- Add Marcel Ziswiler's Ack
Changes in v3:
- Add new commit message from Stefan's proposal on ML
- Fix commit message
- Fix commit title to "...imx6-apalis:..."
Changes in v2:
- Deleted touchrevolution downstream stuff
- Use generic node name
- Better comment
- Changed commit title to '...imx6qdl-apalis:...'
- Deleted touchrevolution downstream stuff
- Use generic node name
- Put a better comment in there
- Commit title
- Removed f0710a
that is downstream only
- Changed to generic node name
- Better comment
Max Krummenacher (2):
ARM: dts: imx6ull-colibri: reduce v_batt current in power off
ARM: dts: imx6ull: improve can templates
Philippe Schenker (9):
ARM: dts: imx7-colibri: Add touch controllers
ARM: dts: imx6qdl-colibri: Add missing pin declaration in iomuxc
ARM: dts: imx6qdl-apalis: Add sleep state to can interfaces
ARM: dts: imx6-apalis: Add touchscreens used on Toradex eval boards
ARM: dts: imx6-colibri: Add missing pinmuxing to Toradex eval board
ARM: dts: imx6ull-colibri: Add sleep mode to fec
ARM: dts: imx6ull-colibri: Add watchdog
ARM: dts: imx6ull-colibri: Add general wakeup key used on Colibri
ARM: dts: imx6ull-colibri: Add touchscreen used with Eval Board
Stefan Agner (2):
ARM: dts: imx7-colibri: add GPIO wakeup key
ARM: dts: imx7-colibri: fix 1.8V/UHS support
arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts | 39 +++++++++++
arch/arm/boot/dts/imx6q-apalis-eval.dts | 13 ++++
arch/arm/boot/dts/imx6q-apalis-ixora-v1.1.dts | 13 ++++
arch/arm/boot/dts/imx6q-apalis-ixora.dts | 13 ++++
arch/arm/boot/dts/imx6qdl-apalis.dtsi | 27 ++++++--
arch/arm/boot/dts/imx6qdl-colibri.dtsi | 17 +++++
.../arm/boot/dts/imx6ull-colibri-eval-v3.dtsi | 38 +++++++++++
.../arm/boot/dts/imx6ull-colibri-nonwifi.dtsi | 2 +-
arch/arm/boot/dts/imx6ull-colibri-wifi.dtsi | 2 +-
arch/arm/boot/dts/imx6ull-colibri.dtsi | 64 +++++++++++++++++--
arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi | 38 +++++++++++
arch/arm/boot/dts/imx7-colibri.dtsi | 30 ++++++++-
12 files changed, 280 insertions(+), 16 deletions(-)
--
2.23.0
_______________________________________________
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/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Rob Herring @ 2019-08-27 13:13 UTC (permalink / raw)
To: Peng Fan
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
f.fainelli@gmail.com, andre.przywara@arm.com,
jassisinghbrar@gmail.com, linux-kernel@vger.kernel.org,
dl-linux-imx, sudeep.holla@arm.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1566942646-18015-2-git-send-email-peng.fan@nxp.com>
On Tue, Aug 27, 2019 at 4:51 AM Peng Fan <peng.fan@nxp.com> wrote:
>
> From: Peng Fan <peng.fan@nxp.com>
>
> The ARM SMC/HVC mailbox binding describes a firmware interface to trigger
> actions in software layers running in the EL2 or EL3 exception levels.
> The term "ARM" here relates to the SMC instruction as part of the ARM
> instruction set, not as a standard endorsed by ARM Ltd.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> .../devicetree/bindings/mailbox/arm-smc.yaml | 126 +++++++++++++++++++++
> 1 file changed, 126 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml
>
> diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> new file mode 100644
> index 000000000000..ae677e0c0910
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> @@ -0,0 +1,126 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ARM SMC Mailbox Interface
> +
> +maintainers:
> + - Peng Fan <peng.fan@nxp.com>
> +
> +description: |
> + This mailbox uses the ARM smc (secure monitor call) and hvc (hypervisor
> + call) instruction to trigger a mailbox-connected activity in firmware,
> + executing on the very same core as the caller. By nature this operation
> + is synchronous and this mailbox provides no way for asynchronous messages
> + to be delivered the other way round, from firmware to the OS, but
> + asynchronous notification could also be supported. However the value of
> + r0/w0/x0 the firmware returns after the smc call is delivered as a received
> + message to the mailbox framework, so a synchronous communication can be
> + established, for a asynchronous notification, no value will be returned.
> + The exact meaning of both the action the mailbox triggers as well as the
> + return value is defined by their users and is not subject to this binding.
> +
> + One use case of this mailbox is the SCMI interface, which uses shared memory
> + to transfer commands and parameters, and a mailbox to trigger a function
> + call. This allows SoCs without a separate management processor (or when
> + such a processor is not available or used) to use this standardized
> + interface anyway.
> +
> + This binding describes no hardware, but establishes a firmware interface.
> + Upon receiving an SMC using one of the described SMC function identifiers,
> + the firmware is expected to trigger some mailbox connected functionality.
> + The communication follows the ARM SMC calling convention.
> + Firmware expects an SMC function identifier in r0 or w0. The supported
> + identifiers are passed from consumers, or listed in the the arm,func-ids
> + properties as described below. The firmware can return one value in
> + the first SMC result register, it is expected to be an error value,
> + which shall be propagated to the mailbox client.
> +
> + Any core which supports the SMC or HVC instruction can be used, as long as
> + a firmware component running in EL3 or EL2 is handling these calls.
> +
> +properties:
> + compatible:
> + const: arm,smc-mbox
> +
> + "#mbox-cells":
> + const: 1
> +
> + arm,num-chans:
> + description: The number of channels supported.
> + items:
> + minimum: 1
> + maximum: 4096 # Should be enough?
> +
> + method:
> + items:
You can drop 'items' as this is a single entry.
> + - enum:
> + - smc
> + - hvc
> +
> + transports:
> + items:
same here
> + - enum:
> + - mem
> + - reg
> +
> + arm,func-ids:
Needs a $ref to a type (uint32-array).
> + description: |
> + An array of 32-bit values specifying the function IDs used by each
> + mailbox channel. Those function IDs follow the ARM SMC calling
> + convention standard [1].
> +
> + There is one identifier per channel and the number of supported
> + channels is determined by the length of this array.
> + minItems: 0
> + maxItems: 4096 # Should be enough?
> +
> +required:
> + - compatible
> + - "#mbox-cells"
> + - arm,num-chans
> + - transports
> + - method
> +
> +examples:
> + - |
> + sram@910000 {
> + compatible = "mmio-sram";
> + reg = <0x0 0x93f000 0x0 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x0 0x93f000 0x1000>;
> +
> + cpu_scp_lpri: scp-shmem@0 {
Looks like some indentation problem...
> + compatible = "arm,scmi-shmem";
> + reg = <0x0 0x200>;
> + };
> +
> + cpu_scp_hpri: scp-shmem@200 {
> + compatible = "arm,scmi-shmem";
> + reg = <0x200 0x200>;
> + };
> + };
> +
> + firmware {
> + smc_mbox: mailbox {
> + #mbox-cells = <1>;
> + compatible = "arm,smc-mbox";
> + method = "smc";
> + arm,num-chans = <0x2>;
> + transports = "mem";
> + /* Optional */
> + arm,func-ids = <0xc20000fe>, <0xc20000ff>;
> + };
> +
> + scmi {
> + compatible = "arm,scmi";
> + mboxes = <&mailbox 0 &mailbox 1>;
&smc_mbox and <> each entry.
> + mbox-names = "tx", "rx";
> + shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
<> each entry
> + };
> + };
> +
> +...
> --
> 2.16.4
>
_______________________________________________
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 01/10] PCI: designware-ep: Add multiple PFs support for DWC
From: Andrew Murray @ 2019-08-27 13:10 UTC (permalink / raw)
To: Xiaowei Bao
Cc: mark.rutland@arm.com, Roy Zang, lorenzo.pieralisi@arm.co,
arnd@arndb.de, devicetree@vger.kernel.org,
gregkh@linuxfoundation.org, linuxppc-dev@lists.ozlabs.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
kishon@ti.com, M.h. Lian, robh+dt@kernel.org,
gustavo.pimentel@synopsys.com, jingoohan1@gmail.com,
bhelgaas@google.com, Leo Li, shawnguo@kernel.org, Mingkai Hu,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <AM5PR04MB32997FFCD08E2C34541D2F9BF5A40@AM5PR04MB3299.eurprd04.prod.outlook.com>
On Fri, Aug 23, 2019 at 11:50:20PM +0000, Xiaowei Bao wrote:
>
>
> > -----Original Message-----
> > From: Andrew Murray <andrew.murray@arm.com>
> > Sent: 2019年8月23日 21:25
> > To: Xiaowei Bao <xiaowei.bao@nxp.com>
> > Cc: bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com;
> > shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; kishon@ti.com;
> > lorenzo.pieralisi@arm.co; arnd@arndb.de; gregkh@linuxfoundation.org; M.h.
> > Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy
> > Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
> > gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
> > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> > linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH v2 01/10] PCI: designware-ep: Add multiple PFs support
> > for DWC
> >
> > On Thu, Aug 22, 2019 at 07:22:33PM +0800, Xiaowei Bao wrote:
> > > Add multiple PFs support for DWC, different PF have different config
> > > space we use pf-offset property which get from the DTS to access the
> > > different pF config space.
> >
> > It looks like you're missing a --cover-letter again.
> >
> > >
> > > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > > ---
> > > v2:
> > > - Remove duplicate redundant code.
> > > - Reimplement the PF config space access way.
> > >
> > > drivers/pci/controller/dwc/pcie-designware-ep.c | 122
> > ++++++++++++++++--------
> > > drivers/pci/controller/dwc/pcie-designware.c | 59 ++++++++----
> > > drivers/pci/controller/dwc/pcie-designware.h | 11 ++-
> > > 3 files changed, 134 insertions(+), 58 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > index 2bf5a35..3e2b740 100644
> > > --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > @@ -19,12 +19,17 @@ void dw_pcie_ep_linkup(struct dw_pcie_ep *ep)
> > > pci_epc_linkup(epc);
> > > }
> > >
> > > -static void __dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno
> > bar,
> > > - int flags)
> > > +static void __dw_pcie_ep_reset_bar(struct dw_pcie *pci, u8 func_no,
> > > + enum pci_barno bar, int flags)
> > > {
> > > u32 reg;
> > > + unsigned int func_offset = 0;
> > > + struct dw_pcie_ep *ep = &pci->ep;
> > >
> > > - reg = PCI_BASE_ADDRESS_0 + (4 * bar);
> > > + if (ep->ops->func_conf_select)
> > > + func_offset = ep->ops->func_conf_select(ep, func_no);
> > > +
> > > + reg = func_offset + PCI_BASE_ADDRESS_0 + (4 * bar);
> >
> > This pattern of checking if func_conf_select exists and using it to get an offset
> > is repeated a lot throughout this file. You could move this functionality into a
> > new function (similar to dw_pcie_read_dbi etc). Or perhaps a new variant of
> > dw_pcie_writel_ should be created that writes takes a func_no argument.
>
> Thanks for your comments, I thought about this method before, but there is a issue
> about the method of access the different func config space, due to our platform use
> this method that different func have different offset from dbi_base to access the
> different config space, but others platform maybe use the way that write a register
> to implement different func config space access, so I think reserve a callback function
My point here was really to move out duplicated code to its own small function.
I wasn't making any comment about (removing) the callback, just that the test and
callback could be in one function.
> to different platform to implement the own method, my point is that, if use register
> method they can implement the code in this function and return offset is 0, if use
> offset method, they can return the offset value which can be use by dw_pcie_ep driver.
By the way, I haven't looked to see how many of the dw_pcie_write_xxx functions
would benefit from a func_no argument - if there were many calls to
dw_pcie_write_xxx that all used a reg value originated from func_conf_select
then an approach similar to the implementation of dw_pcie_write_dbi could
probably be justified (i.e. rather than change the value of reg) for writing to
functions.
>
> >
> >
> > > dw_pcie_dbi_ro_wr_en(pci);
> > > dw_pcie_writel_dbi2(pci, reg, 0x0);
> > > dw_pcie_writel_dbi(pci, reg, 0x0);
> >
> >
> > > @@ -235,7 +257,7 @@ static int dw_pcie_ep_map_addr(struct pci_epc
> > *epc, u8 func_no,
> > > struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > >
> > > - ret = dw_pcie_ep_outbound_atu(ep, addr, pci_addr, size);
> > > + ret = dw_pcie_ep_outbound_atu(ep, func_no, addr, pci_addr, size);
> > > if (ret) {
> > > dev_err(pci->dev, "Failed to enable address\n");
> > > return ret;
> > > @@ -249,11 +271,15 @@ static int dw_pcie_ep_get_msi(struct pci_epc
> > *epc, u8 func_no)
> > > struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > u32 val, reg;
> > > + unsigned int func_offset = 0;
> > > +
> > > + if (ep->ops->func_conf_select)
> > > + func_offset = ep->ops->func_conf_select(ep, func_no);
> > >
> > > if (!ep->msi_cap)
> > > return -EINVAL;
> > >
> > > - reg = ep->msi_cap + PCI_MSI_FLAGS;
> > > + reg = ep->msi_cap + func_offset + PCI_MSI_FLAGS;
> >
> > This makes me nervous.
> >
> > From a PCI viewpoint, each function has it's own capability structure and
> > within each function there may exist a MSI capability. Yet what we're doing
> > here is using dw_pcie_ep_find_capability to get the list of capabilities for
> > function 0, and then applying offsets from that for subsequent functions. I.e.
> > we're applying DW specific knowledge to find the correct capability, rather
> > than following the general PCI approach.
> >
> > I think the above hunk shouldn't be required - but instead
> > dw_pcie_ep_find_capability is updated to take a func_no parameter.
> >
> > Have I understood this correctly?
>
> Yes, this is a issue, I think the different func maybe have different capability,
> but the dw_pcie_ep_find_capability function is called by dw_pcie_ep_init
> function, we can't add func_no parameter to dw_pcie_ep_find_capability,
Why not?
Given that 'struct dw_pcie' represents a controller - and thus potentially
multiple functions - then the _find_capability function should be able to
provide the correct offset for the given function. Surely it needs to know
which function number? Unless there is some reason why we can assume that all
functions share the same capability offset.
Also the 'struct dw_pcie_ep' which represents an endpoint controller - this
has msi_cap and msix_cap fields - given this may be a multifunction device
what do these fields actually refer to?
Perhaps Jungoo/Gustavo can comment.
> I will try to fix it use a new patch, I think move this function to ep_init callback
> function If better, thanks.
>
>
> >
> > > val = dw_pcie_readw_dbi(pci, reg);
> > > if (!(val & PCI_MSI_FLAGS_ENABLE))
> > > return -EINVAL;
> > > @@ -268,11 +294,15 @@ static int dw_pcie_ep_set_msi(struct pci_epc
> > *epc, u8 func_no, u8 interrupts)
> > > struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > u32 val, reg;
> > > + unsigned int func_offset = 0;
> > > +
> > > + if (ep->ops->func_conf_select)
> > > + func_offset = ep->ops->func_conf_select(ep, func_no);
> > >
> > > if (!ep->msi_cap)
> > > return -EINVAL;
> > >
> > > - reg = ep->msi_cap + PCI_MSI_FLAGS;
> > > + reg = ep->msi_cap + func_offset + PCI_MSI_FLAGS;
> > > val = dw_pcie_readw_dbi(pci, reg);
> > > val &= ~PCI_MSI_FLAGS_QMASK;
> > > val |= (interrupts << 1) & PCI_MSI_FLAGS_QMASK; @@ -288,11 +318,15
> > > @@ static int dw_pcie_ep_get_msix(struct pci_epc *epc, u8 func_no)
> > > struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > u32 val, reg;
> > > + unsigned int func_offset = 0;
> > > +
> > > + if (ep->ops->func_conf_select)
> > > + func_offset = ep->ops->func_conf_select(ep, func_no);
> > >
> > > if (!ep->msix_cap)
> > > return -EINVAL;
> > >
> > > - reg = ep->msix_cap + PCI_MSIX_FLAGS;
> > > + reg = ep->msix_cap + func_offset + PCI_MSIX_FLAGS;
> >
> > Same for MSIX.
>
> Yes.
>
> >
> > > val = dw_pcie_readw_dbi(pci, reg);
> > > if (!(val & PCI_MSIX_FLAGS_ENABLE))
> > > return -EINVAL;
> > > @@ -307,11 +341,15 @@ static int dw_pcie_ep_set_msix(struct pci_epc
> > *epc, u8 func_no, u16 interrupts)
> > > struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > u32 val, reg;
> > > + unsigned int func_offset = 0;
> > > +
> > > + if (ep->ops->func_conf_select)
> > > + func_offset = ep->ops->func_conf_select(ep, func_no);
> > >
> > > if (!ep->msix_cap)
> > > return -EINVAL;
> > >
> > > - reg = ep->msix_cap + PCI_MSIX_FLAGS;
> > > + reg = ep->msix_cap + func_offset + PCI_MSIX_FLAGS;
> > > val = dw_pcie_readw_dbi(pci, reg);
> > > val &= ~PCI_MSIX_FLAGS_QSIZE;
> > > val |= interrupts;
> > > @@ -398,29 +436,33 @@ int dw_pcie_ep_raise_msi_irq(struct
> > dw_pcie_ep *ep, u8 func_no,
> > > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > struct pci_epc *epc = ep->epc;
> > > unsigned int aligned_offset;
> > > + unsigned int func_offset = 0;
> > > u16 msg_ctrl, msg_data;
> > > u32 msg_addr_lower, msg_addr_upper, reg;
> > > u64 msg_addr;
> > > bool has_upper;
> > > int ret;
> > >
> > > + if (ep->ops->func_conf_select)
> > > + func_offset = ep->ops->func_conf_select(ep, func_no);
> > > +
> >
> > You could probably move this hunk below the test for msi_cap to save some
> > cycles.
>
> Sorry, I didn't understand the means, please explain it detailly, thanks a lot, ^_^
If you insert the call to func_conf_select *after* the test for
!msi_cap below - then in the case where msi_cap is NULL then you will
save some CPU cycles by not bothering to call func_conf_select.
> >
> > > if (!ep->msi_cap)
> > > return -EINVAL;
> > >
> > > /* Raise MSI per the PCI Local Bus Specification Revision 3.0, 6.8.1. */
> > > - reg = ep->msi_cap + PCI_MSI_FLAGS;
> > > + reg = ep->msi_cap + func_offset + PCI_MSI_FLAGS;
> > > msg_ctrl = dw_pcie_readw_dbi(pci, reg);
> > > has_upper = !!(msg_ctrl & PCI_MSI_FLAGS_64BIT);
> > > - reg = ep->msi_cap + PCI_MSI_ADDRESS_LO;
> > > + reg = ep->msi_cap + func_offset + PCI_MSI_ADDRESS_LO;
> > > msg_addr_lower = dw_pcie_readl_dbi(pci, reg);
> > > if (has_upper) {
> > > - reg = ep->msi_cap + PCI_MSI_ADDRESS_HI;
> > > + reg = ep->msi_cap + func_offset + PCI_MSI_ADDRESS_HI;
> > > msg_addr_upper = dw_pcie_readl_dbi(pci, reg);
> > > - reg = ep->msi_cap + PCI_MSI_DATA_64;
> > > + reg = ep->msi_cap + func_offset + PCI_MSI_DATA_64;
> > > msg_data = dw_pcie_readw_dbi(pci, reg);
> > > } else {
> > > msg_addr_upper = 0;
> > > - reg = ep->msi_cap + PCI_MSI_DATA_32;
> > > + reg = ep->msi_cap + func_offset + PCI_MSI_DATA_32;
> > > msg_data = dw_pcie_readw_dbi(pci, reg);
> > > }
> > > aligned_offset = msg_addr_lower & (epc->mem->page_size - 1);
> >
> >
> >
> > > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > > b/drivers/pci/controller/dwc/pcie-designware.c
> > > index 7d25102..305e73d 100644
> > > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > > @@ -158,9 +158,10 @@ static void dw_pcie_writel_ob_unroll(struct
> > dw_pcie *pci, u32 index, u32 reg,
> > > dw_pcie_writel_atu(pci, offset + reg, val); }
> > >
> > > -static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, int
> > index,
> > > - int type, u64 cpu_addr,
> > > - u64 pci_addr, u32 size)
> > > +static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, u8
> > func_no,
> > > + int index, int type,
> > > + u64 cpu_addr, u64 pci_addr,
> > > + u32 size)
> > > {
> > > u32 retries, val;
> > >
> > > @@ -175,7 +176,7 @@ static void
> > dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, int index,
> > > dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_UPPER_TARGET,
> > > upper_32_bits(pci_addr));
> > > dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL1,
> > > - type);
> > > + type | PCIE_ATU_FUNC_NUM(func_no));
> >
> > Much better :)
>
> Do you mean that use the expression "a? b:c"
>
> >
> > > dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL2,
> > > PCIE_ATU_ENABLE);
> > >
> > > @@ -194,8 +195,9 @@ static void
> > dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, int index,
> > > dev_err(pci->dev, "Outbound iATU is not being enabled\n"); }
> > >
> > > -void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
> > > - u64 cpu_addr, u64 pci_addr, u32 size)
> > > +static void __dw_pcie_prog_outbound_atu(struct dw_pcie *pci, u8
> > func_no,
> > > + int index, int type, u64 cpu_addr,
> > > + u64 pci_addr, u32 size)
> > > {
> > > u32 retries, val;
> > >
> > > @@ -203,8 +205,8 @@ void dw_pcie_prog_outbound_atu(struct dw_pcie
> > *pci, int index, int type,
> > > cpu_addr = pci->ops->cpu_addr_fixup(pci, cpu_addr);
> > >
> > > if (pci->iatu_unroll_enabled) {
> > > - dw_pcie_prog_outbound_atu_unroll(pci, index, type, cpu_addr,
> > > - pci_addr, size);
> > > + dw_pcie_prog_outbound_atu_unroll(pci, func_no, index, type,
> > > + cpu_addr, pci_addr, size);
> > > return;
> > > }
> > >
> >
> >
> > > diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> > > b/drivers/pci/controller/dwc/pcie-designware.h
> > > index ffed084..a0fdbf7 100644
> > > --- a/drivers/pci/controller/dwc/pcie-designware.h
> > > +++ b/drivers/pci/controller/dwc/pcie-designware.h
> > > @@ -71,9 +71,11 @@
> > > #define PCIE_ATU_TYPE_IO 0x2
> > > #define PCIE_ATU_TYPE_CFG0 0x4
> > > #define PCIE_ATU_TYPE_CFG1 0x5
> > > +#define PCIE_ATU_FUNC_NUM(pf) (pf << 20)
> >
> > "Macro argument 'pf' may be better as '(pf)' to avoid precedence issues"
> >
> > > #define PCIE_ATU_CR2 0x908
> > > #define PCIE_ATU_ENABLE BIT(31)
> > > #define PCIE_ATU_BAR_MODE_ENABLE BIT(30)
> > > +#define PCIE_ATU_FUNC_NUM_MATCH_EN BIT(19)
> > > #define PCIE_ATU_LOWER_BASE 0x90C
> > > #define PCIE_ATU_UPPER_BASE 0x910
> > > #define PCIE_ATU_LIMIT 0x914
> > > @@ -197,6 +199,7 @@ struct dw_pcie_ep_ops {
> > > int (*raise_irq)(struct dw_pcie_ep *ep, u8 func_no,
> > > enum pci_epc_irq_type type, u16 interrupt_num);
> > > const struct pci_epc_features* (*get_features)(struct dw_pcie_ep
> > > *ep);
> > > + unsigned int (*func_conf_select)(struct dw_pcie_ep *ep, u8 func_no);
> >
> > Given that this function will return an offset, I'm not sure the name you have
> > is suitable. Something like get_pf_offset or similar is more descriptive.
>
> As above explain, my initial view is that this function can return 0 or offset depends on
> the platform implement mechanism, so I named it func_conf_select, I think add a
> comment for this function, like this:
> /*
> * provide a method to implement the method of different func config space access,
> * if use offset method, return the offset from dbi_base, if your register method, implement
> * the code in this callback function and return 0.
> */
> How about it?
This means that func_conf_select can never (easily) indicate an error to the
caller as this would change the offset. Where func_conf_select doesn't change
the offset there probably isn't much else it can do instead (unless it was
responsible for doing the write as well). So I'm not sure how well this approach
works.
Thanks,
Andrew Murray
>
> >
> > Thanks,
> >
> > Andrew Murray
> >
> > > };
> > >
> > > struct dw_pcie_ep {
> > > @@ -265,8 +268,12 @@ int dw_pcie_wait_for_link(struct dw_pcie *pci);
> > > void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
> > > int type, u64 cpu_addr, u64 pci_addr,
> > > u32 size);
> > > -int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, int index, int bar,
> > > - u64 cpu_addr, enum dw_pcie_as_type as_type);
> > > +void dw_pcie_prog_ep_outbound_atu(struct dw_pcie *pci, u8 func_no, int
> > index,
> > > + int type, u64 cpu_addr, u64 pci_addr,
> > > + u32 size);
> > > +int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, u8 func_no, int index,
> > > + int bar, u64 cpu_addr,
> > > + enum dw_pcie_as_type as_type);
> > > void dw_pcie_disable_atu(struct dw_pcie *pci, int index,
> > > enum dw_pcie_region_type type);
> > > void dw_pcie_setup(struct dw_pcie *pci);
> > > --
> > > 2.9.5
> > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: linux-next: Fixes tags need some work in the arm-soc tree
From: Arnd Bergmann @ 2019-08-27 13:07 UTC (permalink / raw)
To: Alexandre Torgue
Cc: Stephen Rothwell, Linux Kernel Mailing List,
Linux Next Mailing List, Olof Johansson, Fabrice Gasnier, ARM
In-Reply-To: <f4e0e924-03ea-bf63-85a0-5718874ceb38@st.com>
On Mon, Aug 26, 2019 at 11:44 AM Alexandre Torgue
<alexandre.torgue@st.com> wrote:
> On 8/13/19 11:47 PM, Stephen Rothwell wrote:
> > Hi Arnd,
> >
> > On Tue, 13 Aug 2019 21:35:58 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
> >>
> >> On Tue, Aug 13, 2019 at 4:28 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>
> >>>
> >>> Please do not split Fixes tags over more than one line. Also, please
> >>> keep them with the rest of the other tags.
> >>
> >> Thanks for the report. How bad is this? Should I undo the merge and
> >> wait for an updated pull request?
> >
> > Its probably ok to leave as long as lessons are learnt :-)
> >
>
> Sorry for my late answer.
>
> Thanks Stephen for information. I'll take care next time before merging
> patches with "fixes" tag.
>
> Arnd, no need to update the PR ?
No, since it's already pulled, just leave it for this time.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/4] watchdog/aspeed: add support for dual boot
From: Guenter Roeck @ 2019-08-27 13:06 UTC (permalink / raw)
To: Ivan Mikhaylov, Wim Van Sebroeck
Cc: Mark Rutland, devicetree, linux-watchdog, linux-aspeed,
Andrew Jeffery, openbmc, Alexander Amelkin, linux-kernel,
Rob Herring, Joel Stanley, linux-arm-kernel
In-Reply-To: <818746d20661b51914a7802dcbe0081352900b05.camel@yadro.com>
On 8/27/19 2:24 AM, Ivan Mikhaylov wrote:
> On Mon, 2019-08-26 at 17:14 -0700, Guenter Roeck wrote:
>>> +/*
>>> + * At alternate side the 'access_cs0' sysfs node provides:
>>> + * ast2400: a way to get access to the primary SPI flash chip at CS0
>>> + * after booting from the alternate chip at CS1.
>>> + * ast2500: a way to restore the normal address mapping from
>>> + * (CS0->CS1, CS1->CS0) to (CS0->CS0, CS1->CS1).
>>> + *
>>> + * Clearing the boot code selection and timeout counter also resets to the
>>> + * initial state the chip select line mapping. When the SoC is in normal
>>> + * mapping state (i.e. booted from CS0), clearing those bits does nothing
>>> for
>>> + * both versions of the SoC. For alternate boot mode (booted from CS1 due
>>> to
>>> + * wdt2 expiration) the behavior differs as described above.
>>> + *
>> The above needs to be in the sysfs attribute documentation as well.
>
> My apologies but I didn't find any suitable, only watchdog parameters with
> dtbindings file, where should I put it? Documentation/watchdog/aspeed-wdt-
> sysfs.rst?
>
Documentation/ABI/testing/sysfs-class-watchdog
Guenter
>>> + * This option can be used with wdt2 (watchdog1) only.
>>
>> This implies a specific watchdog numbering which is not guaranteed.
>> Someone might implement a system with some external watchdog.
>>
>>> + */
>>> +static DEVICE_ATTR_RW(access_cs0);
>>> +
>>> +static struct attribute *bswitch_attrs[] = {
>>> + &dev_attr_access_cs0.attr,
>>> + NULL
>>> +};
>>> +ATTRIBUTE_GROUPS(bswitch);
>>> +
>>> static const struct watchdog_ops aspeed_wdt_ops = {
>>> .start = aspeed_wdt_start,
>>> .stop = aspeed_wdt_stop,
>>> @@ -306,9 +359,16 @@ static int aspeed_wdt_probe(struct platform_device
>>> *pdev)
>>> }
>>>
>>> status = readl(wdt->base + WDT_TIMEOUT_STATUS);
>>> - if (status & WDT_TIMEOUT_STATUS_BOOT_SECONDARY)
>>> + if (status & WDT_TIMEOUT_STATUS_BOOT_SECONDARY) {
>>> wdt->wdd.bootstatus = WDIOF_CARDRESET;
>>>
>>> + if (of_device_is_compatible(np, "aspeed,ast2400-wdt") ||
>>> + of_device_is_compatible(np, "aspeed,ast2500-wdt"))
>>> + wdt->wdd.groups = bswitch_groups;
>
>> Kind of odd that the attribute only exists if the system booted from the
>> second flash, but if that is what you want I won't object. Just make sure
>> that this is explained properly.
> Perhaps dts configuration option would be better solution for it then? "force-
> cs0-switch" as example? Also, if it would be an option, dtbindings/wdt file for
You said earlier that this can not be done automatically but _must_ be done
from user space after the system has booted. Otherwise you could just
automatically switch to cs0 when the driver probes.
As I said, all I am asking for is proper documentation.
Guenter
> documentation will be the right place for it. Usage of this at side 0 will not
> get any good/bad results, it just makes user confused, so I decided to put it
> only at side 1. It works only for ast2400/2500 board unfortunately, for 2600
> there is big difference in switching mechanism. Any other thoughts how to make
> it better?
>
> Thanks.
>
>
_______________________________________________
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 10/10] arm64: Retrieve stolen time as paravirtualized guest
From: Zenghui Yu @ 2019-08-27 12:43 UTC (permalink / raw)
To: Steven Price, Marc Zyngier, Will Deacon, linux-arm-kernel, kvmarm
Cc: kvm, linux-doc, Catalin Marinas, linux-kernel, Russell King,
Paolo Bonzini
In-Reply-To: <29cd1304-6b4d-05ef-3c08-6b4ba769c8fa@arm.com>
On 2019/8/23 22:22, Steven Price wrote:
> On 23/08/2019 12:45, Zenghui Yu wrote:
>> Hi Steven,
>>
>> On 2019/8/21 23:36, Steven Price wrote:
>>> Enable paravirtualization features when running under a hypervisor
>>> supporting the PV_TIME_ST hypercall.
>>>
>>> For each (v)CPU, we ask the hypervisor for the location of a shared
>>> page which the hypervisor will use to report stolen time to us. We set
>>> pv_time_ops to the stolen time function which simply reads the stolen
>>> value from the shared page for a VCPU. We guarantee single-copy
>>> atomicity using READ_ONCE which means we can also read the stolen
>>> time for another VCPU than the currently running one while it is
>>> potentially being updated by the hypervisor.
>>>
>>> Signed-off-by: Steven Price <steven.price@arm.com>
>>> ---
>>> arch/arm64/include/asm/paravirt.h | 9 +-
>>> arch/arm64/kernel/paravirt.c | 148 ++++++++++++++++++++++++++++++
>>> arch/arm64/kernel/time.c | 3 +
>>> include/linux/cpuhotplug.h | 1 +
>>> 4 files changed, 160 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/include/asm/paravirt.h
>>> b/arch/arm64/include/asm/paravirt.h
>>> index 799d9dd6f7cc..125c26c42902 100644
>>> --- a/arch/arm64/include/asm/paravirt.h
>>> +++ b/arch/arm64/include/asm/paravirt.h
>>> @@ -21,6 +21,13 @@ static inline u64 paravirt_steal_clock(int cpu)
>>> {
>>> return pv_ops.time.steal_clock(cpu);
>>> }
>>> -#endif
>>> +
>>> +int __init kvm_guest_init(void);
>>> +
>>> +#else
>>> +
>>> +#define kvm_guest_init()
>>> +
>>> +#endif // CONFIG_PARAVIRT
>>> #endif
>>> diff --git a/arch/arm64/kernel/paravirt.c b/arch/arm64/kernel/paravirt.c
>>> index 4cfed91fe256..ea8dbbbd3293 100644
>>> --- a/arch/arm64/kernel/paravirt.c
>>> +++ b/arch/arm64/kernel/paravirt.c
>>> @@ -6,13 +6,161 @@
>>> * Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> */
>>> +#define pr_fmt(fmt) "kvmarm-pv: " fmt
>>> +
>>> +#include <linux/arm-smccc.h>
>>> +#include <linux/cpuhotplug.h>
>>> #include <linux/export.h>
>>> +#include <linux/io.h>
>>> #include <linux/jump_label.h>
>>> +#include <linux/printk.h>
>>> +#include <linux/psci.h>
>>> +#include <linux/reboot.h>
>>> +#include <linux/slab.h>
>>> #include <linux/types.h>
>>> +
>>> #include <asm/paravirt.h>
>>> +#include <asm/pvclock-abi.h>
>>> +#include <asm/smp_plat.h>
>>> struct static_key paravirt_steal_enabled;
>>> struct static_key paravirt_steal_rq_enabled;
>>> struct paravirt_patch_template pv_ops;
>>> EXPORT_SYMBOL_GPL(pv_ops);
>>> +
>>> +struct kvmarm_stolen_time_region {
>>> + struct pvclock_vcpu_stolen_time *kaddr;
>>> +};
>>> +
>>> +static DEFINE_PER_CPU(struct kvmarm_stolen_time_region,
>>> stolen_time_region);
>>> +
>>> +static bool steal_acc = true;
>>> +static int __init parse_no_stealacc(char *arg)
>>> +{
>>> + steal_acc = false;
>>> + return 0;
>>> +}
>>> +
>>> +early_param("no-steal-acc", parse_no_stealacc);
>>> +
>>> +/* return stolen time in ns by asking the hypervisor */
>>> +static u64 kvm_steal_clock(int cpu)
>>> +{
>>> + struct kvmarm_stolen_time_region *reg;
>>> +
>>> + reg = per_cpu_ptr(&stolen_time_region, cpu);
>>> + if (!reg->kaddr) {
>>> + pr_warn_once("stolen time enabled but not configured for cpu
>>> %d\n",
>>> + cpu);
>>> + return 0;
>>> + }
>>> +
>>> + return le64_to_cpu(READ_ONCE(reg->kaddr->stolen_time));
>>> +}
>>> +
>>> +static int disable_stolen_time_current_cpu(void)
>>> +{
>>> + struct kvmarm_stolen_time_region *reg;
>>> +
>>> + reg = this_cpu_ptr(&stolen_time_region);
>>> + if (!reg->kaddr)
>>> + return 0;
>>> +
>>> + memunmap(reg->kaddr);
>>> + memset(reg, 0, sizeof(*reg));
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int stolen_time_dying_cpu(unsigned int cpu)
>>> +{
>>> + return disable_stolen_time_current_cpu();
>>> +}
>>> +
>>> +static int init_stolen_time_cpu(unsigned int cpu)
>>> +{
>>> + struct kvmarm_stolen_time_region *reg;
>>> + struct arm_smccc_res res;
>>> +
>>> + reg = this_cpu_ptr(&stolen_time_region);
>>> +
>>> + arm_smccc_1_1_invoke(ARM_SMCCC_HV_PV_TIME_ST, &res);
>>> +
>>> + if ((long)res.a0 < 0)
>>> + return -EINVAL;
>>> +
>>> + reg->kaddr = memremap(res.a0,
>>> + sizeof(struct pvclock_vcpu_stolen_time),
>>> + MEMREMAP_WB);
>>
>> cpuhp callbacks can be invoked in atomic context (see:
>> secondary_start_kernel ->
>> notify_cpu_starting ->
>> invoke callbacks),
>> but memremap might sleep...
>>
>> Try to run a DEBUG_ATOMIC_SLEEP enabled PV guest, I guess we will be
>> greeted by the Sleep-in-Atomic-Context BUG. We need an alternative
>> here?
>
> Actually I had run DEBUG_ATOMIC_SLEEP and not seen any issue. But I
> think that's because of the way I've configured the region in my kvmtool
> changes. I'm hitting the path where the memory region is in the linear
> map of the kernel and so no actual remapping is needed and hence
> memremap doesn't sleep (the shared structure is in a reserved region of
> RAM).
>
> But even changing the memory layout of the guest so the call goes into
> ioremap_page_range() (which contains a might_sleep()) I'm not seeing any
> problems.
Emm, I hit this SAC BUG when testing your V1 with the kvmtool changes
you've provided, but forgot to report it at that time. I go back to V1
and get the following call trace:
[ 0.120113] BUG: sleeping function called from invalid context at
mm/slab.h:501
[ 0.120118] in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/1
[ 0.120122] no locks held by swapper/1/0.
[ 0.120126] irq event stamp: 0
[ 0.120135] hardirqs last enabled at (0): [<0000000000000000>] 0x0
[ 0.120145] hardirqs last disabled at (0): [<ffff200010113b40>]
copy_process+0x870/0x2878
[ 0.120152] softirqs last enabled at (0): [<ffff200010113b40>]
copy_process+0x870/0x2878
[ 0.120157] softirqs last disabled at (0): [<0000000000000000>] 0x0
[ 0.120164] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.3.0-rc6+ #2
[ 0.120168] Hardware name: linux,dummy-virt (DT)
[ 0.120173] Call trace:
[ 0.120179] dump_backtrace+0x0/0x250
[ 0.120184] show_stack+0x24/0x30
[ 0.120192] dump_stack+0x120/0x174
[ 0.120198] ___might_sleep+0x1b0/0x280
[ 0.120203] __might_sleep+0x80/0xf0
[ 0.120209] kmem_cache_alloc_node_trace+0x30c/0x3c8
[ 0.120216] __get_vm_area_node+0x9c/0x208
[ 0.120221] get_vm_area_caller+0x58/0x68
[ 0.120227] __ioremap_caller+0x78/0x120
[ 0.120233] ioremap_cache+0xf0/0x1a8
[ 0.120240] memremap+0x154/0x3b8
[ 0.120245] init_stolen_time_cpu+0x94/0x150
[ 0.120251] cpuhp_invoke_callback+0x12c/0x12f8
[ 0.120257] notify_cpu_starting+0xa0/0xc0
[ 0.120263] secondary_start_kernel+0x1d4/0x328
But things may have changed because we're talking about V3 now...
I will dig it a bit deeper.
> Am I missing something? I have to admit I don't entirely follow the
> early start up - perhaps it's a simple as DEBUG_ATOMIC_SLEEP doesn't
> work this early in boot?
I think it should work.
Thanks,
zenghui
_______________________________________________
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] dt-bindings: mmc: aspeed: Update example ranges property
From: Rob Herring @ 2019-08-27 12:36 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Mark Rutland, devicetree, Ulf Hansson, linux-aspeed, linux-mmc,
linux-kernel@vger.kernel.org, Joel Stanley,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190826021620.11915-1-andrew@aj.id.au>
On Sun, Aug 25, 2019 at 9:15 PM Andrew Jeffery <andrew@aj.id.au> wrote:
>
> The example node in the binding uses the AST2500 compatible string for
> the SD controller with a 64kiB ranges property, but the SD controller is
> allocated 128kiB of MMIO space according to the AST2500 datasheet. Fix
> the example to correctly reflect the hardware in the AST2500, however it
> should be noted that the MMIO region is reduced to 64kiB in the AST2600
> where a second SD controller block has been introduced into the address
> space.
>
> Also add the IBM copyright header that I left out of the initial patch.
>
> Suggested-by: Joel Stanley <joel@jms.id.au>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> Hi Ulf, this is the follow-up fix as discussed here:
>
> http://patchwork.ozlabs.org/patch/1143090/
>
> Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 1/2] input: keyboard: snvs_pwrkey: Send key events for i.MX6 S, DL and Q
From: Robin van der Gracht @ 2019-08-27 12:32 UTC (permalink / raw)
To: Robin Gong
Cc: Mark Rutland, devicetree @ vger . kernel . org,
Robin van der Gracht, Shawn Guo, Sascha Hauer, Dmitry Torokhov,
linux-kernel @ vger . kernel . org, Rob Herring, dl-linux-imx,
Pengutronix Kernel Team, linux-input @ vger . kernel . org,
Adam Ford, Fabio Estevam,
linux-arm-kernel @ lists . infradead . org
The first generation i.MX6 processors does not send an interrupt when the
power key is pressed. It sends a power down request interrupt if the key is
released before a hard shutdown (5 second press). This should allow
software to bring down the SoC safely.
For this driver to work as a regular power key with the older SoCs, we need
to send a keypress AND release when we get the power down request irq.
Signed-off-by: Robin van der Gracht <robin@protonic.nl>
---
.../devicetree/bindings/crypto/fsl-sec4.txt | 16 ++++--
drivers/input/keyboard/Kconfig | 2 +-
drivers/input/keyboard/snvs_pwrkey.c | 52 ++++++++++++++++---
3 files changed, 57 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
index 2fe245ca816a..e4fbb9797082 100644
--- a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
+++ b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
@@ -420,14 +420,22 @@ EXAMPLE
=====================================================================
System ON/OFF key driver
- The snvs-pwrkey is designed to enable POWER key function which controlled
- by SNVS ONOFF, the driver can report the status of POWER key and wakeup
- system if pressed after system suspend.
+ The snvs-pwrkey is designed to enable POWER key function which is controlled
+ by SNVS ONOFF. It can wakeup the system if pressed after system suspend.
+
+ There are two generations of SVNS pwrkey hardware. The first generation is
+ included in i.MX6 Solo, DualLite and Quad processors. The second generation
+ is included in i.MX6 SoloX and newer SoCs.
+
+ Second generation SNVS can detect and report the status of POWER key, but the
+ first generation can only detect a key release and so emits an instantaneous
+ press and release event when the key is released.
- compatible:
Usage: required
Value type: <string>
- Definition: Mush include "fsl,sec-v4.0-pwrkey".
+ Definition: Must include "fsl,sec-v4.0-pwrkey" for i.MX6 SoloX and newer
+ or "fsl,imx6qdl-snvs-pwrkey" for older SoCs.
- interrupts:
Usage: required
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 7c4f19dab34f..937e58da5ce1 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -436,7 +436,7 @@ config KEYBOARD_SNVS_PWRKEY
depends on OF
help
This is the snvs powerkey driver for the Freescale i.MX application
- processors that are newer than i.MX6 SX.
+ processors.
To compile this driver as a module, choose M here; the
module will be called snvs_pwrkey.
diff --git a/drivers/input/keyboard/snvs_pwrkey.c b/drivers/input/keyboard/snvs_pwrkey.c
index 5342d8d45f81..d71c44733103 100644
--- a/drivers/input/keyboard/snvs_pwrkey.c
+++ b/drivers/input/keyboard/snvs_pwrkey.c
@@ -29,6 +29,11 @@
#define DEBOUNCE_TIME 30
#define REPEAT_INTERVAL 60
+enum imx_snvs_hwtype {
+ IMX6SX_SNVS, /* i.MX6 SoloX and newer */
+ IMX6QDL_SNVS, /* i.MX6 Solo, DualLite and Quad */
+};
+
struct pwrkey_drv_data {
struct regmap *snvs;
int irq;
@@ -37,14 +42,41 @@ struct pwrkey_drv_data {
int wakeup;
struct timer_list check_timer;
struct input_dev *input;
+ enum imx_snvs_hwtype hwtype;
};
+static const struct of_device_id imx_snvs_pwrkey_ids[] = {
+ {
+ .compatible = "fsl,sec-v4.0-pwrkey",
+ .data = (const void *)IMX6SX_SNVS,
+ },
+ {
+ .compatible = "fsl,imx6qdl-snvs-pwrkey",
+ .data = (const void *)IMX6QDL_SNVS,
+ },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, imx_snvs_pwrkey_ids);
+
static void imx_imx_snvs_check_for_events(struct timer_list *t)
{
struct pwrkey_drv_data *pdata = from_timer(pdata, t, check_timer);
struct input_dev *input = pdata->input;
u32 state;
+ if (pdata->hwtype == IMX6QDL_SNVS) {
+ /*
+ * The first generation i.MX6 SoCs only sends an interrupt on
+ * button release. To mimic power-key usage, we'll prepend a
+ * press event.
+ */
+ input_report_key(input, pdata->keycode, 1);
+ input_report_key(input, pdata->keycode, 0);
+ input_sync(input);
+ pm_relax(input->dev.parent);
+ return;
+ }
+
regmap_read(pdata->snvs, SNVS_HPSR_REG, &state);
state = state & SNVS_HPSR_BTN ? 1 : 0;
@@ -67,13 +99,17 @@ static irqreturn_t imx_snvs_pwrkey_interrupt(int irq, void *dev_id)
{
struct platform_device *pdev = dev_id;
struct pwrkey_drv_data *pdata = platform_get_drvdata(pdev);
+ unsigned long expire = jiffies;
u32 lp_status;
pm_wakeup_event(pdata->input->dev.parent, 0);
regmap_read(pdata->snvs, SNVS_LPSR_REG, &lp_status);
- if (lp_status & SNVS_LPSR_SPO)
- mod_timer(&pdata->check_timer, jiffies + msecs_to_jiffies(DEBOUNCE_TIME));
+ if (lp_status & SNVS_LPSR_SPO) {
+ if (pdata->hwtype == IMX6SX_SNVS)
+ expire += msecs_to_jiffies(DEBOUNCE_TIME);
+ mod_timer(&pdata->check_timer, expire);
+ }
/* clear SPO status */
regmap_write(pdata->snvs, SNVS_LPSR_REG, SNVS_LPSR_SPO);
@@ -93,6 +129,7 @@ static int imx_snvs_pwrkey_probe(struct platform_device *pdev)
struct pwrkey_drv_data *pdata = NULL;
struct input_dev *input = NULL;
struct device_node *np;
+ const struct of_device_id *match;
int error;
/* Get SNVS register Page */
@@ -100,6 +137,10 @@ static int imx_snvs_pwrkey_probe(struct platform_device *pdev)
if (!np)
return -ENODEV;
+ match = of_match_node(imx_snvs_pwrkey_ids, np);
+ if (!match)
+ return -ENODEV;
+
pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
return -ENOMEM;
@@ -115,6 +156,7 @@ static int imx_snvs_pwrkey_probe(struct platform_device *pdev)
dev_warn(&pdev->dev, "KEY_POWER without setting in dts\n");
}
+ pdata->hwtype = (enum imx_snvs_hwtype)match->data;
pdata->wakeup = of_property_read_bool(np, "wakeup-source");
pdata->irq = platform_get_irq(pdev, 0);
@@ -175,12 +217,6 @@ static int imx_snvs_pwrkey_probe(struct platform_device *pdev)
return 0;
}
-static const struct of_device_id imx_snvs_pwrkey_ids[] = {
- { .compatible = "fsl,sec-v4.0-pwrkey" },
- { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(of, imx_snvs_pwrkey_ids);
-
static struct platform_driver imx_snvs_pwrkey_driver = {
.driver = {
.name = "snvs_pwrkey",
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/2] arm: dts: imx6qdl: snvs-pwrkey: Change compatible string
From: Robin van der Gracht @ 2019-08-27 12:32 UTC (permalink / raw)
To: Robin Gong
Cc: Mark Rutland, devicetree @ vger . kernel . org,
Robin van der Gracht, Shawn Guo, Sascha Hauer, Dmitry Torokhov,
linux-kernel @ vger . kernel . org, Rob Herring, dl-linux-imx,
Pengutronix Kernel Team, linux-input @ vger . kernel . org,
Adam Ford, Fabio Estevam,
linux-arm-kernel @ lists . infradead . org
In-Reply-To: <20190827123216.32728-1-robin@protonic.nl>
The older imx6 SoCs do not send a power key press interrupt, instead it
sends a power down request interrupt when the key is released between
750ms and 5 seconds. The driver uses a different compatible string to ID
the older SoCs.
Signed-off-by: Robin van der Gracht <robin@protonic.nl>
---
arch/arm/boot/dts/imx6qdl.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index b3a77bcf00d5..91b97816881c 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -836,7 +836,7 @@
};
snvs_pwrkey: snvs-powerkey {
- compatible = "fsl,sec-v4.0-pwrkey";
+ compatible = "fsl,imx6qdl-snvs-pwrkey";
regmap = <&snvs>;
interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
linux,keycode = <KEY_POWER>;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/2] ASoC: sun4i: Revert A83t description
From: Maxime Ripard @ 2019-08-27 12:31 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, lgirdwood, broonie
Cc: codekipper, alsa-devel, linux-kernel, linux-arm-kernel
In-Reply-To: <20190827123131.29129-1-mripard@kernel.org>
From: Maxime Ripard <maxime.ripard@bootlin.com>
The last set of reworks included some fixes to change the A83t behaviour
and "fix" it.
It turns out that the controller described in the datasheet and the one
supported here are not the same, yet the A83t has the two of them, and the
one supported in the driver wasn't the one described in the datasheet.
Fix this by reintroducing the proper quirks.
Fixes: 69e450e50ca6 ("ASoC: sun4i-i2s: Fix the LRCK period on A83t")
Fixes: bf943d527987 ("ASoC: sun4i-i2s: Fix MCLK Enable bit offset on A83t")
Fixes: 2e04fc4dbf50 ("ASoC: sun4i-i2s: Fix WSS and SR fields for the A83t")
Fixes: 515fcfbc7736 ("ASoC: sun4i-i2s: Fix LRCK and BCLK polarity offsets on newer SoCs")
Fixes: c1d3a921d72b ("ASoC: sun4i-i2s: Fix the MCLK and BCLK dividers on newer SoCs")
Fixes: fb19739d7f68 ("ASoC: sun4i-i2s: Use module clock as BCLK parent on newer SoCs")
Fixes: 71137bcd0a9a ("ASoC: sun4i-i2s: Move the format configuration to a callback")
Fixes: d70be625f25a ("ASoC: sun4i-i2s: Move the channel configuration to a callback")
Reported-by: Chen-Yu Tsai <wens@csie.org>
Tested-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
Changes from v1:
- Fix function name
---
sound/soc/sunxi/sun4i-i2s.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index a6a3f772fdf0..d0a8d5810c0a 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -1106,18 +1106,18 @@ static const struct sun4i_i2s_quirks sun8i_a83t_i2s_quirks = {
.has_reset = true,
.reg_offset_txdata = SUN8I_I2S_FIFO_TX_REG,
.sun4i_i2s_regmap = &sun4i_i2s_regmap_config,
- .field_clkdiv_mclk_en = REG_FIELD(SUN4I_I2S_CLK_DIV_REG, 8, 8),
- .field_fmt_wss = REG_FIELD(SUN4I_I2S_FMT0_REG, 0, 2),
- .field_fmt_sr = REG_FIELD(SUN4I_I2S_FMT0_REG, 4, 6),
- .bclk_dividers = sun8i_i2s_clk_div,
- .num_bclk_dividers = ARRAY_SIZE(sun8i_i2s_clk_div),
- .mclk_dividers = sun8i_i2s_clk_div,
- .num_mclk_dividers = ARRAY_SIZE(sun8i_i2s_clk_div),
- .get_bclk_parent_rate = sun8i_i2s_get_bclk_parent_rate,
- .get_sr = sun8i_i2s_get_sr_wss,
- .get_wss = sun8i_i2s_get_sr_wss,
- .set_chan_cfg = sun8i_i2s_set_chan_cfg,
- .set_fmt = sun8i_i2s_set_soc_fmt,
+ .field_clkdiv_mclk_en = REG_FIELD(SUN4I_I2S_CLK_DIV_REG, 7, 7),
+ .field_fmt_wss = REG_FIELD(SUN4I_I2S_FMT0_REG, 2, 3),
+ .field_fmt_sr = REG_FIELD(SUN4I_I2S_FMT0_REG, 4, 5),
+ .bclk_dividers = sun4i_i2s_bclk_div,
+ .num_bclk_dividers = ARRAY_SIZE(sun4i_i2s_bclk_div),
+ .mclk_dividers = sun4i_i2s_mclk_div,
+ .num_mclk_dividers = ARRAY_SIZE(sun4i_i2s_mclk_div),
+ .get_bclk_parent_rate = sun4i_i2s_get_bclk_parent_rate,
+ .get_sr = sun4i_i2s_get_sr,
+ .get_wss = sun4i_i2s_get_wss,
+ .set_chan_cfg = sun4i_i2s_set_chan_cfg,
+ .set_fmt = sun4i_i2s_set_soc_fmt,
};
static const struct sun4i_i2s_quirks sun8i_h3_i2s_quirks = {
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 1/2] ASoC: sun4i-i2s: Revert "ASoC: sun4i-i2s: Remove duplicated quirks structure"
From: Maxime Ripard @ 2019-08-27 12:31 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, lgirdwood, broonie
Cc: codekipper, alsa-devel, linux-kernel, linux-arm-kernel
From: Maxime Ripard <maxime.ripard@bootlin.com>
This reverts commit 3e9acd7ac6933cdc20c441bbf9a38ed9e42e1490.
It turns out that while one I2S controller is described in the A83t
datasheet, the driver supports another, undocumented, one that has been
inherited from the older SoCs, while the documented one uses the new
design.
Fixes: 3e9acd7ac693 ("ASoC: sun4i-i2s: Remove duplicated quirks structure")
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
Changes from v1:
- Add the proper prefix to the commit title
---
sound/soc/sunxi/sun4i-i2s.c | 25 ++++++++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 57bf2a33753e..a6a3f772fdf0 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -1097,6 +1097,11 @@ static const struct sun4i_i2s_quirks sun6i_a31_i2s_quirks = {
.set_fmt = sun4i_i2s_set_soc_fmt,
};
+/*
+ * This doesn't describe the TDM controller documented in the A83t
+ * datasheet, but the three undocumented I2S controller that use the
+ * older design.
+ */
static const struct sun4i_i2s_quirks sun8i_a83t_i2s_quirks = {
.has_reset = true,
.reg_offset_txdata = SUN8I_I2S_FIFO_TX_REG,
@@ -1115,6 +1120,24 @@ static const struct sun4i_i2s_quirks sun8i_a83t_i2s_quirks = {
.set_fmt = sun8i_i2s_set_soc_fmt,
};
+static const struct sun4i_i2s_quirks sun8i_h3_i2s_quirks = {
+ .has_reset = true,
+ .reg_offset_txdata = SUN8I_I2S_FIFO_TX_REG,
+ .sun4i_i2s_regmap = &sun8i_i2s_regmap_config,
+ .field_clkdiv_mclk_en = REG_FIELD(SUN4I_I2S_CLK_DIV_REG, 8, 8),
+ .field_fmt_wss = REG_FIELD(SUN4I_I2S_FMT0_REG, 0, 2),
+ .field_fmt_sr = REG_FIELD(SUN4I_I2S_FMT0_REG, 4, 6),
+ .bclk_dividers = sun8i_i2s_clk_div,
+ .num_bclk_dividers = ARRAY_SIZE(sun8i_i2s_clk_div),
+ .mclk_dividers = sun8i_i2s_clk_div,
+ .num_mclk_dividers = ARRAY_SIZE(sun8i_i2s_clk_div),
+ .get_bclk_parent_rate = sun8i_i2s_get_bclk_parent_rate,
+ .get_sr = sun8i_i2s_get_sr_wss,
+ .get_wss = sun8i_i2s_get_sr_wss,
+ .set_chan_cfg = sun8i_i2s_set_chan_cfg,
+ .set_fmt = sun8i_i2s_set_soc_fmt,
+};
+
static const struct sun4i_i2s_quirks sun50i_a64_codec_i2s_quirks = {
.has_reset = true,
.reg_offset_txdata = SUN8I_I2S_FIFO_TX_REG,
@@ -1296,7 +1319,7 @@ static const struct of_device_id sun4i_i2s_match[] = {
},
{
.compatible = "allwinner,sun8i-h3-i2s",
- .data = &sun8i_a83t_i2s_quirks,
+ .data = &sun8i_h3_i2s_quirks,
},
{
.compatible = "allwinner,sun50i-a64-codec-i2s",
--
2.21.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] arm: xen: mm: use __GPF_DMA32 for arm64
From: Robin Murphy @ 2019-08-27 12:23 UTC (permalink / raw)
To: Peng Fan, sstabellini@kernel.org, linux@armlinux.org.uk
Cc: van.freenix@gmail.com, xen-devel@lists.xenproject.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, dl-linux-imx
In-Reply-To: <20190709083729.11135-1-peng.fan@nxp.com>
On 09/07/2019 09:22, Peng Fan wrote:
> arm64 shares some code under arch/arm/xen, including mm.c.
> However ZONE_DMA is removed by commit
> ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32").
> So to ARM64, need use __GFP_DMA32.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> arch/arm/xen/mm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
> index e1d44b903dfc..a95e76d18bf9 100644
> --- a/arch/arm/xen/mm.c
> +++ b/arch/arm/xen/mm.c
> @@ -27,7 +27,7 @@ unsigned long xen_get_swiotlb_free_pages(unsigned int order)
>
> for_each_memblock(memory, reg) {
> if (reg->base < (phys_addr_t)0xffffffff) {
> - flags |= __GFP_DMA;
> + flags |= __GFP_DMA | __GFP_DMA32;
Given the definition of GFP_ZONE_BAD, I'm not sure this combination of
flags is strictly valid, but rather is implicitly reliant on only one of
those zones ever actually existing. As such, it seems liable to blow up
if the plans to add ZONE_DMA to arm64[1] go ahead.
Robin.
[1]
https://lore.kernel.org/linux-arm-kernel/20190820145821.27214-1-nsaenzjulienne@suse.de/
> break;
> }
> }
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] Documentation: add link to stm32mp157 docs
From: Gerald BAEZA @ 2019-08-27 12:19 UTC (permalink / raw)
To: corbet@lwn.net, mcoquelin.stm32@gmail.com, Alexandre TORGUE,
linux-doc@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: Gerald BAEZA
Link to the online stm32mp157 documentation added
in the overview.
Signed-off-by: Gerald Baeza <gerald.baeza@st.com>
---
Documentation/arm/stm32/stm32mp157-overview.rst | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/arm/stm32/stm32mp157-overview.rst b/Documentation/arm/stm32/stm32mp157-overview.rst
index f62fdc8..8d5a476 100644
--- a/Documentation/arm/stm32/stm32mp157-overview.rst
+++ b/Documentation/arm/stm32/stm32mp157-overview.rst
@@ -14,6 +14,12 @@ It features:
- Standard connectivity, widely inherited from the STM32 MCU family
- Comprehensive security support
+Resources
+---------
+
+Datasheet and reference manual are publicly available on ST website:
+.. _STM32MP157: https://www.st.com/en/microcontrollers-microprocessors/stm32mp157.html
+
:Authors:
- Ludovic Barre <ludovic.barre@st.com>
--
2.7.4
_______________________________________________
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] usb: dwc3: Add shutdown to platform_driver
From: Vicente Bergas @ 2019-08-27 12:16 UTC (permalink / raw)
To: Felipe Balbi
Cc: Matthias Brugger, Heiko Stuebner, MarcZyngier, Catalin Marinas,
linux-usb, Will Deacon, linux-rockchip, Greg Kroah-Hartman,
Robin Murphy, linux-arm-kernel
In-Reply-To: <87v9uix1sv.fsf@gmail.com>
On Tuesday, August 27, 2019 1:53:04 PM CEST, Felipe Balbi wrote:
> Hi,
>
> Vicente Bergas <vicencb@gmail.com> writes:
>> On Saturday, August 17, 2019 7:41:40 PM CEST, Vicente Bergas wrote:
>>> Otherwise the device keeps writing to memory after kexec and disturbs
>>> the next kernel.
...
>
> why don't you just have shutdown use the same exact function as remove?
> Frankly, though, I still don't fully understand what's going wrong
> here. Why is the device still alive during kexec?
>
> cheers
Hi Felipe,
the remove and shutdown functions have different prototypes, so
shutdown is wrapping remove.
Would it be preferable to cast remove as shutdown?
The issue with kexec is that the device is being used during the livetime
of the first kernel. When the first kernel executes kexec it calls the
shutdown function of drivers (instead of remove). Because of this the dwc3
device keeps doing things like DMA.
While the second kernel is taking over, it gets its memory corrupted with
such DMA accesses from the device. When the second kernel reaches the point
of taking over the dwc3 device, re-initializes it, but it is already too
late. Still worse, if the second kernel did not have the dwc3 driver, it
would get endless memory corruptions.
All in all, devices that can do DMA need to stop doing it on shutdown.
Regards,
Vicenç.
_______________________________________________
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 01/11] kselftest: arm64: introduce new boilerplate code
From: Cristian Marussi @ 2019-08-27 12:14 UTC (permalink / raw)
To: Dave Martin; +Cc: andreyknvl, shuah, linux-arm-kernel, linux-kselftest
In-Reply-To: <20190813162337.GY10425@arm.com>
Hi
On 13/08/2019 17:23, Dave Martin wrote:
> ^ Regarding the subject line, "boilerplate code" sounds a bit vague.
> Could we say something like "Add skeleton Makefile"?
>
Yes of course.
> On Fri, Aug 02, 2019 at 06:02:50PM +0100, Cristian Marussi wrote:
>> Added a new arm64-specific empty subsystem amongst TARGETS of KSFT build
>> framework; once populated with testcases, it will be possible to build
>> and invoke the new KSFT TARGETS=arm64 related tests from the toplevel
>> Makefile in the usual ways.
>>
>> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
>> ---
>> Reviewed the build instructions reported in the README, to be more
>> agnostic regarding user/device etc..
>> ---
>> tools/testing/selftests/Makefile | 1 +
>> tools/testing/selftests/arm64/Makefile | 51 ++++++++++++++++++++++++++
>> tools/testing/selftests/arm64/README | 43 ++++++++++++++++++++++
>> 3 files changed, 95 insertions(+)
>> create mode 100644 tools/testing/selftests/arm64/Makefile
>> create mode 100644 tools/testing/selftests/arm64/README
>>
>> diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
>> index 25b43a8c2b15..1722dae9381a 100644
>> --- a/tools/testing/selftests/Makefile
>> +++ b/tools/testing/selftests/Makefile
>> @@ -1,5 +1,6 @@
>> # SPDX-License-Identifier: GPL-2.0
>> TARGETS = android
>> +TARGETS += arm64
>> TARGETS += bpf
>> TARGETS += breakpoints
>> TARGETS += capabilities
>> diff --git a/tools/testing/selftests/arm64/Makefile b/tools/testing/selftests/arm64/Makefile
>> new file mode 100644
>> index 000000000000..03a0d4f71218
>> --- /dev/null
>> +++ b/tools/testing/selftests/arm64/Makefile
>> @@ -0,0 +1,51 @@
>> +# SPDX-License-Identifier: GPL-2.0
>> +# Copyright (C) 2019 ARM Limited
>> +
>> +# When ARCH not overridden for crosscompiling, lookup machine
>> +ARCH ?= $(shell uname -m)
>> +ARCH := $(shell echo $(ARCH) | sed -e s/aarch64/arm64/)
>> +
>> +ifeq ("x$(ARCH)", "xarm64")
>> +SUBDIRS :=
>> +else
>> +SUBDIRS :=
>> +endif
>> +
>> +CFLAGS := -Wall -O2 -g
>> +
>> +export CC
>> +export CFLAGS
>> +
>> +all:
>> + @for DIR in $(SUBDIRS); do \
>> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
>> + mkdir -p $$BUILD_TARGET; \
>> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
>> + done
>> +
>> +install: all
>> + @for DIR in $(SUBDIRS); do \
>> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
>> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
>> + done
>> +
>> +run_tests: all
>> + @for DIR in $(SUBDIRS); do \
>> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
>> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
>> + done
>> +
>> +# Avoid any output on non arm64 on emit_tests
>> +emit_tests: all
>> + @for DIR in $(SUBDIRS); do \
>> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
>> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
>> + done
>> +
>> +clean:
>> + @for DIR in $(SUBDIRS); do \
>> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
>> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
>> + done
>> +
>> +.PHONY: all clean install run_tests emit_tests
>> diff --git a/tools/testing/selftests/arm64/README b/tools/testing/selftests/arm64/README
>> new file mode 100644
>> index 000000000000..dee3306071cc
>> --- /dev/null
>> +++ b/tools/testing/selftests/arm64/README
>> @@ -0,0 +1,43 @@
>> +KSelfTest ARM64
>> +===============
>> +
>> +- These tests are arm64 specific and so not built or run but just skipped
>> + completely when env-variable ARCH is found to be different than 'arm64'
>> + and `uname -m` reports other than 'aarch64'.
>> +
>> +- Holding true the above, ARM64 KSFT tests can be run:
>> +
>> + + as standalone (example for signal tests)
>> +
>> + $ make -C tools/testing/selftest/arm64/signal \
>> + INSTALL_PATH=<your-installation-path> install
>> +
>> + and then launching on the target device inside the installed path:
>> +
>> + $ <your-installed-path>/test_arm64_signals.sh [-k | -v]
>> +
>> + + within the KSelfTest framework using standard Linux top-level-makefile
>> + targets:
>> +
>> + $ make TARGETS=arm64 kselftest-clean
>> + $ make TARGETS=arm64 kselftest
>> +
>> + Further details on building and running KFST can be found in:
>> + Documentation/dev-tools/kselftest.rst
>
> The next two paragraphs aren't relevant yet. Can we split them out of
> this patch and add them alongside the relevant code / Makefile changes?
>
Sure. I'm going to remove also standalone mode in V4 as elsewhere advised,
so I'll drop part of this README too.
>> +
>> +- Tests can depend on some arch-specific definitions which can be found in a
>> + standard Kernel Headers installation in $(top_srcdir)/usr/include.
>> + Such Kernel Headers are automatically installed (via make headers_install)
>> + by KSFT framework itself in a dedicated directory when tests are launched
>> + via KSFT itself; when running standalone, instead, a Warning is issued
>> + if such headers cannot be found somewhere (we try to guess a few standard
>> + locations anyway)
>> +
>> +- Some of these tests may be related to possibly not implemented ARMv8
>> + features: depending on their implementation status on the effective HW
>> + we'll expect different results. The tests' harness will take care to check
>> + at run-time if the required features are supported and will act accordingly.
>> + Moreover, in order to avoid any kind of compile-time dependency on the
>> + toolchain (possibly due to the above mentioned not-implemented features),
>> + we make strictly use of direct 'S3_ sysreg' raw-encoding while checking for
>> + those features and/or lookin up sysregs.
>
> This last paragraph is only relevant for people adding new tests. It
> probably makes sense to start "When adding new tests, try to avoid
> unnecessary toolchain dependencies where possible. [...]"
>
> Cheers
> ---Dave
>
Cheers
Cristian
_______________________________________________
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