ARM: dts: imx25-pinfunc: Always set SION for SD CMD

PATCH In review Benoît Thébaudeau 4 participants 7 messages Jan 27, 2018 – Feb 5, 2018

Subsystems (2)

Device tree bindings Arm i.MX and Layerscape

lore

Share & tools

lore

Benoît Thébaudeau

author

2018-01-27 00:07 UTC #0 lore raw

PATCH 1/1 ARM: dts: imx25-pinfunc: Always set SION for SD CMD

The eSDHC does not work properly if the SION bit is not set for the bidirectional CMD signal, whatever the eSDHC instance and the selected pad. Therefore, setting SION is mandatory for all eSDHC CMD ports. Do this for MX25_PAD_*__SD*_CMD in imx25-pinfunc.h in order to enforce this behavior for all boards.

This had already been done for eSDHC1, but not for eSDHC2. Also, define MX25_PAD_FEC_MDC__SDHC2_CMD so that all the possible cases are covered from now on.

Signed-off-by Beno?t Th?baudeau <[email protected]>

---
 arch/arm/boot/dts/imx25-pinfunc.h | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

arch/arm/boot/dts/imx25-pinfunc.h +6 -2

index 6c63dca1b9b8..6cc71f7e1baa 100644
@@ -236,7 +236,8 @@
 #define MX25_PAD_LD8__LD8			0x0e8 0x2e0 0x000 0x00 0x000
 #define MX25_PAD_LD8__UART4_RXD			0x0e8 0x2e0 0x570 0x02 0x000
 #define MX25_PAD_LD8__FEC_TX_ERR		0x0e8 0x2e0 0x000 0x05 0x000
-#define MX25_PAD_LD8__SDHC2_CMD			0x0e8 0x2e0 0x4e0 0x06 0x000
+/* The eSDHC cannot work if SION is not set for the bidirectional CMD signal. */
+#define MX25_PAD_LD8__SDHC2_CMD			0x0e8 0x2e0 0x4e0 0x16 0x000
 
 #define MX25_PAD_LD9__LD9			0x0ec 0x2e4 0x000 0x00 0x000
 #define MX25_PAD_LD9__UART4_TXD			0x0ec 0x2e4 0x000 0x02 0x000

@@ -316,7 +317,8 @@
 #define MX25_PAD_CSI_D5__CSPI3_RDY		0x12c 0x324 0x000 0x07 0x000
 
 #define MX25_PAD_CSI_D6__CSI_D6			0x130 0x328 0x000 0x00 0x000
-#define MX25_PAD_CSI_D6__SDHC2_CMD		0x130 0x328 0x4e0 0x02 0x001
+/* The eSDHC cannot work if SION is not set for the bidirectional CMD signal. */
+#define MX25_PAD_CSI_D6__SDHC2_CMD		0x130 0x328 0x4e0 0x12 0x001
 #define MX25_PAD_CSI_D6__SIM1_PD0		0x130 0x328 0x000 0x04 0x000
 #define MX25_PAD_CSI_D6__GPIO_1_31		0x130 0x328 0x000 0x05 0x000

@@ -496,6 +498,8 @@
 #define MX25_PAD_KPP_COL3__GPIO_3_4		0x1c4 0x3bc 0x000 0x05 0x000
 
 #define MX25_PAD_FEC_MDC__FEC_MDC		0x1c8 0x3c0 0x000 0x00 0x000
+/* The eSDHC cannot work if SION is not set for the bidirectional CMD signal. */
+#define MX25_PAD_FEC_MDC__SDHC2_CMD		0x1c8 0x3c0 0x4e0 0x11 0x002
 #define MX25_PAD_FEC_MDC__AUD4_TXD		0x1c8 0x3c0 0x464 0x02 0x001
 #define MX25_PAD_FEC_MDC__GPIO_3_5		0x1c8 0x3c0 0x000 0x05 0x000

Signature · 1 line

2.14.1

Fabio Estevam

reviewer Reviewed-by on v1 1/1

2018-01-27 00:28 UTC #1 lore raw

Quoted 11 lines · Beno?t Th?baudeau

The eSDHC does not work properly if the SION bit is not set for the bidirectional CMD signal, whatever the eSDHC instance and the selected pad. Therefore, setting SION is mandatory for all eSDHC CMD ports. Do this for MX25_PAD_*__SD*_CMD in imx25-pinfunc.h in order to enforce this behavior for all boards.
This had already been done for eSDHC1, but not for eSDHC2. Also, define MX25_PAD_FEC_MDC__SDHC2_CMD so that all the possible cases are covered from now on.
Signed-off-by Beno?t Th?baudeau <[email protected]>

Thanks for the fix:

Reviewed-by Fabio Estevam <[email protected]>

Uwe Kleine-König

2018-01-27 15:37 UTC #2 lore raw

In reply to Benoît Thébaudeau

Quoted 9 lines · Beno?t Th?baudeau

The eSDHC does not work properly if the SION bit is not set for the bidirectional CMD signal, whatever the eSDHC instance and the selected pad. Therefore, setting SION is mandatory for all eSDHC CMD ports. Do this for MX25_PAD_*__SD*_CMD in imx25-pinfunc.h in order to enforce this behavior for all boards.
This had already been done for eSDHC1, but not for eSDHC2. Also, define MX25_PAD_FEC_MDC__SDHC2_CMD so that all the possible cases are covered from now on.

There is an inconsistency in the naming. The eSDHC1 CMD constants are named:

	MX25_PAD_SD1_CMD__SD1_CMD

The reference calls this:

CMD of instance: esdhc1.

The register name is correct though. Not sure it's worth to fix this to use consistent naming (which would result in:

	MX25_PAD_SD1_CMD__ESDHC1_CMD

which looks ugly, too).

Quoted 10 lines

Signed-off-by Beno?t Th?baudeau <[email protected]>
---
 arch/arm/boot/dts/imx25-pinfunc.h | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
arch/arm/boot/dts/imx25-pinfunc.h +0 -0
index 6c63dca1b9b8..6cc71f7e1baa 100644

arch/arm/boot/dts/imx25-pinfunc.h line 239

Quoted 5 lines

arch/arm/boot/dts/imx25-pinfunc.h +1 -1

@@ -236,7 +236,8 @@
 #define MX25_PAD_LD8__LD8			0x0e8 0x2e0 0x000 0x00 0x000
 #define MX25_PAD_LD8__UART4_RXD			0x0e8 0x2e0 0x570 0x02 0x000
 #define MX25_PAD_LD8__FEC_TX_ERR		0x0e8 0x2e0 0x000 0x05 0x000
-#define MX25_PAD_LD8__SDHC2_CMD			0x0e8 0x2e0 0x4e0 0x06 0x000
+/* The eSDHC cannot work if SION is not set for the bidirectional CMD signal. */

Maybe reference the more verbose comment for MX25_PAD_SD1_CMD__SD1_CMD here?

Quoted 15 lines

arch/arm/boot/dts/imx25-pinfunc.h +3 -1

+#define MX25_PAD_LD8__SDHC2_CMD			0x0e8 0x2e0 0x4e0 0x16 0x000
 
 #define MX25_PAD_LD9__LD9			0x0ec 0x2e4 0x000 0x00 0x000
 #define MX25_PAD_LD9__UART4_TXD			0x0ec 0x2e4 0x000 0x02 0x000

@@ -316,7 +317,8 @@
 #define MX25_PAD_CSI_D5__CSPI3_RDY		0x12c 0x324 0x000 0x07 0x000
 
 #define MX25_PAD_CSI_D6__CSI_D6			0x130 0x328 0x000 0x00 0x000
-#define MX25_PAD_CSI_D6__SDHC2_CMD		0x130 0x328 0x4e0 0x02 0x001
+/* The eSDHC cannot work if SION is not set for the bidirectional CMD signal. */
+#define MX25_PAD_CSI_D6__SDHC2_CMD		0x130 0x328 0x4e0 0x12 0x001
 #define MX25_PAD_CSI_D6__SIM1_PD0		0x130 0x328 0x000 0x04 0x000
 #define MX25_PAD_CSI_D6__GPIO_1_31		0x130 0x328 0x000 0x05 0x000

arch/arm/boot/dts/imx25-pinfunc.h line 504

Quoted 7 lines

arch/arm/boot/dts/imx25-pinfunc.h +2 -0

@@ -496,6 +498,8 @@
 #define MX25_PAD_KPP_COL3__GPIO_3_4		0x1c4 0x3bc 0x000 0x05 0x000
 
 #define MX25_PAD_FEC_MDC__FEC_MDC		0x1c8 0x3c0 0x000 0x00 0x000
+/* The eSDHC cannot work if SION is not set for the bidirectional CMD signal. */
+#define MX25_PAD_FEC_MDC__SDHC2_CMD		0x1c8 0x3c0 0x4e0 0x11 0x002
 #define MX25_PAD_FEC_MDC__AUD4_TXD		0x1c8 0x3c0 0x464 0x02 0x001
 #define MX25_PAD_FEC_MDC__GPIO_3_5		0x1c8 0x3c0 0x000 0x05 0x000

I double checked the numbers, and these seem all to be correct.

Best regards
Uwe

Signature · 2 lines

Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Benoît Thébaudeau

author

2018-01-27 20:37 UTC #3 lore raw

Quoted 18 lines · Uwe Kleine-K?nig

Quoted 9 lines · Beno?t Th?baudeau
The eSDHC does not work properly if the SION bit is not set for the bidirectional CMD signal, whatever the eSDHC instance and the selected pad. Therefore, setting SION is mandatory for all eSDHC CMD ports. Do this for MX25_PAD_*__SD*_CMD in imx25-pinfunc.h in order to enforce this behavior for all boards.
This had already been done for eSDHC1, but not for eSDHC2. Also, define MX25_PAD_FEC_MDC__SDHC2_CMD so that all the possible cases are covered from now on.
There is an inconsistency in the naming. The eSDHC1 CMD constants are named:
        MX25_PAD_SD1_CMD__SD1_CMD
The reference calls this:

Quoted 8 lines

CMD of instance: esdhc1.
The register name is correct though. Not sure it's worth to fix this to use consistent naming (which would result in:
        MX25_PAD_SD1_CMD__ESDHC1_CMD
which looks ugly, too).

Indeed. I had also noticed this. I can send a patch to apply before this one. But that would break the out-of-tree DT files using these definitions. Would that be OK?

Quoted 5 lines

Quoted 5 lines
Signed-off-by Beno?t Th?baudeau <[email protected]>
---
 arch/arm/boot/dts/imx25-pinfunc.h | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

Quoted 13 lines

arch/arm/boot/dts/imx25-pinfunc.h line 239

Quoted 10 lines

arch/arm/boot/dts/imx25-pinfunc.h +1 -1

index 6c63dca1b9b8..6cc71f7e1baa 100644
@@ -236,7 +236,8 @@
 #define MX25_PAD_LD8__LD8                    0x0e8 0x2e0 0x000 0x00 0x000
 #define MX25_PAD_LD8__UART4_RXD                      0x0e8 0x2e0 0x570 0x02 0x000
 #define MX25_PAD_LD8__FEC_TX_ERR             0x0e8 0x2e0 0x000 0x05 0x000
-#define MX25_PAD_LD8__SDHC2_CMD                      0x0e8 0x2e0 0x4e0 0x06 0x000
+/* The eSDHC cannot work if SION is not set for the bidirectional CMD signal. */

Maybe reference the more verbose comment for MX25_PAD_SD1_CMD__SD1_CMD here?

Good idea. That would avoid repeating the same thing everywhere while giving a pointer to more details.

Quoted 17 lines

arch/arm/boot/dts/imx25-pinfunc.h +3 -1

+#define MX25_PAD_LD8__SDHC2_CMD                      0x0e8 0x2e0 0x4e0 0x16 0x000
 
 #define MX25_PAD_LD9__LD9                    0x0ec 0x2e4 0x000 0x00 0x000
 #define MX25_PAD_LD9__UART4_TXD                      0x0ec 0x2e4 0x000 0x02 0x000

@@ -316,7 +317,8 @@
 #define MX25_PAD_CSI_D5__CSPI3_RDY           0x12c 0x324 0x000 0x07 0x000
 
 #define MX25_PAD_CSI_D6__CSI_D6                      0x130 0x328 0x000 0x00 0x000
-#define MX25_PAD_CSI_D6__SDHC2_CMD           0x130 0x328 0x4e0 0x02 0x001
+/* The eSDHC cannot work if SION is not set for the bidirectional CMD signal. */
+#define MX25_PAD_CSI_D6__SDHC2_CMD           0x130 0x328 0x4e0 0x12 0x001
 #define MX25_PAD_CSI_D6__SIM1_PD0            0x130 0x328 0x000 0x04 0x000
 #define MX25_PAD_CSI_D6__GPIO_1_31           0x130 0x328 0x000 0x05 0x000

@@ -496,6 +498,8 @@
 #define MX25_PAD_KPP_COL3__GPIO_3_4          0x1c4 0x3bc 0x000 0x05 0x000

Quoted 7 lines

arch/arm/boot/dts/imx25-pinfunc.h line 504

Quoted 5 lines

arch/arm/boot/dts/imx25-pinfunc.h +2 -0

 #define MX25_PAD_FEC_MDC__FEC_MDC            0x1c8 0x3c0 0x000 0x00 0x000
+/* The eSDHC cannot work if SION is not set for the bidirectional CMD signal. */
+#define MX25_PAD_FEC_MDC__SDHC2_CMD          0x1c8 0x3c0 0x4e0 0x11 0x002
 #define MX25_PAD_FEC_MDC__AUD4_TXD           0x1c8 0x3c0 0x464 0x02 0x001
 #define MX25_PAD_FEC_MDC__GPIO_3_5           0x1c8 0x3c0 0x000 0x05 0x000

I double checked the numbers, and these seem all to be correct.

Thanks for your review.

Best regards,
Beno?t

Uwe Kleine-König

2018-01-27 20:43 UTC #4 lore raw

Quoted 25 lines · Beno?t Th?baudeau

Quoted 23 lines · Uwe Kleine-K?nig
Quoted 9 lines · Beno?t Th?baudeau
The eSDHC does not work properly if the SION bit is not set for the bidirectional CMD signal, whatever the eSDHC instance and the selected pad. Therefore, setting SION is mandatory for all eSDHC CMD ports. Do this for MX25_PAD_*__SD*_CMD in imx25-pinfunc.h in order to enforce this behavior for all boards.
This had already been done for eSDHC1, but not for eSDHC2. Also, define MX25_PAD_FEC_MDC__SDHC2_CMD so that all the possible cases are covered from now on.
There is an inconsistency in the naming. The eSDHC1 CMD constants are named:
        MX25_PAD_SD1_CMD__SD1_CMD
The reference calls this:
CMD of instance: esdhc1.
The register name is correct though. Not sure it's worth to fix this to use consistent naming (which would result in:

Quoted 7 lines

Quoted 3 lines
        MX25_PAD_SD1_CMD__ESDHC1_CMD
which looks ugly, too).
Indeed. I had also noticed this. I can send a patch to apply before this one. But that would break the out-of-tree DT files using these definitions. Would that be OK?

One possibility is to do something like this:

	#define MX25_PAD_SD1_CMD__ESDHC1_CMD	X Y Z ...

	...

	/*
	 * compat defines for out-of-tree users. Yes, you should update when you
	 * make use of one of them.
	 */
	#define MX25_PAD_SD1_CMD__SD1_CMD MX25_PAD_SD1_CMD__ESDHC1_CMD

This would also allow to fix the users in a separate step.

Best regards
Uwe

Signature · 2 lines

Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Shawn Guo

2018-02-05 08:10 UTC #5 lore raw

In reply to Benoît Thébaudeau

Quoted 25 lines · Beno?t Th?baudeau

Quoted 23 lines · Uwe Kleine-K?nig
Quoted 9 lines · Beno?t Th?baudeau
The eSDHC does not work properly if the SION bit is not set for the bidirectional CMD signal, whatever the eSDHC instance and the selected pad. Therefore, setting SION is mandatory for all eSDHC CMD ports. Do this for MX25_PAD_*__SD*_CMD in imx25-pinfunc.h in order to enforce this behavior for all boards.
This had already been done for eSDHC1, but not for eSDHC2. Also, define MX25_PAD_FEC_MDC__SDHC2_CMD so that all the possible cases are covered from now on.
There is an inconsistency in the naming. The eSDHC1 CMD constants are named:
        MX25_PAD_SD1_CMD__SD1_CMD
The reference calls this:
CMD of instance: esdhc1.
The register name is correct though. Not sure it's worth to fix this to use consistent naming (which would result in:

Quoted 7 lines

Quoted 3 lines
        MX25_PAD_SD1_CMD__ESDHC1_CMD
which looks ugly, too).
Indeed. I had also noticed this. I can send a patch to apply before this one. But that would break the out-of-tree DT files using these definitions. Would that be OK?

That's OK, I would say. It could be a reminder of that they should upstream their files.

Shawn

Uwe Kleine-König

2018-02-05 08:32 UTC #6 lore raw

Quoted 28 lines · Shawn Guo

Quoted 27 lines · Beno?t Th?baudeau
Quoted 25 lines · Uwe Kleine-K?nig
Quoted 9 lines · Beno?t Th?baudeau
The eSDHC does not work properly if the SION bit is not set for the bidirectional CMD signal, whatever the eSDHC instance and the selected pad. Therefore, setting SION is mandatory for all eSDHC CMD ports. Do this for MX25_PAD_*__SD*_CMD in imx25-pinfunc.h in order to enforce this behavior for all boards.
This had already been done for eSDHC1, but not for eSDHC2. Also, define MX25_PAD_FEC_MDC__SDHC2_CMD so that all the possible cases are covered from now on.
There is an inconsistency in the naming. The eSDHC1 CMD constants are named:
        MX25_PAD_SD1_CMD__SD1_CMD
The reference calls this:
CMD of instance: esdhc1.
The register name is correct though. Not sure it's worth to fix this to use consistent naming (which would result in:
        MX25_PAD_SD1_CMD__ESDHC1_CMD

Quoted 8 lines

Quoted 5 lines
Quoted 1 line
which looks ugly, too).
Indeed. I had also noticed this. I can send a patch to apply before this one. But that would break the out-of-tree DT files using these definitions. Would that be OK?
That's OK, I would say. It could be a reminder of that they should upstream their files.

I assume you saw v2 which introduced some defines to give those guys a bit of time, which IMHO is still better. Then we can remove these compat defines in (say) a year and so trigger this reminder.

Also one of the advantages of dt that was advertised when ARM was converted to dt was, that upstreaming the dt isn't necessary any more. I personally like this and still consider not upstreaming the dtb part of a machine a sane approach.

Best regards
Uwe

Signature · 2 lines

Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |