* [v10, 0/7] Fix eSDHC host version register bug
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-mmc, linuxppc-dev, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-i2c, iommu, netdev
Cc: ulf.hansson, Scott Wood, Mark Rutland, Rob Herring, Russell King,
Jochen Friedrich, Joerg Roedel, Claudiu Manoil, Bhupesh Sharma,
Qiang Zhao, Kumar Gala, Santosh Shilimkar, leoyang.li,
xiaobo.xie, Yangbo Lu
This patchset is used to fix a host version register bug in the T4240-R1.0-R2.0
eSDHC controller. To get the SoC version and revision, it's needed to add the
GUTS driver to access the global utilities registers.
So, the first four patches are to add the GUTS driver.
The following patches except the updating MAINTAINERS patch are to enable
GUTS driver support to get SVR in eSDHC driver and fix host version for T4240.
Yangbo Lu (7):
Documentation: DT: update Freescale DCFG compatible
ARM64: dts: ls2080a: add device configuration node
soc: fsl: add GUTS driver for QorIQ platforms
dt: move guts devicetree doc out of powerpc directory
powerpc/fsl: move mpc85xx.h to include/linux/fsl
MAINTAINERS: add entry for Freescale SoC drivers
mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
Documentation/devicetree/bindings/arm/fsl.txt | 6 +-
.../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
MAINTAINERS | 11 +-
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
drivers/clk/clk-qoriq.c | 3 +-
drivers/i2c/busses/i2c-mpc.c | 2 +-
drivers/iommu/fsl_pamu.c | 3 +-
drivers/mmc/host/Kconfig | 1 +
drivers/mmc/host/sdhci-of-esdhc.c | 23 ++++
drivers/net/ethernet/freescale/gianfar.c | 2 +-
drivers/soc/Kconfig | 2 +-
drivers/soc/fsl/Kconfig | 8 ++
drivers/soc/fsl/Makefile | 1 +
drivers/soc/fsl/guts.c | 119 +++++++++++++++++++
include/linux/fsl/guts.h | 126 +++++++++++++--------
.../asm/mpc85xx.h => include/linux/fsl/svr.h | 4 +-
17 files changed, 262 insertions(+), 60 deletions(-)
rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
create mode 100644 drivers/soc/fsl/Kconfig
create mode 100644 drivers/soc/fsl/guts.c
rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)
--
2.1.0.27.g96db324
^ permalink raw reply [flat|nested] 185+ messages in thread
* [v10, 0/7] Fix eSDHC host version register bug
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Mark Rutland, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Russell King,
Yangbo Lu, Bhupesh Sharma, Santosh Shilimkar, Jochen Friedrich,
leoyang.li-3arQi8VN3Tc, Scott Wood, Rob Herring, Claudiu Manoil,
Kumar Gala, xiaobo.xie-3arQi8VN3Tc, Qiang Zhao
This patchset is used to fix a host version register bug in the T4240-R1.0-R2.0
eSDHC controller. To get the SoC version and revision, it's needed to add the
GUTS driver to access the global utilities registers.
So, the first four patches are to add the GUTS driver.
The following patches except the updating MAINTAINERS patch are to enable
GUTS driver support to get SVR in eSDHC driver and fix host version for T4240.
Yangbo Lu (7):
Documentation: DT: update Freescale DCFG compatible
ARM64: dts: ls2080a: add device configuration node
soc: fsl: add GUTS driver for QorIQ platforms
dt: move guts devicetree doc out of powerpc directory
powerpc/fsl: move mpc85xx.h to include/linux/fsl
MAINTAINERS: add entry for Freescale SoC drivers
mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
Documentation/devicetree/bindings/arm/fsl.txt | 6 +-
.../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
MAINTAINERS | 11 +-
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
drivers/clk/clk-qoriq.c | 3 +-
drivers/i2c/busses/i2c-mpc.c | 2 +-
drivers/iommu/fsl_pamu.c | 3 +-
drivers/mmc/host/Kconfig | 1 +
drivers/mmc/host/sdhci-of-esdhc.c | 23 ++++
drivers/net/ethernet/freescale/gianfar.c | 2 +-
drivers/soc/Kconfig | 2 +-
drivers/soc/fsl/Kconfig | 8 ++
drivers/soc/fsl/Makefile | 1 +
drivers/soc/fsl/guts.c | 119 +++++++++++++++++++
include/linux/fsl/guts.h | 126 +++++++++++++--------
.../asm/mpc85xx.h => include/linux/fsl/svr.h | 4 +-
17 files changed, 262 insertions(+), 60 deletions(-)
rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
create mode 100644 drivers/soc/fsl/Kconfig
create mode 100644 drivers/soc/fsl/guts.c
rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)
--
2.1.0.27.g96db324
^ permalink raw reply [flat|nested] 185+ messages in thread
* [v10, 0/7] Fix eSDHC host version register bug
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Mark Rutland, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Russell King,
Yangbo Lu, Bhupesh Sharma, Santosh Shilimkar, Jochen Friedrich,
leoyang.li-3arQi8VN3Tc, Scott Wood, Rob Herring, Claudiu Manoil,
Kumar Gala, xiaobo.xie-3arQi8VN3Tc, Qiang Zhao
This patchset is used to fix a host version register bug in the T4240-R1.0-R2.0
eSDHC controller. To get the SoC version and revision, it's needed to add the
GUTS driver to access the global utilities registers.
So, the first four patches are to add the GUTS driver.
The following patches except the updating MAINTAINERS patch are to enable
GUTS driver support to get SVR in eSDHC driver and fix host version for T4240.
Yangbo Lu (7):
Documentation: DT: update Freescale DCFG compatible
ARM64: dts: ls2080a: add device configuration node
soc: fsl: add GUTS driver for QorIQ platforms
dt: move guts devicetree doc out of powerpc directory
powerpc/fsl: move mpc85xx.h to include/linux/fsl
MAINTAINERS: add entry for Freescale SoC drivers
mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
Documentation/devicetree/bindings/arm/fsl.txt | 6 +-
.../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
MAINTAINERS | 11 +-
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
drivers/clk/clk-qoriq.c | 3 +-
drivers/i2c/busses/i2c-mpc.c | 2 +-
drivers/iommu/fsl_pamu.c | 3 +-
drivers/mmc/host/Kconfig | 1 +
drivers/mmc/host/sdhci-of-esdhc.c | 23 ++++
drivers/net/ethernet/freescale/gianfar.c | 2 +-
drivers/soc/Kconfig | 2 +-
drivers/soc/fsl/Kconfig | 8 ++
drivers/soc/fsl/Makefile | 1 +
drivers/soc/fsl/guts.c | 119 +++++++++++++++++++
include/linux/fsl/guts.h | 126 +++++++++++++--------
.../asm/mpc85xx.h => include/linux/fsl/svr.h | 4 +-
17 files changed, 262 insertions(+), 60 deletions(-)
rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
create mode 100644 drivers/soc/fsl/Kconfig
create mode 100644 drivers/soc/fsl/guts.c
rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)
--
2.1.0.27.g96db324
^ permalink raw reply [flat|nested] 185+ messages in thread
* [v10, 0/7] Fix eSDHC host version register bug
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-mmc, linuxppc-dev, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-i2c, iommu, netdev
Cc: Mark Rutland, ulf.hansson, Russell King, Yangbo Lu,
Bhupesh Sharma, Joerg Roedel, Santosh Shilimkar,
Jochen Friedrich, leoyang.li, Scott Wood, Rob Herring,
Claudiu Manoil, Kumar Gala, xiaobo.xie, Qiang Zhao
This patchset is used to fix a host version register bug in the T4240-R1.0-R2.0
eSDHC controller. To get the SoC version and revision, it's needed to add the
GUTS driver to access the global utilities registers.
So, the first four patches are to add the GUTS driver.
The following patches except the updating MAINTAINERS patch are to enable
GUTS driver support to get SVR in eSDHC driver and fix host version for T4240.
Yangbo Lu (7):
Documentation: DT: update Freescale DCFG compatible
ARM64: dts: ls2080a: add device configuration node
soc: fsl: add GUTS driver for QorIQ platforms
dt: move guts devicetree doc out of powerpc directory
powerpc/fsl: move mpc85xx.h to include/linux/fsl
MAINTAINERS: add entry for Freescale SoC drivers
mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
Documentation/devicetree/bindings/arm/fsl.txt | 6 +-
.../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
MAINTAINERS | 11 +-
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
drivers/clk/clk-qoriq.c | 3 +-
drivers/i2c/busses/i2c-mpc.c | 2 +-
drivers/iommu/fsl_pamu.c | 3 +-
drivers/mmc/host/Kconfig | 1 +
drivers/mmc/host/sdhci-of-esdhc.c | 23 ++++
drivers/net/ethernet/freescale/gianfar.c | 2 +-
drivers/soc/Kconfig | 2 +-
drivers/soc/fsl/Kconfig | 8 ++
drivers/soc/fsl/Makefile | 1 +
drivers/soc/fsl/guts.c | 119 +++++++++++++++++++
include/linux/fsl/guts.h | 126 +++++++++++++--------
.../asm/mpc85xx.h => include/linux/fsl/svr.h | 4 +-
17 files changed, 262 insertions(+), 60 deletions(-)
rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
create mode 100644 drivers/soc/fsl/Kconfig
create mode 100644 drivers/soc/fsl/guts.c
rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)
--
2.1.0.27.g96db324
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 185+ messages in thread
* [v10, 0/7] Fix eSDHC host version register bug
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-arm-kernel
This patchset is used to fix a host version register bug in the T4240-R1.0-R2.0
eSDHC controller. To get the SoC version and revision, it's needed to add the
GUTS driver to access the global utilities registers.
So, the first four patches are to add the GUTS driver.
The following patches except the updating MAINTAINERS patch are to enable
GUTS driver support to get SVR in eSDHC driver and fix host version for T4240.
Yangbo Lu (7):
Documentation: DT: update Freescale DCFG compatible
ARM64: dts: ls2080a: add device configuration node
soc: fsl: add GUTS driver for QorIQ platforms
dt: move guts devicetree doc out of powerpc directory
powerpc/fsl: move mpc85xx.h to include/linux/fsl
MAINTAINERS: add entry for Freescale SoC drivers
mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
Documentation/devicetree/bindings/arm/fsl.txt | 6 +-
.../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
MAINTAINERS | 11 +-
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
drivers/clk/clk-qoriq.c | 3 +-
drivers/i2c/busses/i2c-mpc.c | 2 +-
drivers/iommu/fsl_pamu.c | 3 +-
drivers/mmc/host/Kconfig | 1 +
drivers/mmc/host/sdhci-of-esdhc.c | 23 ++++
drivers/net/ethernet/freescale/gianfar.c | 2 +-
drivers/soc/Kconfig | 2 +-
drivers/soc/fsl/Kconfig | 8 ++
drivers/soc/fsl/Makefile | 1 +
drivers/soc/fsl/guts.c | 119 +++++++++++++++++++
include/linux/fsl/guts.h | 126 +++++++++++++--------
.../asm/mpc85xx.h => include/linux/fsl/svr.h | 4 +-
17 files changed, 262 insertions(+), 60 deletions(-)
rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
create mode 100644 drivers/soc/fsl/Kconfig
create mode 100644 drivers/soc/fsl/guts.c
rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)
--
2.1.0.27.g96db324
^ permalink raw reply [flat|nested] 185+ messages in thread
* [v10, 1/7] Documentation: DT: update Freescale DCFG compatible
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-mmc, linuxppc-dev, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-i2c, iommu, netdev
Cc: ulf.hansson, Scott Wood, Mark Rutland, Rob Herring, Russell King,
Jochen Friedrich, Joerg Roedel, Claudiu Manoil, Bhupesh Sharma,
Qiang Zhao, Kumar Gala, Santosh Shilimkar, leoyang.li,
xiaobo.xie, Yangbo Lu
Update Freescale DCFG compatible with 'fsl,<chip>-dcfg' instead
of 'fsl,ls1021a-dcfg' to include more chips such as ls1021a,
ls1043a, and ls2080a.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
---
Changes for v8:
- Added this patch
Changes for v9:
- Added a list for the possible compatibles
Changes for v10:
- None
---
Documentation/devicetree/bindings/arm/fsl.txt | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt
index 752a685..465cba1 100644
--- a/Documentation/devicetree/bindings/arm/fsl.txt
+++ b/Documentation/devicetree/bindings/arm/fsl.txt
@@ -119,7 +119,11 @@ Freescale DCFG
configuration and status for the device. Such as setting the secondary
core start address and release the secondary core from holdoff and startup.
Required properties:
- - compatible: should be "fsl,ls1021a-dcfg"
+ - compatible: should be "fsl,<chip>-dcfg"
+ Possible compatibles:
+ "fsl,ls1021a-dcfg"
+ "fsl,ls1043a-dcfg"
+ "fsl,ls2080a-dcfg"
- reg : should contain base address and length of DCFG memory-mapped registers
Example:
--
2.1.0.27.g96db324
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 1/7] Documentation: DT: update Freescale DCFG compatible
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Mark Rutland, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Russell King,
Yangbo Lu, Bhupesh Sharma, Santosh Shilimkar, Jochen Friedrich,
leoyang.li-3arQi8VN3Tc, Scott Wood, Rob Herring, Claudiu Manoil,
Kumar Gala, xiaobo.xie-3arQi8VN3Tc, Qiang Zhao
Update Freescale DCFG compatible with 'fsl,<chip>-dcfg' instead
of 'fsl,ls1021a-dcfg' to include more chips such as ls1021a,
ls1043a, and ls2080a.
Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
---
Changes for v8:
- Added this patch
Changes for v9:
- Added a list for the possible compatibles
Changes for v10:
- None
---
Documentation/devicetree/bindings/arm/fsl.txt | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt
index 752a685..465cba1 100644
--- a/Documentation/devicetree/bindings/arm/fsl.txt
+++ b/Documentation/devicetree/bindings/arm/fsl.txt
@@ -119,7 +119,11 @@ Freescale DCFG
configuration and status for the device. Such as setting the secondary
core start address and release the secondary core from holdoff and startup.
Required properties:
- - compatible: should be "fsl,ls1021a-dcfg"
+ - compatible: should be "fsl,<chip>-dcfg"
+ Possible compatibles:
+ "fsl,ls1021a-dcfg"
+ "fsl,ls1043a-dcfg"
+ "fsl,ls2080a-dcfg"
- reg : should contain base address and length of DCFG memory-mapped registers
Example:
--
2.1.0.27.g96db324
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 1/7] Documentation: DT: update Freescale DCFG compatible
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Mark Rutland, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Russell King,
Yangbo Lu, Bhupesh Sharma, Santosh Shilimkar, Jochen Friedrich,
leoyang.li-3arQi8VN3Tc, Scott Wood, Rob Herring, Claudiu Manoil,
Kumar Gala, xiaobo.xie-3arQi8VN3Tc, Qiang Zhao
Update Freescale DCFG compatible with 'fsl,<chip>-dcfg' instead
of 'fsl,ls1021a-dcfg' to include more chips such as ls1021a,
ls1043a, and ls2080a.
Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
---
Changes for v8:
- Added this patch
Changes for v9:
- Added a list for the possible compatibles
Changes for v10:
- None
---
Documentation/devicetree/bindings/arm/fsl.txt | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt
index 752a685..465cba1 100644
--- a/Documentation/devicetree/bindings/arm/fsl.txt
+++ b/Documentation/devicetree/bindings/arm/fsl.txt
@@ -119,7 +119,11 @@ Freescale DCFG
configuration and status for the device. Such as setting the secondary
core start address and release the secondary core from holdoff and startup.
Required properties:
- - compatible: should be "fsl,ls1021a-dcfg"
+ - compatible: should be "fsl,<chip>-dcfg"
+ Possible compatibles:
+ "fsl,ls1021a-dcfg"
+ "fsl,ls1043a-dcfg"
+ "fsl,ls2080a-dcfg"
- reg : should contain base address and length of DCFG memory-mapped registers
Example:
--
2.1.0.27.g96db324
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 1/7] Documentation: DT: update Freescale DCFG compatible
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-mmc, linuxppc-dev, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-i2c, iommu, netdev
Cc: Mark Rutland, ulf.hansson, Russell King, Yangbo Lu,
Bhupesh Sharma, Joerg Roedel, Santosh Shilimkar,
Jochen Friedrich, leoyang.li, Scott Wood, Rob Herring,
Claudiu Manoil, Kumar Gala, xiaobo.xie, Qiang Zhao
Update Freescale DCFG compatible with 'fsl,<chip>-dcfg' instead
of 'fsl,ls1021a-dcfg' to include more chips such as ls1021a,
ls1043a, and ls2080a.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
---
Changes for v8:
- Added this patch
Changes for v9:
- Added a list for the possible compatibles
Changes for v10:
- None
---
Documentation/devicetree/bindings/arm/fsl.txt | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt
index 752a685..465cba1 100644
--- a/Documentation/devicetree/bindings/arm/fsl.txt
+++ b/Documentation/devicetree/bindings/arm/fsl.txt
@@ -119,7 +119,11 @@ Freescale DCFG
configuration and status for the device. Such as setting the secondary
core start address and release the secondary core from holdoff and startup.
Required properties:
- - compatible: should be "fsl,ls1021a-dcfg"
+ - compatible: should be "fsl,<chip>-dcfg"
+ Possible compatibles:
+ "fsl,ls1021a-dcfg"
+ "fsl,ls1043a-dcfg"
+ "fsl,ls2080a-dcfg"
- reg : should contain base address and length of DCFG memory-mapped registers
Example:
--
2.1.0.27.g96db324
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 1/7] Documentation: DT: update Freescale DCFG compatible
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-arm-kernel
Update Freescale DCFG compatible with 'fsl,<chip>-dcfg' instead
of 'fsl,ls1021a-dcfg' to include more chips such as ls1021a,
ls1043a, and ls2080a.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
---
Changes for v8:
- Added this patch
Changes for v9:
- Added a list for the possible compatibles
Changes for v10:
- None
---
Documentation/devicetree/bindings/arm/fsl.txt | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt
index 752a685..465cba1 100644
--- a/Documentation/devicetree/bindings/arm/fsl.txt
+++ b/Documentation/devicetree/bindings/arm/fsl.txt
@@ -119,7 +119,11 @@ Freescale DCFG
configuration and status for the device. Such as setting the secondary
core start address and release the secondary core from holdoff and startup.
Required properties:
- - compatible: should be "fsl,ls1021a-dcfg"
+ - compatible: should be "fsl,<chip>-dcfg"
+ Possible compatibles:
+ "fsl,ls1021a-dcfg"
+ "fsl,ls1043a-dcfg"
+ "fsl,ls2080a-dcfg"
- reg : should contain base address and length of DCFG memory-mapped registers
Example:
--
2.1.0.27.g96db324
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 2/7] ARM64: dts: ls2080a: add device configuration node
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-mmc, linuxppc-dev, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-i2c, iommu, netdev
Cc: ulf.hansson, Scott Wood, Mark Rutland, Rob Herring, Russell King,
Jochen Friedrich, Joerg Roedel, Claudiu Manoil, Bhupesh Sharma,
Qiang Zhao, Kumar Gala, Santosh Shilimkar, leoyang.li,
xiaobo.xie, Yangbo Lu
Add the dts node for device configuration unit that provides
general purpose configuration and status for the device.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Scott Wood <oss@buserror.net>
---
Changes for v5:
- Added this patch
Changes for v6:
- None
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
Changes for v9:
- None
Changes for v10:
- None
---
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index 9d746c6..8724cf1 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -191,6 +191,12 @@
clocks = <&sysclk>;
};
+ dcfg: dcfg@1e00000 {
+ compatible = "fsl,ls2080a-dcfg", "syscon";
+ reg = <0x0 0x1e00000 0x0 0x10000>;
+ little-endian;
+ };
+
serial0: serial@21c0500 {
compatible = "fsl,ns16550", "ns16550a";
reg = <0x0 0x21c0500 0x0 0x100>;
--
2.1.0.27.g96db324
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 2/7] ARM64: dts: ls2080a: add device configuration node
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Mark Rutland, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Russell King,
Yangbo Lu, Bhupesh Sharma, Santosh Shilimkar, Jochen Friedrich,
leoyang.li-3arQi8VN3Tc, Scott Wood, Rob Herring, Claudiu Manoil,
Kumar Gala, xiaobo.xie-3arQi8VN3Tc, Qiang Zhao
Add the dts node for device configuration unit that provides
general purpose configuration and status for the device.
Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
Acked-by: Scott Wood <oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org>
---
Changes for v5:
- Added this patch
Changes for v6:
- None
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
Changes for v9:
- None
Changes for v10:
- None
---
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index 9d746c6..8724cf1 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -191,6 +191,12 @@
clocks = <&sysclk>;
};
+ dcfg: dcfg@1e00000 {
+ compatible = "fsl,ls2080a-dcfg", "syscon";
+ reg = <0x0 0x1e00000 0x0 0x10000>;
+ little-endian;
+ };
+
serial0: serial@21c0500 {
compatible = "fsl,ns16550", "ns16550a";
reg = <0x0 0x21c0500 0x0 0x100>;
--
2.1.0.27.g96db324
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 2/7] ARM64: dts: ls2080a: add device configuration node
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Mark Rutland, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Russell King,
Yangbo Lu, Bhupesh Sharma, Santosh Shilimkar, Jochen Friedrich,
leoyang.li-3arQi8VN3Tc, Scott Wood, Rob Herring, Claudiu Manoil,
Kumar Gala, xiaobo.xie-3arQi8VN3Tc, Qiang Zhao
Add the dts node for device configuration unit that provides
general purpose configuration and status for the device.
Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
Acked-by: Scott Wood <oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org>
---
Changes for v5:
- Added this patch
Changes for v6:
- None
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
Changes for v9:
- None
Changes for v10:
- None
---
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index 9d746c6..8724cf1 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -191,6 +191,12 @@
clocks = <&sysclk>;
};
+ dcfg: dcfg@1e00000 {
+ compatible = "fsl,ls2080a-dcfg", "syscon";
+ reg = <0x0 0x1e00000 0x0 0x10000>;
+ little-endian;
+ };
+
serial0: serial@21c0500 {
compatible = "fsl,ns16550", "ns16550a";
reg = <0x0 0x21c0500 0x0 0x100>;
--
2.1.0.27.g96db324
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 2/7] ARM64: dts: ls2080a: add device configuration node
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-mmc, linuxppc-dev, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-i2c, iommu, netdev
Cc: Mark Rutland, ulf.hansson, Russell King, Yangbo Lu,
Bhupesh Sharma, Joerg Roedel, Santosh Shilimkar,
Jochen Friedrich, leoyang.li, Scott Wood, Rob Herring,
Claudiu Manoil, Kumar Gala, xiaobo.xie, Qiang Zhao
Add the dts node for device configuration unit that provides
general purpose configuration and status for the device.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Scott Wood <oss@buserror.net>
---
Changes for v5:
- Added this patch
Changes for v6:
- None
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
Changes for v9:
- None
Changes for v10:
- None
---
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index 9d746c6..8724cf1 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -191,6 +191,12 @@
clocks = <&sysclk>;
};
+ dcfg: dcfg@1e00000 {
+ compatible = "fsl,ls2080a-dcfg", "syscon";
+ reg = <0x0 0x1e00000 0x0 0x10000>;
+ little-endian;
+ };
+
serial0: serial@21c0500 {
compatible = "fsl,ns16550", "ns16550a";
reg = <0x0 0x21c0500 0x0 0x100>;
--
2.1.0.27.g96db324
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 2/7] ARM64: dts: ls2080a: add device configuration node
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-arm-kernel
Add the dts node for device configuration unit that provides
general purpose configuration and status for the device.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Scott Wood <oss@buserror.net>
---
Changes for v5:
- Added this patch
Changes for v6:
- None
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
Changes for v9:
- None
Changes for v10:
- None
---
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index 9d746c6..8724cf1 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -191,6 +191,12 @@
clocks = <&sysclk>;
};
+ dcfg: dcfg at 1e00000 {
+ compatible = "fsl,ls2080a-dcfg", "syscon";
+ reg = <0x0 0x1e00000 0x0 0x10000>;
+ little-endian;
+ };
+
serial0: serial at 21c0500 {
compatible = "fsl,ns16550", "ns16550a";
reg = <0x0 0x21c0500 0x0 0x100>;
--
2.1.0.27.g96db324
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 3/7] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-mmc, linuxppc-dev, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-i2c, iommu, netdev
Cc: ulf.hansson, Scott Wood, Mark Rutland, Rob Herring, Russell King,
Jochen Friedrich, Joerg Roedel, Claudiu Manoil, Bhupesh Sharma,
Qiang Zhao, Kumar Gala, Santosh Shilimkar, leoyang.li,
xiaobo.xie, Yangbo Lu
The global utilities block controls power management, I/O device
enabling, power-onreset(POR) configuration monitoring, alternate
function selection for multiplexed signals,and clock control.
This patch adds GUTS driver to manage and access global utilities
block.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Scott Wood <oss@buserror.net>
---
Changes for v4:
- Added this patch
Changes for v5:
- Modified copyright info
- Changed MODULE_LICENSE to GPL
- Changed EXPORT_SYMBOL_GPL to EXPORT_SYMBOL
- Made FSL_GUTS user-invisible
- Added a complete compatible list for GUTS
- Stored guts info in file-scope variable
- Added mfspr() getting SVR
- Redefined GUTS APIs
- Called fsl_guts_init rather than using platform driver
- Removed useless parentheses
- Removed useless 'extern' key words
Changes for v6:
- Made guts thread safe in fsl_guts_init
Changes for v7:
- Removed 'ifdef' for function declaration in guts.h
Changes for v8:
- Fixes lines longer than 80 characters checkpatch issue
- Added 'Acked-by: Scott Wood'
Changes for v9:
- None
Changes for v10:
- None
---
drivers/soc/Kconfig | 2 +-
drivers/soc/fsl/Kconfig | 8 +++
drivers/soc/fsl/Makefile | 1 +
drivers/soc/fsl/guts.c | 119 ++++++++++++++++++++++++++++++++++++++++++++
include/linux/fsl/guts.h | 126 +++++++++++++++++++++++++++++------------------
5 files changed, 207 insertions(+), 49 deletions(-)
create mode 100644 drivers/soc/fsl/Kconfig
create mode 100644 drivers/soc/fsl/guts.c
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index cb58ef0..7106463 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -2,7 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
source "drivers/soc/bcm/Kconfig"
source "drivers/soc/brcmstb/Kconfig"
-source "drivers/soc/fsl/qe/Kconfig"
+source "drivers/soc/fsl/Kconfig"
source "drivers/soc/mediatek/Kconfig"
source "drivers/soc/qcom/Kconfig"
source "drivers/soc/rockchip/Kconfig"
diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
new file mode 100644
index 0000000..b313759
--- /dev/null
+++ b/drivers/soc/fsl/Kconfig
@@ -0,0 +1,8 @@
+#
+# Freescale SOC drivers
+#
+
+source "drivers/soc/fsl/qe/Kconfig"
+
+config FSL_GUTS
+ bool
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 203307f..02afb7f 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_QUICC_ENGINE) += qe/
obj-$(CONFIG_CPM) += qe/
+obj-$(CONFIG_FSL_GUTS) += guts.o
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
new file mode 100644
index 0000000..fa155e6
--- /dev/null
+++ b/drivers/soc/fsl/guts.c
@@ -0,0 +1,119 @@
+/*
+ * Freescale QorIQ Platforms GUTS Driver
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/mutex.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/fsl/guts.h>
+
+struct guts {
+ struct ccsr_guts __iomem *regs;
+ bool little_endian;
+};
+
+static struct guts *guts;
+static DEFINE_MUTEX(guts_lock);
+
+u32 fsl_guts_get_svr(void)
+{
+ u32 svr = 0;
+
+ if (!guts || !guts->regs) {
+#ifdef CONFIG_PPC
+ svr = mfspr(SPRN_SVR);
+#endif
+ return svr;
+ }
+
+ if (guts->little_endian)
+ svr = ioread32(&guts->regs->svr);
+ else
+ svr = ioread32be(&guts->regs->svr);
+
+ return svr;
+}
+EXPORT_SYMBOL(fsl_guts_get_svr);
+
+/*
+ * Table for matching compatible strings, for device tree
+ * guts node, for Freescale QorIQ SOCs.
+ */
+static const struct of_device_id guts_of_match[] = {
+ /* For T4 & B4 Series SOCs */
+ { .compatible = "fsl,qoriq-device-config-1.0", },
+ /* For P Series SOCs */
+ { .compatible = "fsl,qoriq-device-config-2.0", },
+ { .compatible = "fsl,p1010-guts", },
+ { .compatible = "fsl,p1020-guts", },
+ { .compatible = "fsl,p1021-guts", },
+ { .compatible = "fsl,p1022-guts", },
+ { .compatible = "fsl,p1023-guts", },
+ { .compatible = "fsl,p2020-guts", },
+ /* For BSC Series SOCs */
+ { .compatible = "fsl,bsc9131-guts", },
+ { .compatible = "fsl,bsc9132-guts", },
+ /* For MPC85xx Series SOCs */
+ { .compatible = "fsl,mpc8536-guts", },
+ { .compatible = "fsl,mpc8544-guts", },
+ { .compatible = "fsl,mpc8548-guts", },
+ { .compatible = "fsl,mpc8568-guts", },
+ { .compatible = "fsl,mpc8569-guts", },
+ { .compatible = "fsl,mpc8572-guts", },
+ /* For Layerscape Series SOCs */
+ { .compatible = "fsl,ls1021a-dcfg", },
+ { .compatible = "fsl,ls1043a-dcfg", },
+ { .compatible = "fsl,ls2080a-dcfg", },
+ {}
+};
+
+int fsl_guts_init(void)
+{
+ struct device_node *np;
+ int ret;
+
+ mutex_lock(&guts_lock);
+ /* Initialize guts only once */
+ if (guts) {
+ ret = guts->regs ? 0 : -ENOMEM;
+ goto out;
+ }
+
+ np = of_find_matching_node(NULL, guts_of_match);
+ if (!np) {
+ ret = -ENODEV;
+ goto out;
+ }
+
+ guts = kzalloc(sizeof(*guts), GFP_KERNEL);
+ if (!guts) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ guts->little_endian = of_property_read_bool(np, "little-endian");
+
+ guts->regs = of_iomap(np, 0);
+ if (!guts->regs) {
+ ret = -ENOMEM;
+ kfree(guts);
+ goto out;
+ }
+
+ of_node_put(np);
+ ret = 0;
+out:
+ mutex_unlock(&guts_lock);
+ return ret;
+}
+EXPORT_SYMBOL(fsl_guts_init);
diff --git a/include/linux/fsl/guts.h b/include/linux/fsl/guts.h
index 649e917..7e1e22b 100644
--- a/include/linux/fsl/guts.h
+++ b/include/linux/fsl/guts.h
@@ -29,83 +29,113 @@
* #ifdefs.
*/
struct ccsr_guts {
- __be32 porpllsr; /* 0x.0000 - POR PLL Ratio Status Register */
- __be32 porbmsr; /* 0x.0004 - POR Boot Mode Status Register */
- __be32 porimpscr; /* 0x.0008 - POR I/O Impedance Status and Control Register */
- __be32 pordevsr; /* 0x.000c - POR I/O Device Status Register */
- __be32 pordbgmsr; /* 0x.0010 - POR Debug Mode Status Register */
- __be32 pordevsr2; /* 0x.0014 - POR device status register 2 */
+ u32 porpllsr; /* 0x.0000 - POR PLL Ratio Status Register */
+ u32 porbmsr; /* 0x.0004 - POR Boot Mode Status Register */
+ u32 porimpscr; /* 0x.0008 - POR I/O Impedance Status and
+ * Control Register
+ */
+ u32 pordevsr; /* 0x.000c - POR I/O Device Status Register */
+ u32 pordbgmsr; /* 0x.0010 - POR Debug Mode Status Register */
+ u32 pordevsr2; /* 0x.0014 - POR device status register 2 */
u8 res018[0x20 - 0x18];
- __be32 porcir; /* 0x.0020 - POR Configuration Information Register */
+ u32 porcir; /* 0x.0020 - POR Configuration Information
+ * Register
+ */
u8 res024[0x30 - 0x24];
- __be32 gpiocr; /* 0x.0030 - GPIO Control Register */
+ u32 gpiocr; /* 0x.0030 - GPIO Control Register */
u8 res034[0x40 - 0x34];
- __be32 gpoutdr; /* 0x.0040 - General-Purpose Output Data Register */
+ u32 gpoutdr; /* 0x.0040 - General-Purpose Output Data
+ * Register
+ */
u8 res044[0x50 - 0x44];
- __be32 gpindr; /* 0x.0050 - General-Purpose Input Data Register */
+ u32 gpindr; /* 0x.0050 - General-Purpose Input Data
+ * Register
+ */
u8 res054[0x60 - 0x54];
- __be32 pmuxcr; /* 0x.0060 - Alternate Function Signal Multiplex Control */
- __be32 pmuxcr2; /* 0x.0064 - Alternate function signal multiplex control 2 */
- __be32 dmuxcr; /* 0x.0068 - DMA Mux Control Register */
+ u32 pmuxcr; /* 0x.0060 - Alternate Function Signal
+ * Multiplex Control
+ */
+ u32 pmuxcr2; /* 0x.0064 - Alternate function signal
+ * multiplex control 2
+ */
+ u32 dmuxcr; /* 0x.0068 - DMA Mux Control Register */
u8 res06c[0x70 - 0x6c];
- __be32 devdisr; /* 0x.0070 - Device Disable Control */
+ u32 devdisr; /* 0x.0070 - Device Disable Control */
#define CCSR_GUTS_DEVDISR_TB1 0x00001000
#define CCSR_GUTS_DEVDISR_TB0 0x00004000
- __be32 devdisr2; /* 0x.0074 - Device Disable Control 2 */
+ u32 devdisr2; /* 0x.0074 - Device Disable Control 2 */
u8 res078[0x7c - 0x78];
- __be32 pmjcr; /* 0x.007c - 4 Power Management Jog Control Register */
- __be32 powmgtcsr; /* 0x.0080 - Power Management Status and Control Register */
- __be32 pmrccr; /* 0x.0084 - Power Management Reset Counter Configuration Register */
- __be32 pmpdccr; /* 0x.0088 - Power Management Power Down Counter Configuration Register */
- __be32 pmcdr; /* 0x.008c - 4Power management clock disable register */
- __be32 mcpsumr; /* 0x.0090 - Machine Check Summary Register */
- __be32 rstrscr; /* 0x.0094 - Reset Request Status and Control Register */
- __be32 ectrstcr; /* 0x.0098 - Exception reset control register */
- __be32 autorstsr; /* 0x.009c - Automatic reset status register */
- __be32 pvr; /* 0x.00a0 - Processor Version Register */
- __be32 svr; /* 0x.00a4 - System Version Register */
+ u32 pmjcr; /* 0x.007c - 4 Power Management Jog Control
+ * Register
+ */
+ u32 powmgtcsr; /* 0x.0080 - Power Management Status and
+ * Control Register
+ */
+ u32 pmrccr; /* 0x.0084 - Power Management Reset Counter
+ * Configuration Register
+ */
+ u32 pmpdccr; /* 0x.0088 - Power Management Power Down Counter
+ * Configuration Register
+ */
+ u32 pmcdr; /* 0x.008c - 4Power management clock disable
+ * register
+ */
+ u32 mcpsumr; /* 0x.0090 - Machine Check Summary Register */
+ u32 rstrscr; /* 0x.0094 - Reset Request Status and
+ * Control Register
+ */
+ u32 ectrstcr; /* 0x.0098 - Exception reset control register */
+ u32 autorstsr; /* 0x.009c - Automatic reset status register */
+ u32 pvr; /* 0x.00a0 - Processor Version Register */
+ u32 svr; /* 0x.00a4 - System Version Register */
u8 res0a8[0xb0 - 0xa8];
- __be32 rstcr; /* 0x.00b0 - Reset Control Register */
+ u32 rstcr; /* 0x.00b0 - Reset Control Register */
u8 res0b4[0xc0 - 0xb4];
- __be32 iovselsr; /* 0x.00c0 - I/O voltage select status register
+ u32 iovselsr; /* 0x.00c0 - I/O voltage select status register
Called 'elbcvselcr' on 86xx SOCs */
u8 res0c4[0x100 - 0xc4];
- __be32 rcwsr[16]; /* 0x.0100 - Reset Control Word Status registers
+ u32 rcwsr[16]; /* 0x.0100 - Reset Control Word Status registers
There are 16 registers */
u8 res140[0x224 - 0x140];
- __be32 iodelay1; /* 0x.0224 - IO delay control register 1 */
- __be32 iodelay2; /* 0x.0228 - IO delay control register 2 */
+ u32 iodelay1; /* 0x.0224 - IO delay control register 1 */
+ u32 iodelay2; /* 0x.0228 - IO delay control register 2 */
u8 res22c[0x604 - 0x22c];
- __be32 pamubypenr; /* 0x.604 - PAMU bypass enable register */
+ u32 pamubypenr; /* 0x.604 - PAMU bypass enable register */
u8 res608[0x800 - 0x608];
- __be32 clkdvdr; /* 0x.0800 - Clock Divide Register */
+ u32 clkdvdr; /* 0x.0800 - Clock Divide Register */
u8 res804[0x900 - 0x804];
- __be32 ircr; /* 0x.0900 - Infrared Control Register */
+ u32 ircr; /* 0x.0900 - Infrared Control Register */
u8 res904[0x908 - 0x904];
- __be32 dmacr; /* 0x.0908 - DMA Control Register */
+ u32 dmacr; /* 0x.0908 - DMA Control Register */
u8 res90c[0x914 - 0x90c];
- __be32 elbccr; /* 0x.0914 - eLBC Control Register */
+ u32 elbccr; /* 0x.0914 - eLBC Control Register */
u8 res918[0xb20 - 0x918];
- __be32 ddr1clkdr; /* 0x.0b20 - DDR1 Clock Disable Register */
- __be32 ddr2clkdr; /* 0x.0b24 - DDR2 Clock Disable Register */
- __be32 ddrclkdr; /* 0x.0b28 - DDR Clock Disable Register */
+ u32 ddr1clkdr; /* 0x.0b20 - DDR1 Clock Disable Register */
+ u32 ddr2clkdr; /* 0x.0b24 - DDR2 Clock Disable Register */
+ u32 ddrclkdr; /* 0x.0b28 - DDR Clock Disable Register */
u8 resb2c[0xe00 - 0xb2c];
- __be32 clkocr; /* 0x.0e00 - Clock Out Select Register */
+ u32 clkocr; /* 0x.0e00 - Clock Out Select Register */
u8 rese04[0xe10 - 0xe04];
- __be32 ddrdllcr; /* 0x.0e10 - DDR DLL Control Register */
+ u32 ddrdllcr; /* 0x.0e10 - DDR DLL Control Register */
u8 rese14[0xe20 - 0xe14];
- __be32 lbcdllcr; /* 0x.0e20 - LBC DLL Control Register */
- __be32 cpfor; /* 0x.0e24 - L2 charge pump fuse override register */
+ u32 lbcdllcr; /* 0x.0e20 - LBC DLL Control Register */
+ u32 cpfor; /* 0x.0e24 - L2 charge pump fuse override
+ * register
+ */
u8 rese28[0xf04 - 0xe28];
- __be32 srds1cr0; /* 0x.0f04 - SerDes1 Control Register 0 */
- __be32 srds1cr1; /* 0x.0f08 - SerDes1 Control Register 0 */
+ u32 srds1cr0; /* 0x.0f04 - SerDes1 Control Register 0 */
+ u32 srds1cr1; /* 0x.0f08 - SerDes1 Control Register 0 */
u8 resf0c[0xf2c - 0xf0c];
- __be32 itcr; /* 0x.0f2c - Internal transaction control register */
+ u32 itcr; /* 0x.0f2c - Internal transaction control
+ * register
+ */
u8 resf30[0xf40 - 0xf30];
- __be32 srds2cr0; /* 0x.0f40 - SerDes2 Control Register 0 */
- __be32 srds2cr1; /* 0x.0f44 - SerDes2 Control Register 0 */
+ u32 srds2cr0; /* 0x.0f40 - SerDes2 Control Register 0 */
+ u32 srds2cr1; /* 0x.0f44 - SerDes2 Control Register 0 */
} __attribute__ ((packed));
+u32 fsl_guts_get_svr(void);
+int fsl_guts_init(void);
/* Alternate function signal multiplex control */
#define MPC85xx_PMUXCR_QE(x) (0x8000 >> (x))
--
2.1.0.27.g96db324
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 3/7] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Mark Rutland, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Russell King,
Yangbo Lu, Bhupesh Sharma, Santosh Shilimkar, Jochen Friedrich,
leoyang.li-3arQi8VN3Tc, Scott Wood, Rob Herring, Claudiu Manoil,
Kumar Gala, xiaobo.xie-3arQi8VN3Tc, Qiang Zhao
The global utilities block controls power management, I/O device
enabling, power-onreset(POR) configuration monitoring, alternate
function selection for multiplexed signals,and clock control.
This patch adds GUTS driver to manage and access global utilities
block.
Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
Acked-by: Scott Wood <oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org>
---
Changes for v4:
- Added this patch
Changes for v5:
- Modified copyright info
- Changed MODULE_LICENSE to GPL
- Changed EXPORT_SYMBOL_GPL to EXPORT_SYMBOL
- Made FSL_GUTS user-invisible
- Added a complete compatible list for GUTS
- Stored guts info in file-scope variable
- Added mfspr() getting SVR
- Redefined GUTS APIs
- Called fsl_guts_init rather than using platform driver
- Removed useless parentheses
- Removed useless 'extern' key words
Changes for v6:
- Made guts thread safe in fsl_guts_init
Changes for v7:
- Removed 'ifdef' for function declaration in guts.h
Changes for v8:
- Fixes lines longer than 80 characters checkpatch issue
- Added 'Acked-by: Scott Wood'
Changes for v9:
- None
Changes for v10:
- None
---
drivers/soc/Kconfig | 2 +-
drivers/soc/fsl/Kconfig | 8 +++
drivers/soc/fsl/Makefile | 1 +
drivers/soc/fsl/guts.c | 119 ++++++++++++++++++++++++++++++++++++++++++++
include/linux/fsl/guts.h | 126 +++++++++++++++++++++++++++++------------------
5 files changed, 207 insertions(+), 49 deletions(-)
create mode 100644 drivers/soc/fsl/Kconfig
create mode 100644 drivers/soc/fsl/guts.c
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index cb58ef0..7106463 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -2,7 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
source "drivers/soc/bcm/Kconfig"
source "drivers/soc/brcmstb/Kconfig"
-source "drivers/soc/fsl/qe/Kconfig"
+source "drivers/soc/fsl/Kconfig"
source "drivers/soc/mediatek/Kconfig"
source "drivers/soc/qcom/Kconfig"
source "drivers/soc/rockchip/Kconfig"
diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
new file mode 100644
index 0000000..b313759
--- /dev/null
+++ b/drivers/soc/fsl/Kconfig
@@ -0,0 +1,8 @@
+#
+# Freescale SOC drivers
+#
+
+source "drivers/soc/fsl/qe/Kconfig"
+
+config FSL_GUTS
+ bool
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 203307f..02afb7f 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_QUICC_ENGINE) += qe/
obj-$(CONFIG_CPM) += qe/
+obj-$(CONFIG_FSL_GUTS) += guts.o
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
new file mode 100644
index 0000000..fa155e6
--- /dev/null
+++ b/drivers/soc/fsl/guts.c
@@ -0,0 +1,119 @@
+/*
+ * Freescale QorIQ Platforms GUTS Driver
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/mutex.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/fsl/guts.h>
+
+struct guts {
+ struct ccsr_guts __iomem *regs;
+ bool little_endian;
+};
+
+static struct guts *guts;
+static DEFINE_MUTEX(guts_lock);
+
+u32 fsl_guts_get_svr(void)
+{
+ u32 svr = 0;
+
+ if (!guts || !guts->regs) {
+#ifdef CONFIG_PPC
+ svr = mfspr(SPRN_SVR);
+#endif
+ return svr;
+ }
+
+ if (guts->little_endian)
+ svr = ioread32(&guts->regs->svr);
+ else
+ svr = ioread32be(&guts->regs->svr);
+
+ return svr;
+}
+EXPORT_SYMBOL(fsl_guts_get_svr);
+
+/*
+ * Table for matching compatible strings, for device tree
+ * guts node, for Freescale QorIQ SOCs.
+ */
+static const struct of_device_id guts_of_match[] = {
+ /* For T4 & B4 Series SOCs */
+ { .compatible = "fsl,qoriq-device-config-1.0", },
+ /* For P Series SOCs */
+ { .compatible = "fsl,qoriq-device-config-2.0", },
+ { .compatible = "fsl,p1010-guts", },
+ { .compatible = "fsl,p1020-guts", },
+ { .compatible = "fsl,p1021-guts", },
+ { .compatible = "fsl,p1022-guts", },
+ { .compatible = "fsl,p1023-guts", },
+ { .compatible = "fsl,p2020-guts", },
+ /* For BSC Series SOCs */
+ { .compatible = "fsl,bsc9131-guts", },
+ { .compatible = "fsl,bsc9132-guts", },
+ /* For MPC85xx Series SOCs */
+ { .compatible = "fsl,mpc8536-guts", },
+ { .compatible = "fsl,mpc8544-guts", },
+ { .compatible = "fsl,mpc8548-guts", },
+ { .compatible = "fsl,mpc8568-guts", },
+ { .compatible = "fsl,mpc8569-guts", },
+ { .compatible = "fsl,mpc8572-guts", },
+ /* For Layerscape Series SOCs */
+ { .compatible = "fsl,ls1021a-dcfg", },
+ { .compatible = "fsl,ls1043a-dcfg", },
+ { .compatible = "fsl,ls2080a-dcfg", },
+ {}
+};
+
+int fsl_guts_init(void)
+{
+ struct device_node *np;
+ int ret;
+
+ mutex_lock(&guts_lock);
+ /* Initialize guts only once */
+ if (guts) {
+ ret = guts->regs ? 0 : -ENOMEM;
+ goto out;
+ }
+
+ np = of_find_matching_node(NULL, guts_of_match);
+ if (!np) {
+ ret = -ENODEV;
+ goto out;
+ }
+
+ guts = kzalloc(sizeof(*guts), GFP_KERNEL);
+ if (!guts) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ guts->little_endian = of_property_read_bool(np, "little-endian");
+
+ guts->regs = of_iomap(np, 0);
+ if (!guts->regs) {
+ ret = -ENOMEM;
+ kfree(guts);
+ goto out;
+ }
+
+ of_node_put(np);
+ ret = 0;
+out:
+ mutex_unlock(&guts_lock);
+ return ret;
+}
+EXPORT_SYMBOL(fsl_guts_init);
diff --git a/include/linux/fsl/guts.h b/include/linux/fsl/guts.h
index 649e917..7e1e22b 100644
--- a/include/linux/fsl/guts.h
+++ b/include/linux/fsl/guts.h
@@ -29,83 +29,113 @@
* #ifdefs.
*/
struct ccsr_guts {
- __be32 porpllsr; /* 0x.0000 - POR PLL Ratio Status Register */
- __be32 porbmsr; /* 0x.0004 - POR Boot Mode Status Register */
- __be32 porimpscr; /* 0x.0008 - POR I/O Impedance Status and Control Register */
- __be32 pordevsr; /* 0x.000c - POR I/O Device Status Register */
- __be32 pordbgmsr; /* 0x.0010 - POR Debug Mode Status Register */
- __be32 pordevsr2; /* 0x.0014 - POR device status register 2 */
+ u32 porpllsr; /* 0x.0000 - POR PLL Ratio Status Register */
+ u32 porbmsr; /* 0x.0004 - POR Boot Mode Status Register */
+ u32 porimpscr; /* 0x.0008 - POR I/O Impedance Status and
+ * Control Register
+ */
+ u32 pordevsr; /* 0x.000c - POR I/O Device Status Register */
+ u32 pordbgmsr; /* 0x.0010 - POR Debug Mode Status Register */
+ u32 pordevsr2; /* 0x.0014 - POR device status register 2 */
u8 res018[0x20 - 0x18];
- __be32 porcir; /* 0x.0020 - POR Configuration Information Register */
+ u32 porcir; /* 0x.0020 - POR Configuration Information
+ * Register
+ */
u8 res024[0x30 - 0x24];
- __be32 gpiocr; /* 0x.0030 - GPIO Control Register */
+ u32 gpiocr; /* 0x.0030 - GPIO Control Register */
u8 res034[0x40 - 0x34];
- __be32 gpoutdr; /* 0x.0040 - General-Purpose Output Data Register */
+ u32 gpoutdr; /* 0x.0040 - General-Purpose Output Data
+ * Register
+ */
u8 res044[0x50 - 0x44];
- __be32 gpindr; /* 0x.0050 - General-Purpose Input Data Register */
+ u32 gpindr; /* 0x.0050 - General-Purpose Input Data
+ * Register
+ */
u8 res054[0x60 - 0x54];
- __be32 pmuxcr; /* 0x.0060 - Alternate Function Signal Multiplex Control */
- __be32 pmuxcr2; /* 0x.0064 - Alternate function signal multiplex control 2 */
- __be32 dmuxcr; /* 0x.0068 - DMA Mux Control Register */
+ u32 pmuxcr; /* 0x.0060 - Alternate Function Signal
+ * Multiplex Control
+ */
+ u32 pmuxcr2; /* 0x.0064 - Alternate function signal
+ * multiplex control 2
+ */
+ u32 dmuxcr; /* 0x.0068 - DMA Mux Control Register */
u8 res06c[0x70 - 0x6c];
- __be32 devdisr; /* 0x.0070 - Device Disable Control */
+ u32 devdisr; /* 0x.0070 - Device Disable Control */
#define CCSR_GUTS_DEVDISR_TB1 0x00001000
#define CCSR_GUTS_DEVDISR_TB0 0x00004000
- __be32 devdisr2; /* 0x.0074 - Device Disable Control 2 */
+ u32 devdisr2; /* 0x.0074 - Device Disable Control 2 */
u8 res078[0x7c - 0x78];
- __be32 pmjcr; /* 0x.007c - 4 Power Management Jog Control Register */
- __be32 powmgtcsr; /* 0x.0080 - Power Management Status and Control Register */
- __be32 pmrccr; /* 0x.0084 - Power Management Reset Counter Configuration Register */
- __be32 pmpdccr; /* 0x.0088 - Power Management Power Down Counter Configuration Register */
- __be32 pmcdr; /* 0x.008c - 4Power management clock disable register */
- __be32 mcpsumr; /* 0x.0090 - Machine Check Summary Register */
- __be32 rstrscr; /* 0x.0094 - Reset Request Status and Control Register */
- __be32 ectrstcr; /* 0x.0098 - Exception reset control register */
- __be32 autorstsr; /* 0x.009c - Automatic reset status register */
- __be32 pvr; /* 0x.00a0 - Processor Version Register */
- __be32 svr; /* 0x.00a4 - System Version Register */
+ u32 pmjcr; /* 0x.007c - 4 Power Management Jog Control
+ * Register
+ */
+ u32 powmgtcsr; /* 0x.0080 - Power Management Status and
+ * Control Register
+ */
+ u32 pmrccr; /* 0x.0084 - Power Management Reset Counter
+ * Configuration Register
+ */
+ u32 pmpdccr; /* 0x.0088 - Power Management Power Down Counter
+ * Configuration Register
+ */
+ u32 pmcdr; /* 0x.008c - 4Power management clock disable
+ * register
+ */
+ u32 mcpsumr; /* 0x.0090 - Machine Check Summary Register */
+ u32 rstrscr; /* 0x.0094 - Reset Request Status and
+ * Control Register
+ */
+ u32 ectrstcr; /* 0x.0098 - Exception reset control register */
+ u32 autorstsr; /* 0x.009c - Automatic reset status register */
+ u32 pvr; /* 0x.00a0 - Processor Version Register */
+ u32 svr; /* 0x.00a4 - System Version Register */
u8 res0a8[0xb0 - 0xa8];
- __be32 rstcr; /* 0x.00b0 - Reset Control Register */
+ u32 rstcr; /* 0x.00b0 - Reset Control Register */
u8 res0b4[0xc0 - 0xb4];
- __be32 iovselsr; /* 0x.00c0 - I/O voltage select status register
+ u32 iovselsr; /* 0x.00c0 - I/O voltage select status register
Called 'elbcvselcr' on 86xx SOCs */
u8 res0c4[0x100 - 0xc4];
- __be32 rcwsr[16]; /* 0x.0100 - Reset Control Word Status registers
+ u32 rcwsr[16]; /* 0x.0100 - Reset Control Word Status registers
There are 16 registers */
u8 res140[0x224 - 0x140];
- __be32 iodelay1; /* 0x.0224 - IO delay control register 1 */
- __be32 iodelay2; /* 0x.0228 - IO delay control register 2 */
+ u32 iodelay1; /* 0x.0224 - IO delay control register 1 */
+ u32 iodelay2; /* 0x.0228 - IO delay control register 2 */
u8 res22c[0x604 - 0x22c];
- __be32 pamubypenr; /* 0x.604 - PAMU bypass enable register */
+ u32 pamubypenr; /* 0x.604 - PAMU bypass enable register */
u8 res608[0x800 - 0x608];
- __be32 clkdvdr; /* 0x.0800 - Clock Divide Register */
+ u32 clkdvdr; /* 0x.0800 - Clock Divide Register */
u8 res804[0x900 - 0x804];
- __be32 ircr; /* 0x.0900 - Infrared Control Register */
+ u32 ircr; /* 0x.0900 - Infrared Control Register */
u8 res904[0x908 - 0x904];
- __be32 dmacr; /* 0x.0908 - DMA Control Register */
+ u32 dmacr; /* 0x.0908 - DMA Control Register */
u8 res90c[0x914 - 0x90c];
- __be32 elbccr; /* 0x.0914 - eLBC Control Register */
+ u32 elbccr; /* 0x.0914 - eLBC Control Register */
u8 res918[0xb20 - 0x918];
- __be32 ddr1clkdr; /* 0x.0b20 - DDR1 Clock Disable Register */
- __be32 ddr2clkdr; /* 0x.0b24 - DDR2 Clock Disable Register */
- __be32 ddrclkdr; /* 0x.0b28 - DDR Clock Disable Register */
+ u32 ddr1clkdr; /* 0x.0b20 - DDR1 Clock Disable Register */
+ u32 ddr2clkdr; /* 0x.0b24 - DDR2 Clock Disable Register */
+ u32 ddrclkdr; /* 0x.0b28 - DDR Clock Disable Register */
u8 resb2c[0xe00 - 0xb2c];
- __be32 clkocr; /* 0x.0e00 - Clock Out Select Register */
+ u32 clkocr; /* 0x.0e00 - Clock Out Select Register */
u8 rese04[0xe10 - 0xe04];
- __be32 ddrdllcr; /* 0x.0e10 - DDR DLL Control Register */
+ u32 ddrdllcr; /* 0x.0e10 - DDR DLL Control Register */
u8 rese14[0xe20 - 0xe14];
- __be32 lbcdllcr; /* 0x.0e20 - LBC DLL Control Register */
- __be32 cpfor; /* 0x.0e24 - L2 charge pump fuse override register */
+ u32 lbcdllcr; /* 0x.0e20 - LBC DLL Control Register */
+ u32 cpfor; /* 0x.0e24 - L2 charge pump fuse override
+ * register
+ */
u8 rese28[0xf04 - 0xe28];
- __be32 srds1cr0; /* 0x.0f04 - SerDes1 Control Register 0 */
- __be32 srds1cr1; /* 0x.0f08 - SerDes1 Control Register 0 */
+ u32 srds1cr0; /* 0x.0f04 - SerDes1 Control Register 0 */
+ u32 srds1cr1; /* 0x.0f08 - SerDes1 Control Register 0 */
u8 resf0c[0xf2c - 0xf0c];
- __be32 itcr; /* 0x.0f2c - Internal transaction control register */
+ u32 itcr; /* 0x.0f2c - Internal transaction control
+ * register
+ */
u8 resf30[0xf40 - 0xf30];
- __be32 srds2cr0; /* 0x.0f40 - SerDes2 Control Register 0 */
- __be32 srds2cr1; /* 0x.0f44 - SerDes2 Control Register 0 */
+ u32 srds2cr0; /* 0x.0f40 - SerDes2 Control Register 0 */
+ u32 srds2cr1; /* 0x.0f44 - SerDes2 Control Register 0 */
} __attribute__ ((packed));
+u32 fsl_guts_get_svr(void);
+int fsl_guts_init(void);
/* Alternate function signal multiplex control */
#define MPC85xx_PMUXCR_QE(x) (0x8000 >> (x))
--
2.1.0.27.g96db324
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 3/7] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Mark Rutland, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Russell King,
Yangbo Lu, Bhupesh Sharma, Santosh Shilimkar, Jochen Friedrich,
leoyang.li-3arQi8VN3Tc, Scott Wood, Rob Herring, Claudiu Manoil,
Kumar Gala, xiaobo.xie-3arQi8VN3Tc, Qiang Zhao
The global utilities block controls power management, I/O device
enabling, power-onreset(POR) configuration monitoring, alternate
function selection for multiplexed signals,and clock control.
This patch adds GUTS driver to manage and access global utilities
block.
Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
Acked-by: Scott Wood <oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org>
---
Changes for v4:
- Added this patch
Changes for v5:
- Modified copyright info
- Changed MODULE_LICENSE to GPL
- Changed EXPORT_SYMBOL_GPL to EXPORT_SYMBOL
- Made FSL_GUTS user-invisible
- Added a complete compatible list for GUTS
- Stored guts info in file-scope variable
- Added mfspr() getting SVR
- Redefined GUTS APIs
- Called fsl_guts_init rather than using platform driver
- Removed useless parentheses
- Removed useless 'extern' key words
Changes for v6:
- Made guts thread safe in fsl_guts_init
Changes for v7:
- Removed 'ifdef' for function declaration in guts.h
Changes for v8:
- Fixes lines longer than 80 characters checkpatch issue
- Added 'Acked-by: Scott Wood'
Changes for v9:
- None
Changes for v10:
- None
---
drivers/soc/Kconfig | 2 +-
drivers/soc/fsl/Kconfig | 8 +++
drivers/soc/fsl/Makefile | 1 +
drivers/soc/fsl/guts.c | 119 ++++++++++++++++++++++++++++++++++++++++++++
include/linux/fsl/guts.h | 126 +++++++++++++++++++++++++++++------------------
5 files changed, 207 insertions(+), 49 deletions(-)
create mode 100644 drivers/soc/fsl/Kconfig
create mode 100644 drivers/soc/fsl/guts.c
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index cb58ef0..7106463 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -2,7 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
source "drivers/soc/bcm/Kconfig"
source "drivers/soc/brcmstb/Kconfig"
-source "drivers/soc/fsl/qe/Kconfig"
+source "drivers/soc/fsl/Kconfig"
source "drivers/soc/mediatek/Kconfig"
source "drivers/soc/qcom/Kconfig"
source "drivers/soc/rockchip/Kconfig"
diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
new file mode 100644
index 0000000..b313759
--- /dev/null
+++ b/drivers/soc/fsl/Kconfig
@@ -0,0 +1,8 @@
+#
+# Freescale SOC drivers
+#
+
+source "drivers/soc/fsl/qe/Kconfig"
+
+config FSL_GUTS
+ bool
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 203307f..02afb7f 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_QUICC_ENGINE) += qe/
obj-$(CONFIG_CPM) += qe/
+obj-$(CONFIG_FSL_GUTS) += guts.o
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
new file mode 100644
index 0000000..fa155e6
--- /dev/null
+++ b/drivers/soc/fsl/guts.c
@@ -0,0 +1,119 @@
+/*
+ * Freescale QorIQ Platforms GUTS Driver
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/mutex.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/fsl/guts.h>
+
+struct guts {
+ struct ccsr_guts __iomem *regs;
+ bool little_endian;
+};
+
+static struct guts *guts;
+static DEFINE_MUTEX(guts_lock);
+
+u32 fsl_guts_get_svr(void)
+{
+ u32 svr = 0;
+
+ if (!guts || !guts->regs) {
+#ifdef CONFIG_PPC
+ svr = mfspr(SPRN_SVR);
+#endif
+ return svr;
+ }
+
+ if (guts->little_endian)
+ svr = ioread32(&guts->regs->svr);
+ else
+ svr = ioread32be(&guts->regs->svr);
+
+ return svr;
+}
+EXPORT_SYMBOL(fsl_guts_get_svr);
+
+/*
+ * Table for matching compatible strings, for device tree
+ * guts node, for Freescale QorIQ SOCs.
+ */
+static const struct of_device_id guts_of_match[] = {
+ /* For T4 & B4 Series SOCs */
+ { .compatible = "fsl,qoriq-device-config-1.0", },
+ /* For P Series SOCs */
+ { .compatible = "fsl,qoriq-device-config-2.0", },
+ { .compatible = "fsl,p1010-guts", },
+ { .compatible = "fsl,p1020-guts", },
+ { .compatible = "fsl,p1021-guts", },
+ { .compatible = "fsl,p1022-guts", },
+ { .compatible = "fsl,p1023-guts", },
+ { .compatible = "fsl,p2020-guts", },
+ /* For BSC Series SOCs */
+ { .compatible = "fsl,bsc9131-guts", },
+ { .compatible = "fsl,bsc9132-guts", },
+ /* For MPC85xx Series SOCs */
+ { .compatible = "fsl,mpc8536-guts", },
+ { .compatible = "fsl,mpc8544-guts", },
+ { .compatible = "fsl,mpc8548-guts", },
+ { .compatible = "fsl,mpc8568-guts", },
+ { .compatible = "fsl,mpc8569-guts", },
+ { .compatible = "fsl,mpc8572-guts", },
+ /* For Layerscape Series SOCs */
+ { .compatible = "fsl,ls1021a-dcfg", },
+ { .compatible = "fsl,ls1043a-dcfg", },
+ { .compatible = "fsl,ls2080a-dcfg", },
+ {}
+};
+
+int fsl_guts_init(void)
+{
+ struct device_node *np;
+ int ret;
+
+ mutex_lock(&guts_lock);
+ /* Initialize guts only once */
+ if (guts) {
+ ret = guts->regs ? 0 : -ENOMEM;
+ goto out;
+ }
+
+ np = of_find_matching_node(NULL, guts_of_match);
+ if (!np) {
+ ret = -ENODEV;
+ goto out;
+ }
+
+ guts = kzalloc(sizeof(*guts), GFP_KERNEL);
+ if (!guts) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ guts->little_endian = of_property_read_bool(np, "little-endian");
+
+ guts->regs = of_iomap(np, 0);
+ if (!guts->regs) {
+ ret = -ENOMEM;
+ kfree(guts);
+ goto out;
+ }
+
+ of_node_put(np);
+ ret = 0;
+out:
+ mutex_unlock(&guts_lock);
+ return ret;
+}
+EXPORT_SYMBOL(fsl_guts_init);
diff --git a/include/linux/fsl/guts.h b/include/linux/fsl/guts.h
index 649e917..7e1e22b 100644
--- a/include/linux/fsl/guts.h
+++ b/include/linux/fsl/guts.h
@@ -29,83 +29,113 @@
* #ifdefs.
*/
struct ccsr_guts {
- __be32 porpllsr; /* 0x.0000 - POR PLL Ratio Status Register */
- __be32 porbmsr; /* 0x.0004 - POR Boot Mode Status Register */
- __be32 porimpscr; /* 0x.0008 - POR I/O Impedance Status and Control Register */
- __be32 pordevsr; /* 0x.000c - POR I/O Device Status Register */
- __be32 pordbgmsr; /* 0x.0010 - POR Debug Mode Status Register */
- __be32 pordevsr2; /* 0x.0014 - POR device status register 2 */
+ u32 porpllsr; /* 0x.0000 - POR PLL Ratio Status Register */
+ u32 porbmsr; /* 0x.0004 - POR Boot Mode Status Register */
+ u32 porimpscr; /* 0x.0008 - POR I/O Impedance Status and
+ * Control Register
+ */
+ u32 pordevsr; /* 0x.000c - POR I/O Device Status Register */
+ u32 pordbgmsr; /* 0x.0010 - POR Debug Mode Status Register */
+ u32 pordevsr2; /* 0x.0014 - POR device status register 2 */
u8 res018[0x20 - 0x18];
- __be32 porcir; /* 0x.0020 - POR Configuration Information Register */
+ u32 porcir; /* 0x.0020 - POR Configuration Information
+ * Register
+ */
u8 res024[0x30 - 0x24];
- __be32 gpiocr; /* 0x.0030 - GPIO Control Register */
+ u32 gpiocr; /* 0x.0030 - GPIO Control Register */
u8 res034[0x40 - 0x34];
- __be32 gpoutdr; /* 0x.0040 - General-Purpose Output Data Register */
+ u32 gpoutdr; /* 0x.0040 - General-Purpose Output Data
+ * Register
+ */
u8 res044[0x50 - 0x44];
- __be32 gpindr; /* 0x.0050 - General-Purpose Input Data Register */
+ u32 gpindr; /* 0x.0050 - General-Purpose Input Data
+ * Register
+ */
u8 res054[0x60 - 0x54];
- __be32 pmuxcr; /* 0x.0060 - Alternate Function Signal Multiplex Control */
- __be32 pmuxcr2; /* 0x.0064 - Alternate function signal multiplex control 2 */
- __be32 dmuxcr; /* 0x.0068 - DMA Mux Control Register */
+ u32 pmuxcr; /* 0x.0060 - Alternate Function Signal
+ * Multiplex Control
+ */
+ u32 pmuxcr2; /* 0x.0064 - Alternate function signal
+ * multiplex control 2
+ */
+ u32 dmuxcr; /* 0x.0068 - DMA Mux Control Register */
u8 res06c[0x70 - 0x6c];
- __be32 devdisr; /* 0x.0070 - Device Disable Control */
+ u32 devdisr; /* 0x.0070 - Device Disable Control */
#define CCSR_GUTS_DEVDISR_TB1 0x00001000
#define CCSR_GUTS_DEVDISR_TB0 0x00004000
- __be32 devdisr2; /* 0x.0074 - Device Disable Control 2 */
+ u32 devdisr2; /* 0x.0074 - Device Disable Control 2 */
u8 res078[0x7c - 0x78];
- __be32 pmjcr; /* 0x.007c - 4 Power Management Jog Control Register */
- __be32 powmgtcsr; /* 0x.0080 - Power Management Status and Control Register */
- __be32 pmrccr; /* 0x.0084 - Power Management Reset Counter Configuration Register */
- __be32 pmpdccr; /* 0x.0088 - Power Management Power Down Counter Configuration Register */
- __be32 pmcdr; /* 0x.008c - 4Power management clock disable register */
- __be32 mcpsumr; /* 0x.0090 - Machine Check Summary Register */
- __be32 rstrscr; /* 0x.0094 - Reset Request Status and Control Register */
- __be32 ectrstcr; /* 0x.0098 - Exception reset control register */
- __be32 autorstsr; /* 0x.009c - Automatic reset status register */
- __be32 pvr; /* 0x.00a0 - Processor Version Register */
- __be32 svr; /* 0x.00a4 - System Version Register */
+ u32 pmjcr; /* 0x.007c - 4 Power Management Jog Control
+ * Register
+ */
+ u32 powmgtcsr; /* 0x.0080 - Power Management Status and
+ * Control Register
+ */
+ u32 pmrccr; /* 0x.0084 - Power Management Reset Counter
+ * Configuration Register
+ */
+ u32 pmpdccr; /* 0x.0088 - Power Management Power Down Counter
+ * Configuration Register
+ */
+ u32 pmcdr; /* 0x.008c - 4Power management clock disable
+ * register
+ */
+ u32 mcpsumr; /* 0x.0090 - Machine Check Summary Register */
+ u32 rstrscr; /* 0x.0094 - Reset Request Status and
+ * Control Register
+ */
+ u32 ectrstcr; /* 0x.0098 - Exception reset control register */
+ u32 autorstsr; /* 0x.009c - Automatic reset status register */
+ u32 pvr; /* 0x.00a0 - Processor Version Register */
+ u32 svr; /* 0x.00a4 - System Version Register */
u8 res0a8[0xb0 - 0xa8];
- __be32 rstcr; /* 0x.00b0 - Reset Control Register */
+ u32 rstcr; /* 0x.00b0 - Reset Control Register */
u8 res0b4[0xc0 - 0xb4];
- __be32 iovselsr; /* 0x.00c0 - I/O voltage select status register
+ u32 iovselsr; /* 0x.00c0 - I/O voltage select status register
Called 'elbcvselcr' on 86xx SOCs */
u8 res0c4[0x100 - 0xc4];
- __be32 rcwsr[16]; /* 0x.0100 - Reset Control Word Status registers
+ u32 rcwsr[16]; /* 0x.0100 - Reset Control Word Status registers
There are 16 registers */
u8 res140[0x224 - 0x140];
- __be32 iodelay1; /* 0x.0224 - IO delay control register 1 */
- __be32 iodelay2; /* 0x.0228 - IO delay control register 2 */
+ u32 iodelay1; /* 0x.0224 - IO delay control register 1 */
+ u32 iodelay2; /* 0x.0228 - IO delay control register 2 */
u8 res22c[0x604 - 0x22c];
- __be32 pamubypenr; /* 0x.604 - PAMU bypass enable register */
+ u32 pamubypenr; /* 0x.604 - PAMU bypass enable register */
u8 res608[0x800 - 0x608];
- __be32 clkdvdr; /* 0x.0800 - Clock Divide Register */
+ u32 clkdvdr; /* 0x.0800 - Clock Divide Register */
u8 res804[0x900 - 0x804];
- __be32 ircr; /* 0x.0900 - Infrared Control Register */
+ u32 ircr; /* 0x.0900 - Infrared Control Register */
u8 res904[0x908 - 0x904];
- __be32 dmacr; /* 0x.0908 - DMA Control Register */
+ u32 dmacr; /* 0x.0908 - DMA Control Register */
u8 res90c[0x914 - 0x90c];
- __be32 elbccr; /* 0x.0914 - eLBC Control Register */
+ u32 elbccr; /* 0x.0914 - eLBC Control Register */
u8 res918[0xb20 - 0x918];
- __be32 ddr1clkdr; /* 0x.0b20 - DDR1 Clock Disable Register */
- __be32 ddr2clkdr; /* 0x.0b24 - DDR2 Clock Disable Register */
- __be32 ddrclkdr; /* 0x.0b28 - DDR Clock Disable Register */
+ u32 ddr1clkdr; /* 0x.0b20 - DDR1 Clock Disable Register */
+ u32 ddr2clkdr; /* 0x.0b24 - DDR2 Clock Disable Register */
+ u32 ddrclkdr; /* 0x.0b28 - DDR Clock Disable Register */
u8 resb2c[0xe00 - 0xb2c];
- __be32 clkocr; /* 0x.0e00 - Clock Out Select Register */
+ u32 clkocr; /* 0x.0e00 - Clock Out Select Register */
u8 rese04[0xe10 - 0xe04];
- __be32 ddrdllcr; /* 0x.0e10 - DDR DLL Control Register */
+ u32 ddrdllcr; /* 0x.0e10 - DDR DLL Control Register */
u8 rese14[0xe20 - 0xe14];
- __be32 lbcdllcr; /* 0x.0e20 - LBC DLL Control Register */
- __be32 cpfor; /* 0x.0e24 - L2 charge pump fuse override register */
+ u32 lbcdllcr; /* 0x.0e20 - LBC DLL Control Register */
+ u32 cpfor; /* 0x.0e24 - L2 charge pump fuse override
+ * register
+ */
u8 rese28[0xf04 - 0xe28];
- __be32 srds1cr0; /* 0x.0f04 - SerDes1 Control Register 0 */
- __be32 srds1cr1; /* 0x.0f08 - SerDes1 Control Register 0 */
+ u32 srds1cr0; /* 0x.0f04 - SerDes1 Control Register 0 */
+ u32 srds1cr1; /* 0x.0f08 - SerDes1 Control Register 0 */
u8 resf0c[0xf2c - 0xf0c];
- __be32 itcr; /* 0x.0f2c - Internal transaction control register */
+ u32 itcr; /* 0x.0f2c - Internal transaction control
+ * register
+ */
u8 resf30[0xf40 - 0xf30];
- __be32 srds2cr0; /* 0x.0f40 - SerDes2 Control Register 0 */
- __be32 srds2cr1; /* 0x.0f44 - SerDes2 Control Register 0 */
+ u32 srds2cr0; /* 0x.0f40 - SerDes2 Control Register 0 */
+ u32 srds2cr1; /* 0x.0f44 - SerDes2 Control Register 0 */
} __attribute__ ((packed));
+u32 fsl_guts_get_svr(void);
+int fsl_guts_init(void);
/* Alternate function signal multiplex control */
#define MPC85xx_PMUXCR_QE(x) (0x8000 >> (x))
--
2.1.0.27.g96db324
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 3/7] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-arm-kernel
The global utilities block controls power management, I/O device
enabling, power-onreset(POR) configuration monitoring, alternate
function selection for multiplexed signals,and clock control.
This patch adds GUTS driver to manage and access global utilities
block.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Scott Wood <oss@buserror.net>
---
Changes for v4:
- Added this patch
Changes for v5:
- Modified copyright info
- Changed MODULE_LICENSE to GPL
- Changed EXPORT_SYMBOL_GPL to EXPORT_SYMBOL
- Made FSL_GUTS user-invisible
- Added a complete compatible list for GUTS
- Stored guts info in file-scope variable
- Added mfspr() getting SVR
- Redefined GUTS APIs
- Called fsl_guts_init rather than using platform driver
- Removed useless parentheses
- Removed useless 'extern' key words
Changes for v6:
- Made guts thread safe in fsl_guts_init
Changes for v7:
- Removed 'ifdef' for function declaration in guts.h
Changes for v8:
- Fixes lines longer than 80 characters checkpatch issue
- Added 'Acked-by: Scott Wood'
Changes for v9:
- None
Changes for v10:
- None
---
drivers/soc/Kconfig | 2 +-
drivers/soc/fsl/Kconfig | 8 +++
drivers/soc/fsl/Makefile | 1 +
drivers/soc/fsl/guts.c | 119 ++++++++++++++++++++++++++++++++++++++++++++
include/linux/fsl/guts.h | 126 +++++++++++++++++++++++++++++------------------
5 files changed, 207 insertions(+), 49 deletions(-)
create mode 100644 drivers/soc/fsl/Kconfig
create mode 100644 drivers/soc/fsl/guts.c
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index cb58ef0..7106463 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -2,7 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
source "drivers/soc/bcm/Kconfig"
source "drivers/soc/brcmstb/Kconfig"
-source "drivers/soc/fsl/qe/Kconfig"
+source "drivers/soc/fsl/Kconfig"
source "drivers/soc/mediatek/Kconfig"
source "drivers/soc/qcom/Kconfig"
source "drivers/soc/rockchip/Kconfig"
diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
new file mode 100644
index 0000000..b313759
--- /dev/null
+++ b/drivers/soc/fsl/Kconfig
@@ -0,0 +1,8 @@
+#
+# Freescale SOC drivers
+#
+
+source "drivers/soc/fsl/qe/Kconfig"
+
+config FSL_GUTS
+ bool
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 203307f..02afb7f 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_QUICC_ENGINE) += qe/
obj-$(CONFIG_CPM) += qe/
+obj-$(CONFIG_FSL_GUTS) += guts.o
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
new file mode 100644
index 0000000..fa155e6
--- /dev/null
+++ b/drivers/soc/fsl/guts.c
@@ -0,0 +1,119 @@
+/*
+ * Freescale QorIQ Platforms GUTS Driver
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/mutex.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/fsl/guts.h>
+
+struct guts {
+ struct ccsr_guts __iomem *regs;
+ bool little_endian;
+};
+
+static struct guts *guts;
+static DEFINE_MUTEX(guts_lock);
+
+u32 fsl_guts_get_svr(void)
+{
+ u32 svr = 0;
+
+ if (!guts || !guts->regs) {
+#ifdef CONFIG_PPC
+ svr = mfspr(SPRN_SVR);
+#endif
+ return svr;
+ }
+
+ if (guts->little_endian)
+ svr = ioread32(&guts->regs->svr);
+ else
+ svr = ioread32be(&guts->regs->svr);
+
+ return svr;
+}
+EXPORT_SYMBOL(fsl_guts_get_svr);
+
+/*
+ * Table for matching compatible strings, for device tree
+ * guts node, for Freescale QorIQ SOCs.
+ */
+static const struct of_device_id guts_of_match[] = {
+ /* For T4 & B4 Series SOCs */
+ { .compatible = "fsl,qoriq-device-config-1.0", },
+ /* For P Series SOCs */
+ { .compatible = "fsl,qoriq-device-config-2.0", },
+ { .compatible = "fsl,p1010-guts", },
+ { .compatible = "fsl,p1020-guts", },
+ { .compatible = "fsl,p1021-guts", },
+ { .compatible = "fsl,p1022-guts", },
+ { .compatible = "fsl,p1023-guts", },
+ { .compatible = "fsl,p2020-guts", },
+ /* For BSC Series SOCs */
+ { .compatible = "fsl,bsc9131-guts", },
+ { .compatible = "fsl,bsc9132-guts", },
+ /* For MPC85xx Series SOCs */
+ { .compatible = "fsl,mpc8536-guts", },
+ { .compatible = "fsl,mpc8544-guts", },
+ { .compatible = "fsl,mpc8548-guts", },
+ { .compatible = "fsl,mpc8568-guts", },
+ { .compatible = "fsl,mpc8569-guts", },
+ { .compatible = "fsl,mpc8572-guts", },
+ /* For Layerscape Series SOCs */
+ { .compatible = "fsl,ls1021a-dcfg", },
+ { .compatible = "fsl,ls1043a-dcfg", },
+ { .compatible = "fsl,ls2080a-dcfg", },
+ {}
+};
+
+int fsl_guts_init(void)
+{
+ struct device_node *np;
+ int ret;
+
+ mutex_lock(&guts_lock);
+ /* Initialize guts only once */
+ if (guts) {
+ ret = guts->regs ? 0 : -ENOMEM;
+ goto out;
+ }
+
+ np = of_find_matching_node(NULL, guts_of_match);
+ if (!np) {
+ ret = -ENODEV;
+ goto out;
+ }
+
+ guts = kzalloc(sizeof(*guts), GFP_KERNEL);
+ if (!guts) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ guts->little_endian = of_property_read_bool(np, "little-endian");
+
+ guts->regs = of_iomap(np, 0);
+ if (!guts->regs) {
+ ret = -ENOMEM;
+ kfree(guts);
+ goto out;
+ }
+
+ of_node_put(np);
+ ret = 0;
+out:
+ mutex_unlock(&guts_lock);
+ return ret;
+}
+EXPORT_SYMBOL(fsl_guts_init);
diff --git a/include/linux/fsl/guts.h b/include/linux/fsl/guts.h
index 649e917..7e1e22b 100644
--- a/include/linux/fsl/guts.h
+++ b/include/linux/fsl/guts.h
@@ -29,83 +29,113 @@
* #ifdefs.
*/
struct ccsr_guts {
- __be32 porpllsr; /* 0x.0000 - POR PLL Ratio Status Register */
- __be32 porbmsr; /* 0x.0004 - POR Boot Mode Status Register */
- __be32 porimpscr; /* 0x.0008 - POR I/O Impedance Status and Control Register */
- __be32 pordevsr; /* 0x.000c - POR I/O Device Status Register */
- __be32 pordbgmsr; /* 0x.0010 - POR Debug Mode Status Register */
- __be32 pordevsr2; /* 0x.0014 - POR device status register 2 */
+ u32 porpllsr; /* 0x.0000 - POR PLL Ratio Status Register */
+ u32 porbmsr; /* 0x.0004 - POR Boot Mode Status Register */
+ u32 porimpscr; /* 0x.0008 - POR I/O Impedance Status and
+ * Control Register
+ */
+ u32 pordevsr; /* 0x.000c - POR I/O Device Status Register */
+ u32 pordbgmsr; /* 0x.0010 - POR Debug Mode Status Register */
+ u32 pordevsr2; /* 0x.0014 - POR device status register 2 */
u8 res018[0x20 - 0x18];
- __be32 porcir; /* 0x.0020 - POR Configuration Information Register */
+ u32 porcir; /* 0x.0020 - POR Configuration Information
+ * Register
+ */
u8 res024[0x30 - 0x24];
- __be32 gpiocr; /* 0x.0030 - GPIO Control Register */
+ u32 gpiocr; /* 0x.0030 - GPIO Control Register */
u8 res034[0x40 - 0x34];
- __be32 gpoutdr; /* 0x.0040 - General-Purpose Output Data Register */
+ u32 gpoutdr; /* 0x.0040 - General-Purpose Output Data
+ * Register
+ */
u8 res044[0x50 - 0x44];
- __be32 gpindr; /* 0x.0050 - General-Purpose Input Data Register */
+ u32 gpindr; /* 0x.0050 - General-Purpose Input Data
+ * Register
+ */
u8 res054[0x60 - 0x54];
- __be32 pmuxcr; /* 0x.0060 - Alternate Function Signal Multiplex Control */
- __be32 pmuxcr2; /* 0x.0064 - Alternate function signal multiplex control 2 */
- __be32 dmuxcr; /* 0x.0068 - DMA Mux Control Register */
+ u32 pmuxcr; /* 0x.0060 - Alternate Function Signal
+ * Multiplex Control
+ */
+ u32 pmuxcr2; /* 0x.0064 - Alternate function signal
+ * multiplex control 2
+ */
+ u32 dmuxcr; /* 0x.0068 - DMA Mux Control Register */
u8 res06c[0x70 - 0x6c];
- __be32 devdisr; /* 0x.0070 - Device Disable Control */
+ u32 devdisr; /* 0x.0070 - Device Disable Control */
#define CCSR_GUTS_DEVDISR_TB1 0x00001000
#define CCSR_GUTS_DEVDISR_TB0 0x00004000
- __be32 devdisr2; /* 0x.0074 - Device Disable Control 2 */
+ u32 devdisr2; /* 0x.0074 - Device Disable Control 2 */
u8 res078[0x7c - 0x78];
- __be32 pmjcr; /* 0x.007c - 4 Power Management Jog Control Register */
- __be32 powmgtcsr; /* 0x.0080 - Power Management Status and Control Register */
- __be32 pmrccr; /* 0x.0084 - Power Management Reset Counter Configuration Register */
- __be32 pmpdccr; /* 0x.0088 - Power Management Power Down Counter Configuration Register */
- __be32 pmcdr; /* 0x.008c - 4Power management clock disable register */
- __be32 mcpsumr; /* 0x.0090 - Machine Check Summary Register */
- __be32 rstrscr; /* 0x.0094 - Reset Request Status and Control Register */
- __be32 ectrstcr; /* 0x.0098 - Exception reset control register */
- __be32 autorstsr; /* 0x.009c - Automatic reset status register */
- __be32 pvr; /* 0x.00a0 - Processor Version Register */
- __be32 svr; /* 0x.00a4 - System Version Register */
+ u32 pmjcr; /* 0x.007c - 4 Power Management Jog Control
+ * Register
+ */
+ u32 powmgtcsr; /* 0x.0080 - Power Management Status and
+ * Control Register
+ */
+ u32 pmrccr; /* 0x.0084 - Power Management Reset Counter
+ * Configuration Register
+ */
+ u32 pmpdccr; /* 0x.0088 - Power Management Power Down Counter
+ * Configuration Register
+ */
+ u32 pmcdr; /* 0x.008c - 4Power management clock disable
+ * register
+ */
+ u32 mcpsumr; /* 0x.0090 - Machine Check Summary Register */
+ u32 rstrscr; /* 0x.0094 - Reset Request Status and
+ * Control Register
+ */
+ u32 ectrstcr; /* 0x.0098 - Exception reset control register */
+ u32 autorstsr; /* 0x.009c - Automatic reset status register */
+ u32 pvr; /* 0x.00a0 - Processor Version Register */
+ u32 svr; /* 0x.00a4 - System Version Register */
u8 res0a8[0xb0 - 0xa8];
- __be32 rstcr; /* 0x.00b0 - Reset Control Register */
+ u32 rstcr; /* 0x.00b0 - Reset Control Register */
u8 res0b4[0xc0 - 0xb4];
- __be32 iovselsr; /* 0x.00c0 - I/O voltage select status register
+ u32 iovselsr; /* 0x.00c0 - I/O voltage select status register
Called 'elbcvselcr' on 86xx SOCs */
u8 res0c4[0x100 - 0xc4];
- __be32 rcwsr[16]; /* 0x.0100 - Reset Control Word Status registers
+ u32 rcwsr[16]; /* 0x.0100 - Reset Control Word Status registers
There are 16 registers */
u8 res140[0x224 - 0x140];
- __be32 iodelay1; /* 0x.0224 - IO delay control register 1 */
- __be32 iodelay2; /* 0x.0228 - IO delay control register 2 */
+ u32 iodelay1; /* 0x.0224 - IO delay control register 1 */
+ u32 iodelay2; /* 0x.0228 - IO delay control register 2 */
u8 res22c[0x604 - 0x22c];
- __be32 pamubypenr; /* 0x.604 - PAMU bypass enable register */
+ u32 pamubypenr; /* 0x.604 - PAMU bypass enable register */
u8 res608[0x800 - 0x608];
- __be32 clkdvdr; /* 0x.0800 - Clock Divide Register */
+ u32 clkdvdr; /* 0x.0800 - Clock Divide Register */
u8 res804[0x900 - 0x804];
- __be32 ircr; /* 0x.0900 - Infrared Control Register */
+ u32 ircr; /* 0x.0900 - Infrared Control Register */
u8 res904[0x908 - 0x904];
- __be32 dmacr; /* 0x.0908 - DMA Control Register */
+ u32 dmacr; /* 0x.0908 - DMA Control Register */
u8 res90c[0x914 - 0x90c];
- __be32 elbccr; /* 0x.0914 - eLBC Control Register */
+ u32 elbccr; /* 0x.0914 - eLBC Control Register */
u8 res918[0xb20 - 0x918];
- __be32 ddr1clkdr; /* 0x.0b20 - DDR1 Clock Disable Register */
- __be32 ddr2clkdr; /* 0x.0b24 - DDR2 Clock Disable Register */
- __be32 ddrclkdr; /* 0x.0b28 - DDR Clock Disable Register */
+ u32 ddr1clkdr; /* 0x.0b20 - DDR1 Clock Disable Register */
+ u32 ddr2clkdr; /* 0x.0b24 - DDR2 Clock Disable Register */
+ u32 ddrclkdr; /* 0x.0b28 - DDR Clock Disable Register */
u8 resb2c[0xe00 - 0xb2c];
- __be32 clkocr; /* 0x.0e00 - Clock Out Select Register */
+ u32 clkocr; /* 0x.0e00 - Clock Out Select Register */
u8 rese04[0xe10 - 0xe04];
- __be32 ddrdllcr; /* 0x.0e10 - DDR DLL Control Register */
+ u32 ddrdllcr; /* 0x.0e10 - DDR DLL Control Register */
u8 rese14[0xe20 - 0xe14];
- __be32 lbcdllcr; /* 0x.0e20 - LBC DLL Control Register */
- __be32 cpfor; /* 0x.0e24 - L2 charge pump fuse override register */
+ u32 lbcdllcr; /* 0x.0e20 - LBC DLL Control Register */
+ u32 cpfor; /* 0x.0e24 - L2 charge pump fuse override
+ * register
+ */
u8 rese28[0xf04 - 0xe28];
- __be32 srds1cr0; /* 0x.0f04 - SerDes1 Control Register 0 */
- __be32 srds1cr1; /* 0x.0f08 - SerDes1 Control Register 0 */
+ u32 srds1cr0; /* 0x.0f04 - SerDes1 Control Register 0 */
+ u32 srds1cr1; /* 0x.0f08 - SerDes1 Control Register 0 */
u8 resf0c[0xf2c - 0xf0c];
- __be32 itcr; /* 0x.0f2c - Internal transaction control register */
+ u32 itcr; /* 0x.0f2c - Internal transaction control
+ * register
+ */
u8 resf30[0xf40 - 0xf30];
- __be32 srds2cr0; /* 0x.0f40 - SerDes2 Control Register 0 */
- __be32 srds2cr1; /* 0x.0f44 - SerDes2 Control Register 0 */
+ u32 srds2cr0; /* 0x.0f40 - SerDes2 Control Register 0 */
+ u32 srds2cr1; /* 0x.0f44 - SerDes2 Control Register 0 */
} __attribute__ ((packed));
+u32 fsl_guts_get_svr(void);
+int fsl_guts_init(void);
/* Alternate function signal multiplex control */
#define MPC85xx_PMUXCR_QE(x) (0x8000 >> (x))
--
2.1.0.27.g96db324
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 4/7] dt: move guts devicetree doc out of powerpc directory
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-mmc, linuxppc-dev, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-i2c, iommu, netdev
Cc: ulf.hansson, Scott Wood, Mark Rutland, Rob Herring, Russell King,
Jochen Friedrich, Joerg Roedel, Claudiu Manoil, Bhupesh Sharma,
Qiang Zhao, Kumar Gala, Santosh Shilimkar, leoyang.li,
xiaobo.xie, Yangbo Lu
Move guts devicetree doc to Documentation/devicetree/bindings/soc/fsl/
since it's used by not only PowerPC but also ARM. And add a specification
for 'little-endian' property.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Scott Wood <oss@buserror.net>
Acked-by: Rob Herring <robh@kernel.org>
---
Changes for v4:
- Added this patch
Changes for v5:
- Modified the description for little-endian property
Changes for v6:
- None
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
- Added 'Acked-by: Rob Herring'
Changes for v9:
- None
Changes for v10:
- None
---
Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt | 3 +++
1 file changed, 3 insertions(+)
rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt b/Documentation/devicetree/bindings/soc/fsl/guts.txt
similarity index 91%
rename from Documentation/devicetree/bindings/powerpc/fsl/guts.txt
rename to Documentation/devicetree/bindings/soc/fsl/guts.txt
index b71b203..07adca9 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/guts.txt
@@ -25,6 +25,9 @@ Recommended properties:
- fsl,liodn-bits : Indicates the number of defined bits in the LIODN
registers, for those SOCs that have a PAMU device.
+ - little-endian : Indicates that the global utilities block is little
+ endian. The default is big endian.
+
Examples:
global-utilities@e0000 { /* global utilities block */
compatible = "fsl,mpc8548-guts";
--
2.1.0.27.g96db324
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 4/7] dt: move guts devicetree doc out of powerpc directory
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Mark Rutland, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Russell King,
Yangbo Lu, Bhupesh Sharma, Santosh Shilimkar, Jochen Friedrich,
leoyang.li-3arQi8VN3Tc, Scott Wood, Rob Herring, Claudiu Manoil,
Kumar Gala, xiaobo.xie-3arQi8VN3Tc, Qiang Zhao
Move guts devicetree doc to Documentation/devicetree/bindings/soc/fsl/
since it's used by not only PowerPC but also ARM. And add a specification
for 'little-endian' property.
Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
Acked-by: Scott Wood <oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Changes for v4:
- Added this patch
Changes for v5:
- Modified the description for little-endian property
Changes for v6:
- None
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
- Added 'Acked-by: Rob Herring'
Changes for v9:
- None
Changes for v10:
- None
---
Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt | 3 +++
1 file changed, 3 insertions(+)
rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt b/Documentation/devicetree/bindings/soc/fsl/guts.txt
similarity index 91%
rename from Documentation/devicetree/bindings/powerpc/fsl/guts.txt
rename to Documentation/devicetree/bindings/soc/fsl/guts.txt
index b71b203..07adca9 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/guts.txt
@@ -25,6 +25,9 @@ Recommended properties:
- fsl,liodn-bits : Indicates the number of defined bits in the LIODN
registers, for those SOCs that have a PAMU device.
+ - little-endian : Indicates that the global utilities block is little
+ endian. The default is big endian.
+
Examples:
global-utilities@e0000 { /* global utilities block */
compatible = "fsl,mpc8548-guts";
--
2.1.0.27.g96db324
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 4/7] dt: move guts devicetree doc out of powerpc directory
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Mark Rutland, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Russell King,
Yangbo Lu, Bhupesh Sharma, Santosh Shilimkar, Jochen Friedrich,
leoyang.li-3arQi8VN3Tc, Scott Wood, Rob Herring, Claudiu Manoil,
Kumar Gala, xiaobo.xie-3arQi8VN3Tc, Qiang Zhao
Move guts devicetree doc to Documentation/devicetree/bindings/soc/fsl/
since it's used by not only PowerPC but also ARM. And add a specification
for 'little-endian' property.
Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
Acked-by: Scott Wood <oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Changes for v4:
- Added this patch
Changes for v5:
- Modified the description for little-endian property
Changes for v6:
- None
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
- Added 'Acked-by: Rob Herring'
Changes for v9:
- None
Changes for v10:
- None
---
Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt | 3 +++
1 file changed, 3 insertions(+)
rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt b/Documentation/devicetree/bindings/soc/fsl/guts.txt
similarity index 91%
rename from Documentation/devicetree/bindings/powerpc/fsl/guts.txt
rename to Documentation/devicetree/bindings/soc/fsl/guts.txt
index b71b203..07adca9 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/guts.txt
@@ -25,6 +25,9 @@ Recommended properties:
- fsl,liodn-bits : Indicates the number of defined bits in the LIODN
registers, for those SOCs that have a PAMU device.
+ - little-endian : Indicates that the global utilities block is little
+ endian. The default is big endian.
+
Examples:
global-utilities@e0000 { /* global utilities block */
compatible = "fsl,mpc8548-guts";
--
2.1.0.27.g96db324
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 4/7] dt: move guts devicetree doc out of powerpc directory
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-mmc, linuxppc-dev, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-i2c, iommu, netdev
Cc: Mark Rutland, ulf.hansson, Russell King, Yangbo Lu,
Bhupesh Sharma, Joerg Roedel, Santosh Shilimkar,
Jochen Friedrich, leoyang.li, Scott Wood, Rob Herring,
Claudiu Manoil, Kumar Gala, xiaobo.xie, Qiang Zhao
Move guts devicetree doc to Documentation/devicetree/bindings/soc/fsl/
since it's used by not only PowerPC but also ARM. And add a specification
for 'little-endian' property.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Scott Wood <oss@buserror.net>
Acked-by: Rob Herring <robh@kernel.org>
---
Changes for v4:
- Added this patch
Changes for v5:
- Modified the description for little-endian property
Changes for v6:
- None
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
- Added 'Acked-by: Rob Herring'
Changes for v9:
- None
Changes for v10:
- None
---
Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt | 3 +++
1 file changed, 3 insertions(+)
rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt b/Documentation/devicetree/bindings/soc/fsl/guts.txt
similarity index 91%
rename from Documentation/devicetree/bindings/powerpc/fsl/guts.txt
rename to Documentation/devicetree/bindings/soc/fsl/guts.txt
index b71b203..07adca9 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/guts.txt
@@ -25,6 +25,9 @@ Recommended properties:
- fsl,liodn-bits : Indicates the number of defined bits in the LIODN
registers, for those SOCs that have a PAMU device.
+ - little-endian : Indicates that the global utilities block is little
+ endian. The default is big endian.
+
Examples:
global-utilities@e0000 { /* global utilities block */
compatible = "fsl,mpc8548-guts";
--
2.1.0.27.g96db324
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 4/7] dt: move guts devicetree doc out of powerpc directory
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-arm-kernel
Move guts devicetree doc to Documentation/devicetree/bindings/soc/fsl/
since it's used by not only PowerPC but also ARM. And add a specification
for 'little-endian' property.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Scott Wood <oss@buserror.net>
Acked-by: Rob Herring <robh@kernel.org>
---
Changes for v4:
- Added this patch
Changes for v5:
- Modified the description for little-endian property
Changes for v6:
- None
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
- Added 'Acked-by: Rob Herring'
Changes for v9:
- None
Changes for v10:
- None
---
Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt | 3 +++
1 file changed, 3 insertions(+)
rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt b/Documentation/devicetree/bindings/soc/fsl/guts.txt
similarity index 91%
rename from Documentation/devicetree/bindings/powerpc/fsl/guts.txt
rename to Documentation/devicetree/bindings/soc/fsl/guts.txt
index b71b203..07adca9 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/guts.txt
@@ -25,6 +25,9 @@ Recommended properties:
- fsl,liodn-bits : Indicates the number of defined bits in the LIODN
registers, for those SOCs that have a PAMU device.
+ - little-endian : Indicates that the global utilities block is little
+ endian. The default is big endian.
+
Examples:
global-utilities at e0000 { /* global utilities block */
compatible = "fsl,mpc8548-guts";
--
2.1.0.27.g96db324
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 5/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-mmc, linuxppc-dev, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-i2c, iommu, netdev
Cc: ulf.hansson, Scott Wood, Mark Rutland, Rob Herring, Russell King,
Jochen Friedrich, Joerg Roedel, Claudiu Manoil, Bhupesh Sharma,
Qiang Zhao, Kumar Gala, Santosh Shilimkar, leoyang.li,
xiaobo.xie, Yangbo Lu
Move mpc85xx.h to include/linux/fsl and rename it to svr.h as
a common header file. It has been used for mpc85xx and it will
be used for ARM-based SoC as well.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Scott Wood <oss@buserror.net>
Acked-by: Joerg Roedel <jroedel@suse.de>
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- Changed to Move mpc85xx.h to include/linux/fsl/
- Adjusted '#include <linux/fsl/svr.h>' position in file
Changes for v6:
- None
Changes for v7:
- Added 'Acked-by: Wolfram Sang' for I2C part
- Also applied to arch/powerpc/kernel/cpu_setup_fsl_booke.S
Changes for v8:
- Added 'Acked-by: Stephen Boyd' for clk part
- Added 'Acked-by: Scott Wood'
- Added 'Acked-by: Joerg Roedel' for iommu part
Changes for v9:
- None
Changes for v10:
- None
---
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
drivers/clk/clk-qoriq.c | 3 +--
drivers/i2c/busses/i2c-mpc.c | 2 +-
drivers/iommu/fsl_pamu.c | 3 +--
drivers/net/ethernet/freescale/gianfar.c | 2 +-
arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h | 4 ++--
6 files changed, 7 insertions(+), 9 deletions(-)
rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)
diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index 462aed9..2b0284e 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -13,13 +13,13 @@
*
*/
+#include <linux/fsl/svr.h>
#include <asm/page.h>
#include <asm/processor.h>
#include <asm/cputable.h>
#include <asm/ppc_asm.h>
#include <asm/mmu-book3e.h>
#include <asm/asm-offsets.h>
-#include <asm/mpc85xx.h>
_GLOBAL(__e500_icache_setup)
mfspr r0, SPRN_L1CSR1
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
index 7bc1c45..fc7f722 100644
--- a/drivers/clk/clk-qoriq.c
+++ b/drivers/clk/clk-qoriq.c
@@ -13,6 +13,7 @@
#include <linux/clk.h>
#include <linux/clk-provider.h>
#include <linux/fsl/guts.h>
+#include <linux/fsl/svr.h>
#include <linux/io.h>
#include <linux/kernel.h>
#include <linux/module.h>
@@ -1148,8 +1149,6 @@ bad_args:
}
#ifdef CONFIG_PPC
-#include <asm/mpc85xx.h>
-
static const u32 a4510_svrs[] __initconst = {
(SVR_P2040 << 8) | 0x10, /* P2040 1.0 */
(SVR_P2040 << 8) | 0x11, /* P2040 1.1 */
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 48ecffe..600704c 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -27,9 +27,9 @@
#include <linux/i2c.h>
#include <linux/interrupt.h>
#include <linux/delay.h>
+#include <linux/fsl/svr.h>
#include <asm/mpc52xx.h>
-#include <asm/mpc85xx.h>
#include <sysdev/fsl_soc.h>
#define DRV_NAME "mpc-i2c"
diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index a34355f..af8fb27 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -21,11 +21,10 @@
#include "fsl_pamu.h"
#include <linux/fsl/guts.h>
+#include <linux/fsl/svr.h>
#include <linux/interrupt.h>
#include <linux/genalloc.h>
-#include <asm/mpc85xx.h>
-
/* define indexes for each operation mapping scenario */
#define OMI_QMAN 0x00
#define OMI_FMAN 0x01
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index d2f917a..2224b10 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -86,11 +86,11 @@
#include <linux/udp.h>
#include <linux/in.h>
#include <linux/net_tstamp.h>
+#include <linux/fsl/svr.h>
#include <asm/io.h>
#ifdef CONFIG_PPC
#include <asm/reg.h>
-#include <asm/mpc85xx.h>
#endif
#include <asm/irq.h>
#include <asm/uaccess.h>
diff --git a/arch/powerpc/include/asm/mpc85xx.h b/include/linux/fsl/svr.h
similarity index 97%
rename from arch/powerpc/include/asm/mpc85xx.h
rename to include/linux/fsl/svr.h
index 213f3a8..8d13836 100644
--- a/arch/powerpc/include/asm/mpc85xx.h
+++ b/include/linux/fsl/svr.h
@@ -9,8 +9,8 @@
* (at your option) any later version.
*/
-#ifndef __ASM_PPC_MPC85XX_H
-#define __ASM_PPC_MPC85XX_H
+#ifndef FSL_SVR_H
+#define FSL_SVR_H
#define SVR_REV(svr) ((svr) & 0xFF) /* SOC design resision */
#define SVR_MAJ(svr) (((svr) >> 4) & 0xF) /* Major revision field*/
--
2.1.0.27.g96db324
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 5/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Mark Rutland, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Russell King,
Yangbo Lu, Bhupesh Sharma, Santosh Shilimkar, Jochen Friedrich,
leoyang.li-3arQi8VN3Tc, Scott Wood, Rob Herring, Claudiu Manoil,
Kumar Gala, xiaobo.xie-3arQi8VN3Tc, Qiang Zhao
Move mpc85xx.h to include/linux/fsl and rename it to svr.h as
a common header file. It has been used for mpc85xx and it will
be used for ARM-based SoC as well.
Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
Acked-by: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
Acked-by: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Acked-by: Scott Wood <oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org>
Acked-by: Joerg Roedel <jroedel-l3A5Bk7waGM@public.gmane.org>
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- Changed to Move mpc85xx.h to include/linux/fsl/
- Adjusted '#include <linux/fsl/svr.h>' position in file
Changes for v6:
- None
Changes for v7:
- Added 'Acked-by: Wolfram Sang' for I2C part
- Also applied to arch/powerpc/kernel/cpu_setup_fsl_booke.S
Changes for v8:
- Added 'Acked-by: Stephen Boyd' for clk part
- Added 'Acked-by: Scott Wood'
- Added 'Acked-by: Joerg Roedel' for iommu part
Changes for v9:
- None
Changes for v10:
- None
---
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
drivers/clk/clk-qoriq.c | 3 +--
drivers/i2c/busses/i2c-mpc.c | 2 +-
drivers/iommu/fsl_pamu.c | 3 +--
drivers/net/ethernet/freescale/gianfar.c | 2 +-
arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h | 4 ++--
6 files changed, 7 insertions(+), 9 deletions(-)
rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)
diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index 462aed9..2b0284e 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -13,13 +13,13 @@
*
*/
+#include <linux/fsl/svr.h>
#include <asm/page.h>
#include <asm/processor.h>
#include <asm/cputable.h>
#include <asm/ppc_asm.h>
#include <asm/mmu-book3e.h>
#include <asm/asm-offsets.h>
-#include <asm/mpc85xx.h>
_GLOBAL(__e500_icache_setup)
mfspr r0, SPRN_L1CSR1
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
index 7bc1c45..fc7f722 100644
--- a/drivers/clk/clk-qoriq.c
+++ b/drivers/clk/clk-qoriq.c
@@ -13,6 +13,7 @@
#include <linux/clk.h>
#include <linux/clk-provider.h>
#include <linux/fsl/guts.h>
+#include <linux/fsl/svr.h>
#include <linux/io.h>
#include <linux/kernel.h>
#include <linux/module.h>
@@ -1148,8 +1149,6 @@ bad_args:
}
#ifdef CONFIG_PPC
-#include <asm/mpc85xx.h>
-
static const u32 a4510_svrs[] __initconst = {
(SVR_P2040 << 8) | 0x10, /* P2040 1.0 */
(SVR_P2040 << 8) | 0x11, /* P2040 1.1 */
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 48ecffe..600704c 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -27,9 +27,9 @@
#include <linux/i2c.h>
#include <linux/interrupt.h>
#include <linux/delay.h>
+#include <linux/fsl/svr.h>
#include <asm/mpc52xx.h>
-#include <asm/mpc85xx.h>
#include <sysdev/fsl_soc.h>
#define DRV_NAME "mpc-i2c"
diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index a34355f..af8fb27 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -21,11 +21,10 @@
#include "fsl_pamu.h"
#include <linux/fsl/guts.h>
+#include <linux/fsl/svr.h>
#include <linux/interrupt.h>
#include <linux/genalloc.h>
-#include <asm/mpc85xx.h>
-
/* define indexes for each operation mapping scenario */
#define OMI_QMAN 0x00
#define OMI_FMAN 0x01
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index d2f917a..2224b10 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -86,11 +86,11 @@
#include <linux/udp.h>
#include <linux/in.h>
#include <linux/net_tstamp.h>
+#include <linux/fsl/svr.h>
#include <asm/io.h>
#ifdef CONFIG_PPC
#include <asm/reg.h>
-#include <asm/mpc85xx.h>
#endif
#include <asm/irq.h>
#include <asm/uaccess.h>
diff --git a/arch/powerpc/include/asm/mpc85xx.h b/include/linux/fsl/svr.h
similarity index 97%
rename from arch/powerpc/include/asm/mpc85xx.h
rename to include/linux/fsl/svr.h
index 213f3a8..8d13836 100644
--- a/arch/powerpc/include/asm/mpc85xx.h
+++ b/include/linux/fsl/svr.h
@@ -9,8 +9,8 @@
* (at your option) any later version.
*/
-#ifndef __ASM_PPC_MPC85XX_H
-#define __ASM_PPC_MPC85XX_H
+#ifndef FSL_SVR_H
+#define FSL_SVR_H
#define SVR_REV(svr) ((svr) & 0xFF) /* SOC design resision */
#define SVR_MAJ(svr) (((svr) >> 4) & 0xF) /* Major revision field*/
--
2.1.0.27.g96db324
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 5/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Mark Rutland, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Russell King,
Yangbo Lu, Bhupesh Sharma, Santosh Shilimkar, Jochen Friedrich,
leoyang.li-3arQi8VN3Tc, Scott Wood, Rob Herring, Claudiu Manoil,
Kumar Gala, xiaobo.xie-3arQi8VN3Tc, Qiang Zhao
Move mpc85xx.h to include/linux/fsl and rename it to svr.h as
a common header file. It has been used for mpc85xx and it will
be used for ARM-based SoC as well.
Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
Acked-by: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
Acked-by: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Acked-by: Scott Wood <oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org>
Acked-by: Joerg Roedel <jroedel-l3A5Bk7waGM@public.gmane.org>
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- Changed to Move mpc85xx.h to include/linux/fsl/
- Adjusted '#include <linux/fsl/svr.h>' position in file
Changes for v6:
- None
Changes for v7:
- Added 'Acked-by: Wolfram Sang' for I2C part
- Also applied to arch/powerpc/kernel/cpu_setup_fsl_booke.S
Changes for v8:
- Added 'Acked-by: Stephen Boyd' for clk part
- Added 'Acked-by: Scott Wood'
- Added 'Acked-by: Joerg Roedel' for iommu part
Changes for v9:
- None
Changes for v10:
- None
---
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
drivers/clk/clk-qoriq.c | 3 +--
drivers/i2c/busses/i2c-mpc.c | 2 +-
drivers/iommu/fsl_pamu.c | 3 +--
drivers/net/ethernet/freescale/gianfar.c | 2 +-
arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h | 4 ++--
6 files changed, 7 insertions(+), 9 deletions(-)
rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)
diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index 462aed9..2b0284e 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -13,13 +13,13 @@
*
*/
+#include <linux/fsl/svr.h>
#include <asm/page.h>
#include <asm/processor.h>
#include <asm/cputable.h>
#include <asm/ppc_asm.h>
#include <asm/mmu-book3e.h>
#include <asm/asm-offsets.h>
-#include <asm/mpc85xx.h>
_GLOBAL(__e500_icache_setup)
mfspr r0, SPRN_L1CSR1
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
index 7bc1c45..fc7f722 100644
--- a/drivers/clk/clk-qoriq.c
+++ b/drivers/clk/clk-qoriq.c
@@ -13,6 +13,7 @@
#include <linux/clk.h>
#include <linux/clk-provider.h>
#include <linux/fsl/guts.h>
+#include <linux/fsl/svr.h>
#include <linux/io.h>
#include <linux/kernel.h>
#include <linux/module.h>
@@ -1148,8 +1149,6 @@ bad_args:
}
#ifdef CONFIG_PPC
-#include <asm/mpc85xx.h>
-
static const u32 a4510_svrs[] __initconst = {
(SVR_P2040 << 8) | 0x10, /* P2040 1.0 */
(SVR_P2040 << 8) | 0x11, /* P2040 1.1 */
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 48ecffe..600704c 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -27,9 +27,9 @@
#include <linux/i2c.h>
#include <linux/interrupt.h>
#include <linux/delay.h>
+#include <linux/fsl/svr.h>
#include <asm/mpc52xx.h>
-#include <asm/mpc85xx.h>
#include <sysdev/fsl_soc.h>
#define DRV_NAME "mpc-i2c"
diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index a34355f..af8fb27 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -21,11 +21,10 @@
#include "fsl_pamu.h"
#include <linux/fsl/guts.h>
+#include <linux/fsl/svr.h>
#include <linux/interrupt.h>
#include <linux/genalloc.h>
-#include <asm/mpc85xx.h>
-
/* define indexes for each operation mapping scenario */
#define OMI_QMAN 0x00
#define OMI_FMAN 0x01
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index d2f917a..2224b10 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -86,11 +86,11 @@
#include <linux/udp.h>
#include <linux/in.h>
#include <linux/net_tstamp.h>
+#include <linux/fsl/svr.h>
#include <asm/io.h>
#ifdef CONFIG_PPC
#include <asm/reg.h>
-#include <asm/mpc85xx.h>
#endif
#include <asm/irq.h>
#include <asm/uaccess.h>
diff --git a/arch/powerpc/include/asm/mpc85xx.h b/include/linux/fsl/svr.h
similarity index 97%
rename from arch/powerpc/include/asm/mpc85xx.h
rename to include/linux/fsl/svr.h
index 213f3a8..8d13836 100644
--- a/arch/powerpc/include/asm/mpc85xx.h
+++ b/include/linux/fsl/svr.h
@@ -9,8 +9,8 @@
* (at your option) any later version.
*/
-#ifndef __ASM_PPC_MPC85XX_H
-#define __ASM_PPC_MPC85XX_H
+#ifndef FSL_SVR_H
+#define FSL_SVR_H
#define SVR_REV(svr) ((svr) & 0xFF) /* SOC design resision */
#define SVR_MAJ(svr) (((svr) >> 4) & 0xF) /* Major revision field*/
--
2.1.0.27.g96db324
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 5/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-mmc, linuxppc-dev, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-i2c, iommu, netdev
Cc: Mark Rutland, ulf.hansson, Russell King, Yangbo Lu,
Bhupesh Sharma, Joerg Roedel, Santosh Shilimkar,
Jochen Friedrich, leoyang.li, Scott Wood, Rob Herring,
Claudiu Manoil, Kumar Gala, xiaobo.xie, Qiang Zhao
Move mpc85xx.h to include/linux/fsl and rename it to svr.h as
a common header file. It has been used for mpc85xx and it will
be used for ARM-based SoC as well.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Scott Wood <oss@buserror.net>
Acked-by: Joerg Roedel <jroedel@suse.de>
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- Changed to Move mpc85xx.h to include/linux/fsl/
- Adjusted '#include <linux/fsl/svr.h>' position in file
Changes for v6:
- None
Changes for v7:
- Added 'Acked-by: Wolfram Sang' for I2C part
- Also applied to arch/powerpc/kernel/cpu_setup_fsl_booke.S
Changes for v8:
- Added 'Acked-by: Stephen Boyd' for clk part
- Added 'Acked-by: Scott Wood'
- Added 'Acked-by: Joerg Roedel' for iommu part
Changes for v9:
- None
Changes for v10:
- None
---
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
drivers/clk/clk-qoriq.c | 3 +--
drivers/i2c/busses/i2c-mpc.c | 2 +-
drivers/iommu/fsl_pamu.c | 3 +--
drivers/net/ethernet/freescale/gianfar.c | 2 +-
arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h | 4 ++--
6 files changed, 7 insertions(+), 9 deletions(-)
rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)
diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index 462aed9..2b0284e 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -13,13 +13,13 @@
*
*/
+#include <linux/fsl/svr.h>
#include <asm/page.h>
#include <asm/processor.h>
#include <asm/cputable.h>
#include <asm/ppc_asm.h>
#include <asm/mmu-book3e.h>
#include <asm/asm-offsets.h>
-#include <asm/mpc85xx.h>
_GLOBAL(__e500_icache_setup)
mfspr r0, SPRN_L1CSR1
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
index 7bc1c45..fc7f722 100644
--- a/drivers/clk/clk-qoriq.c
+++ b/drivers/clk/clk-qoriq.c
@@ -13,6 +13,7 @@
#include <linux/clk.h>
#include <linux/clk-provider.h>
#include <linux/fsl/guts.h>
+#include <linux/fsl/svr.h>
#include <linux/io.h>
#include <linux/kernel.h>
#include <linux/module.h>
@@ -1148,8 +1149,6 @@ bad_args:
}
#ifdef CONFIG_PPC
-#include <asm/mpc85xx.h>
-
static const u32 a4510_svrs[] __initconst = {
(SVR_P2040 << 8) | 0x10, /* P2040 1.0 */
(SVR_P2040 << 8) | 0x11, /* P2040 1.1 */
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 48ecffe..600704c 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -27,9 +27,9 @@
#include <linux/i2c.h>
#include <linux/interrupt.h>
#include <linux/delay.h>
+#include <linux/fsl/svr.h>
#include <asm/mpc52xx.h>
-#include <asm/mpc85xx.h>
#include <sysdev/fsl_soc.h>
#define DRV_NAME "mpc-i2c"
diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index a34355f..af8fb27 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -21,11 +21,10 @@
#include "fsl_pamu.h"
#include <linux/fsl/guts.h>
+#include <linux/fsl/svr.h>
#include <linux/interrupt.h>
#include <linux/genalloc.h>
-#include <asm/mpc85xx.h>
-
/* define indexes for each operation mapping scenario */
#define OMI_QMAN 0x00
#define OMI_FMAN 0x01
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index d2f917a..2224b10 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -86,11 +86,11 @@
#include <linux/udp.h>
#include <linux/in.h>
#include <linux/net_tstamp.h>
+#include <linux/fsl/svr.h>
#include <asm/io.h>
#ifdef CONFIG_PPC
#include <asm/reg.h>
-#include <asm/mpc85xx.h>
#endif
#include <asm/irq.h>
#include <asm/uaccess.h>
diff --git a/arch/powerpc/include/asm/mpc85xx.h b/include/linux/fsl/svr.h
similarity index 97%
rename from arch/powerpc/include/asm/mpc85xx.h
rename to include/linux/fsl/svr.h
index 213f3a8..8d13836 100644
--- a/arch/powerpc/include/asm/mpc85xx.h
+++ b/include/linux/fsl/svr.h
@@ -9,8 +9,8 @@
* (at your option) any later version.
*/
-#ifndef __ASM_PPC_MPC85XX_H
-#define __ASM_PPC_MPC85XX_H
+#ifndef FSL_SVR_H
+#define FSL_SVR_H
#define SVR_REV(svr) ((svr) & 0xFF) /* SOC design resision */
#define SVR_MAJ(svr) (((svr) >> 4) & 0xF) /* Major revision field*/
--
2.1.0.27.g96db324
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 5/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-arm-kernel
Move mpc85xx.h to include/linux/fsl and rename it to svr.h as
a common header file. It has been used for mpc85xx and it will
be used for ARM-based SoC as well.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Scott Wood <oss@buserror.net>
Acked-by: Joerg Roedel <jroedel@suse.de>
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- Changed to Move mpc85xx.h to include/linux/fsl/
- Adjusted '#include <linux/fsl/svr.h>' position in file
Changes for v6:
- None
Changes for v7:
- Added 'Acked-by: Wolfram Sang' for I2C part
- Also applied to arch/powerpc/kernel/cpu_setup_fsl_booke.S
Changes for v8:
- Added 'Acked-by: Stephen Boyd' for clk part
- Added 'Acked-by: Scott Wood'
- Added 'Acked-by: Joerg Roedel' for iommu part
Changes for v9:
- None
Changes for v10:
- None
---
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
drivers/clk/clk-qoriq.c | 3 +--
drivers/i2c/busses/i2c-mpc.c | 2 +-
drivers/iommu/fsl_pamu.c | 3 +--
drivers/net/ethernet/freescale/gianfar.c | 2 +-
arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h | 4 ++--
6 files changed, 7 insertions(+), 9 deletions(-)
rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)
diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index 462aed9..2b0284e 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -13,13 +13,13 @@
*
*/
+#include <linux/fsl/svr.h>
#include <asm/page.h>
#include <asm/processor.h>
#include <asm/cputable.h>
#include <asm/ppc_asm.h>
#include <asm/mmu-book3e.h>
#include <asm/asm-offsets.h>
-#include <asm/mpc85xx.h>
_GLOBAL(__e500_icache_setup)
mfspr r0, SPRN_L1CSR1
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
index 7bc1c45..fc7f722 100644
--- a/drivers/clk/clk-qoriq.c
+++ b/drivers/clk/clk-qoriq.c
@@ -13,6 +13,7 @@
#include <linux/clk.h>
#include <linux/clk-provider.h>
#include <linux/fsl/guts.h>
+#include <linux/fsl/svr.h>
#include <linux/io.h>
#include <linux/kernel.h>
#include <linux/module.h>
@@ -1148,8 +1149,6 @@ bad_args:
}
#ifdef CONFIG_PPC
-#include <asm/mpc85xx.h>
-
static const u32 a4510_svrs[] __initconst = {
(SVR_P2040 << 8) | 0x10, /* P2040 1.0 */
(SVR_P2040 << 8) | 0x11, /* P2040 1.1 */
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 48ecffe..600704c 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -27,9 +27,9 @@
#include <linux/i2c.h>
#include <linux/interrupt.h>
#include <linux/delay.h>
+#include <linux/fsl/svr.h>
#include <asm/mpc52xx.h>
-#include <asm/mpc85xx.h>
#include <sysdev/fsl_soc.h>
#define DRV_NAME "mpc-i2c"
diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index a34355f..af8fb27 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -21,11 +21,10 @@
#include "fsl_pamu.h"
#include <linux/fsl/guts.h>
+#include <linux/fsl/svr.h>
#include <linux/interrupt.h>
#include <linux/genalloc.h>
-#include <asm/mpc85xx.h>
-
/* define indexes for each operation mapping scenario */
#define OMI_QMAN 0x00
#define OMI_FMAN 0x01
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index d2f917a..2224b10 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -86,11 +86,11 @@
#include <linux/udp.h>
#include <linux/in.h>
#include <linux/net_tstamp.h>
+#include <linux/fsl/svr.h>
#include <asm/io.h>
#ifdef CONFIG_PPC
#include <asm/reg.h>
-#include <asm/mpc85xx.h>
#endif
#include <asm/irq.h>
#include <asm/uaccess.h>
diff --git a/arch/powerpc/include/asm/mpc85xx.h b/include/linux/fsl/svr.h
similarity index 97%
rename from arch/powerpc/include/asm/mpc85xx.h
rename to include/linux/fsl/svr.h
index 213f3a8..8d13836 100644
--- a/arch/powerpc/include/asm/mpc85xx.h
+++ b/include/linux/fsl/svr.h
@@ -9,8 +9,8 @@
* (at your option) any later version.
*/
-#ifndef __ASM_PPC_MPC85XX_H
-#define __ASM_PPC_MPC85XX_H
+#ifndef FSL_SVR_H
+#define FSL_SVR_H
#define SVR_REV(svr) ((svr) & 0xFF) /* SOC design resision */
#define SVR_MAJ(svr) (((svr) >> 4) & 0xF) /* Major revision field*/
--
2.1.0.27.g96db324
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 6/7] MAINTAINERS: add entry for Freescale SoC drivers
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-mmc, linuxppc-dev, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-i2c, iommu, netdev
Cc: ulf.hansson, Scott Wood, Mark Rutland, Rob Herring, Russell King,
Jochen Friedrich, Joerg Roedel, Claudiu Manoil, Bhupesh Sharma,
Qiang Zhao, Kumar Gala, Santosh Shilimkar, leoyang.li,
xiaobo.xie, Yangbo Lu
Add maintainer entry for Freescale SoC drivers including
the QE library and the GUTS driver now. Also add maintainer
for QE library.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Scott Wood <oss@buserror.net>
Acked-by: Qiang Zhao <qiang.zhao@nxp.com>
---
Changes for v8:
- Added this patch
Changes for v9:
- Added linux-arm mail list
- Removed GUTS driver entry
Changes for v10:
- Changed 'DRIVER' to 'DRIVERS'
- Added 'Acked-by' of Scott and Qiang
---
MAINTAINERS | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 42e65d1..85c4b8b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4622,9 +4622,18 @@ F: drivers/net/ethernet/freescale/fec_ptp.c
F: drivers/net/ethernet/freescale/fec.h
F: Documentation/devicetree/bindings/net/fsl-fec.txt
+FREESCALE SOC DRIVERS
+M: Scott Wood <oss@buserror.net>
+L: linuxppc-dev@lists.ozlabs.org
+L: linux-arm-kernel@lists.infradead.org
+S: Maintained
+F: drivers/soc/fsl/
+F: include/linux/fsl/
+
FREESCALE QUICC ENGINE LIBRARY
+M: Qiang Zhao <qiang.zhao@nxp.com>
L: linuxppc-dev@lists.ozlabs.org
-S: Orphan
+S: Maintained
F: drivers/soc/fsl/qe/
F: include/soc/fsl/*qe*.h
F: include/soc/fsl/*ucc*.h
--
2.1.0.27.g96db324
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 6/7] MAINTAINERS: add entry for Freescale SoC drivers
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Mark Rutland, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Russell King,
Yangbo Lu, Bhupesh Sharma, Santosh Shilimkar, Jochen Friedrich,
leoyang.li-3arQi8VN3Tc, Scott Wood, Rob Herring, Claudiu Manoil,
Kumar Gala, xiaobo.xie-3arQi8VN3Tc, Qiang Zhao
Add maintainer entry for Freescale SoC drivers including
the QE library and the GUTS driver now. Also add maintainer
for QE library.
Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
Acked-by: Scott Wood <oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org>
Acked-by: Qiang Zhao <qiang.zhao-3arQi8VN3Tc@public.gmane.org>
---
Changes for v8:
- Added this patch
Changes for v9:
- Added linux-arm mail list
- Removed GUTS driver entry
Changes for v10:
- Changed 'DRIVER' to 'DRIVERS'
- Added 'Acked-by' of Scott and Qiang
---
MAINTAINERS | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 42e65d1..85c4b8b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4622,9 +4622,18 @@ F: drivers/net/ethernet/freescale/fec_ptp.c
F: drivers/net/ethernet/freescale/fec.h
F: Documentation/devicetree/bindings/net/fsl-fec.txt
+FREESCALE SOC DRIVERS
+M: Scott Wood <oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org>
+L: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
+L: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
+S: Maintained
+F: drivers/soc/fsl/
+F: include/linux/fsl/
+
FREESCALE QUICC ENGINE LIBRARY
+M: Qiang Zhao <qiang.zhao-3arQi8VN3Tc@public.gmane.org>
L: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
-S: Orphan
+S: Maintained
F: drivers/soc/fsl/qe/
F: include/soc/fsl/*qe*.h
F: include/soc/fsl/*ucc*.h
--
2.1.0.27.g96db324
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 6/7] MAINTAINERS: add entry for Freescale SoC drivers
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Mark Rutland, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Russell King,
Yangbo Lu, Bhupesh Sharma, Santosh Shilimkar, Jochen Friedrich,
leoyang.li-3arQi8VN3Tc, Scott Wood, Rob Herring, Claudiu Manoil,
Kumar Gala, xiaobo.xie-3arQi8VN3Tc, Qiang Zhao
Add maintainer entry for Freescale SoC drivers including
the QE library and the GUTS driver now. Also add maintainer
for QE library.
Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
Acked-by: Scott Wood <oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org>
Acked-by: Qiang Zhao <qiang.zhao-3arQi8VN3Tc@public.gmane.org>
---
Changes for v8:
- Added this patch
Changes for v9:
- Added linux-arm mail list
- Removed GUTS driver entry
Changes for v10:
- Changed 'DRIVER' to 'DRIVERS'
- Added 'Acked-by' of Scott and Qiang
---
MAINTAINERS | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 42e65d1..85c4b8b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4622,9 +4622,18 @@ F: drivers/net/ethernet/freescale/fec_ptp.c
F: drivers/net/ethernet/freescale/fec.h
F: Documentation/devicetree/bindings/net/fsl-fec.txt
+FREESCALE SOC DRIVERS
+M: Scott Wood <oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org>
+L: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
+L: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
+S: Maintained
+F: drivers/soc/fsl/
+F: include/linux/fsl/
+
FREESCALE QUICC ENGINE LIBRARY
+M: Qiang Zhao <qiang.zhao-3arQi8VN3Tc@public.gmane.org>
L: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
-S: Orphan
+S: Maintained
F: drivers/soc/fsl/qe/
F: include/soc/fsl/*qe*.h
F: include/soc/fsl/*ucc*.h
--
2.1.0.27.g96db324
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 6/7] MAINTAINERS: add entry for Freescale SoC drivers
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-arm-kernel
Add maintainer entry for Freescale SoC drivers including
the QE library and the GUTS driver now. Also add maintainer
for QE library.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Scott Wood <oss@buserror.net>
Acked-by: Qiang Zhao <qiang.zhao@nxp.com>
---
Changes for v8:
- Added this patch
Changes for v9:
- Added linux-arm mail list
- Removed GUTS driver entry
Changes for v10:
- Changed 'DRIVER' to 'DRIVERS'
- Added 'Acked-by' of Scott and Qiang
---
MAINTAINERS | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 42e65d1..85c4b8b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4622,9 +4622,18 @@ F: drivers/net/ethernet/freescale/fec_ptp.c
F: drivers/net/ethernet/freescale/fec.h
F: Documentation/devicetree/bindings/net/fsl-fec.txt
+FREESCALE SOC DRIVERS
+M: Scott Wood <oss@buserror.net>
+L: linuxppc-dev at lists.ozlabs.org
+L: linux-arm-kernel at lists.infradead.org
+S: Maintained
+F: drivers/soc/fsl/
+F: include/linux/fsl/
+
FREESCALE QUICC ENGINE LIBRARY
+M: Qiang Zhao <qiang.zhao@nxp.com>
L: linuxppc-dev at lists.ozlabs.org
-S: Orphan
+S: Maintained
F: drivers/soc/fsl/qe/
F: include/soc/fsl/*qe*.h
F: include/soc/fsl/*ucc*.h
--
2.1.0.27.g96db324
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-mmc, linuxppc-dev, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-i2c, iommu, netdev
Cc: ulf.hansson, Scott Wood, Mark Rutland, Rob Herring, Russell King,
Jochen Friedrich, Joerg Roedel, Claudiu Manoil, Bhupesh Sharma,
Qiang Zhao, Kumar Gala, Santosh Shilimkar, leoyang.li,
xiaobo.xie, Yangbo Lu
The eSDHC of T4240-R1.0-R2.0 has incorrect vender version and spec version.
Acturally the right version numbers should be VVN=0x13 and SVN = 0x1.
This patch adds the GUTS driver support for eSDHC driver to get SVR(System
version register). And fix host version to avoid that incorrect version
numbers break down the ADMA data transfer.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Scott Wood <oss@buserror.net>
---
Changes for v2:
- Got SVR through iomap instead of dts
Changes for v3:
- Managed GUTS through syscon instead of iomap in eSDHC driver
Changes for v4:
- Got SVR by GUTS driver instead of SYSCON
Changes for v5:
- Changed to get SVR through API fsl_guts_get_svr()
- Combined patch 4, patch 5 and patch 6 into one
Changes for v6:
- Added 'Acked-by: Ulf Hansson'
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
Changes for v9:
- None
Changes for v10:
- None
---
drivers/mmc/host/Kconfig | 1 +
drivers/mmc/host/sdhci-of-esdhc.c | 23 +++++++++++++++++++++++
2 files changed, 24 insertions(+)
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 0aa484c..e15e836 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -143,6 +143,7 @@ config MMC_SDHCI_OF_ESDHC
depends on MMC_SDHCI_PLTFM
depends on PPC || ARCH_MXC || ARCH_LAYERSCAPE
select MMC_SDHCI_IO_ACCESSORS
+ select FSL_GUTS
help
This selects the Freescale eSDHC controller support.
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
index 3f34d35..68cc020 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -18,6 +18,8 @@
#include <linux/of.h>
#include <linux/delay.h>
#include <linux/module.h>
+#include <linux/fsl/svr.h>
+#include <linux/fsl/guts.h>
#include <linux/mmc/host.h>
#include "sdhci-pltfm.h"
#include "sdhci-esdhc.h"
@@ -28,6 +30,8 @@
struct sdhci_esdhc {
u8 vendor_ver;
u8 spec_ver;
+ u32 soc_ver;
+ u8 soc_rev;
};
/**
@@ -73,6 +77,8 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
static u16 esdhc_readw_fixup(struct sdhci_host *host,
int spec_reg, u32 value)
{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
u16 ret;
int shift = (spec_reg & 0x2) * 8;
@@ -80,6 +86,13 @@ static u16 esdhc_readw_fixup(struct sdhci_host *host,
ret = value & 0xffff;
else
ret = (value >> shift) & 0xffff;
+
+ /* Workaround for T4240-R1.0-R2.0 eSDHC which has incorrect
+ * vendor version and spec version information.
+ */
+ if ((spec_reg == SDHCI_HOST_VERSION) &&
+ (esdhc->soc_ver == SVR_T4240) && (esdhc->soc_rev <= 0x20))
+ ret = (VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) | SDHCI_SPEC_200;
return ret;
}
@@ -567,10 +580,20 @@ static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host)
struct sdhci_pltfm_host *pltfm_host;
struct sdhci_esdhc *esdhc;
u16 host_ver;
+ u32 svr;
pltfm_host = sdhci_priv(host);
esdhc = sdhci_pltfm_priv(pltfm_host);
+ fsl_guts_init();
+ svr = fsl_guts_get_svr();
+ if (svr) {
+ esdhc->soc_ver = SVR_SOC_VER(svr);
+ esdhc->soc_rev = SVR_REV(svr);
+ } else {
+ dev_err(&pdev->dev, "Failed to get SVR value!\n");
+ }
+
host_ver = sdhci_readw(host, SDHCI_HOST_VERSION);
esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >>
SDHCI_VENDOR_VER_SHIFT;
--
2.1.0.27.g96db324
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Mark Rutland, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Russell King,
Yangbo Lu, Bhupesh Sharma, Santosh Shilimkar, Jochen Friedrich,
leoyang.li-3arQi8VN3Tc, Scott Wood, Rob Herring, Claudiu Manoil,
Kumar Gala, xiaobo.xie-3arQi8VN3Tc, Qiang Zhao
The eSDHC of T4240-R1.0-R2.0 has incorrect vender version and spec version.
Acturally the right version numbers should be VVN=0x13 and SVN = 0x1.
This patch adds the GUTS driver support for eSDHC driver to get SVR(System
version register). And fix host version to avoid that incorrect version
numbers break down the ADMA data transfer.
Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
Acked-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Acked-by: Scott Wood <oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org>
---
Changes for v2:
- Got SVR through iomap instead of dts
Changes for v3:
- Managed GUTS through syscon instead of iomap in eSDHC driver
Changes for v4:
- Got SVR by GUTS driver instead of SYSCON
Changes for v5:
- Changed to get SVR through API fsl_guts_get_svr()
- Combined patch 4, patch 5 and patch 6 into one
Changes for v6:
- Added 'Acked-by: Ulf Hansson'
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
Changes for v9:
- None
Changes for v10:
- None
---
drivers/mmc/host/Kconfig | 1 +
drivers/mmc/host/sdhci-of-esdhc.c | 23 +++++++++++++++++++++++
2 files changed, 24 insertions(+)
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 0aa484c..e15e836 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -143,6 +143,7 @@ config MMC_SDHCI_OF_ESDHC
depends on MMC_SDHCI_PLTFM
depends on PPC || ARCH_MXC || ARCH_LAYERSCAPE
select MMC_SDHCI_IO_ACCESSORS
+ select FSL_GUTS
help
This selects the Freescale eSDHC controller support.
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
index 3f34d35..68cc020 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -18,6 +18,8 @@
#include <linux/of.h>
#include <linux/delay.h>
#include <linux/module.h>
+#include <linux/fsl/svr.h>
+#include <linux/fsl/guts.h>
#include <linux/mmc/host.h>
#include "sdhci-pltfm.h"
#include "sdhci-esdhc.h"
@@ -28,6 +30,8 @@
struct sdhci_esdhc {
u8 vendor_ver;
u8 spec_ver;
+ u32 soc_ver;
+ u8 soc_rev;
};
/**
@@ -73,6 +77,8 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
static u16 esdhc_readw_fixup(struct sdhci_host *host,
int spec_reg, u32 value)
{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
u16 ret;
int shift = (spec_reg & 0x2) * 8;
@@ -80,6 +86,13 @@ static u16 esdhc_readw_fixup(struct sdhci_host *host,
ret = value & 0xffff;
else
ret = (value >> shift) & 0xffff;
+
+ /* Workaround for T4240-R1.0-R2.0 eSDHC which has incorrect
+ * vendor version and spec version information.
+ */
+ if ((spec_reg == SDHCI_HOST_VERSION) &&
+ (esdhc->soc_ver == SVR_T4240) && (esdhc->soc_rev <= 0x20))
+ ret = (VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) | SDHCI_SPEC_200;
return ret;
}
@@ -567,10 +580,20 @@ static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host)
struct sdhci_pltfm_host *pltfm_host;
struct sdhci_esdhc *esdhc;
u16 host_ver;
+ u32 svr;
pltfm_host = sdhci_priv(host);
esdhc = sdhci_pltfm_priv(pltfm_host);
+ fsl_guts_init();
+ svr = fsl_guts_get_svr();
+ if (svr) {
+ esdhc->soc_ver = SVR_SOC_VER(svr);
+ esdhc->soc_rev = SVR_REV(svr);
+ } else {
+ dev_err(&pdev->dev, "Failed to get SVR value!\n");
+ }
+
host_ver = sdhci_readw(host, SDHCI_HOST_VERSION);
esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >>
SDHCI_VENDOR_VER_SHIFT;
--
2.1.0.27.g96db324
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Mark Rutland, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Russell King,
Yangbo Lu, Bhupesh Sharma, Santosh Shilimkar, Jochen Friedrich,
leoyang.li-3arQi8VN3Tc, Scott Wood, Rob Herring, Claudiu Manoil,
Kumar Gala, xiaobo.xie-3arQi8VN3Tc, Qiang Zhao
The eSDHC of T4240-R1.0-R2.0 has incorrect vender version and spec version.
Acturally the right version numbers should be VVN=0x13 and SVN = 0x1.
This patch adds the GUTS driver support for eSDHC driver to get SVR(System
version register). And fix host version to avoid that incorrect version
numbers break down the ADMA data transfer.
Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
Acked-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Acked-by: Scott Wood <oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org>
---
Changes for v2:
- Got SVR through iomap instead of dts
Changes for v3:
- Managed GUTS through syscon instead of iomap in eSDHC driver
Changes for v4:
- Got SVR by GUTS driver instead of SYSCON
Changes for v5:
- Changed to get SVR through API fsl_guts_get_svr()
- Combined patch 4, patch 5 and patch 6 into one
Changes for v6:
- Added 'Acked-by: Ulf Hansson'
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
Changes for v9:
- None
Changes for v10:
- None
---
drivers/mmc/host/Kconfig | 1 +
drivers/mmc/host/sdhci-of-esdhc.c | 23 +++++++++++++++++++++++
2 files changed, 24 insertions(+)
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 0aa484c..e15e836 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -143,6 +143,7 @@ config MMC_SDHCI_OF_ESDHC
depends on MMC_SDHCI_PLTFM
depends on PPC || ARCH_MXC || ARCH_LAYERSCAPE
select MMC_SDHCI_IO_ACCESSORS
+ select FSL_GUTS
help
This selects the Freescale eSDHC controller support.
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
index 3f34d35..68cc020 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -18,6 +18,8 @@
#include <linux/of.h>
#include <linux/delay.h>
#include <linux/module.h>
+#include <linux/fsl/svr.h>
+#include <linux/fsl/guts.h>
#include <linux/mmc/host.h>
#include "sdhci-pltfm.h"
#include "sdhci-esdhc.h"
@@ -28,6 +30,8 @@
struct sdhci_esdhc {
u8 vendor_ver;
u8 spec_ver;
+ u32 soc_ver;
+ u8 soc_rev;
};
/**
@@ -73,6 +77,8 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
static u16 esdhc_readw_fixup(struct sdhci_host *host,
int spec_reg, u32 value)
{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
u16 ret;
int shift = (spec_reg & 0x2) * 8;
@@ -80,6 +86,13 @@ static u16 esdhc_readw_fixup(struct sdhci_host *host,
ret = value & 0xffff;
else
ret = (value >> shift) & 0xffff;
+
+ /* Workaround for T4240-R1.0-R2.0 eSDHC which has incorrect
+ * vendor version and spec version information.
+ */
+ if ((spec_reg == SDHCI_HOST_VERSION) &&
+ (esdhc->soc_ver == SVR_T4240) && (esdhc->soc_rev <= 0x20))
+ ret = (VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) | SDHCI_SPEC_200;
return ret;
}
@@ -567,10 +580,20 @@ static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host)
struct sdhci_pltfm_host *pltfm_host;
struct sdhci_esdhc *esdhc;
u16 host_ver;
+ u32 svr;
pltfm_host = sdhci_priv(host);
esdhc = sdhci_pltfm_priv(pltfm_host);
+ fsl_guts_init();
+ svr = fsl_guts_get_svr();
+ if (svr) {
+ esdhc->soc_ver = SVR_SOC_VER(svr);
+ esdhc->soc_rev = SVR_REV(svr);
+ } else {
+ dev_err(&pdev->dev, "Failed to get SVR value!\n");
+ }
+
host_ver = sdhci_readw(host, SDHCI_HOST_VERSION);
esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >>
SDHCI_VENDOR_VER_SHIFT;
--
2.1.0.27.g96db324
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-05 3:12 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 3:12 UTC (permalink / raw)
To: linux-arm-kernel
The eSDHC of T4240-R1.0-R2.0 has incorrect vender version and spec version.
Acturally the right version numbers should be VVN=0x13 and SVN = 0x1.
This patch adds the GUTS driver support for eSDHC driver to get SVR(System
version register). And fix host version to avoid that incorrect version
numbers break down the ADMA data transfer.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Scott Wood <oss@buserror.net>
---
Changes for v2:
- Got SVR through iomap instead of dts
Changes for v3:
- Managed GUTS through syscon instead of iomap in eSDHC driver
Changes for v4:
- Got SVR by GUTS driver instead of SYSCON
Changes for v5:
- Changed to get SVR through API fsl_guts_get_svr()
- Combined patch 4, patch 5 and patch 6 into one
Changes for v6:
- Added 'Acked-by: Ulf Hansson'
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
Changes for v9:
- None
Changes for v10:
- None
---
drivers/mmc/host/Kconfig | 1 +
drivers/mmc/host/sdhci-of-esdhc.c | 23 +++++++++++++++++++++++
2 files changed, 24 insertions(+)
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 0aa484c..e15e836 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -143,6 +143,7 @@ config MMC_SDHCI_OF_ESDHC
depends on MMC_SDHCI_PLTFM
depends on PPC || ARCH_MXC || ARCH_LAYERSCAPE
select MMC_SDHCI_IO_ACCESSORS
+ select FSL_GUTS
help
This selects the Freescale eSDHC controller support.
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
index 3f34d35..68cc020 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -18,6 +18,8 @@
#include <linux/of.h>
#include <linux/delay.h>
#include <linux/module.h>
+#include <linux/fsl/svr.h>
+#include <linux/fsl/guts.h>
#include <linux/mmc/host.h>
#include "sdhci-pltfm.h"
#include "sdhci-esdhc.h"
@@ -28,6 +30,8 @@
struct sdhci_esdhc {
u8 vendor_ver;
u8 spec_ver;
+ u32 soc_ver;
+ u8 soc_rev;
};
/**
@@ -73,6 +77,8 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
static u16 esdhc_readw_fixup(struct sdhci_host *host,
int spec_reg, u32 value)
{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
u16 ret;
int shift = (spec_reg & 0x2) * 8;
@@ -80,6 +86,13 @@ static u16 esdhc_readw_fixup(struct sdhci_host *host,
ret = value & 0xffff;
else
ret = (value >> shift) & 0xffff;
+
+ /* Workaround for T4240-R1.0-R2.0 eSDHC which has incorrect
+ * vendor version and spec version information.
+ */
+ if ((spec_reg == SDHCI_HOST_VERSION) &&
+ (esdhc->soc_ver == SVR_T4240) && (esdhc->soc_rev <= 0x20))
+ ret = (VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) | SDHCI_SPEC_200;
return ret;
}
@@ -567,10 +580,20 @@ static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host)
struct sdhci_pltfm_host *pltfm_host;
struct sdhci_esdhc *esdhc;
u16 host_ver;
+ u32 svr;
pltfm_host = sdhci_priv(host);
esdhc = sdhci_pltfm_priv(pltfm_host);
+ fsl_guts_init();
+ svr = fsl_guts_get_svr();
+ if (svr) {
+ esdhc->soc_ver = SVR_SOC_VER(svr);
+ esdhc->soc_rev = SVR_REV(svr);
+ } else {
+ dev_err(&pdev->dev, "Failed to get SVR value!\n");
+ }
+
host_ver = sdhci_readw(host, SDHCI_HOST_VERSION);
esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >>
SDHCI_VENDOR_VER_SHIFT;
--
2.1.0.27.g96db324
^ permalink raw reply related [flat|nested] 185+ messages in thread
* Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-05 8:31 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-05 8:31 UTC (permalink / raw)
To: linuxppc-dev
Cc: Yangbo Lu, linux-mmc, devicetree, linux-arm-kernel, linux-kernel,
linux-clk, linux-i2c, iommu, netdev, Mark Rutland, ulf.hansson,
Russell King, Bhupesh Sharma, Joerg Roedel, Santosh Shilimkar,
leoyang.li, Scott Wood, Rob Herring, Claudiu Manoil, Kumar Gala,
xiaobo.xie, Qiang Zhao
On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
>
> + fsl_guts_init();
> + svr = fsl_guts_get_svr();
> + if (svr) {
> + esdhc->soc_ver = SVR_SOC_VER(svr);
> + esdhc->soc_rev = SVR_REV(svr);
> + } else {
> + dev_err(&pdev->dev, "Failed to get SVR value!\n");
> + }
> +
>
Sorry for jumping in again after not participating in the discussion for the
past few versions.
What happened to my suggestion of making this a platform-independent interface
to avoid the link time dependency?
Specifically, why not add an exported function to drivers/base/soc.c that
uses glob_match() for comparing a string in the device driver to the ID
of the SoC that is set by whatever SoC identifying driver the platform
has?
Arnd
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-05 8:31 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-05 8:31 UTC (permalink / raw)
To: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
Cc: Mark Rutland, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
xiaobo.xie-3arQi8VN3Tc, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Qiang Zhao, Russell King,
Bhupesh Sharma, Claudiu Manoil,
devicetree-u79uwXL29TY76Z2rM5mHXA, Kumar Gala, Scott Wood,
Rob Herring, Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, leoyang.li-3arQi8VN3Tc,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Yangbo Lu
On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
>
> + fsl_guts_init();
> + svr = fsl_guts_get_svr();
> + if (svr) {
> + esdhc->soc_ver = SVR_SOC_VER(svr);
> + esdhc->soc_rev = SVR_REV(svr);
> + } else {
> + dev_err(&pdev->dev, "Failed to get SVR value!\n");
> + }
> +
>
Sorry for jumping in again after not participating in the discussion for the
past few versions.
What happened to my suggestion of making this a platform-independent interface
to avoid the link time dependency?
Specifically, why not add an exported function to drivers/base/soc.c that
uses glob_match() for comparing a string in the device driver to the ID
of the SoC that is set by whatever SoC identifying driver the platform
has?
Arnd
^ permalink raw reply [flat|nested] 185+ messages in thread
* [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-05 8:31 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-05 8:31 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
>
> + fsl_guts_init();
> + svr = fsl_guts_get_svr();
> + if (svr) {
> + esdhc->soc_ver = SVR_SOC_VER(svr);
> + esdhc->soc_rev = SVR_REV(svr);
> + } else {
> + dev_err(&pdev->dev, "Failed to get SVR value!\n");
> + }
> +
>
Sorry for jumping in again after not participating in the discussion for the
past few versions.
What happened to my suggestion of making this a platform-independent interface
to avoid the link time dependency?
Specifically, why not add an exported function to drivers/base/soc.c that
uses glob_match() for comparing a string in the device driver to the ID
of the SoC that is set by whatever SoC identifying driver the platform
has?
Arnd
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
2016-05-05 8:31 ` Arnd Bergmann
` (3 preceding siblings ...)
(?)
@ 2016-05-05 9:41 ` Yangbo Lu
-1 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 9:41 UTC (permalink / raw)
To: Arnd Bergmann, Scott Wood, linuxppc-dev
Cc: linux-mmc, devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-i2c, iommu, netdev, Mark Rutland, ulf.hansson,
Russell King, Bhupesh Sharma, Joerg Roedel, Santosh Shilimkar,
Yang-Leo Li, Rob Herring, Claudiu Manoil, Kumar Gala, Xiaobo Xie,
Qiang Zhao
Hi Arnd,
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@arndb.de]
> Sent: Thursday, May 05, 2016 4:32 PM
> To: linuxppc-dev@lists.ozlabs.org
> Cc: Yangbo Lu; linux-mmc@vger.kernel.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> linux-clk@vger.kernel.org; linux-i2c@vger.kernel.org; iommu@lists.linux-
> foundation.org; netdev@vger.kernel.org; Mark Rutland;
> ulf.hansson@linaro.org; Russell King; Bhupesh Sharma; Joerg Roedel;
> Santosh Shilimkar; Yang-Leo Li; Scott Wood; Rob Herring; Claudiu Manoil;
> Kumar Gala; Xiaobo Xie; Qiang Zhao
> Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
> R1.0-R2.0
>
> On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
> >
> > + fsl_guts_init();
> > + svr = fsl_guts_get_svr();
> > + if (svr) {
> > + esdhc->soc_ver = SVR_SOC_VER(svr);
> > + esdhc->soc_rev = SVR_REV(svr);
> > + } else {
> > + dev_err(&pdev->dev, "Failed to get SVR value!\n");
> > + }
> > +
> >
>
>
> Sorry for jumping in again after not participating in the discussion for
> the past few versions.
>
> What happened to my suggestion of making this a platform-independent
> interface to avoid the link time dependency?
>
> Specifically, why not add an exported function to drivers/base/soc.c that
> uses glob_match() for comparing a string in the device driver to the ID
> of the SoC that is set by whatever SoC identifying driver the platform
> has?
>
> Arnd
[Lu Yangbo-B47093] I think this has been discussed in v6.
You can find Scott's comments about this in below link.
https://patchwork.kernel.org/patch/8544501/
Thanks.
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-05 9:41 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 9:41 UTC (permalink / raw)
To: Arnd Bergmann, Scott Wood, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Russell King, Bhupesh Sharma,
netdev-u79uwXL29TY76Z2rM5mHXA, Kumar Gala,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Yang-Leo Li,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Rob Herring,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Claudiu Manoil,
Santosh Shilimkar, Xiaobo Xie, linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Hi Arnd,
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd-r2nGTMty4D4@public.gmane.org]
> Sent: Thursday, May 05, 2016 4:32 PM
> To: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> Cc: Yangbo Lu; linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; iommu-cunTk1MwBs/ROKNJybVBZg@public.gmane.org
> foundation.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Mark Rutland;
> ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org; Russell King; Bhupesh Sharma; Joerg Roedel;
> Santosh Shilimkar; Yang-Leo Li; Scott Wood; Rob Herring; Claudiu Manoil;
> Kumar Gala; Xiaobo Xie; Qiang Zhao
> Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
> R1.0-R2.0
>
> On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
> >
> > + fsl_guts_init();
> > + svr = fsl_guts_get_svr();
> > + if (svr) {
> > + esdhc->soc_ver = SVR_SOC_VER(svr);
> > + esdhc->soc_rev = SVR_REV(svr);
> > + } else {
> > + dev_err(&pdev->dev, "Failed to get SVR value!\n");
> > + }
> > +
> >
>
>
> Sorry for jumping in again after not participating in the discussion for
> the past few versions.
>
> What happened to my suggestion of making this a platform-independent
> interface to avoid the link time dependency?
>
> Specifically, why not add an exported function to drivers/base/soc.c that
> uses glob_match() for comparing a string in the device driver to the ID
> of the SoC that is set by whatever SoC identifying driver the platform
> has?
>
> Arnd
[Lu Yangbo-B47093] I think this has been discussed in v6.
You can find Scott's comments about this in below link.
https://patchwork.kernel.org/patch/8544501/
Thanks.
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-05 9:41 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 9:41 UTC (permalink / raw)
To: Arnd Bergmann, Scott Wood, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Russell King, Bhupesh Sharma,
netdev-u79uwXL29TY76Z2rM5mHXA, Kumar Gala,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Yang-Leo Li,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Rob Herring,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Claudiu Manoil,
Santosh Shilimkar, Xiaobo Xie, linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Hi Arnd,
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd-r2nGTMty4D4@public.gmane.org]
> Sent: Thursday, May 05, 2016 4:32 PM
> To: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> Cc: Yangbo Lu; linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; iommu-cunTk1MwBs/ROKNJybVBZg@public.gmane.org
> foundation.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Mark Rutland;
> ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org; Russell King; Bhupesh Sharma; Joerg Roedel;
> Santosh Shilimkar; Yang-Leo Li; Scott Wood; Rob Herring; Claudiu Manoil;
> Kumar Gala; Xiaobo Xie; Qiang Zhao
> Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
> R1.0-R2.0
>
> On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
> >
> > + fsl_guts_init();
> > + svr = fsl_guts_get_svr();
> > + if (svr) {
> > + esdhc->soc_ver = SVR_SOC_VER(svr);
> > + esdhc->soc_rev = SVR_REV(svr);
> > + } else {
> > + dev_err(&pdev->dev, "Failed to get SVR value!\n");
> > + }
> > +
> >
>
>
> Sorry for jumping in again after not participating in the discussion for
> the past few versions.
>
> What happened to my suggestion of making this a platform-independent
> interface to avoid the link time dependency?
>
> Specifically, why not add an exported function to drivers/base/soc.c that
> uses glob_match() for comparing a string in the device driver to the ID
> of the SoC that is set by whatever SoC identifying driver the platform
> has?
>
> Arnd
[Lu Yangbo-B47093] I think this has been discussed in v6.
You can find Scott's comments about this in below link.
https://patchwork.kernel.org/patch/8544501/
Thanks.
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-05 9:41 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 9:41 UTC (permalink / raw)
To: Arnd Bergmann, Scott Wood, linuxppc-dev
Cc: Mark Rutland, devicetree, ulf.hansson, Russell King,
Bhupesh Sharma, netdev, Joerg Roedel, Kumar Gala, linux-mmc,
linux-kernel, Yang-Leo Li, iommu, Rob Herring, linux-i2c,
Claudiu Manoil, Santosh Shilimkar, Xiaobo Xie, linux-clk,
linux-arm-kernel, Qiang Zhao
Hi Arnd,
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@arndb.de]
> Sent: Thursday, May 05, 2016 4:32 PM
> To: linuxppc-dev@lists.ozlabs.org
> Cc: Yangbo Lu; linux-mmc@vger.kernel.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> linux-clk@vger.kernel.org; linux-i2c@vger.kernel.org; iommu@lists.linux-
> foundation.org; netdev@vger.kernel.org; Mark Rutland;
> ulf.hansson@linaro.org; Russell King; Bhupesh Sharma; Joerg Roedel;
> Santosh Shilimkar; Yang-Leo Li; Scott Wood; Rob Herring; Claudiu Manoil;
> Kumar Gala; Xiaobo Xie; Qiang Zhao
> Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
> R1.0-R2.0
>
> On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
> >
> > + fsl_guts_init();
> > + svr = fsl_guts_get_svr();
> > + if (svr) {
> > + esdhc->soc_ver = SVR_SOC_VER(svr);
> > + esdhc->soc_rev = SVR_REV(svr);
> > + } else {
> > + dev_err(&pdev->dev, "Failed to get SVR value!\n");
> > + }
> > +
> >
>
>
> Sorry for jumping in again after not participating in the discussion for
> the past few versions.
>
> What happened to my suggestion of making this a platform-independent
> interface to avoid the link time dependency?
>
> Specifically, why not add an exported function to drivers/base/soc.c that
> uses glob_match() for comparing a string in the device driver to the ID
> of the SoC that is set by whatever SoC identifying driver the platform
> has?
>
> Arnd
[Lu Yangbo-B47093] I think this has been discussed in v6.
You can find Scott's comments about this in below link.
https://patchwork.kernel.org/patch/8544501/
Thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-05 9:41 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 9:41 UTC (permalink / raw)
To: Arnd Bergmann, Scott Wood, linuxppc-dev
Cc: linux-mmc, devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-i2c, iommu, netdev, Mark Rutland, ulf.hansson,
Russell King, Bhupesh Sharma, Joerg Roedel, Santosh Shilimkar,
Yang-Leo Li, Rob Herring, Claudiu Manoil, Kumar Gala, Xiaobo Xie,
Qiang Zhao
Hi Arnd,
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@arndb.de]
> Sent: Thursday, May 05, 2016 4:32 PM
> To: linuxppc-dev@lists.ozlabs.org
> Cc: Yangbo Lu; linux-mmc@vger.kernel.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> linux-clk@vger.kernel.org; linux-i2c@vger.kernel.org; iommu@lists.linux-
> foundation.org; netdev@vger.kernel.org; Mark Rutland;
> ulf.hansson@linaro.org; Russell King; Bhupesh Sharma; Joerg Roedel;
> Santosh Shilimkar; Yang-Leo Li; Scott Wood; Rob Herring; Claudiu Manoil;
> Kumar Gala; Xiaobo Xie; Qiang Zhao
> Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
> R1.0-R2.0
>=20
> On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
> >
> > + fsl_guts_init();
> > + svr =3D fsl_guts_get_svr();
> > + if (svr) {
> > + esdhc->soc_ver =3D SVR_SOC_VER(svr);
> > + esdhc->soc_rev =3D SVR_REV(svr);
> > + } else {
> > + dev_err(&pdev->dev, "Failed to get SVR value!\n");
> > + }
> > +
> >
>=20
>=20
> Sorry for jumping in again after not participating in the discussion for
> the past few versions.
>=20
> What happened to my suggestion of making this a platform-independent
> interface to avoid the link time dependency?
>=20
> Specifically, why not add an exported function to drivers/base/soc.c that
> uses glob_match() for comparing a string in the device driver to the ID
> of the SoC that is set by whatever SoC identifying driver the platform
> has?
>=20
> Arnd
[Lu Yangbo-B47093] I think this has been discussed in v6.
You can find Scott's comments about this in below link.
https://patchwork.kernel.org/patch/8544501/
Thanks.
^ permalink raw reply [flat|nested] 185+ messages in thread
* [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-05 9:41 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-05 9:41 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Thursday, May 05, 2016 4:32 PM
> To: linuxppc-dev at lists.ozlabs.org
> Cc: Yangbo Lu; linux-mmc at vger.kernel.org; devicetree at vger.kernel.org;
> linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> linux-clk at vger.kernel.org; linux-i2c at vger.kernel.org; iommu at lists.linux-
> foundation.org; netdev at vger.kernel.org; Mark Rutland;
> ulf.hansson at linaro.org; Russell King; Bhupesh Sharma; Joerg Roedel;
> Santosh Shilimkar; Yang-Leo Li; Scott Wood; Rob Herring; Claudiu Manoil;
> Kumar Gala; Xiaobo Xie; Qiang Zhao
> Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
> R1.0-R2.0
>
> On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
> >
> > + fsl_guts_init();
> > + svr = fsl_guts_get_svr();
> > + if (svr) {
> > + esdhc->soc_ver = SVR_SOC_VER(svr);
> > + esdhc->soc_rev = SVR_REV(svr);
> > + } else {
> > + dev_err(&pdev->dev, "Failed to get SVR value!\n");
> > + }
> > +
> >
>
>
> Sorry for jumping in again after not participating in the discussion for
> the past few versions.
>
> What happened to my suggestion of making this a platform-independent
> interface to avoid the link time dependency?
>
> Specifically, why not add an exported function to drivers/base/soc.c that
> uses glob_match() for comparing a string in the device driver to the ID
> of the SoC that is set by whatever SoC identifying driver the platform
> has?
>
> Arnd
[Lu Yangbo-B47093] I think this has been discussed in v6.
You can find Scott's comments about this in below link.
https://patchwork.kernel.org/patch/8544501/
Thanks.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-05 11:10 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-05 11:10 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Yangbo Lu, Scott Wood, linuxppc-dev, Mark Rutland, devicetree,
ulf.hansson, Russell King, Bhupesh Sharma, netdev, Joerg Roedel,
Kumar Gala, linux-mmc, linux-kernel, Yang-Leo Li, iommu,
Rob Herring, linux-i2c, Claudiu Manoil, Santosh Shilimkar,
Xiaobo Xie, linux-clk, Qiang Zhao
On Thursday 05 May 2016 09:41:32 Yangbo Lu wrote:
> > -----Original Message-----
> > From: Arnd Bergmann [mailto:arnd@arndb.de]
> > Sent: Thursday, May 05, 2016 4:32 PM
> > To: linuxppc-dev@lists.ozlabs.org
> > Cc: Yangbo Lu; linux-mmc@vger.kernel.org; devicetree@vger.kernel.org;
> > linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> > linux-clk@vger.kernel.org; linux-i2c@vger.kernel.org; iommu@lists.linux-
> > foundation.org; netdev@vger.kernel.org; Mark Rutland;
> > ulf.hansson@linaro.org; Russell King; Bhupesh Sharma; Joerg Roedel;
> > Santosh Shilimkar; Yang-Leo Li; Scott Wood; Rob Herring; Claudiu Manoil;
> > Kumar Gala; Xiaobo Xie; Qiang Zhao
> > Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
> > R1.0-R2.0
> >
> > On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
> > >
> > > + fsl_guts_init();
> > > + svr = fsl_guts_get_svr();
> > > + if (svr) {
> > > + esdhc->soc_ver = SVR_SOC_VER(svr);
> > > + esdhc->soc_rev = SVR_REV(svr);
> > > + } else {
> > > + dev_err(&pdev->dev, "Failed to get SVR value!\n");
> > > + }
> > > +
> > >
> >
> >
> > Sorry for jumping in again after not participating in the discussion for
> > the past few versions.
> >
> > What happened to my suggestion of making this a platform-independent
> > interface to avoid the link time dependency?
> >
> > Specifically, why not add an exported function to drivers/base/soc.c that
> > uses glob_match() for comparing a string in the device driver to the ID
> > of the SoC that is set by whatever SoC identifying driver the platform
> > has?
>
> [Lu Yangbo-B47093] I think this has been discussed in v6.
> You can find Scott's comments about this in below link.
> https://patchwork.kernel.org/patch/8544501/
Ah, thanks for bearing with me and digging this out again. Let me follow
up on Scott's older replies here then:
> >> IIRC, it is the same IP block as i.MX and Arnd's point is this won't
> >> even compile on !PPC. It is things like this that prevent sharing the
> >> driver.
>
> The whole point of using the MMIO SVR instead of the PPC SPR is so that
> it will work on ARM... The guts driver should build on any platform as
> long as OF is enabled, and if it doesn't find a node to bind to it will
> return 0 for SVR, and the eSDHC driver will continue (after printing an
> error that should be removed) without the ability to test for errata
> based on SVR.
It feels like a bad design to have to come up with a different
method for each SoC type here when they all do the same thing
and want to identify some variant of the chip to do device
specific quirks.
As far as I'm concerned, every driver in drivers/soc that needs to
export a symbol to be used by a device driver is an indication that
we don't have the right set of abstractions yet. There are cases
that are not worth abstracting because the functionality is rather
obscure and only a couple of drivers for one particular chip
ever need it.
Finding out the version of the SoC does not look like this case.
> > I think the first four patches take care of building for ARM,
> > but the problem remains if you want to enable COMPILE_TEST as
> > we need for certain automated checking.
>
> What specific problem is there with COMPILE_TEST?
COMPILE_TEST is solvable here and the way it is implemented in this
case (selecting FSL_GUTS from the driver) indeed looks like it works
correctly, but it's still awkward that this means building the
SoC specific ID stuff into the vmlinux binary for any driver that
uses something like that for a particular SoC.
> >> Dealing with Si revs is a common problem. We should have a
> >> common solution. There is soc_device for this purpose.
> >
> > Exactly. The last time this came up, I think we agreed to implement a
> > helper using glob_match() on the soc_device strings. Unfortunately
> > this hasn't happened then, but I'd still prefer that over yet another
> > vendor-specific way of dealing with the generic issue.
>
> soc_device would require encoding the SVR as a string and then decoding
> the string, which is more complicated and error prone than having
> platform-specific code test a platform-specific number.
You already need to encode it as a string to register the soc_device,
and the driver just needs to pass a glob string, so the only part that
is missing is the generic function that takes the string from the
driver and passes that to glob_match for the soc_device.
> And when would it get registered on arm64, which doesn't have
> platform code?
Whenever the soc driver is loaded, as is the case now. The match
function can return -EPROBE_DEFER if no SoC device is registered
yet.
Arnd
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-05 11:10 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-05 11:10 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Mark Rutland, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Xiaobo Xie,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Qiang Zhao, Russell King,
Bhupesh Sharma, Claudiu Manoil,
devicetree-u79uwXL29TY76Z2rM5mHXA, Yangbo Lu, Scott Wood,
Rob Herring, Santosh Shilimkar, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Yang-Leo Li,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Kumar
On Thursday 05 May 2016 09:41:32 Yangbo Lu wrote:
> > -----Original Message-----
> > From: Arnd Bergmann [mailto:arnd-r2nGTMty4D4@public.gmane.org]
> > Sent: Thursday, May 05, 2016 4:32 PM
> > To: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> > Cc: Yangbo Lu; linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; iommu-cunTk1MwBs/ROKNJybVBZg@public.gmane.org
> > foundation.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Mark Rutland;
> > ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org; Russell King; Bhupesh Sharma; Joerg Roedel;
> > Santosh Shilimkar; Yang-Leo Li; Scott Wood; Rob Herring; Claudiu Manoil;
> > Kumar Gala; Xiaobo Xie; Qiang Zhao
> > Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
> > R1.0-R2.0
> >
> > On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
> > >
> > > + fsl_guts_init();
> > > + svr = fsl_guts_get_svr();
> > > + if (svr) {
> > > + esdhc->soc_ver = SVR_SOC_VER(svr);
> > > + esdhc->soc_rev = SVR_REV(svr);
> > > + } else {
> > > + dev_err(&pdev->dev, "Failed to get SVR value!\n");
> > > + }
> > > +
> > >
> >
> >
> > Sorry for jumping in again after not participating in the discussion for
> > the past few versions.
> >
> > What happened to my suggestion of making this a platform-independent
> > interface to avoid the link time dependency?
> >
> > Specifically, why not add an exported function to drivers/base/soc.c that
> > uses glob_match() for comparing a string in the device driver to the ID
> > of the SoC that is set by whatever SoC identifying driver the platform
> > has?
>
> [Lu Yangbo-B47093] I think this has been discussed in v6.
> You can find Scott's comments about this in below link.
> https://patchwork.kernel.org/patch/8544501/
Ah, thanks for bearing with me and digging this out again. Let me follow
up on Scott's older replies here then:
> >> IIRC, it is the same IP block as i.MX and Arnd's point is this won't
> >> even compile on !PPC. It is things like this that prevent sharing the
> >> driver.
>
> The whole point of using the MMIO SVR instead of the PPC SPR is so that
> it will work on ARM... The guts driver should build on any platform as
> long as OF is enabled, and if it doesn't find a node to bind to it will
> return 0 for SVR, and the eSDHC driver will continue (after printing an
> error that should be removed) without the ability to test for errata
> based on SVR.
It feels like a bad design to have to come up with a different
method for each SoC type here when they all do the same thing
and want to identify some variant of the chip to do device
specific quirks.
As far as I'm concerned, every driver in drivers/soc that needs to
export a symbol to be used by a device driver is an indication that
we don't have the right set of abstractions yet. There are cases
that are not worth abstracting because the functionality is rather
obscure and only a couple of drivers for one particular chip
ever need it.
Finding out the version of the SoC does not look like this case.
> > I think the first four patches take care of building for ARM,
> > but the problem remains if you want to enable COMPILE_TEST as
> > we need for certain automated checking.
>
> What specific problem is there with COMPILE_TEST?
COMPILE_TEST is solvable here and the way it is implemented in this
case (selecting FSL_GUTS from the driver) indeed looks like it works
correctly, but it's still awkward that this means building the
SoC specific ID stuff into the vmlinux binary for any driver that
uses something like that for a particular SoC.
> >> Dealing with Si revs is a common problem. We should have a
> >> common solution. There is soc_device for this purpose.
> >
> > Exactly. The last time this came up, I think we agreed to implement a
> > helper using glob_match() on the soc_device strings. Unfortunately
> > this hasn't happened then, but I'd still prefer that over yet another
> > vendor-specific way of dealing with the generic issue.
>
> soc_device would require encoding the SVR as a string and then decoding
> the string, which is more complicated and error prone than having
> platform-specific code test a platform-specific number.
You already need to encode it as a string to register the soc_device,
and the driver just needs to pass a glob string, so the only part that
is missing is the generic function that takes the string from the
driver and passes that to glob_match for the soc_device.
> And when would it get registered on arm64, which doesn't have
> platform code?
Whenever the soc driver is loaded, as is the case now. The match
function can return -EPROBE_DEFER if no SoC device is registered
yet.
Arnd
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-05 11:10 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-05 11:10 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Mark Rutland, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Xiaobo Xie,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Qiang Zhao, Russell King,
Bhupesh Sharma, Claudiu Manoil,
devicetree-u79uwXL29TY76Z2rM5mHXA, Yangbo Lu, Scott Wood,
Rob Herring, Santosh Shilimkar, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Yang-Leo Li,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Kumar
On Thursday 05 May 2016 09:41:32 Yangbo Lu wrote:
> > -----Original Message-----
> > From: Arnd Bergmann [mailto:arnd-r2nGTMty4D4@public.gmane.org]
> > Sent: Thursday, May 05, 2016 4:32 PM
> > To: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> > Cc: Yangbo Lu; linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; iommu-cunTk1MwBs/ROKNJybVBZg@public.gmane.org
> > foundation.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Mark Rutland;
> > ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org; Russell King; Bhupesh Sharma; Joerg Roedel;
> > Santosh Shilimkar; Yang-Leo Li; Scott Wood; Rob Herring; Claudiu Manoil;
> > Kumar Gala; Xiaobo Xie; Qiang Zhao
> > Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
> > R1.0-R2.0
> >
> > On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
> > >
> > > + fsl_guts_init();
> > > + svr = fsl_guts_get_svr();
> > > + if (svr) {
> > > + esdhc->soc_ver = SVR_SOC_VER(svr);
> > > + esdhc->soc_rev = SVR_REV(svr);
> > > + } else {
> > > + dev_err(&pdev->dev, "Failed to get SVR value!\n");
> > > + }
> > > +
> > >
> >
> >
> > Sorry for jumping in again after not participating in the discussion for
> > the past few versions.
> >
> > What happened to my suggestion of making this a platform-independent
> > interface to avoid the link time dependency?
> >
> > Specifically, why not add an exported function to drivers/base/soc.c that
> > uses glob_match() for comparing a string in the device driver to the ID
> > of the SoC that is set by whatever SoC identifying driver the platform
> > has?
>
> [Lu Yangbo-B47093] I think this has been discussed in v6.
> You can find Scott's comments about this in below link.
> https://patchwork.kernel.org/patch/8544501/
Ah, thanks for bearing with me and digging this out again. Let me follow
up on Scott's older replies here then:
> >> IIRC, it is the same IP block as i.MX and Arnd's point is this won't
> >> even compile on !PPC. It is things like this that prevent sharing the
> >> driver.
>
> The whole point of using the MMIO SVR instead of the PPC SPR is so that
> it will work on ARM... The guts driver should build on any platform as
> long as OF is enabled, and if it doesn't find a node to bind to it will
> return 0 for SVR, and the eSDHC driver will continue (after printing an
> error that should be removed) without the ability to test for errata
> based on SVR.
It feels like a bad design to have to come up with a different
method for each SoC type here when they all do the same thing
and want to identify some variant of the chip to do device
specific quirks.
As far as I'm concerned, every driver in drivers/soc that needs to
export a symbol to be used by a device driver is an indication that
we don't have the right set of abstractions yet. There are cases
that are not worth abstracting because the functionality is rather
obscure and only a couple of drivers for one particular chip
ever need it.
Finding out the version of the SoC does not look like this case.
> > I think the first four patches take care of building for ARM,
> > but the problem remains if you want to enable COMPILE_TEST as
> > we need for certain automated checking.
>
> What specific problem is there with COMPILE_TEST?
COMPILE_TEST is solvable here and the way it is implemented in this
case (selecting FSL_GUTS from the driver) indeed looks like it works
correctly, but it's still awkward that this means building the
SoC specific ID stuff into the vmlinux binary for any driver that
uses something like that for a particular SoC.
> >> Dealing with Si revs is a common problem. We should have a
> >> common solution. There is soc_device for this purpose.
> >
> > Exactly. The last time this came up, I think we agreed to implement a
> > helper using glob_match() on the soc_device strings. Unfortunately
> > this hasn't happened then, but I'd still prefer that over yet another
> > vendor-specific way of dealing with the generic issue.
>
> soc_device would require encoding the SVR as a string and then decoding
> the string, which is more complicated and error prone than having
> platform-specific code test a platform-specific number.
You already need to encode it as a string to register the soc_device,
and the driver just needs to pass a glob string, so the only part that
is missing is the generic function that takes the string from the
driver and passes that to glob_match for the soc_device.
> And when would it get registered on arm64, which doesn't have
> platform code?
Whenever the soc driver is loaded, as is the case now. The match
function can return -EPROBE_DEFER if no SoC device is registered
yet.
Arnd
^ permalink raw reply [flat|nested] 185+ messages in thread
* [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-05 11:10 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-05 11:10 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 05 May 2016 09:41:32 Yangbo Lu wrote:
> > -----Original Message-----
> > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > Sent: Thursday, May 05, 2016 4:32 PM
> > To: linuxppc-dev at lists.ozlabs.org
> > Cc: Yangbo Lu; linux-mmc at vger.kernel.org; devicetree at vger.kernel.org;
> > linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> > linux-clk at vger.kernel.org; linux-i2c at vger.kernel.org; iommu at lists.linux-
> > foundation.org; netdev at vger.kernel.org; Mark Rutland;
> > ulf.hansson at linaro.org; Russell King; Bhupesh Sharma; Joerg Roedel;
> > Santosh Shilimkar; Yang-Leo Li; Scott Wood; Rob Herring; Claudiu Manoil;
> > Kumar Gala; Xiaobo Xie; Qiang Zhao
> > Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
> > R1.0-R2.0
> >
> > On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
> > >
> > > + fsl_guts_init();
> > > + svr = fsl_guts_get_svr();
> > > + if (svr) {
> > > + esdhc->soc_ver = SVR_SOC_VER(svr);
> > > + esdhc->soc_rev = SVR_REV(svr);
> > > + } else {
> > > + dev_err(&pdev->dev, "Failed to get SVR value!\n");
> > > + }
> > > +
> > >
> >
> >
> > Sorry for jumping in again after not participating in the discussion for
> > the past few versions.
> >
> > What happened to my suggestion of making this a platform-independent
> > interface to avoid the link time dependency?
> >
> > Specifically, why not add an exported function to drivers/base/soc.c that
> > uses glob_match() for comparing a string in the device driver to the ID
> > of the SoC that is set by whatever SoC identifying driver the platform
> > has?
>
> [Lu Yangbo-B47093] I think this has been discussed in v6.
> You can find Scott's comments about this in below link.
> https://patchwork.kernel.org/patch/8544501/
Ah, thanks for bearing with me and digging this out again. Let me follow
up on Scott's older replies here then:
> >> IIRC, it is the same IP block as i.MX and Arnd's point is this won't
> >> even compile on !PPC. It is things like this that prevent sharing the
> >> driver.
>
> The whole point of using the MMIO SVR instead of the PPC SPR is so that
> it will work on ARM... The guts driver should build on any platform as
> long as OF is enabled, and if it doesn't find a node to bind to it will
> return 0 for SVR, and the eSDHC driver will continue (after printing an
> error that should be removed) without the ability to test for errata
> based on SVR.
It feels like a bad design to have to come up with a different
method for each SoC type here when they all do the same thing
and want to identify some variant of the chip to do device
specific quirks.
As far as I'm concerned, every driver in drivers/soc that needs to
export a symbol to be used by a device driver is an indication that
we don't have the right set of abstractions yet. There are cases
that are not worth abstracting because the functionality is rather
obscure and only a couple of drivers for one particular chip
ever need it.
Finding out the version of the SoC does not look like this case.
> > I think the first four patches take care of building for ARM,
> > but the problem remains if you want to enable COMPILE_TEST as
> > we need for certain automated checking.
>
> What specific problem is there with COMPILE_TEST?
COMPILE_TEST is solvable here and the way it is implemented in this
case (selecting FSL_GUTS from the driver) indeed looks like it works
correctly, but it's still awkward that this means building the
SoC specific ID stuff into the vmlinux binary for any driver that
uses something like that for a particular SoC.
> >> Dealing with Si revs is a common problem. We should have a
> >> common solution. There is soc_device for this purpose.
> >
> > Exactly. The last time this came up, I think we agreed to implement a
> > helper using glob_match() on the soc_device strings. Unfortunately
> > this hasn't happened then, but I'd still prefer that over yet another
> > vendor-specific way of dealing with the generic issue.
>
> soc_device would require encoding the SVR as a string and then decoding
> the string, which is more complicated and error prone than having
> platform-specific code test a platform-specific number.
You already need to encode it as a string to register the soc_device,
and the driver just needs to pass a glob string, so the only part that
is missing is the generic function that takes the string from the
driver and passes that to glob_match for the soc_device.
> And when would it get registered on arm64, which doesn't have
> platform code?
Whenever the soc driver is loaded, as is the case now. The match
function can return -EPROBE_DEFER if no SoC device is registered
yet.
Arnd
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [v10, 1/7] Documentation: DT: update Freescale DCFG compatible
2016-05-05 3:12 ` Yangbo Lu
@ 2016-05-05 22:25 ` Rob Herring
-1 siblings, 0 replies; 185+ messages in thread
From: Rob Herring @ 2016-05-05 22:25 UTC (permalink / raw)
To: Yangbo Lu
Cc: linux-mmc, linuxppc-dev, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-i2c, iommu, netdev, ulf.hansson,
Scott Wood, Mark Rutland, Russell King, Jochen Friedrich,
Joerg Roedel, Claudiu Manoil, Bhupesh Sharma, Qiang Zhao,
Kumar Gala, Santosh Shilimkar, leoyang.li, xiaobo.xie
On Thu, May 05, 2016 at 11:12:24AM +0800, Yangbo Lu wrote:
> Update Freescale DCFG compatible with 'fsl,<chip>-dcfg' instead
> of 'fsl,ls1021a-dcfg' to include more chips such as ls1021a,
> ls1043a, and ls2080a.
>
> Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> ---
> Changes for v8:
> - Added this patch
> Changes for v9:
> - Added a list for the possible compatibles
> Changes for v10:
> - None
> ---
> Documentation/devicetree/bindings/arm/fsl.txt | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply [flat|nested] 185+ messages in thread
* [v10, 1/7] Documentation: DT: update Freescale DCFG compatible
@ 2016-05-05 22:25 ` Rob Herring
0 siblings, 0 replies; 185+ messages in thread
From: Rob Herring @ 2016-05-05 22:25 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, May 05, 2016 at 11:12:24AM +0800, Yangbo Lu wrote:
> Update Freescale DCFG compatible with 'fsl,<chip>-dcfg' instead
> of 'fsl,ls1021a-dcfg' to include more chips such as ls1021a,
> ls1043a, and ls2080a.
>
> Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> ---
> Changes for v8:
> - Added this patch
> Changes for v9:
> - Added a list for the possible compatibles
> Changes for v10:
> - None
> ---
> Documentation/devicetree/bindings/arm/fsl.txt | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
2016-05-05 11:10 ` Arnd Bergmann
(?)
(?)
@ 2016-05-11 3:26 ` Scott Wood
-1 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-05-11 3:26 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel
Cc: Yangbo Lu, linuxppc-dev, Mark Rutland, devicetree, ulf.hansson,
Russell King, Bhupesh Sharma, netdev, Joerg Roedel, Kumar Gala,
linux-mmc, linux-kernel, Yang-Leo Li, iommu, Rob Herring,
linux-i2c, Claudiu Manoil, Santosh Shilimkar, Xiaobo Xie,
linux-clk, Qiang Zhao
On Thu, 2016-05-05 at 13:10 +0200, Arnd Bergmann wrote:
> On Thursday 05 May 2016 09:41:32 Yangbo Lu wrote:
> > > -----Original Message-----
> > > From: Arnd Bergmann [mailto:arnd@arndb.de]
> > > Sent: Thursday, May 05, 2016 4:32 PM
> > > To: linuxppc-dev@lists.ozlabs.org
> > > Cc: Yangbo Lu; linux-mmc@vger.kernel.org; devicetree@vger.kernel.org;
> > > linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> > > linux-clk@vger.kernel.org; linux-i2c@vger.kernel.org; iommu@lists.linux-
> > > foundation.org; netdev@vger.kernel.org; Mark Rutland;
> > > ulf.hansson@linaro.org; Russell King; Bhupesh Sharma; Joerg Roedel;
> > > Santosh Shilimkar; Yang-Leo Li; Scott Wood; Rob Herring; Claudiu Manoil;
> > > Kumar Gala; Xiaobo Xie; Qiang Zhao
> > > Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
> > > R1.0-R2.0
> > >
> > > On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
> > > > IIRC, it is the same IP block as i.MX and Arnd's point is this won't
> > > > even compile on !PPC. It is things like this that prevent sharing the
> > > > driver.
> >
> > The whole point of using the MMIO SVR instead of the PPC SPR is so that
> > it will work on ARM... The guts driver should build on any platform as
> > long as OF is enabled, and if it doesn't find a node to bind to it will
> > return 0 for SVR, and the eSDHC driver will continue (after printing an
> > error that should be removed) without the ability to test for errata
> > based on SVR.
>
> It feels like a bad design to have to come up with a different
> method for each SoC type here when they all do the same thing
> and want to identify some variant of the chip to do device
> specific quirks.
>
> As far as I'm concerned, every driver in drivers/soc that needs to
> export a symbol to be used by a device driver is an indication that
> we don't have the right set of abstractions yet. There are cases
> that are not worth abstracting because the functionality is rather
> obscure and only a couple of drivers for one particular chip
> ever need it.
>
> Finding out the version of the SoC does not look like this case.
I'm open to new ways of abstracting this, but can that please be discussed
after these patches are merged? This patchset is fixing a problem, the
existing abstraction is unappealing and not widely adopted, a new abstraction
is not ready, and we're only touching code for our hardware.
Oh, and the existing abstraction isn't even "existing". I don't see any
examples where soc_device is being used like this -- or even any way for a
driver (the one consuming the information, not the soc "driver") to get a
reference to the soc_device that's been registered short of searching for the
device object by name -- and you're asking for new functionality in
drivers/base/soc.c.
> > > I think the first four patches take care of building for ARM,
> > > but the problem remains if you want to enable COMPILE_TEST as
> > > we need for certain automated checking.
> >
> > What specific problem is there with COMPILE_TEST?
>
> COMPILE_TEST is solvable here and the way it is implemented in this
> case (selecting FSL_GUTS from the driver) indeed looks like it works
> correctly, but it's still awkward that this means building the
> SoC specific ID stuff into the vmlinux binary for any driver that
> uses something like that for a particular SoC.
Please keep in mind that this is a Freescale-specific driver... it's not as if
we're attaching this dependency to common SDHCI code.
>
> > > > Dealing with Si revs is a common problem. We should have a
> > > > common solution. There is soc_device for this purpose.
> > >
> > > Exactly. The last time this came up, I think we agreed to implement a
> > > helper using glob_match() on the soc_device strings. Unfortunately
> > > this hasn't happened then, but I'd still prefer that over yet another
> > > vendor-specific way of dealing with the generic issue.
> >
> > soc_device would require encoding the SVR as a string and then decoding
> > the string, which is more complicated and error prone than having
> > platform-specific code test a platform-specific number.
>
> You already need to encode it as a string to register the soc_device,
No we don't, because we don't already register a soc_device on arm64 or ppc
(and it looks like whatever does get registered on at least some relevant
arm32 chips is not particularly useful).
> and the driver just needs to pass a glob string, so the only part that
> is missing is the generic function that takes the string from the
> driver and passes that to glob_match for the soc_device.
"just"
And what would the glob look like?
I'd rather not write kernel code as if it were a shell/Perl script.
> > And when would it get registered on arm64, which doesn't have
> > platform code?
>
> Whenever the soc driver is loaded, as is the case now. The match
> function can return -EPROBE_DEFER if no SoC device is registered
> yet.
That's too late for some places where we need access to SVR, e.g. clock
drivers (which use CLK_OF_DECLARE and are initialized very early, not as part
of the driver model and thus can't defer). Currently we have an #ifdef
CONFIG_PPC for this in drivers/clk/clk-qoriq.c... Maybe we should have done
that here as well, and saved some grief. :-) At least until an erratum pops
up on an ARM-based chip.
And what happens if we're running on arm32, and thus the arch code already
registered an soc_device with a different (and less useful) encoding?
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-11 3:26 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-05-11 3:26 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Russell King,
Santosh Shilimkar, Bhupesh Sharma, netdev-u79uwXL29TY76Z2rM5mHXA,
Kumar Gala, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Yang-Leo Li,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Rob Herring,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Claudiu Manoil, Yangbo Lu,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Xi
On Thu, 2016-05-05 at 13:10 +0200, Arnd Bergmann wrote:
> On Thursday 05 May 2016 09:41:32 Yangbo Lu wrote:
> > > -----Original Message-----
> > > From: Arnd Bergmann [mailto:arnd-r2nGTMty4D4@public.gmane.org]
> > > Sent: Thursday, May 05, 2016 4:32 PM
> > > To: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> > > Cc: Yangbo Lu; linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > > linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > > linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; iommu-cunTk1MwBs/ROKNJybVBZg@public.gmane.org
> > > foundation.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Mark Rutland;
> > > ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org; Russell King; Bhupesh Sharma; Joerg Roedel;
> > > Santosh Shilimkar; Yang-Leo Li; Scott Wood; Rob Herring; Claudiu Manoil;
> > > Kumar Gala; Xiaobo Xie; Qiang Zhao
> > > Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
> > > R1.0-R2.0
> > >
> > > On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
> > > > IIRC, it is the same IP block as i.MX and Arnd's point is this won't
> > > > even compile on !PPC. It is things like this that prevent sharing the
> > > > driver.
> >
> > The whole point of using the MMIO SVR instead of the PPC SPR is so that
> > it will work on ARM... The guts driver should build on any platform as
> > long as OF is enabled, and if it doesn't find a node to bind to it will
> > return 0 for SVR, and the eSDHC driver will continue (after printing an
> > error that should be removed) without the ability to test for errata
> > based on SVR.
>
> It feels like a bad design to have to come up with a different
> method for each SoC type here when they all do the same thing
> and want to identify some variant of the chip to do device
> specific quirks.
>
> As far as I'm concerned, every driver in drivers/soc that needs to
> export a symbol to be used by a device driver is an indication that
> we don't have the right set of abstractions yet. There are cases
> that are not worth abstracting because the functionality is rather
> obscure and only a couple of drivers for one particular chip
> ever need it.
>
> Finding out the version of the SoC does not look like this case.
I'm open to new ways of abstracting this, but can that please be discussed
after these patches are merged? This patchset is fixing a problem, the
existing abstraction is unappealing and not widely adopted, a new abstraction
is not ready, and we're only touching code for our hardware.
Oh, and the existing abstraction isn't even "existing". I don't see any
examples where soc_device is being used like this -- or even any way for a
driver (the one consuming the information, not the soc "driver") to get a
reference to the soc_device that's been registered short of searching for the
device object by name -- and you're asking for new functionality in
drivers/base/soc.c.
> > > I think the first four patches take care of building for ARM,
> > > but the problem remains if you want to enable COMPILE_TEST as
> > > we need for certain automated checking.
> >
> > What specific problem is there with COMPILE_TEST?
>
> COMPILE_TEST is solvable here and the way it is implemented in this
> case (selecting FSL_GUTS from the driver) indeed looks like it works
> correctly, but it's still awkward that this means building the
> SoC specific ID stuff into the vmlinux binary for any driver that
> uses something like that for a particular SoC.
Please keep in mind that this is a Freescale-specific driver... it's not as if
we're attaching this dependency to common SDHCI code.
>
> > > > Dealing with Si revs is a common problem. We should have a
> > > > common solution. There is soc_device for this purpose.
> > >
> > > Exactly. The last time this came up, I think we agreed to implement a
> > > helper using glob_match() on the soc_device strings. Unfortunately
> > > this hasn't happened then, but I'd still prefer that over yet another
> > > vendor-specific way of dealing with the generic issue.
> >
> > soc_device would require encoding the SVR as a string and then decoding
> > the string, which is more complicated and error prone than having
> > platform-specific code test a platform-specific number.
>
> You already need to encode it as a string to register the soc_device,
No we don't, because we don't already register a soc_device on arm64 or ppc
(and it looks like whatever does get registered on at least some relevant
arm32 chips is not particularly useful).
> and the driver just needs to pass a glob string, so the only part that
> is missing is the generic function that takes the string from the
> driver and passes that to glob_match for the soc_device.
"just"
And what would the glob look like?
I'd rather not write kernel code as if it were a shell/Perl script.
> > And when would it get registered on arm64, which doesn't have
> > platform code?
>
> Whenever the soc driver is loaded, as is the case now. The match
> function can return -EPROBE_DEFER if no SoC device is registered
> yet.
That's too late for some places where we need access to SVR, e.g. clock
drivers (which use CLK_OF_DECLARE and are initialized very early, not as part
of the driver model and thus can't defer). Currently we have an #ifdef
CONFIG_PPC for this in drivers/clk/clk-qoriq.c... Maybe we should have done
that here as well, and saved some grief. :-) At least until an erratum pops
up on an ARM-based chip.
And what happens if we're running on arm32, and thus the arch code already
registered an soc_device with a different (and less useful) encoding?
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-11 3:26 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-05-11 3:26 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel
Cc: Yangbo Lu, linuxppc-dev, Mark Rutland, devicetree, ulf.hansson,
Russell King, Bhupesh Sharma, netdev, Joerg Roedel, Kumar Gala,
linux-mmc, linux-kernel, Yang-Leo Li, iommu, Rob Herring,
linux-i2c, Claudiu Manoil, Santosh Shilimkar, Xiaobo Xie,
linux-clk, Qiang Zhao
On Thu, 2016-05-05 at 13:10 +0200, Arnd Bergmann wrote:
> On Thursday 05 May 2016 09:41:32 Yangbo Lu wrote:
> > > -----Original Message-----
> > > From: Arnd Bergmann [mailto:arnd@arndb.de]
> > > Sent: Thursday, May 05, 2016 4:32 PM
> > > To: linuxppc-dev@lists.ozlabs.org
> > > Cc: Yangbo Lu; linux-mmc@vger.kernel.org; devicetree@vger.kernel.org;
> > > linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> > > linux-clk@vger.kernel.org; linux-i2c@vger.kernel.org; iommu@lists.linux-
> > > foundation.org; netdev@vger.kernel.org; Mark Rutland;
> > > ulf.hansson@linaro.org; Russell King; Bhupesh Sharma; Joerg Roedel;
> > > Santosh Shilimkar; Yang-Leo Li; Scott Wood; Rob Herring; Claudiu Manoil;
> > > Kumar Gala; Xiaobo Xie; Qiang Zhao
> > > Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
> > > R1.0-R2.0
> > >
> > > On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
> > > > IIRC, it is the same IP block as i.MX and Arnd's point is this won't
> > > > even compile on !PPC. It is things like this that prevent sharing the
> > > > driver.
> >
> > The whole point of using the MMIO SVR instead of the PPC SPR is so that
> > it will work on ARM... The guts driver should build on any platform as
> > long as OF is enabled, and if it doesn't find a node to bind to it will
> > return 0 for SVR, and the eSDHC driver will continue (after printing an
> > error that should be removed) without the ability to test for errata
> > based on SVR.
>
> It feels like a bad design to have to come up with a different
> method for each SoC type here when they all do the same thing
> and want to identify some variant of the chip to do device
> specific quirks.
>
> As far as I'm concerned, every driver in drivers/soc that needs to
> export a symbol to be used by a device driver is an indication that
> we don't have the right set of abstractions yet. There are cases
> that are not worth abstracting because the functionality is rather
> obscure and only a couple of drivers for one particular chip
> ever need it.
>
> Finding out the version of the SoC does not look like this case.
I'm open to new ways of abstracting this, but can that please be discussed
after these patches are merged? This patchset is fixing a problem, the
existing abstraction is unappealing and not widely adopted, a new abstraction
is not ready, and we're only touching code for our hardware.
Oh, and the existing abstraction isn't even "existing". I don't see any
examples where soc_device is being used like this -- or even any way for a
driver (the one consuming the information, not the soc "driver") to get a
reference to the soc_device that's been registered short of searching for the
device object by name -- and you're asking for new functionality in
drivers/base/soc.c.
> > > I think the first four patches take care of building for ARM,
> > > but the problem remains if you want to enable COMPILE_TEST as
> > > we need for certain automated checking.
> >
> > What specific problem is there with COMPILE_TEST?
>
> COMPILE_TEST is solvable here and the way it is implemented in this
> case (selecting FSL_GUTS from the driver) indeed looks like it works
> correctly, but it's still awkward that this means building the
> SoC specific ID stuff into the vmlinux binary for any driver that
> uses something like that for a particular SoC.
Please keep in mind that this is a Freescale-specific driver... it's not as if
we're attaching this dependency to common SDHCI code.
>
> > > > Dealing with Si revs is a common problem. We should have a
> > > > common solution. There is soc_device for this purpose.
> > >
> > > Exactly. The last time this came up, I think we agreed to implement a
> > > helper using glob_match() on the soc_device strings. Unfortunately
> > > this hasn't happened then, but I'd still prefer that over yet another
> > > vendor-specific way of dealing with the generic issue.
> >
> > soc_device would require encoding the SVR as a string and then decoding
> > the string, which is more complicated and error prone than having
> > platform-specific code test a platform-specific number.
>
> You already need to encode it as a string to register the soc_device,
No we don't, because we don't already register a soc_device on arm64 or ppc
(and it looks like whatever does get registered on at least some relevant
arm32 chips is not particularly useful).
> and the driver just needs to pass a glob string, so the only part that
> is missing is the generic function that takes the string from the
> driver and passes that to glob_match for the soc_device.
"just"
And what would the glob look like?
I'd rather not write kernel code as if it were a shell/Perl script.
> > And when would it get registered on arm64, which doesn't have
> > platform code?
>
> Whenever the soc driver is loaded, as is the case now. The match
> function can return -EPROBE_DEFER if no SoC device is registered
> yet.
That's too late for some places where we need access to SVR, e.g. clock
drivers (which use CLK_OF_DECLARE and are initialized very early, not as part
of the driver model and thus can't defer). Currently we have an #ifdef
CONFIG_PPC for this in drivers/clk/clk-qoriq.c... Maybe we should have done
that here as well, and saved some grief. :-) At least until an erratum pops
up on an ARM-based chip.
And what happens if we're running on arm32, and thus the arch code already
registered an soc_device with a different (and less useful) encoding?
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-11 3:26 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-05-11 3:26 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 2016-05-05 at 13:10 +0200, Arnd Bergmann wrote:
> On Thursday 05 May 2016 09:41:32 Yangbo Lu wrote:
> > > -----Original Message-----
> > > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > > Sent: Thursday, May 05, 2016 4:32 PM
> > > To: linuxppc-dev at lists.ozlabs.org
> > > Cc: Yangbo Lu; linux-mmc at vger.kernel.org; devicetree at vger.kernel.org;
> > > linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> > > linux-clk at vger.kernel.org; linux-i2c at vger.kernel.org; iommu at lists.linux-
> > > foundation.org; netdev at vger.kernel.org; Mark Rutland;
> > > ulf.hansson at linaro.org; Russell King; Bhupesh Sharma; Joerg Roedel;
> > > Santosh Shilimkar; Yang-Leo Li; Scott Wood; Rob Herring; Claudiu Manoil;
> > > Kumar Gala; Xiaobo Xie; Qiang Zhao
> > > Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
> > > R1.0-R2.0
> > >
> > > On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
> > > > IIRC, it is the same IP block as i.MX and Arnd's point is this won't
> > > > even compile on !PPC. It is things like this that prevent sharing the
> > > > driver.
> >
> > The whole point of using the MMIO SVR instead of the PPC SPR is so that
> > it will work on ARM... The guts driver should build on any platform as
> > long as OF is enabled, and if it doesn't find a node to bind to it will
> > return 0 for SVR, and the eSDHC driver will continue (after printing an
> > error that should be removed) without the ability to test for errata
> > based on SVR.
>
> It feels like a bad design to have to come up with a different
> method for each SoC type here when they all do the same thing
> and want to identify some variant of the chip to do device
> specific quirks.
>
> As far as I'm concerned, every driver in drivers/soc that needs to
> export a symbol to be used by a device driver is an indication that
> we don't have the right set of abstractions yet. There are cases
> that are not worth abstracting because the functionality is rather
> obscure and only a couple of drivers for one particular chip
> ever need it.
>
> Finding out the version of the SoC does not look like this case.
I'm open to new ways of abstracting this, but can that please be discussed
after these patches are merged? This patchset is fixing a problem, the
existing abstraction is unappealing and not widely adopted, a new abstraction
is not ready, and we're only touching code for our hardware.
Oh, and the existing abstraction isn't even "existing". I don't see any
examples where soc_device is being used like this -- or even any way for a
driver (the one consuming the information, not the soc "driver") to get a
reference to the soc_device that's been registered short of searching for the
device object by name -- and you're asking for new functionality in
drivers/base/soc.c.
> > > I think the first four patches take care of building for ARM,
> > > but the problem remains if you want to enable COMPILE_TEST as
> > > we need for certain automated checking.
> >
> > What specific problem is there with COMPILE_TEST?
>
> COMPILE_TEST is solvable here and the way it is implemented in this
> case (selecting FSL_GUTS from the driver) indeed looks like it works
> correctly, but it's still awkward that this means building the
> SoC specific ID stuff into the vmlinux binary for any driver that
> uses something like that for a particular SoC.
Please keep in mind that this is a Freescale-specific driver... it's not as if
we're attaching this dependency to common SDHCI code.
>
> > > > Dealing with Si revs is a common problem. We should have a
> > > > common solution. There is soc_device for this purpose.
> > >
> > > Exactly. The last time this came up, I think we agreed to implement a
> > > helper using glob_match() on the soc_device strings. Unfortunately
> > > this hasn't happened then, but I'd still prefer that over yet another
> > > vendor-specific way of dealing with the generic issue.
> >
> > soc_device would require encoding the SVR as a string and then decoding
> > the string, which is more complicated and error prone than having
> > platform-specific code test a platform-specific number.
>
> You already need to encode it as a string to register the soc_device,
No we don't, because we don't already register a soc_device on arm64 or ppc
(and it looks like whatever does get registered on at least some relevant
arm32 chips is not particularly useful).
> and the driver just needs to pass a glob string, so the only part that
> is missing is the generic function that takes the string from the
> driver and passes that to glob_match for the soc_device.
"just"
And what would the glob look like?
I'd rather not write kernel code as if it were a shell/Perl script.
> > And when would it get registered on arm64, which doesn't have
> > platform code?
>
> Whenever the soc driver is loaded, as is the case now. The match
> function can return -EPROBE_DEFER if no SoC device is registered
> yet.
That's too late for some places where we need access to SVR, e.g. clock
drivers (which use CLK_OF_DECLARE and are initialized very early, not as part
of the driver model and thus can't defer). Currently we have an #ifdef
CONFIG_PPC for this in drivers/clk/clk-qoriq.c... Maybe we should have done
that here as well, and saved some grief. :-) At least until an erratum pops
up on an ARM-based chip.
And what happens if we're running on arm32, and thus the arch code already
registered an soc_device with a different (and less useful) encoding?
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-20 6:05 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-20 6:05 UTC (permalink / raw)
To: Scott Wood, Arnd Bergmann, linux-arm-kernel
Cc: linuxppc-dev, Mark Rutland, devicetree, ulf.hansson,
Russell King, Bhupesh Sharma, netdev, Joerg Roedel, Kumar Gala,
linux-mmc, linux-kernel, Yang-Leo Li, iommu, Rob Herring,
linux-i2c, Claudiu Manoil, Santosh Shilimkar, Xiaobo Xie,
linux-clk, Qiang Zhao
Hi Arnd,
Any comments?
Please reply when you see the email since we want this eSDHC issue to be fixed soon.
All the patches are Freescale-specific and is to fix the eSDHC driver.
Could we let them merged first if you were talking about a new way of abstracting getting SoC version.
Thanks :)
Best regards,
Yangbo Lu
> -----Original Message-----
> From: Scott Wood [mailto:oss@buserror.net]
> Sent: Wednesday, May 11, 2016 11:26 AM
> To: Arnd Bergmann; linux-arm-kernel@lists.infradead.org
> Cc: Yangbo Lu; linuxppc-dev@lists.ozlabs.org; Mark Rutland;
> devicetree@vger.kernel.org; ulf.hansson@linaro.org; Russell King; Bhupesh
> Sharma; netdev@vger.kernel.org; Joerg Roedel; Kumar Gala; linux-
> mmc@vger.kernel.org; linux-kernel@vger.kernel.org; Yang-Leo Li;
> iommu@lists.linux-foundation.org; Rob Herring; linux-i2c@vger.kernel.org;
> Claudiu Manoil; Santosh Shilimkar; Xiaobo Xie; linux-clk@vger.kernel.org;
> Qiang Zhao
> Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
> R1.0-R2.0
>
> On Thu, 2016-05-05 at 13:10 +0200, Arnd Bergmann wrote:
> > On Thursday 05 May 2016 09:41:32 Yangbo Lu wrote:
> > > > -----Original Message-----
> > > > From: Arnd Bergmann [mailto:arnd@arndb.de]
> > > > Sent: Thursday, May 05, 2016 4:32 PM
> > > > To: linuxppc-dev@lists.ozlabs.org
> > > > Cc: Yangbo Lu; linux-mmc@vger.kernel.org;
> > > > devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> > > > linux-kernel@vger.kernel.org; linux-clk@vger.kernel.org;
> > > > linux-i2c@vger.kernel.org; iommu@lists.linux- foundation.org;
> > > > netdev@vger.kernel.org; Mark Rutland; ulf.hansson@linaro.org;
> > > > Russell King; Bhupesh Sharma; Joerg Roedel; Santosh Shilimkar;
> > > > Yang-Leo Li; Scott Wood; Rob Herring; Claudiu Manoil; Kumar Gala;
> > > > Xiaobo Xie; Qiang Zhao
> > > > Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for
> > > > T4240-
> > > > R1.0-R2.0
> > > >
> > > > On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
> > > > > IIRC, it is the same IP block as i.MX and Arnd's point is this
> > > > > won't even compile on !PPC. It is things like this that prevent
> > > > > sharing the driver.
> > >
> > > The whole point of using the MMIO SVR instead of the PPC SPR is so
> > > that it will work on ARM... The guts driver should build on any
> > > platform as long as OF is enabled, and if it doesn't find a node to
> > > bind to it will return 0 for SVR, and the eSDHC driver will continue
> > > (after printing an error that should be removed) without the ability
> > > to test for errata based on SVR.
> >
> > It feels like a bad design to have to come up with a different method
> > for each SoC type here when they all do the same thing and want to
> > identify some variant of the chip to do device specific quirks.
> >
> > As far as I'm concerned, every driver in drivers/soc that needs to
> > export a symbol to be used by a device driver is an indication that we
> > don't have the right set of abstractions yet. There are cases that are
> > not worth abstracting because the functionality is rather obscure and
> > only a couple of drivers for one particular chip ever need it.
> >
> > Finding out the version of the SoC does not look like this case.
>
> I'm open to new ways of abstracting this, but can that please be
> discussed after these patches are merged? This patchset is fixing a
> problem, the existing abstraction is unappealing and not widely adopted,
> a new abstraction is not ready, and we're only touching code for our
> hardware.
>
> Oh, and the existing abstraction isn't even "existing". I don't see any
> examples where soc_device is being used like this -- or even any way for
> a driver (the one consuming the information, not the soc "driver") to get
> a reference to the soc_device that's been registered short of searching
> for the device object by name -- and you're asking for new functionality
> in drivers/base/soc.c.
>
> > > > I think the first four patches take care of building for ARM, but
> > > > the problem remains if you want to enable COMPILE_TEST as we need
> > > > for certain automated checking.
> > >
> > > What specific problem is there with COMPILE_TEST?
> >
> > COMPILE_TEST is solvable here and the way it is implemented in this
> > case (selecting FSL_GUTS from the driver) indeed looks like it works
> > correctly, but it's still awkward that this means building the SoC
> > specific ID stuff into the vmlinux binary for any driver that uses
> > something like that for a particular SoC.
>
> Please keep in mind that this is a Freescale-specific driver... it's not
> as if we're attaching this dependency to common SDHCI code.
>
> >
> > > > > Dealing with Si revs is a common problem. We should have a
> > > > > common solution. There is soc_device for this purpose.
> > > >
> > > > Exactly. The last time this came up, I think we agreed to
> > > > implement a helper using glob_match() on the soc_device strings.
> > > > Unfortunately this hasn't happened then, but I'd still prefer that
> > > > over yet another vendor-specific way of dealing with the generic
> issue.
> > >
> > > soc_device would require encoding the SVR as a string and then
> > > decoding the string, which is more complicated and error prone than
> > > having platform-specific code test a platform-specific number.
> >
> > You already need to encode it as a string to register the soc_device,
>
> No we don't, because we don't already register a soc_device on arm64 or
> ppc (and it looks like whatever does get registered on at least some
> relevant
> arm32 chips is not particularly useful).
>
> > and the driver just needs to pass a glob string, so the only part that
> > is missing is the generic function that takes the string from the
> > driver and passes that to glob_match for the soc_device.
>
> "just"
>
> And what would the glob look like?
>
> I'd rather not write kernel code as if it were a shell/Perl script.
>
> > > And when would it get registered on arm64, which doesn't have
> > > platform code?
> >
> > Whenever the soc driver is loaded, as is the case now. The match
> > function can return -EPROBE_DEFER if no SoC device is registered yet.
>
> That's too late for some places where we need access to SVR, e.g. clock
> drivers (which use CLK_OF_DECLARE and are initialized very early, not as
> part of the driver model and thus can't defer). Currently we have an
> #ifdef CONFIG_PPC for this in drivers/clk/clk-qoriq.c... Maybe we should
> have done that here as well, and saved some grief. :-) At least until an
> erratum pops up on an ARM-based chip.
>
> And what happens if we're running on arm32, and thus the arch code
> already registered an soc_device with a different (and less useful)
> encoding?
>
> -Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-20 6:05 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-20 6:05 UTC (permalink / raw)
To: Scott Wood, Arnd Bergmann,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Russell King, Bhupesh Sharma,
netdev-u79uwXL29TY76Z2rM5mHXA, Santosh Shilimkar,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Yang-Leo Li,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Rob Herring,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Claudiu Manoil, Kumar Gala,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Xiaobo Xie, Q
Hi Arnd,
Any comments?
Please reply when you see the email since we want this eSDHC issue to be fixed soon.
All the patches are Freescale-specific and is to fix the eSDHC driver.
Could we let them merged first if you were talking about a new way of abstracting getting SoC version.
Thanks :)
Best regards,
Yangbo Lu
> -----Original Message-----
> From: Scott Wood [mailto:oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org]
> Sent: Wednesday, May 11, 2016 11:26 AM
> To: Arnd Bergmann; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> Cc: Yangbo Lu; linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; Mark Rutland;
> devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org; Russell King; Bhupesh
> Sharma; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Joerg Roedel; Kumar Gala; linux-
> mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Yang-Leo Li;
> iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; Rob Herring; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> Claudiu Manoil; Santosh Shilimkar; Xiaobo Xie; linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> Qiang Zhao
> Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
> R1.0-R2.0
>
> On Thu, 2016-05-05 at 13:10 +0200, Arnd Bergmann wrote:
> > On Thursday 05 May 2016 09:41:32 Yangbo Lu wrote:
> > > > -----Original Message-----
> > > > From: Arnd Bergmann [mailto:arnd-r2nGTMty4D4@public.gmane.org]
> > > > Sent: Thursday, May 05, 2016 4:32 PM
> > > > To: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> > > > Cc: Yangbo Lu; linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > > > devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org;
> > > > linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > > > linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; iommu-cunTk1MwBs/ROKNJybVBZg@public.gmane.org foundation.org;
> > > > netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Mark Rutland; ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org;
> > > > Russell King; Bhupesh Sharma; Joerg Roedel; Santosh Shilimkar;
> > > > Yang-Leo Li; Scott Wood; Rob Herring; Claudiu Manoil; Kumar Gala;
> > > > Xiaobo Xie; Qiang Zhao
> > > > Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for
> > > > T4240-
> > > > R1.0-R2.0
> > > >
> > > > On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
> > > > > IIRC, it is the same IP block as i.MX and Arnd's point is this
> > > > > won't even compile on !PPC. It is things like this that prevent
> > > > > sharing the driver.
> > >
> > > The whole point of using the MMIO SVR instead of the PPC SPR is so
> > > that it will work on ARM... The guts driver should build on any
> > > platform as long as OF is enabled, and if it doesn't find a node to
> > > bind to it will return 0 for SVR, and the eSDHC driver will continue
> > > (after printing an error that should be removed) without the ability
> > > to test for errata based on SVR.
> >
> > It feels like a bad design to have to come up with a different method
> > for each SoC type here when they all do the same thing and want to
> > identify some variant of the chip to do device specific quirks.
> >
> > As far as I'm concerned, every driver in drivers/soc that needs to
> > export a symbol to be used by a device driver is an indication that we
> > don't have the right set of abstractions yet. There are cases that are
> > not worth abstracting because the functionality is rather obscure and
> > only a couple of drivers for one particular chip ever need it.
> >
> > Finding out the version of the SoC does not look like this case.
>
> I'm open to new ways of abstracting this, but can that please be
> discussed after these patches are merged? This patchset is fixing a
> problem, the existing abstraction is unappealing and not widely adopted,
> a new abstraction is not ready, and we're only touching code for our
> hardware.
>
> Oh, and the existing abstraction isn't even "existing". I don't see any
> examples where soc_device is being used like this -- or even any way for
> a driver (the one consuming the information, not the soc "driver") to get
> a reference to the soc_device that's been registered short of searching
> for the device object by name -- and you're asking for new functionality
> in drivers/base/soc.c.
>
> > > > I think the first four patches take care of building for ARM, but
> > > > the problem remains if you want to enable COMPILE_TEST as we need
> > > > for certain automated checking.
> > >
> > > What specific problem is there with COMPILE_TEST?
> >
> > COMPILE_TEST is solvable here and the way it is implemented in this
> > case (selecting FSL_GUTS from the driver) indeed looks like it works
> > correctly, but it's still awkward that this means building the SoC
> > specific ID stuff into the vmlinux binary for any driver that uses
> > something like that for a particular SoC.
>
> Please keep in mind that this is a Freescale-specific driver... it's not
> as if we're attaching this dependency to common SDHCI code.
>
> >
> > > > > Dealing with Si revs is a common problem. We should have a
> > > > > common solution. There is soc_device for this purpose.
> > > >
> > > > Exactly. The last time this came up, I think we agreed to
> > > > implement a helper using glob_match() on the soc_device strings.
> > > > Unfortunately this hasn't happened then, but I'd still prefer that
> > > > over yet another vendor-specific way of dealing with the generic
> issue.
> > >
> > > soc_device would require encoding the SVR as a string and then
> > > decoding the string, which is more complicated and error prone than
> > > having platform-specific code test a platform-specific number.
> >
> > You already need to encode it as a string to register the soc_device,
>
> No we don't, because we don't already register a soc_device on arm64 or
> ppc (and it looks like whatever does get registered on at least some
> relevant
> arm32 chips is not particularly useful).
>
> > and the driver just needs to pass a glob string, so the only part that
> > is missing is the generic function that takes the string from the
> > driver and passes that to glob_match for the soc_device.
>
> "just"
>
> And what would the glob look like?
>
> I'd rather not write kernel code as if it were a shell/Perl script.
>
> > > And when would it get registered on arm64, which doesn't have
> > > platform code?
> >
> > Whenever the soc driver is loaded, as is the case now. The match
> > function can return -EPROBE_DEFER if no SoC device is registered yet.
>
> That's too late for some places where we need access to SVR, e.g. clock
> drivers (which use CLK_OF_DECLARE and are initialized very early, not as
> part of the driver model and thus can't defer). Currently we have an
> #ifdef CONFIG_PPC for this in drivers/clk/clk-qoriq.c... Maybe we should
> have done that here as well, and saved some grief. :-) At least until an
> erratum pops up on an ARM-based chip.
>
> And what happens if we're running on arm32, and thus the arch code
> already registered an soc_device with a different (and less useful)
> encoding?
>
> -Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-20 6:05 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-20 6:05 UTC (permalink / raw)
To: Scott Wood, Arnd Bergmann,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Russell King, Bhupesh Sharma,
netdev-u79uwXL29TY76Z2rM5mHXA, Santosh Shilimkar,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Yang-Leo Li,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Rob Herring,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Claudiu Manoil, Kumar Gala,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Xiaobo Xie
Hi Arnd,
Any comments?
Please reply when you see the email since we want this eSDHC issue to be fixed soon.
All the patches are Freescale-specific and is to fix the eSDHC driver.
Could we let them merged first if you were talking about a new way of abstracting getting SoC version.
Thanks :)
Best regards,
Yangbo Lu
> -----Original Message-----
> From: Scott Wood [mailto:oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org]
> Sent: Wednesday, May 11, 2016 11:26 AM
> To: Arnd Bergmann; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> Cc: Yangbo Lu; linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; Mark Rutland;
> devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org; Russell King; Bhupesh
> Sharma; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Joerg Roedel; Kumar Gala; linux-
> mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Yang-Leo Li;
> iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; Rob Herring; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> Claudiu Manoil; Santosh Shilimkar; Xiaobo Xie; linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> Qiang Zhao
> Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
> R1.0-R2.0
>
> On Thu, 2016-05-05 at 13:10 +0200, Arnd Bergmann wrote:
> > On Thursday 05 May 2016 09:41:32 Yangbo Lu wrote:
> > > > -----Original Message-----
> > > > From: Arnd Bergmann [mailto:arnd-r2nGTMty4D4@public.gmane.org]
> > > > Sent: Thursday, May 05, 2016 4:32 PM
> > > > To: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> > > > Cc: Yangbo Lu; linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > > > devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org;
> > > > linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > > > linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; iommu-cunTk1MwBs/ROKNJybVBZg@public.gmane.org foundation.org;
> > > > netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Mark Rutland; ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org;
> > > > Russell King; Bhupesh Sharma; Joerg Roedel; Santosh Shilimkar;
> > > > Yang-Leo Li; Scott Wood; Rob Herring; Claudiu Manoil; Kumar Gala;
> > > > Xiaobo Xie; Qiang Zhao
> > > > Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for
> > > > T4240-
> > > > R1.0-R2.0
> > > >
> > > > On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
> > > > > IIRC, it is the same IP block as i.MX and Arnd's point is this
> > > > > won't even compile on !PPC. It is things like this that prevent
> > > > > sharing the driver.
> > >
> > > The whole point of using the MMIO SVR instead of the PPC SPR is so
> > > that it will work on ARM... The guts driver should build on any
> > > platform as long as OF is enabled, and if it doesn't find a node to
> > > bind to it will return 0 for SVR, and the eSDHC driver will continue
> > > (after printing an error that should be removed) without the ability
> > > to test for errata based on SVR.
> >
> > It feels like a bad design to have to come up with a different method
> > for each SoC type here when they all do the same thing and want to
> > identify some variant of the chip to do device specific quirks.
> >
> > As far as I'm concerned, every driver in drivers/soc that needs to
> > export a symbol to be used by a device driver is an indication that we
> > don't have the right set of abstractions yet. There are cases that are
> > not worth abstracting because the functionality is rather obscure and
> > only a couple of drivers for one particular chip ever need it.
> >
> > Finding out the version of the SoC does not look like this case.
>
> I'm open to new ways of abstracting this, but can that please be
> discussed after these patches are merged? This patchset is fixing a
> problem, the existing abstraction is unappealing and not widely adopted,
> a new abstraction is not ready, and we're only touching code for our
> hardware.
>
> Oh, and the existing abstraction isn't even "existing". I don't see any
> examples where soc_device is being used like this -- or even any way for
> a driver (the one consuming the information, not the soc "driver") to get
> a reference to the soc_device that's been registered short of searching
> for the device object by name -- and you're asking for new functionality
> in drivers/base/soc.c.
>
> > > > I think the first four patches take care of building for ARM, but
> > > > the problem remains if you want to enable COMPILE_TEST as we need
> > > > for certain automated checking.
> > >
> > > What specific problem is there with COMPILE_TEST?
> >
> > COMPILE_TEST is solvable here and the way it is implemented in this
> > case (selecting FSL_GUTS from the driver) indeed looks like it works
> > correctly, but it's still awkward that this means building the SoC
> > specific ID stuff into the vmlinux binary for any driver that uses
> > something like that for a particular SoC.
>
> Please keep in mind that this is a Freescale-specific driver... it's not
> as if we're attaching this dependency to common SDHCI code.
>
> >
> > > > > Dealing with Si revs is a common problem. We should have a
> > > > > common solution. There is soc_device for this purpose.
> > > >
> > > > Exactly. The last time this came up, I think we agreed to
> > > > implement a helper using glob_match() on the soc_device strings.
> > > > Unfortunately this hasn't happened then, but I'd still prefer that
> > > > over yet another vendor-specific way of dealing with the generic
> issue.
> > >
> > > soc_device would require encoding the SVR as a string and then
> > > decoding the string, which is more complicated and error prone than
> > > having platform-specific code test a platform-specific number.
> >
> > You already need to encode it as a string to register the soc_device,
>
> No we don't, because we don't already register a soc_device on arm64 or
> ppc (and it looks like whatever does get registered on at least some
> relevant
> arm32 chips is not particularly useful).
>
> > and the driver just needs to pass a glob string, so the only part that
> > is missing is the generic function that takes the string from the
> > driver and passes that to glob_match for the soc_device.
>
> "just"
>
> And what would the glob look like?
>
> I'd rather not write kernel code as if it were a shell/Perl script.
>
> > > And when would it get registered on arm64, which doesn't have
> > > platform code?
> >
> > Whenever the soc driver is loaded, as is the case now. The match
> > function can return -EPROBE_DEFER if no SoC device is registered yet.
>
> That's too late for some places where we need access to SVR, e.g. clock
> drivers (which use CLK_OF_DECLARE and are initialized very early, not as
> part of the driver model and thus can't defer). Currently we have an
> #ifdef CONFIG_PPC for this in drivers/clk/clk-qoriq.c... Maybe we should
> have done that here as well, and saved some grief. :-) At least until an
> erratum pops up on an ARM-based chip.
>
> And what happens if we're running on arm32, and thus the arch code
> already registered an soc_device with a different (and less useful)
> encoding?
>
> -Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-20 6:05 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-20 6:05 UTC (permalink / raw)
To: Scott Wood, Arnd Bergmann, linux-arm-kernel
Cc: Mark Rutland, devicetree, ulf.hansson, Russell King,
Bhupesh Sharma, netdev, Joerg Roedel, Santosh Shilimkar,
linux-mmc, linux-kernel, Yang-Leo Li, iommu, Rob Herring,
linux-i2c, Claudiu Manoil, Kumar Gala, linuxppc-dev, linux-clk,
Xiaobo Xie, Qiang Zhao
Hi Arnd,
Any comments?
Please reply when you see the email since we want this eSDHC issue to be fixed soon.
All the patches are Freescale-specific and is to fix the eSDHC driver.
Could we let them merged first if you were talking about a new way of abstracting getting SoC version.
Thanks :)
Best regards,
Yangbo Lu
> -----Original Message-----
> From: Scott Wood [mailto:oss@buserror.net]
> Sent: Wednesday, May 11, 2016 11:26 AM
> To: Arnd Bergmann; linux-arm-kernel@lists.infradead.org
> Cc: Yangbo Lu; linuxppc-dev@lists.ozlabs.org; Mark Rutland;
> devicetree@vger.kernel.org; ulf.hansson@linaro.org; Russell King; Bhupesh
> Sharma; netdev@vger.kernel.org; Joerg Roedel; Kumar Gala; linux-
> mmc@vger.kernel.org; linux-kernel@vger.kernel.org; Yang-Leo Li;
> iommu@lists.linux-foundation.org; Rob Herring; linux-i2c@vger.kernel.org;
> Claudiu Manoil; Santosh Shilimkar; Xiaobo Xie; linux-clk@vger.kernel.org;
> Qiang Zhao
> Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
> R1.0-R2.0
>
> On Thu, 2016-05-05 at 13:10 +0200, Arnd Bergmann wrote:
> > On Thursday 05 May 2016 09:41:32 Yangbo Lu wrote:
> > > > -----Original Message-----
> > > > From: Arnd Bergmann [mailto:arnd@arndb.de]
> > > > Sent: Thursday, May 05, 2016 4:32 PM
> > > > To: linuxppc-dev@lists.ozlabs.org
> > > > Cc: Yangbo Lu; linux-mmc@vger.kernel.org;
> > > > devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> > > > linux-kernel@vger.kernel.org; linux-clk@vger.kernel.org;
> > > > linux-i2c@vger.kernel.org; iommu@lists.linux- foundation.org;
> > > > netdev@vger.kernel.org; Mark Rutland; ulf.hansson@linaro.org;
> > > > Russell King; Bhupesh Sharma; Joerg Roedel; Santosh Shilimkar;
> > > > Yang-Leo Li; Scott Wood; Rob Herring; Claudiu Manoil; Kumar Gala;
> > > > Xiaobo Xie; Qiang Zhao
> > > > Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for
> > > > T4240-
> > > > R1.0-R2.0
> > > >
> > > > On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
> > > > > IIRC, it is the same IP block as i.MX and Arnd's point is this
> > > > > won't even compile on !PPC. It is things like this that prevent
> > > > > sharing the driver.
> > >
> > > The whole point of using the MMIO SVR instead of the PPC SPR is so
> > > that it will work on ARM... The guts driver should build on any
> > > platform as long as OF is enabled, and if it doesn't find a node to
> > > bind to it will return 0 for SVR, and the eSDHC driver will continue
> > > (after printing an error that should be removed) without the ability
> > > to test for errata based on SVR.
> >
> > It feels like a bad design to have to come up with a different method
> > for each SoC type here when they all do the same thing and want to
> > identify some variant of the chip to do device specific quirks.
> >
> > As far as I'm concerned, every driver in drivers/soc that needs to
> > export a symbol to be used by a device driver is an indication that we
> > don't have the right set of abstractions yet. There are cases that are
> > not worth abstracting because the functionality is rather obscure and
> > only a couple of drivers for one particular chip ever need it.
> >
> > Finding out the version of the SoC does not look like this case.
>
> I'm open to new ways of abstracting this, but can that please be
> discussed after these patches are merged? This patchset is fixing a
> problem, the existing abstraction is unappealing and not widely adopted,
> a new abstraction is not ready, and we're only touching code for our
> hardware.
>
> Oh, and the existing abstraction isn't even "existing". I don't see any
> examples where soc_device is being used like this -- or even any way for
> a driver (the one consuming the information, not the soc "driver") to get
> a reference to the soc_device that's been registered short of searching
> for the device object by name -- and you're asking for new functionality
> in drivers/base/soc.c.
>
> > > > I think the first four patches take care of building for ARM, but
> > > > the problem remains if you want to enable COMPILE_TEST as we need
> > > > for certain automated checking.
> > >
> > > What specific problem is there with COMPILE_TEST?
> >
> > COMPILE_TEST is solvable here and the way it is implemented in this
> > case (selecting FSL_GUTS from the driver) indeed looks like it works
> > correctly, but it's still awkward that this means building the SoC
> > specific ID stuff into the vmlinux binary for any driver that uses
> > something like that for a particular SoC.
>
> Please keep in mind that this is a Freescale-specific driver... it's not
> as if we're attaching this dependency to common SDHCI code.
>
> >
> > > > > Dealing with Si revs is a common problem. We should have a
> > > > > common solution. There is soc_device for this purpose.
> > > >
> > > > Exactly. The last time this came up, I think we agreed to
> > > > implement a helper using glob_match() on the soc_device strings.
> > > > Unfortunately this hasn't happened then, but I'd still prefer that
> > > > over yet another vendor-specific way of dealing with the generic
> issue.
> > >
> > > soc_device would require encoding the SVR as a string and then
> > > decoding the string, which is more complicated and error prone than
> > > having platform-specific code test a platform-specific number.
> >
> > You already need to encode it as a string to register the soc_device,
>
> No we don't, because we don't already register a soc_device on arm64 or
> ppc (and it looks like whatever does get registered on at least some
> relevant
> arm32 chips is not particularly useful).
>
> > and the driver just needs to pass a glob string, so the only part that
> > is missing is the generic function that takes the string from the
> > driver and passes that to glob_match for the soc_device.
>
> "just"
>
> And what would the glob look like?
>
> I'd rather not write kernel code as if it were a shell/Perl script.
>
> > > And when would it get registered on arm64, which doesn't have
> > > platform code?
> >
> > Whenever the soc driver is loaded, as is the case now. The match
> > function can return -EPROBE_DEFER if no SoC device is registered yet.
>
> That's too late for some places where we need access to SVR, e.g. clock
> drivers (which use CLK_OF_DECLARE and are initialized very early, not as
> part of the driver model and thus can't defer). Currently we have an
> #ifdef CONFIG_PPC for this in drivers/clk/clk-qoriq.c... Maybe we should
> have done that here as well, and saved some grief. :-) At least until an
> erratum pops up on an ARM-based chip.
>
> And what happens if we're running on arm32, and thus the arch code
> already registered an soc_device with a different (and less useful)
> encoding?
>
> -Scott
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-20 6:05 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-20 6:05 UTC (permalink / raw)
To: Scott Wood, Arnd Bergmann, linux-arm-kernel
Cc: linuxppc-dev, Mark Rutland, devicetree, ulf.hansson,
Russell King, Bhupesh Sharma, netdev, Joerg Roedel, Kumar Gala,
linux-mmc, linux-kernel, Yang-Leo Li, iommu, Rob Herring,
linux-i2c, Claudiu Manoil, Santosh Shilimkar, Xiaobo Xie,
linux-clk, Qiang Zhao
SGkgQXJuZCwNCg0KQW55IGNvbW1lbnRzPyANClBsZWFzZSByZXBseSB3aGVuIHlvdSBzZWUgdGhl
IGVtYWlsIHNpbmNlIHdlIHdhbnQgdGhpcyBlU0RIQyBpc3N1ZSB0byBiZSBmaXhlZCBzb29uLg0K
DQpBbGwgdGhlIHBhdGNoZXMgYXJlIEZyZWVzY2FsZS1zcGVjaWZpYyBhbmQgaXMgdG8gZml4IHRo
ZSBlU0RIQyBkcml2ZXIuDQpDb3VsZCB3ZSBsZXQgdGhlbSBtZXJnZWQgZmlyc3QgaWYgeW91IHdl
cmUgdGFsa2luZyBhYm91dCBhIG5ldyB3YXkgb2YgYWJzdHJhY3RpbmcgZ2V0dGluZyBTb0MgdmVy
c2lvbi4NCg0KDQpUaGFua3MgOikNCg0KDQpCZXN0IHJlZ2FyZHMsDQpZYW5nYm8gTHUNCg0KPiAt
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTY290dCBXb29kIFttYWlsdG86b3Nz
QGJ1c2Vycm9yLm5ldF0NCj4gU2VudDogV2VkbmVzZGF5LCBNYXkgMTEsIDIwMTYgMTE6MjYgQU0N
Cj4gVG86IEFybmQgQmVyZ21hbm47IGxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9y
Zw0KPiBDYzogWWFuZ2JvIEx1OyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsgTWFyayBS
dXRsYW5kOw0KPiBkZXZpY2V0cmVlQHZnZXIua2VybmVsLm9yZzsgdWxmLmhhbnNzb25AbGluYXJv
Lm9yZzsgUnVzc2VsbCBLaW5nOyBCaHVwZXNoDQo+IFNoYXJtYTsgbmV0ZGV2QHZnZXIua2VybmVs
Lm9yZzsgSm9lcmcgUm9lZGVsOyBLdW1hciBHYWxhOyBsaW51eC0NCj4gbW1jQHZnZXIua2VybmVs
Lm9yZzsgbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsgWWFuZy1MZW8gTGk7DQo+IGlvbW11
QGxpc3RzLmxpbnV4LWZvdW5kYXRpb24ub3JnOyBSb2IgSGVycmluZzsgbGludXgtaTJjQHZnZXIu
a2VybmVsLm9yZzsNCj4gQ2xhdWRpdSBNYW5vaWw7IFNhbnRvc2ggU2hpbGlta2FyOyBYaWFvYm8g
WGllOyBsaW51eC1jbGtAdmdlci5rZXJuZWwub3JnOw0KPiBRaWFuZyBaaGFvDQo+IFN1YmplY3Q6
IFJlOiBbdjEwLCA3LzddIG1tYzogc2RoY2ktb2YtZXNkaGM6IGZpeCBob3N0IHZlcnNpb24gZm9y
IFQ0MjQwLQ0KPiBSMS4wLVIyLjANCj4gDQo+IE9uIFRodSwgMjAxNi0wNS0wNSBhdCAxMzoxMCAr
MDIwMCwgQXJuZCBCZXJnbWFubiB3cm90ZToNCj4gPiBPbiBUaHVyc2RheSAwNSBNYXkgMjAxNiAw
OTo0MTozMiBZYW5nYm8gTHUgd3JvdGU6DQo+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQo+ID4gPiA+IEZyb206IEFybmQgQmVyZ21hbm4gW21haWx0bzphcm5kQGFybmRiLmRlXQ0K
PiA+ID4gPiBTZW50OiBUaHVyc2RheSwgTWF5IDA1LCAyMDE2IDQ6MzIgUE0NCj4gPiA+ID4gVG86
IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnDQo+ID4gPiA+IENjOiBZYW5nYm8gTHU7IGxp
bnV4LW1tY0B2Z2VyLmtlcm5lbC5vcmc7DQo+ID4gPiA+IGRldmljZXRyZWVAdmdlci5rZXJuZWwu
b3JnOyBsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmc7DQo+ID4gPiA+IGxpbnV4
LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LWNsa0B2Z2VyLmtlcm5lbC5vcmc7DQo+ID4g
PiA+IGxpbnV4LWkyY0B2Z2VyLmtlcm5lbC5vcmc7IGlvbW11QGxpc3RzLmxpbnV4LSBmb3VuZGF0
aW9uLm9yZzsNCj4gPiA+ID4gbmV0ZGV2QHZnZXIua2VybmVsLm9yZzsgTWFyayBSdXRsYW5kOyB1
bGYuaGFuc3NvbkBsaW5hcm8ub3JnOw0KPiA+ID4gPiBSdXNzZWxsIEtpbmc7IEJodXBlc2ggU2hh
cm1hOyBKb2VyZyBSb2VkZWw7IFNhbnRvc2ggU2hpbGlta2FyOw0KPiA+ID4gPiBZYW5nLUxlbyBM
aTsgU2NvdHQgV29vZDsgUm9iIEhlcnJpbmc7IENsYXVkaXUgTWFub2lsOyBLdW1hciBHYWxhOw0K
PiA+ID4gPiBYaWFvYm8gWGllOyBRaWFuZyBaaGFvDQo+ID4gPiA+IFN1YmplY3Q6IFJlOiBbdjEw
LCA3LzddIG1tYzogc2RoY2ktb2YtZXNkaGM6IGZpeCBob3N0IHZlcnNpb24gZm9yDQo+ID4gPiA+
IFQ0MjQwLQ0KPiA+ID4gPiBSMS4wLVIyLjANCj4gPiA+ID4NCj4gPiA+ID4gT24gVGh1cnNkYXkg
MDUgTWF5IDIwMTYgMTE6MTI6MzAgWWFuZ2JvIEx1IHdyb3RlOg0KPiA+ID4gPiA+IElJUkMsIGl0
IGlzIHRoZSBzYW1lIElQIGJsb2NrIGFzIGkuTVggYW5kIEFybmQncyBwb2ludCBpcyB0aGlzDQo+
ID4gPiA+ID4gd29uJ3QgZXZlbiBjb21waWxlIG9uICFQUEMuIEl0IGlzIHRoaW5ncyBsaWtlIHRo
aXMgdGhhdCBwcmV2ZW50DQo+ID4gPiA+ID4gc2hhcmluZyB0aGUgZHJpdmVyLg0KPiA+ID4NCj4g
PiA+IFRoZSB3aG9sZSBwb2ludCBvZiB1c2luZyB0aGUgTU1JTyBTVlIgaW5zdGVhZCBvZiB0aGUg
UFBDIFNQUiBpcyBzbw0KPiA+ID4gdGhhdCBpdCB3aWxsIHdvcmsgb24gQVJNLi4uICBUaGUgZ3V0
cyBkcml2ZXIgc2hvdWxkIGJ1aWxkIG9uIGFueQ0KPiA+ID4gcGxhdGZvcm0gYXMgbG9uZyBhcyBP
RiBpcyBlbmFibGVkLCBhbmQgaWYgaXQgZG9lc24ndCBmaW5kIGEgbm9kZSB0bw0KPiA+ID4gYmlu
ZCB0byBpdCB3aWxsIHJldHVybiAwIGZvciBTVlIsIGFuZCB0aGUgZVNESEMgZHJpdmVyIHdpbGwg
Y29udGludWUNCj4gPiA+IChhZnRlciBwcmludGluZyBhbiBlcnJvciB0aGF0IHNob3VsZCBiZSBy
ZW1vdmVkKSB3aXRob3V0IHRoZSBhYmlsaXR5DQo+ID4gPiB0byB0ZXN0IGZvciBlcnJhdGEgYmFz
ZWQgb24gU1ZSLg0KPiA+DQo+ID4gSXQgZmVlbHMgbGlrZSBhIGJhZCBkZXNpZ24gdG8gaGF2ZSB0
byBjb21lIHVwIHdpdGggYSBkaWZmZXJlbnQgbWV0aG9kDQo+ID4gZm9yIGVhY2ggU29DIHR5cGUg
aGVyZSB3aGVuIHRoZXkgYWxsIGRvIHRoZSBzYW1lIHRoaW5nIGFuZCB3YW50IHRvDQo+ID4gaWRl
bnRpZnkgc29tZSB2YXJpYW50IG9mIHRoZSBjaGlwIHRvIGRvIGRldmljZSBzcGVjaWZpYyBxdWly
a3MuDQo+ID4NCj4gPiBBcyBmYXIgYXMgSSdtIGNvbmNlcm5lZCwgZXZlcnkgZHJpdmVyIGluIGRy
aXZlcnMvc29jIHRoYXQgbmVlZHMgdG8NCj4gPiBleHBvcnQgYSBzeW1ib2wgdG8gYmUgdXNlZCBi
eSBhIGRldmljZSBkcml2ZXIgaXMgYW4gaW5kaWNhdGlvbiB0aGF0IHdlDQo+ID4gZG9uJ3QgaGF2
ZSB0aGUgcmlnaHQgc2V0IG9mIGFic3RyYWN0aW9ucyB5ZXQuIFRoZXJlIGFyZSBjYXNlcyB0aGF0
IGFyZQ0KPiA+IG5vdCB3b3J0aCBhYnN0cmFjdGluZyBiZWNhdXNlIHRoZSBmdW5jdGlvbmFsaXR5
IGlzIHJhdGhlciBvYnNjdXJlIGFuZA0KPiA+IG9ubHkgYSBjb3VwbGUgb2YgZHJpdmVycyBmb3Ig
b25lIHBhcnRpY3VsYXIgY2hpcCBldmVyIG5lZWQgaXQuDQo+ID4NCj4gPiBGaW5kaW5nIG91dCB0
aGUgdmVyc2lvbiBvZiB0aGUgU29DIGRvZXMgbm90IGxvb2sgbGlrZSB0aGlzIGNhc2UuDQo+IA0K
PiBJJ20gb3BlbiB0byBuZXcgd2F5cyBvZiBhYnN0cmFjdGluZyB0aGlzLCBidXQgY2FuIHRoYXQg
cGxlYXNlIGJlDQo+IGRpc2N1c3NlZCBhZnRlciB0aGVzZSBwYXRjaGVzIGFyZSBtZXJnZWQ/ICBU
aGlzIHBhdGNoc2V0IGlzIGZpeGluZyBhDQo+IHByb2JsZW0sIHRoZSBleGlzdGluZyBhYnN0cmFj
dGlvbiBpcyB1bmFwcGVhbGluZyBhbmQgbm90IHdpZGVseSBhZG9wdGVkLA0KPiBhIG5ldyBhYnN0
cmFjdGlvbiBpcyBub3QgcmVhZHksIGFuZCB3ZSdyZSBvbmx5IHRvdWNoaW5nIGNvZGUgZm9yIG91
cg0KPiBoYXJkd2FyZS4NCj4gDQo+IE9oLCBhbmQgdGhlIGV4aXN0aW5nIGFic3RyYWN0aW9uIGlz
bid0IGV2ZW4gImV4aXN0aW5nIi4gIEkgZG9uJ3Qgc2VlIGFueQ0KPiBleGFtcGxlcyB3aGVyZSBz
b2NfZGV2aWNlIGlzIGJlaW5nIHVzZWQgbGlrZSB0aGlzIC0tIG9yIGV2ZW4gYW55IHdheSBmb3IN
Cj4gYSBkcml2ZXIgKHRoZSBvbmUgY29uc3VtaW5nIHRoZSBpbmZvcm1hdGlvbiwgbm90IHRoZSBz
b2MgImRyaXZlciIpIHRvIGdldA0KPiBhIHJlZmVyZW5jZSB0byB0aGUgc29jX2RldmljZSB0aGF0
J3MgYmVlbiByZWdpc3RlcmVkIHNob3J0IG9mIHNlYXJjaGluZw0KPiBmb3IgdGhlIGRldmljZSBv
YmplY3QgYnkgbmFtZSAtLSBhbmQgeW91J3JlIGFza2luZyBmb3IgbmV3IGZ1bmN0aW9uYWxpdHkN
Cj4gaW4gZHJpdmVycy9iYXNlL3NvYy5jLg0KPiANCj4gPiA+ID4gSSB0aGluayB0aGUgZmlyc3Qg
Zm91ciBwYXRjaGVzIHRha2UgY2FyZSBvZiBidWlsZGluZyBmb3IgQVJNLCBidXQNCj4gPiA+ID4g
dGhlIHByb2JsZW0gcmVtYWlucyBpZiB5b3Ugd2FudCB0byBlbmFibGUgQ09NUElMRV9URVNUIGFz
IHdlIG5lZWQNCj4gPiA+ID4gZm9yIGNlcnRhaW4gYXV0b21hdGVkIGNoZWNraW5nLg0KPiA+ID4N
Cj4gPiA+IFdoYXQgc3BlY2lmaWMgcHJvYmxlbSBpcyB0aGVyZSB3aXRoIENPTVBJTEVfVEVTVD8N
Cj4gPg0KPiA+IENPTVBJTEVfVEVTVCBpcyBzb2x2YWJsZSBoZXJlIGFuZCB0aGUgd2F5IGl0IGlz
IGltcGxlbWVudGVkIGluIHRoaXMNCj4gPiBjYXNlIChzZWxlY3RpbmcgRlNMX0dVVFMgZnJvbSB0
aGUgZHJpdmVyKSBpbmRlZWQgbG9va3MgbGlrZSBpdCB3b3Jrcw0KPiA+IGNvcnJlY3RseSwgYnV0
IGl0J3Mgc3RpbGwgYXdrd2FyZCB0aGF0IHRoaXMgbWVhbnMgYnVpbGRpbmcgdGhlIFNvQw0KPiA+
IHNwZWNpZmljIElEIHN0dWZmIGludG8gdGhlIHZtbGludXggYmluYXJ5IGZvciBhbnkgZHJpdmVy
IHRoYXQgdXNlcw0KPiA+IHNvbWV0aGluZyBsaWtlIHRoYXQgZm9yIGEgcGFydGljdWxhciBTb0Mu
DQo+IA0KPiBQbGVhc2Uga2VlcCBpbiBtaW5kIHRoYXQgdGhpcyBpcyBhIEZyZWVzY2FsZS1zcGVj
aWZpYyBkcml2ZXIuLi4gaXQncyBub3QNCj4gYXMgaWYgd2UncmUgYXR0YWNoaW5nIHRoaXMgZGVw
ZW5kZW5jeSB0byBjb21tb24gU0RIQ0kgY29kZS4NCj4gDQo+ID4NCj4gPiA+ID4gPiBEZWFsaW5n
IHdpdGggU2kgcmV2cyBpcyBhIGNvbW1vbiBwcm9ibGVtLiBXZSBzaG91bGQgaGF2ZSBhDQo+ID4g
PiA+ID4gY29tbW9uIHNvbHV0aW9uLiBUaGVyZSBpcyBzb2NfZGV2aWNlIGZvciB0aGlzIHB1cnBv
c2UuDQo+ID4gPiA+DQo+ID4gPiA+IEV4YWN0bHkuIFRoZSBsYXN0IHRpbWUgdGhpcyBjYW1lIHVw
LCBJIHRoaW5rIHdlIGFncmVlZCB0bw0KPiA+ID4gPiBpbXBsZW1lbnQgYSBoZWxwZXIgdXNpbmcg
Z2xvYl9tYXRjaCgpIG9uIHRoZSBzb2NfZGV2aWNlIHN0cmluZ3MuDQo+ID4gPiA+IFVuZm9ydHVu
YXRlbHkgdGhpcyBoYXNuJ3QgaGFwcGVuZWQgdGhlbiwgYnV0IEknZCBzdGlsbCBwcmVmZXIgdGhh
dA0KPiA+ID4gPiBvdmVyIHlldCBhbm90aGVyIHZlbmRvci1zcGVjaWZpYyB3YXkgb2YgZGVhbGlu
ZyB3aXRoIHRoZSBnZW5lcmljDQo+IGlzc3VlLg0KPiA+ID4NCj4gPiA+IHNvY19kZXZpY2Ugd291
bGQgcmVxdWlyZSBlbmNvZGluZyB0aGUgU1ZSIGFzIGEgc3RyaW5nIGFuZCB0aGVuDQo+ID4gPiBk
ZWNvZGluZyB0aGUgc3RyaW5nLCB3aGljaCBpcyBtb3JlIGNvbXBsaWNhdGVkIGFuZCBlcnJvciBw
cm9uZSB0aGFuDQo+ID4gPiBoYXZpbmcgcGxhdGZvcm0tc3BlY2lmaWMgY29kZSB0ZXN0IGEgcGxh
dGZvcm0tc3BlY2lmaWMgbnVtYmVyLg0KPiA+DQo+ID4gWW91IGFscmVhZHkgbmVlZCB0byBlbmNv
ZGUgaXQgYXMgYSBzdHJpbmcgdG8gcmVnaXN0ZXIgdGhlIHNvY19kZXZpY2UsDQo+IA0KPiBObyB3
ZSBkb24ndCwgYmVjYXVzZSB3ZSBkb24ndCBhbHJlYWR5IHJlZ2lzdGVyIGEgc29jX2RldmljZSBv
biBhcm02NCBvcg0KPiBwcGMgKGFuZCBpdCBsb29rcyBsaWtlIHdoYXRldmVyIGRvZXMgZ2V0IHJl
Z2lzdGVyZWQgb24gYXQgbGVhc3Qgc29tZQ0KPiByZWxldmFudA0KPiBhcm0zMiBjaGlwcyBpcyBu
b3QgcGFydGljdWxhcmx5IHVzZWZ1bCkuDQo+IA0KPiA+IGFuZCB0aGUgZHJpdmVyIGp1c3QgbmVl
ZHMgdG8gcGFzcyBhIGdsb2Igc3RyaW5nLCBzbyB0aGUgb25seSBwYXJ0IHRoYXQNCj4gPiBpcyBt
aXNzaW5nIGlzIHRoZSBnZW5lcmljIGZ1bmN0aW9uIHRoYXQgdGFrZXMgdGhlIHN0cmluZyBmcm9t
IHRoZQ0KPiA+IGRyaXZlciBhbmQgcGFzc2VzIHRoYXQgdG8gZ2xvYl9tYXRjaCBmb3IgdGhlIHNv
Y19kZXZpY2UuDQo+IA0KPiAianVzdCINCj4gDQo+IEFuZCB3aGF0IHdvdWxkIHRoZSBnbG9iIGxv
b2sgbGlrZT8NCj4gDQo+IEknZCByYXRoZXIgbm90IHdyaXRlIGtlcm5lbCBjb2RlIGFzIGlmIGl0
IHdlcmUgYSBzaGVsbC9QZXJsIHNjcmlwdC4NCj4gDQo+ID4gPiBBbmQgd2hlbiB3b3VsZCBpdCBn
ZXQgcmVnaXN0ZXJlZCBvbiBhcm02NCwgd2hpY2ggZG9lc24ndCBoYXZlDQo+ID4gPiBwbGF0Zm9y
bSBjb2RlPw0KPiA+DQo+ID4gV2hlbmV2ZXIgdGhlIHNvYyBkcml2ZXIgaXMgbG9hZGVkLCBhcyBp
cyB0aGUgY2FzZSBub3cuIFRoZSBtYXRjaA0KPiA+IGZ1bmN0aW9uIGNhbiByZXR1cm4gLUVQUk9C
RV9ERUZFUiBpZiBubyBTb0MgZGV2aWNlIGlzIHJlZ2lzdGVyZWQgeWV0Lg0KPiANCj4gVGhhdCdz
IHRvbyBsYXRlIGZvciBzb21lIHBsYWNlcyB3aGVyZSB3ZSBuZWVkIGFjY2VzcyB0byBTVlIsIGUu
Zy4gY2xvY2sNCj4gZHJpdmVycyAod2hpY2ggdXNlIENMS19PRl9ERUNMQVJFIGFuZCBhcmUgaW5p
dGlhbGl6ZWQgdmVyeSBlYXJseSwgbm90IGFzDQo+IHBhcnQgb2YgdGhlIGRyaXZlciBtb2RlbCBh
bmQgdGh1cyBjYW4ndCBkZWZlcikuICBDdXJyZW50bHkgd2UgaGF2ZSBhbg0KPiAjaWZkZWYgQ09O
RklHX1BQQyBmb3IgdGhpcyBpbiBkcml2ZXJzL2Nsay9jbGstcW9yaXEuYy4uLiBNYXliZSB3ZSBz
aG91bGQNCj4gaGF2ZSBkb25lIHRoYXQgaGVyZSBhcyB3ZWxsLCBhbmQgc2F2ZWQgc29tZSBncmll
Zi4gOi0pICBBdCBsZWFzdCB1bnRpbCBhbg0KPiBlcnJhdHVtIHBvcHMgdXAgb24gYW4gQVJNLWJh
c2VkIGNoaXAuDQo+IA0KPiBBbmQgd2hhdCBoYXBwZW5zIGlmIHdlJ3JlIHJ1bm5pbmcgb24gYXJt
MzIsIGFuZCB0aHVzIHRoZSBhcmNoIGNvZGUNCj4gYWxyZWFkeSByZWdpc3RlcmVkIGFuIHNvY19k
ZXZpY2Ugd2l0aCBhIGRpZmZlcmVudCAoYW5kIGxlc3MgdXNlZnVsKQ0KPiBlbmNvZGluZz8NCj4g
DQo+IC1TY290dA0KDQo=
^ permalink raw reply [flat|nested] 185+ messages in thread
* [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-20 6:05 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-20 6:05 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
Any comments?
Please reply when you see the email since we want this eSDHC issue to be fixed soon.
All the patches are Freescale-specific and is to fix the eSDHC driver.
Could we let them merged first if you were talking about a new way of abstracting getting SoC version.
Thanks :)
Best regards,
Yangbo Lu
> -----Original Message-----
> From: Scott Wood [mailto:oss at buserror.net]
> Sent: Wednesday, May 11, 2016 11:26 AM
> To: Arnd Bergmann; linux-arm-kernel at lists.infradead.org
> Cc: Yangbo Lu; linuxppc-dev at lists.ozlabs.org; Mark Rutland;
> devicetree at vger.kernel.org; ulf.hansson at linaro.org; Russell King; Bhupesh
> Sharma; netdev at vger.kernel.org; Joerg Roedel; Kumar Gala; linux-
> mmc at vger.kernel.org; linux-kernel at vger.kernel.org; Yang-Leo Li;
> iommu at lists.linux-foundation.org; Rob Herring; linux-i2c at vger.kernel.org;
> Claudiu Manoil; Santosh Shilimkar; Xiaobo Xie; linux-clk at vger.kernel.org;
> Qiang Zhao
> Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
> R1.0-R2.0
>
> On Thu, 2016-05-05 at 13:10 +0200, Arnd Bergmann wrote:
> > On Thursday 05 May 2016 09:41:32 Yangbo Lu wrote:
> > > > -----Original Message-----
> > > > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > > > Sent: Thursday, May 05, 2016 4:32 PM
> > > > To: linuxppc-dev at lists.ozlabs.org
> > > > Cc: Yangbo Lu; linux-mmc at vger.kernel.org;
> > > > devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> > > > linux-kernel at vger.kernel.org; linux-clk at vger.kernel.org;
> > > > linux-i2c at vger.kernel.org; iommu at lists.linux- foundation.org;
> > > > netdev at vger.kernel.org; Mark Rutland; ulf.hansson at linaro.org;
> > > > Russell King; Bhupesh Sharma; Joerg Roedel; Santosh Shilimkar;
> > > > Yang-Leo Li; Scott Wood; Rob Herring; Claudiu Manoil; Kumar Gala;
> > > > Xiaobo Xie; Qiang Zhao
> > > > Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for
> > > > T4240-
> > > > R1.0-R2.0
> > > >
> > > > On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
> > > > > IIRC, it is the same IP block as i.MX and Arnd's point is this
> > > > > won't even compile on !PPC. It is things like this that prevent
> > > > > sharing the driver.
> > >
> > > The whole point of using the MMIO SVR instead of the PPC SPR is so
> > > that it will work on ARM... The guts driver should build on any
> > > platform as long as OF is enabled, and if it doesn't find a node to
> > > bind to it will return 0 for SVR, and the eSDHC driver will continue
> > > (after printing an error that should be removed) without the ability
> > > to test for errata based on SVR.
> >
> > It feels like a bad design to have to come up with a different method
> > for each SoC type here when they all do the same thing and want to
> > identify some variant of the chip to do device specific quirks.
> >
> > As far as I'm concerned, every driver in drivers/soc that needs to
> > export a symbol to be used by a device driver is an indication that we
> > don't have the right set of abstractions yet. There are cases that are
> > not worth abstracting because the functionality is rather obscure and
> > only a couple of drivers for one particular chip ever need it.
> >
> > Finding out the version of the SoC does not look like this case.
>
> I'm open to new ways of abstracting this, but can that please be
> discussed after these patches are merged? This patchset is fixing a
> problem, the existing abstraction is unappealing and not widely adopted,
> a new abstraction is not ready, and we're only touching code for our
> hardware.
>
> Oh, and the existing abstraction isn't even "existing". I don't see any
> examples where soc_device is being used like this -- or even any way for
> a driver (the one consuming the information, not the soc "driver") to get
> a reference to the soc_device that's been registered short of searching
> for the device object by name -- and you're asking for new functionality
> in drivers/base/soc.c.
>
> > > > I think the first four patches take care of building for ARM, but
> > > > the problem remains if you want to enable COMPILE_TEST as we need
> > > > for certain automated checking.
> > >
> > > What specific problem is there with COMPILE_TEST?
> >
> > COMPILE_TEST is solvable here and the way it is implemented in this
> > case (selecting FSL_GUTS from the driver) indeed looks like it works
> > correctly, but it's still awkward that this means building the SoC
> > specific ID stuff into the vmlinux binary for any driver that uses
> > something like that for a particular SoC.
>
> Please keep in mind that this is a Freescale-specific driver... it's not
> as if we're attaching this dependency to common SDHCI code.
>
> >
> > > > > Dealing with Si revs is a common problem. We should have a
> > > > > common solution. There is soc_device for this purpose.
> > > >
> > > > Exactly. The last time this came up, I think we agreed to
> > > > implement a helper using glob_match() on the soc_device strings.
> > > > Unfortunately this hasn't happened then, but I'd still prefer that
> > > > over yet another vendor-specific way of dealing with the generic
> issue.
> > >
> > > soc_device would require encoding the SVR as a string and then
> > > decoding the string, which is more complicated and error prone than
> > > having platform-specific code test a platform-specific number.
> >
> > You already need to encode it as a string to register the soc_device,
>
> No we don't, because we don't already register a soc_device on arm64 or
> ppc (and it looks like whatever does get registered on at least some
> relevant
> arm32 chips is not particularly useful).
>
> > and the driver just needs to pass a glob string, so the only part that
> > is missing is the generic function that takes the string from the
> > driver and passes that to glob_match for the soc_device.
>
> "just"
>
> And what would the glob look like?
>
> I'd rather not write kernel code as if it were a shell/Perl script.
>
> > > And when would it get registered on arm64, which doesn't have
> > > platform code?
> >
> > Whenever the soc driver is loaded, as is the case now. The match
> > function can return -EPROBE_DEFER if no SoC device is registered yet.
>
> That's too late for some places where we need access to SVR, e.g. clock
> drivers (which use CLK_OF_DECLARE and are initialized very early, not as
> part of the driver model and thus can't defer). Currently we have an
> #ifdef CONFIG_PPC for this in drivers/clk/clk-qoriq.c... Maybe we should
> have done that here as well, and saved some grief. :-) At least until an
> erratum pops up on an ARM-based chip.
>
> And what happens if we're running on arm32, and thus the arch code
> already registered an soc_device with a different (and less useful)
> encoding?
>
> -Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
2016-05-11 3:26 ` Scott Wood
` (2 preceding siblings ...)
(?)
@ 2016-05-26 4:05 ` Yangbo Lu
-1 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-26 4:05 UTC (permalink / raw)
To: ulf.hansson, Scott Wood, Arnd Bergmann, linux-arm-kernel
Cc: linuxppc-dev, Mark Rutland, devicetree, Russell King,
Bhupesh Sharma, netdev, Joerg Roedel, Kumar Gala, linux-mmc,
linux-kernel, Yang-Leo Li, iommu, Rob Herring, linux-i2c,
Claudiu Manoil, Santosh Shilimkar, Xiaobo Xie, linux-clk,
Qiang Zhao
Hi Uffe,
Could we merge this patchset? ...
It has been a long time to wait for Arnd's response...
Thanks a lot.
Best regards,
Yangbo Lu
> -----Original Message-----
> From: Yangbo Lu
> Sent: Friday, May 20, 2016 2:06 PM
> To: 'Scott Wood'; Arnd Bergmann; linux-arm-kernel@lists.infradead.org
> Cc: linuxppc-dev@lists.ozlabs.org; Mark Rutland;
> devicetree@vger.kernel.org; ulf.hansson@linaro.org; Russell King; Bhupesh
> Sharma; netdev@vger.kernel.org; Joerg Roedel; Kumar Gala; linux-
> mmc@vger.kernel.org; linux-kernel@vger.kernel.org; Yang-Leo Li;
> iommu@lists.linux-foundation.org; Rob Herring; linux-i2c@vger.kernel.org;
> Claudiu Manoil; Santosh Shilimkar; Xiaobo Xie; linux-clk@vger.kernel.org;
> Qiang Zhao
> Subject: RE: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
> R1.0-R2.0
>
> Hi Arnd,
>
> Any comments?
> Please reply when you see the email since we want this eSDHC issue to be
> fixed soon.
>
> All the patches are Freescale-specific and is to fix the eSDHC driver.
> Could we let them merged first if you were talking about a new way of
> abstracting getting SoC version.
>
>
> Thanks :)
>
>
> Best regards,
> Yangbo Lu
>
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-26 4:05 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-26 4:05 UTC (permalink / raw)
To: ulf.hansson, Scott Wood, Arnd Bergmann, linux-arm-kernel
Cc: linuxppc-dev, Mark Rutland, devicetree, Russell King,
Bhupesh Sharma, netdev, Joerg Roedel, Kumar Gala, linux-mmc,
linux-kernel, Yang-Leo Li, iommu, Rob Herring, linux-i2c,
Claudiu Manoil, Santosh Shilimkar, Xiaobo Xie, linux-clk,
Qiang Zhao
Hi Uffe,
Could we merge this patchset? ...
It has been a long time to wait for Arnd's response...
Thanks a lot.
Best regards,
Yangbo Lu
> -----Original Message-----
> From: Yangbo Lu
> Sent: Friday, May 20, 2016 2:06 PM
> To: 'Scott Wood'; Arnd Bergmann; linux-arm-kernel@lists.infradead.org
> Cc: linuxppc-dev@lists.ozlabs.org; Mark Rutland;
> devicetree@vger.kernel.org; ulf.hansson@linaro.org; Russell King; Bhupesh
> Sharma; netdev@vger.kernel.org; Joerg Roedel; Kumar Gala; linux-
> mmc@vger.kernel.org; linux-kernel@vger.kernel.org; Yang-Leo Li;
> iommu@lists.linux-foundation.org; Rob Herring; linux-i2c@vger.kernel.org;
> Claudiu Manoil; Santosh Shilimkar; Xiaobo Xie; linux-clk@vger.kernel.org;
> Qiang Zhao
> Subject: RE: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
> R1.0-R2.0
>
> Hi Arnd,
>
> Any comments?
> Please reply when you see the email since we want this eSDHC issue to be
> fixed soon.
>
> All the patches are Freescale-specific and is to fix the eSDHC driver.
> Could we let them merged first if you were talking about a new way of
> abstracting getting SoC version.
>
>
> Thanks :)
>
>
> Best regards,
> Yangbo Lu
>
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-26 4:05 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-26 4:05 UTC (permalink / raw)
To: ulf.hansson, Scott Wood, Arnd Bergmann, linux-arm-kernel
Cc: linuxppc-dev, Mark Rutland, devicetree, Russell King,
Bhupesh Sharma, netdev, Joerg Roedel, Kumar Gala, linux-mmc,
linux-kernel, Yang-Leo Li, iommu, Rob Herring, linux-i2c,
Claudiu Manoil, Santosh Shilimkar, Xiaobo Xie, linux-clk,
Qiang Zhao
Hi Uffe,
Could we merge this patchset? ...
It has been a long time to wait for Arnd's response...
Thanks a lot.
Best regards,
Yangbo Lu
> -----Original Message-----
> From: Yangbo Lu
> Sent: Friday, May 20, 2016 2:06 PM
> To: 'Scott Wood'; Arnd Bergmann; linux-arm-kernel@lists.infradead.org
> Cc: linuxppc-dev@lists.ozlabs.org; Mark Rutland;
> devicetree@vger.kernel.org; ulf.hansson@linaro.org; Russell King; Bhupesh
> Sharma; netdev@vger.kernel.org; Joerg Roedel; Kumar Gala; linux-
> mmc@vger.kernel.org; linux-kernel@vger.kernel.org; Yang-Leo Li;
> iommu@lists.linux-foundation.org; Rob Herring; linux-i2c@vger.kernel.org;
> Claudiu Manoil; Santosh Shilimkar; Xiaobo Xie; linux-clk@vger.kernel.org;
> Qiang Zhao
> Subject: RE: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
> R1.0-R2.0
>
> Hi Arnd,
>
> Any comments?
> Please reply when you see the email since we want this eSDHC issue to be
> fixed soon.
>
> All the patches are Freescale-specific and is to fix the eSDHC driver.
> Could we let them merged first if you were talking about a new way of
> abstracting getting SoC version.
>
>
> Thanks :)
>
>
> Best regards,
> Yangbo Lu
>
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-26 4:05 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-26 4:05 UTC (permalink / raw)
To: ulf.hansson, Scott Wood, Arnd Bergmann, linux-arm-kernel
Cc: linuxppc-dev, Mark Rutland, devicetree, Russell King,
Bhupesh Sharma, netdev, Joerg Roedel, Kumar Gala, linux-mmc,
linux-kernel, Yang-Leo Li, iommu, Rob Herring, linux-i2c,
Claudiu Manoil, Santosh Shilimkar, Xiaobo Xie, linux-clk,
Qiang Zhao
SGkgVWZmZSwNCg0KQ291bGQgd2UgbWVyZ2UgdGhpcyBwYXRjaHNldD8gLi4uDQpJdCBoYXMgYmVl
biBhIGxvbmcgdGltZSB0byB3YWl0IGZvciBBcm5kJ3MgcmVzcG9uc2UuLi4NCiANClRoYW5rcyBh
IGxvdC4NCg0KDQpCZXN0IHJlZ2FyZHMsDQpZYW5nYm8gTHUNCg0KDQo+IC0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQo+IEZyb206IFlhbmdibyBMdQ0KPiBTZW50OiBGcmlkYXksIE1heSAyMCwg
MjAxNiAyOjA2IFBNDQo+IFRvOiAnU2NvdHQgV29vZCc7IEFybmQgQmVyZ21hbm47IGxpbnV4LWFy
bS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZw0KPiBDYzogbGludXhwcGMtZGV2QGxpc3RzLm96
bGFicy5vcmc7IE1hcmsgUnV0bGFuZDsNCj4gZGV2aWNldHJlZUB2Z2VyLmtlcm5lbC5vcmc7IHVs
Zi5oYW5zc29uQGxpbmFyby5vcmc7IFJ1c3NlbGwgS2luZzsgQmh1cGVzaA0KPiBTaGFybWE7IG5l
dGRldkB2Z2VyLmtlcm5lbC5vcmc7IEpvZXJnIFJvZWRlbDsgS3VtYXIgR2FsYTsgbGludXgtDQo+
IG1tY0B2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IFlhbmct
TGVvIExpOw0KPiBpb21tdUBsaXN0cy5saW51eC1mb3VuZGF0aW9uLm9yZzsgUm9iIEhlcnJpbmc7
IGxpbnV4LWkyY0B2Z2VyLmtlcm5lbC5vcmc7DQo+IENsYXVkaXUgTWFub2lsOyBTYW50b3NoIFNo
aWxpbWthcjsgWGlhb2JvIFhpZTsgbGludXgtY2xrQHZnZXIua2VybmVsLm9yZzsNCj4gUWlhbmcg
Wmhhbw0KPiBTdWJqZWN0OiBSRTogW3YxMCwgNy83XSBtbWM6IHNkaGNpLW9mLWVzZGhjOiBmaXgg
aG9zdCB2ZXJzaW9uIGZvciBUNDI0MC0NCj4gUjEuMC1SMi4wDQo+IA0KPiBIaSBBcm5kLA0KPiAN
Cj4gQW55IGNvbW1lbnRzPw0KPiBQbGVhc2UgcmVwbHkgd2hlbiB5b3Ugc2VlIHRoZSBlbWFpbCBz
aW5jZSB3ZSB3YW50IHRoaXMgZVNESEMgaXNzdWUgdG8gYmUNCj4gZml4ZWQgc29vbi4NCj4gDQo+
IEFsbCB0aGUgcGF0Y2hlcyBhcmUgRnJlZXNjYWxlLXNwZWNpZmljIGFuZCBpcyB0byBmaXggdGhl
IGVTREhDIGRyaXZlci4NCj4gQ291bGQgd2UgbGV0IHRoZW0gbWVyZ2VkIGZpcnN0IGlmIHlvdSB3
ZXJlIHRhbGtpbmcgYWJvdXQgYSBuZXcgd2F5IG9mDQo+IGFic3RyYWN0aW5nIGdldHRpbmcgU29D
IHZlcnNpb24uDQo+IA0KPiANCj4gVGhhbmtzIDopDQo+IA0KPiANCj4gQmVzdCByZWdhcmRzLA0K
PiBZYW5nYm8gTHUNCj4gDQoNCg==
^ permalink raw reply [flat|nested] 185+ messages in thread
* [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-26 4:05 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-05-26 4:05 UTC (permalink / raw)
To: linux-arm-kernel
Hi Uffe,
Could we merge this patchset? ...
It has been a long time to wait for Arnd's response...
Thanks a lot.
Best regards,
Yangbo Lu
> -----Original Message-----
> From: Yangbo Lu
> Sent: Friday, May 20, 2016 2:06 PM
> To: 'Scott Wood'; Arnd Bergmann; linux-arm-kernel at lists.infradead.org
> Cc: linuxppc-dev at lists.ozlabs.org; Mark Rutland;
> devicetree at vger.kernel.org; ulf.hansson at linaro.org; Russell King; Bhupesh
> Sharma; netdev at vger.kernel.org; Joerg Roedel; Kumar Gala; linux-
> mmc at vger.kernel.org; linux-kernel at vger.kernel.org; Yang-Leo Li;
> iommu at lists.linux-foundation.org; Rob Herring; linux-i2c at vger.kernel.org;
> Claudiu Manoil; Santosh Shilimkar; Xiaobo Xie; linux-clk at vger.kernel.org;
> Qiang Zhao
> Subject: RE: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
> R1.0-R2.0
>
> Hi Arnd,
>
> Any comments?
> Please reply when you see the email since we want this eSDHC issue to be
> fixed soon.
>
> All the patches are Freescale-specific and is to fix the eSDHC driver.
> Could we let them merged first if you were talking about a new way of
> abstracting getting SoC version.
>
>
> Thanks :)
>
>
> Best regards,
> Yangbo Lu
>
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
2016-05-26 4:05 ` Yangbo Lu
(?)
(?)
@ 2016-05-26 7:44 ` Ulf Hansson
-1 siblings, 0 replies; 185+ messages in thread
From: Ulf Hansson @ 2016-05-26 7:44 UTC (permalink / raw)
To: Yangbo Lu
Cc: Scott Wood, Arnd Bergmann, linux-arm-kernel, linuxppc-dev,
Mark Rutland, devicetree, Russell King, Bhupesh Sharma, netdev,
Joerg Roedel, Kumar Gala, linux-mmc, linux-kernel, Yang-Leo Li,
iommu, Rob Herring, linux-i2c, Claudiu Manoil, Santosh Shilimkar,
Xiaobo Xie, linux-clk, Qiang Zhao
On 26 May 2016 at 06:05, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> Hi Uffe,
>
> Could we merge this patchset? ...
> It has been a long time to wait for Arnd's response...
>
> Thanks a lot.
>
>
As we are still in the merge window I won't queue anything but fixes.
Let's give Arnd another week or so to respond.
Kind regards
Uffe
> Best regards,
> Yangbo Lu
>
>
>> -----Original Message-----
>> From: Yangbo Lu
>> Sent: Friday, May 20, 2016 2:06 PM
>> To: 'Scott Wood'; Arnd Bergmann; linux-arm-kernel@lists.infradead.org
>> Cc: linuxppc-dev@lists.ozlabs.org; Mark Rutland;
>> devicetree@vger.kernel.org; ulf.hansson@linaro.org; Russell King; Bhupesh
>> Sharma; netdev@vger.kernel.org; Joerg Roedel; Kumar Gala; linux-
>> mmc@vger.kernel.org; linux-kernel@vger.kernel.org; Yang-Leo Li;
>> iommu@lists.linux-foundation.org; Rob Herring; linux-i2c@vger.kernel.org;
>> Claudiu Manoil; Santosh Shilimkar; Xiaobo Xie; linux-clk@vger.kernel.org;
>> Qiang Zhao
>> Subject: RE: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
>> R1.0-R2.0
>>
>> Hi Arnd,
>>
>> Any comments?
>> Please reply when you see the email since we want this eSDHC issue to be
>> fixed soon.
>>
>> All the patches are Freescale-specific and is to fix the eSDHC driver.
>> Could we let them merged first if you were talking about a new way of
>> abstracting getting SoC version.
>>
>>
>> Thanks :)
>>
>>
>> Best regards,
>> Yangbo Lu
>>
>
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-26 7:44 ` Ulf Hansson
0 siblings, 0 replies; 185+ messages in thread
From: Ulf Hansson @ 2016-05-26 7:44 UTC (permalink / raw)
To: Yangbo Lu
Cc: Scott Wood, Arnd Bergmann, linux-arm-kernel, linuxppc-dev,
Mark Rutland, devicetree, Russell King, Bhupesh Sharma, netdev,
Joerg Roedel, Kumar Gala, linux-mmc, linux-kernel, Yang-Leo Li,
iommu, Rob Herring, linux-i2c, Claudiu Manoil, Santosh
On 26 May 2016 at 06:05, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> Hi Uffe,
>
> Could we merge this patchset? ...
> It has been a long time to wait for Arnd's response...
>
> Thanks a lot.
>
>
As we are still in the merge window I won't queue anything but fixes.
Let's give Arnd another week or so to respond.
Kind regards
Uffe
> Best regards,
> Yangbo Lu
>
>
>> -----Original Message-----
>> From: Yangbo Lu
>> Sent: Friday, May 20, 2016 2:06 PM
>> To: 'Scott Wood'; Arnd Bergmann; linux-arm-kernel@lists.infradead.org
>> Cc: linuxppc-dev@lists.ozlabs.org; Mark Rutland;
>> devicetree@vger.kernel.org; ulf.hansson@linaro.org; Russell King; Bhupesh
>> Sharma; netdev@vger.kernel.org; Joerg Roedel; Kumar Gala; linux-
>> mmc@vger.kernel.org; linux-kernel@vger.kernel.org; Yang-Leo Li;
>> iommu@lists.linux-foundation.org; Rob Herring; linux-i2c@vger.kernel.org;
>> Claudiu Manoil; Santosh Shilimkar; Xiaobo Xie; linux-clk@vger.kernel.org;
>> Qiang Zhao
>> Subject: RE: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
>> R1.0-R2.0
>>
>> Hi Arnd,
>>
>> Any comments?
>> Please reply when you see the email since we want this eSDHC issue to be
>> fixed soon.
>>
>> All the patches are Freescale-specific and is to fix the eSDHC driver.
>> Could we let them merged first if you were talking about a new way of
>> abstracting getting SoC version.
>>
>>
>> Thanks :)
>>
>>
>> Best regards,
>> Yangbo Lu
>>
>
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-26 7:44 ` Ulf Hansson
0 siblings, 0 replies; 185+ messages in thread
From: Ulf Hansson @ 2016-05-26 7:44 UTC (permalink / raw)
To: Yangbo Lu
Cc: Scott Wood, Arnd Bergmann, linux-arm-kernel, linuxppc-dev,
Mark Rutland, devicetree, Russell King, Bhupesh Sharma, netdev,
Joerg Roedel, Kumar Gala, linux-mmc, linux-kernel, Yang-Leo Li,
iommu, Rob Herring, linux-i2c, Claudiu Manoil, Santosh Shilimkar,
Xiaobo Xie, linux-clk, Qiang Zhao
On 26 May 2016 at 06:05, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> Hi Uffe,
>
> Could we merge this patchset? ...
> It has been a long time to wait for Arnd's response...
>
> Thanks a lot.
>
>
As we are still in the merge window I won't queue anything but fixes.
Let's give Arnd another week or so to respond.
Kind regards
Uffe
> Best regards,
> Yangbo Lu
>
>
>> -----Original Message-----
>> From: Yangbo Lu
>> Sent: Friday, May 20, 2016 2:06 PM
>> To: 'Scott Wood'; Arnd Bergmann; linux-arm-kernel@lists.infradead.org
>> Cc: linuxppc-dev@lists.ozlabs.org; Mark Rutland;
>> devicetree@vger.kernel.org; ulf.hansson@linaro.org; Russell King; Bhupesh
>> Sharma; netdev@vger.kernel.org; Joerg Roedel; Kumar Gala; linux-
>> mmc@vger.kernel.org; linux-kernel@vger.kernel.org; Yang-Leo Li;
>> iommu@lists.linux-foundation.org; Rob Herring; linux-i2c@vger.kernel.org;
>> Claudiu Manoil; Santosh Shilimkar; Xiaobo Xie; linux-clk@vger.kernel.org;
>> Qiang Zhao
>> Subject: RE: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
>> R1.0-R2.0
>>
>> Hi Arnd,
>>
>> Any comments?
>> Please reply when you see the email since we want this eSDHC issue to be
>> fixed soon.
>>
>> All the patches are Freescale-specific and is to fix the eSDHC driver.
>> Could we let them merged first if you were talking about a new way of
>> abstracting getting SoC version.
>>
>>
>> Thanks :)
>>
>>
>> Best regards,
>> Yangbo Lu
>>
>
^ permalink raw reply [flat|nested] 185+ messages in thread
* [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-26 7:44 ` Ulf Hansson
0 siblings, 0 replies; 185+ messages in thread
From: Ulf Hansson @ 2016-05-26 7:44 UTC (permalink / raw)
To: linux-arm-kernel
On 26 May 2016 at 06:05, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> Hi Uffe,
>
> Could we merge this patchset? ...
> It has been a long time to wait for Arnd's response...
>
> Thanks a lot.
>
>
As we are still in the merge window I won't queue anything but fixes.
Let's give Arnd another week or so to respond.
Kind regards
Uffe
> Best regards,
> Yangbo Lu
>
>
>> -----Original Message-----
>> From: Yangbo Lu
>> Sent: Friday, May 20, 2016 2:06 PM
>> To: 'Scott Wood'; Arnd Bergmann; linux-arm-kernel at lists.infradead.org
>> Cc: linuxppc-dev at lists.ozlabs.org; Mark Rutland;
>> devicetree at vger.kernel.org; ulf.hansson at linaro.org; Russell King; Bhupesh
>> Sharma; netdev at vger.kernel.org; Joerg Roedel; Kumar Gala; linux-
>> mmc at vger.kernel.org; linux-kernel at vger.kernel.org; Yang-Leo Li;
>> iommu at lists.linux-foundation.org; Rob Herring; linux-i2c at vger.kernel.org;
>> Claudiu Manoil; Santosh Shilimkar; Xiaobo Xie; linux-clk at vger.kernel.org;
>> Qiang Zhao
>> Subject: RE: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
>> R1.0-R2.0
>>
>> Hi Arnd,
>>
>> Any comments?
>> Please reply when you see the email since we want this eSDHC issue to be
>> fixed soon.
>>
>> All the patches are Freescale-specific and is to fix the eSDHC driver.
>> Could we let them merged first if you were talking about a new way of
>> abstracting getting SoC version.
>>
>>
>> Thanks :)
>>
>>
>> Best regards,
>> Yangbo Lu
>>
>
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
2016-05-26 7:44 ` Ulf Hansson
(?)
(?)
@ 2016-05-30 13:13 ` Arnd Bergmann
-1 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-30 13:13 UTC (permalink / raw)
To: Ulf Hansson
Cc: Yangbo Lu, Scott Wood, linux-arm-kernel, linuxppc-dev,
Mark Rutland, devicetree, Russell King, Bhupesh Sharma, netdev,
Joerg Roedel, Kumar Gala, linux-mmc, linux-kernel, Yang-Leo Li,
iommu, Rob Herring, linux-i2c, Claudiu Manoil, Santosh Shilimkar,
Xiaobo Xie, linux-clk, Qiang Zhao
On Thursday, May 26, 2016 9:44:10 AM CEST Ulf Hansson wrote:
> On 26 May 2016 at 06:05, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> > Hi Uffe,
> >
> > Could we merge this patchset? ...
> > It has been a long time to wait for Arnd's response...
> >
> > Thanks a lot.
> >
> >
>
> As we are still in the merge window I won't queue anything but fixes.
> Let's give Arnd another week or so to respond.
I've got a patch series now that implements a method for matching
the soc ID, see the following emails.
Arnd
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-30 13:13 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-30 13:13 UTC (permalink / raw)
To: Ulf Hansson
Cc: Yangbo Lu, Scott Wood, linux-arm-kernel, linuxppc-dev,
Mark Rutland, devicetree, Russell King, Bhupesh Sharma, netdev,
Joerg Roedel, Kumar Gala, linux-mmc, linux-kernel, Yang-Leo Li,
iommu, Rob Herring, linux-i2c, Claudiu Manoil, Santosh
On Thursday, May 26, 2016 9:44:10 AM CEST Ulf Hansson wrote:
> On 26 May 2016 at 06:05, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> > Hi Uffe,
> >
> > Could we merge this patchset? ...
> > It has been a long time to wait for Arnd's response...
> >
> > Thanks a lot.
> >
> >
>
> As we are still in the merge window I won't queue anything but fixes.
> Let's give Arnd another week or so to respond.
I've got a patch series now that implements a method for matching
the soc ID, see the following emails.
Arnd
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-30 13:13 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-30 13:13 UTC (permalink / raw)
To: Ulf Hansson
Cc: Yangbo Lu, Scott Wood, linux-arm-kernel, linuxppc-dev,
Mark Rutland, devicetree, Russell King, Bhupesh Sharma, netdev,
Joerg Roedel, Kumar Gala, linux-mmc, linux-kernel, Yang-Leo Li,
iommu, Rob Herring, linux-i2c, Claudiu Manoil, Santosh Shilimkar,
Xiaobo Xie, linux-clk, Qiang Zhao
On Thursday, May 26, 2016 9:44:10 AM CEST Ulf Hansson wrote:
> On 26 May 2016 at 06:05, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> > Hi Uffe,
> >
> > Could we merge this patchset? ...
> > It has been a long time to wait for Arnd's response...
> >
> > Thanks a lot.
> >
> >
>
> As we are still in the merge window I won't queue anything but fixes.
> Let's give Arnd another week or so to respond.
I've got a patch series now that implements a method for matching
the soc ID, see the following emails.
Arnd
^ permalink raw reply [flat|nested] 185+ messages in thread
* [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-30 13:13 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-30 13:13 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday, May 26, 2016 9:44:10 AM CEST Ulf Hansson wrote:
> On 26 May 2016 at 06:05, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> > Hi Uffe,
> >
> > Could we merge this patchset? ...
> > It has been a long time to wait for Arnd's response...
> >
> > Thanks a lot.
> >
> >
>
> As we are still in the merge window I won't queue anything but fixes.
> Let's give Arnd another week or so to respond.
I've got a patch series now that implements a method for matching
the soc ID, see the following emails.
Arnd
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH 1/4] base: soc: introduce soc_device_match() interface
2016-05-26 7:44 ` Ulf Hansson
(?)
(?)
@ 2016-05-30 13:14 ` Arnd Bergmann
-1 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-30 13:14 UTC (permalink / raw)
To: linuxppc-dev
Cc: Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Scott Wood,
Rob Herring, Santosh Shilimkar, linux-arm-kernel, netdev,
linux-mmc, linux-kernel, Yang-Leo Li, iommu, Kumar Gala
We keep running into cases where device drivers want to know the exact
version of the SoC a they are currently running on. In the past, this
has usually been done through a vendor specific API that can be called
by a driver, or by directly accessing some kind of version register
that is not part of the device itself but that belongs to a global
register area of the chip.
Common reasons for doing this include:
- A machine is not using devicetree or similar for passing data
about on-chip devices, but just announces their presence using
boot-time platform devices, and the machine code itself does
not care about the revision.
- There is existing firmware or boot loaders with existing DT
binaries with generic compatible strings that do not identify
the particular revision of each device, but the driver knows
which SoC revisions include which part
- A prerelease version of a chip has some quirks and we are
using the same version of the bootloader and the DT blob
on both the prerelease and the final version. An update of
the DT binding seems inappropriate because that would involve
maintaining multiple copies of the dts and/or bootloader.
This introduces the soc_device_match() interface that is meant
to work like of_match_node() but instead of identifying the
version of a device, it identifies the SoC itself using a
vendor-agnostic interface.
Unlike soc_device_match(), we do not do an exact string compare
but instead use glob_match() to allow wildcards in strings.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 246acdafedb6..fc7613cc7fd5 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -225,6 +225,7 @@ config GENERIC_CPU_AUTOPROBE
config SOC_BUS
bool
+ select GLOB
source "drivers/base/regmap/Kconfig"
diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index 75b98aad6faf..e9623c6674a5 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -14,6 +14,7 @@
#include <linux/spinlock.h>
#include <linux/sys_soc.h>
#include <linux/err.h>
+#include <linux/glob.h>
static DEFINE_IDA(soc_ida);
@@ -168,3 +169,60 @@ static void __exit soc_bus_unregister(void)
bus_unregister(&soc_bus_type);
}
module_exit(soc_bus_unregister);
+
+static int soc_device_match_one(struct device *dev, void *arg)
+{
+ struct soc_device *soc_dev = container_of(dev, struct soc_device, dev);
+ struct soc_device_attribute *match = arg;
+
+ if (match->machine && !glob_match(match->machine, soc_dev->attr->machine))
+ return 0;
+
+ if (match->family && !glob_match(match->family, soc_dev->attr->family))
+ return 0;
+
+ if (match->revision && !glob_match(match->revision, soc_dev->attr->revision))
+ return 0;
+
+ if (match->soc_id && !glob_match(match->soc_id, soc_dev->attr->revision))
+ return 0;
+
+ return 1;
+}
+
+/*
+ * soc_device_match - identify the SoC in the machine
+ * @matches: zero-terminated array of possible matches
+ *
+ * returns the first matching entry of the argument array, or NULL
+ * if none of them match.
+ *
+ * This function is meant as a helper in place of of_match_node()
+ * in cases where either no device tree is available or the information
+ * in a device node is insufficient to identify a particular variant
+ * by its compatible strings or other properties. For new devices,
+ * the DT binding should always provide unique compatible strings
+ * that allow the use of of_match_node() instead.
+ *
+ * The calling function can use the .data entry of the
+ * soc_device_attribute to pass a structure or function pointer for
+ * each entry.
+ */
+struct soc_device_attribute *soc_device_match(struct soc_device_attribute *matches)
+{
+ struct device *dev;
+ int ret;
+
+ for (ret = 0; ret == 0; matches++) {
+ if (matches->machine || matches->family ||
+ matches->revision || matches->soc_id)
+ return NULL;
+
+ dev = NULL;
+ ret = bus_for_each_dev(&soc_bus_type, dev, matches,
+ soc_device_match_one);
+ }
+
+ return matches;
+}
+EXPORT_SYMBOL_GPL(soc_device_match);
diff --git a/include/linux/sys_soc.h b/include/linux/sys_soc.h
index 2739ccb69571..02c48c76052b 100644
--- a/include/linux/sys_soc.h
+++ b/include/linux/sys_soc.h
@@ -13,6 +13,8 @@ struct soc_device_attribute {
const char *family;
const char *revision;
const char *soc_id;
+
+ const void *data;
};
/**
@@ -34,4 +36,6 @@ void soc_device_unregister(struct soc_device *soc_dev);
*/
struct device *soc_device_to_device(struct soc_device *soc);
+struct soc_device_attribute *soc_device_match(struct soc_device_attribute *matches);
+
#endif /* __SOC_BUS_H */
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [PATCH 1/4] base: soc: introduce soc_device_match() interface
@ 2016-05-30 13:14 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-30 13:14 UTC (permalink / raw)
To: linuxppc-dev
Cc: Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Scott Wood,
Rob Herring, Santosh Shilimkar, linux-arm-kernel, netdev,
linux-mmc, linux-kernel, Yang-Leo
We keep running into cases where device drivers want to know the exact
version of the SoC a they are currently running on. In the past, this
has usually been done through a vendor specific API that can be called
by a driver, or by directly accessing some kind of version register
that is not part of the device itself but that belongs to a global
register area of the chip.
Common reasons for doing this include:
- A machine is not using devicetree or similar for passing data
about on-chip devices, but just announces their presence using
boot-time platform devices, and the machine code itself does
not care about the revision.
- There is existing firmware or boot loaders with existing DT
binaries with generic compatible strings that do not identify
the particular revision of each device, but the driver knows
which SoC revisions include which part
- A prerelease version of a chip has some quirks and we are
using the same version of the bootloader and the DT blob
on both the prerelease and the final version. An update of
the DT binding seems inappropriate because that would involve
maintaining multiple copies of the dts and/or bootloader.
This introduces the soc_device_match() interface that is meant
to work like of_match_node() but instead of identifying the
version of a device, it identifies the SoC itself using a
vendor-agnostic interface.
Unlike soc_device_match(), we do not do an exact string compare
but instead use glob_match() to allow wildcards in strings.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 246acdafedb6..fc7613cc7fd5 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -225,6 +225,7 @@ config GENERIC_CPU_AUTOPROBE
config SOC_BUS
bool
+ select GLOB
source "drivers/base/regmap/Kconfig"
diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index 75b98aad6faf..e9623c6674a5 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -14,6 +14,7 @@
#include <linux/spinlock.h>
#include <linux/sys_soc.h>
#include <linux/err.h>
+#include <linux/glob.h>
static DEFINE_IDA(soc_ida);
@@ -168,3 +169,60 @@ static void __exit soc_bus_unregister(void)
bus_unregister(&soc_bus_type);
}
module_exit(soc_bus_unregister);
+
+static int soc_device_match_one(struct device *dev, void *arg)
+{
+ struct soc_device *soc_dev = container_of(dev, struct soc_device, dev);
+ struct soc_device_attribute *match = arg;
+
+ if (match->machine && !glob_match(match->machine, soc_dev->attr->machine))
+ return 0;
+
+ if (match->family && !glob_match(match->family, soc_dev->attr->family))
+ return 0;
+
+ if (match->revision && !glob_match(match->revision, soc_dev->attr->revision))
+ return 0;
+
+ if (match->soc_id && !glob_match(match->soc_id, soc_dev->attr->revision))
+ return 0;
+
+ return 1;
+}
+
+/*
+ * soc_device_match - identify the SoC in the machine
+ * @matches: zero-terminated array of possible matches
+ *
+ * returns the first matching entry of the argument array, or NULL
+ * if none of them match.
+ *
+ * This function is meant as a helper in place of of_match_node()
+ * in cases where either no device tree is available or the information
+ * in a device node is insufficient to identify a particular variant
+ * by its compatible strings or other properties. For new devices,
+ * the DT binding should always provide unique compatible strings
+ * that allow the use of of_match_node() instead.
+ *
+ * The calling function can use the .data entry of the
+ * soc_device_attribute to pass a structure or function pointer for
+ * each entry.
+ */
+struct soc_device_attribute *soc_device_match(struct soc_device_attribute *matches)
+{
+ struct device *dev;
+ int ret;
+
+ for (ret = 0; ret == 0; matches++) {
+ if (matches->machine || matches->family ||
+ matches->revision || matches->soc_id)
+ return NULL;
+
+ dev = NULL;
+ ret = bus_for_each_dev(&soc_bus_type, dev, matches,
+ soc_device_match_one);
+ }
+
+ return matches;
+}
+EXPORT_SYMBOL_GPL(soc_device_match);
diff --git a/include/linux/sys_soc.h b/include/linux/sys_soc.h
index 2739ccb69571..02c48c76052b 100644
--- a/include/linux/sys_soc.h
+++ b/include/linux/sys_soc.h
@@ -13,6 +13,8 @@ struct soc_device_attribute {
const char *family;
const char *revision;
const char *soc_id;
+
+ const void *data;
};
/**
@@ -34,4 +36,6 @@ void soc_device_unregister(struct soc_device *soc_dev);
*/
struct device *soc_device_to_device(struct soc_device *soc);
+struct soc_device_attribute *soc_device_match(struct soc_device_attribute *matches);
+
#endif /* __SOC_BUS_H */
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [PATCH 1/4] base: soc: introduce soc_device_match() interface
@ 2016-05-30 13:14 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-30 13:14 UTC (permalink / raw)
To: linuxppc-dev
Cc: Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Scott Wood,
Rob Herring, Santosh Shilimkar, linux-arm-kernel, netdev,
linux-mmc, linux-kernel, Yang-Leo Li, iommu, Kumar Gala
We keep running into cases where device drivers want to know the exact
version of the SoC a they are currently running on. In the past, this
has usually been done through a vendor specific API that can be called
by a driver, or by directly accessing some kind of version register
that is not part of the device itself but that belongs to a global
register area of the chip.
Common reasons for doing this include:
- A machine is not using devicetree or similar for passing data
about on-chip devices, but just announces their presence using
boot-time platform devices, and the machine code itself does
not care about the revision.
- There is existing firmware or boot loaders with existing DT
binaries with generic compatible strings that do not identify
the particular revision of each device, but the driver knows
which SoC revisions include which part
- A prerelease version of a chip has some quirks and we are
using the same version of the bootloader and the DT blob
on both the prerelease and the final version. An update of
the DT binding seems inappropriate because that would involve
maintaining multiple copies of the dts and/or bootloader.
This introduces the soc_device_match() interface that is meant
to work like of_match_node() but instead of identifying the
version of a device, it identifies the SoC itself using a
vendor-agnostic interface.
Unlike soc_device_match(), we do not do an exact string compare
but instead use glob_match() to allow wildcards in strings.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 246acdafedb6..fc7613cc7fd5 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -225,6 +225,7 @@ config GENERIC_CPU_AUTOPROBE
config SOC_BUS
bool
+ select GLOB
source "drivers/base/regmap/Kconfig"
diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index 75b98aad6faf..e9623c6674a5 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -14,6 +14,7 @@
#include <linux/spinlock.h>
#include <linux/sys_soc.h>
#include <linux/err.h>
+#include <linux/glob.h>
static DEFINE_IDA(soc_ida);
@@ -168,3 +169,60 @@ static void __exit soc_bus_unregister(void)
bus_unregister(&soc_bus_type);
}
module_exit(soc_bus_unregister);
+
+static int soc_device_match_one(struct device *dev, void *arg)
+{
+ struct soc_device *soc_dev = container_of(dev, struct soc_device, dev);
+ struct soc_device_attribute *match = arg;
+
+ if (match->machine && !glob_match(match->machine, soc_dev->attr->machine))
+ return 0;
+
+ if (match->family && !glob_match(match->family, soc_dev->attr->family))
+ return 0;
+
+ if (match->revision && !glob_match(match->revision, soc_dev->attr->revision))
+ return 0;
+
+ if (match->soc_id && !glob_match(match->soc_id, soc_dev->attr->revision))
+ return 0;
+
+ return 1;
+}
+
+/*
+ * soc_device_match - identify the SoC in the machine
+ * @matches: zero-terminated array of possible matches
+ *
+ * returns the first matching entry of the argument array, or NULL
+ * if none of them match.
+ *
+ * This function is meant as a helper in place of of_match_node()
+ * in cases where either no device tree is available or the information
+ * in a device node is insufficient to identify a particular variant
+ * by its compatible strings or other properties. For new devices,
+ * the DT binding should always provide unique compatible strings
+ * that allow the use of of_match_node() instead.
+ *
+ * The calling function can use the .data entry of the
+ * soc_device_attribute to pass a structure or function pointer for
+ * each entry.
+ */
+struct soc_device_attribute *soc_device_match(struct soc_device_attribute *matches)
+{
+ struct device *dev;
+ int ret;
+
+ for (ret = 0; ret == 0; matches++) {
+ if (matches->machine || matches->family ||
+ matches->revision || matches->soc_id)
+ return NULL;
+
+ dev = NULL;
+ ret = bus_for_each_dev(&soc_bus_type, dev, matches,
+ soc_device_match_one);
+ }
+
+ return matches;
+}
+EXPORT_SYMBOL_GPL(soc_device_match);
diff --git a/include/linux/sys_soc.h b/include/linux/sys_soc.h
index 2739ccb69571..02c48c76052b 100644
--- a/include/linux/sys_soc.h
+++ b/include/linux/sys_soc.h
@@ -13,6 +13,8 @@ struct soc_device_attribute {
const char *family;
const char *revision;
const char *soc_id;
+
+ const void *data;
};
/**
@@ -34,4 +36,6 @@ void soc_device_unregister(struct soc_device *soc_dev);
*/
struct device *soc_device_to_device(struct soc_device *soc);
+struct soc_device_attribute *soc_device_match(struct soc_device_attribute *matches);
+
#endif /* __SOC_BUS_H */
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [PATCH 1/4] base: soc: introduce soc_device_match() interface
@ 2016-05-30 13:14 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-30 13:14 UTC (permalink / raw)
To: linux-arm-kernel
We keep running into cases where device drivers want to know the exact
version of the SoC a they are currently running on. In the past, this
has usually been done through a vendor specific API that can be called
by a driver, or by directly accessing some kind of version register
that is not part of the device itself but that belongs to a global
register area of the chip.
Common reasons for doing this include:
- A machine is not using devicetree or similar for passing data
about on-chip devices, but just announces their presence using
boot-time platform devices, and the machine code itself does
not care about the revision.
- There is existing firmware or boot loaders with existing DT
binaries with generic compatible strings that do not identify
the particular revision of each device, but the driver knows
which SoC revisions include which part
- A prerelease version of a chip has some quirks and we are
using the same version of the bootloader and the DT blob
on both the prerelease and the final version. An update of
the DT binding seems inappropriate because that would involve
maintaining multiple copies of the dts and/or bootloader.
This introduces the soc_device_match() interface that is meant
to work like of_match_node() but instead of identifying the
version of a device, it identifies the SoC itself using a
vendor-agnostic interface.
Unlike soc_device_match(), we do not do an exact string compare
but instead use glob_match() to allow wildcards in strings.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 246acdafedb6..fc7613cc7fd5 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -225,6 +225,7 @@ config GENERIC_CPU_AUTOPROBE
config SOC_BUS
bool
+ select GLOB
source "drivers/base/regmap/Kconfig"
diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index 75b98aad6faf..e9623c6674a5 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -14,6 +14,7 @@
#include <linux/spinlock.h>
#include <linux/sys_soc.h>
#include <linux/err.h>
+#include <linux/glob.h>
static DEFINE_IDA(soc_ida);
@@ -168,3 +169,60 @@ static void __exit soc_bus_unregister(void)
bus_unregister(&soc_bus_type);
}
module_exit(soc_bus_unregister);
+
+static int soc_device_match_one(struct device *dev, void *arg)
+{
+ struct soc_device *soc_dev = container_of(dev, struct soc_device, dev);
+ struct soc_device_attribute *match = arg;
+
+ if (match->machine && !glob_match(match->machine, soc_dev->attr->machine))
+ return 0;
+
+ if (match->family && !glob_match(match->family, soc_dev->attr->family))
+ return 0;
+
+ if (match->revision && !glob_match(match->revision, soc_dev->attr->revision))
+ return 0;
+
+ if (match->soc_id && !glob_match(match->soc_id, soc_dev->attr->revision))
+ return 0;
+
+ return 1;
+}
+
+/*
+ * soc_device_match - identify the SoC in the machine
+ * @matches: zero-terminated array of possible matches
+ *
+ * returns the first matching entry of the argument array, or NULL
+ * if none of them match.
+ *
+ * This function is meant as a helper in place of of_match_node()
+ * in cases where either no device tree is available or the information
+ * in a device node is insufficient to identify a particular variant
+ * by its compatible strings or other properties. For new devices,
+ * the DT binding should always provide unique compatible strings
+ * that allow the use of of_match_node() instead.
+ *
+ * The calling function can use the .data entry of the
+ * soc_device_attribute to pass a structure or function pointer for
+ * each entry.
+ */
+struct soc_device_attribute *soc_device_match(struct soc_device_attribute *matches)
+{
+ struct device *dev;
+ int ret;
+
+ for (ret = 0; ret == 0; matches++) {
+ if (matches->machine || matches->family ||
+ matches->revision || matches->soc_id)
+ return NULL;
+
+ dev = NULL;
+ ret = bus_for_each_dev(&soc_bus_type, dev, matches,
+ soc_device_match_one);
+ }
+
+ return matches;
+}
+EXPORT_SYMBOL_GPL(soc_device_match);
diff --git a/include/linux/sys_soc.h b/include/linux/sys_soc.h
index 2739ccb69571..02c48c76052b 100644
--- a/include/linux/sys_soc.h
+++ b/include/linux/sys_soc.h
@@ -13,6 +13,8 @@ struct soc_device_attribute {
const char *family;
const char *revision;
const char *soc_id;
+
+ const void *data;
};
/**
@@ -34,4 +36,6 @@ void soc_device_unregister(struct soc_device *soc_dev);
*/
struct device *soc_device_to_device(struct soc_device *soc);
+struct soc_device_attribute *soc_device_match(struct soc_device_attribute *matches);
+
#endif /* __SOC_BUS_H */
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
2016-05-26 7:44 ` Ulf Hansson
(?)
(?)
@ 2016-05-30 13:15 ` Arnd Bergmann
-1 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-30 13:15 UTC (permalink / raw)
To: linuxppc-dev
Cc: Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Scott Wood,
Rob Herring, Santosh Shilimkar, linux-arm-kernel, netdev,
linux-mmc, linux-kernel, Yang-Leo Li, iommu, Kumar Gala
From: Yangbo Lu <yangbo.lu@nxp.com>
The global utilities block controls power management, I/O device
enabling, power-onreset(POR) configuration monitoring, alternate
function selection for multiplexed signals,and clock control.
This patch adds GUTS driver to manage and access global utilities
block.
[arnd turned this into a platform_driver registering a soc_device
rather than providing an ad-hoc interface for soc-id]
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index cb58ef0d9b2c..7106463f118e 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -2,7 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
source "drivers/soc/bcm/Kconfig"
source "drivers/soc/brcmstb/Kconfig"
-source "drivers/soc/fsl/qe/Kconfig"
+source "drivers/soc/fsl/Kconfig"
source "drivers/soc/mediatek/Kconfig"
source "drivers/soc/qcom/Kconfig"
source "drivers/soc/rockchip/Kconfig"
diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
new file mode 100644
index 000000000000..33d331cac8d6
--- /dev/null
+++ b/drivers/soc/fsl/Kconfig
@@ -0,0 +1,15 @@
+#
+# Freescale SOC drivers
+#
+
+source "drivers/soc/fsl/qe/Kconfig"
+
+config FSL_GUTS
+ bool "NXP Layerscale SoC identification"
+ depends on PPC_FSL || SOC_LS1021A || ARCH_LAYERSCAPE || COMPILE_TEST
+ default PPC_FSL || SOC_LS1021A || ARCH_LAYERSCAPE
+ select SOC_BUS
+ help
+ This registers a SoC device for NXP (formerly Freescale)
+ Layerscape devices, making information about the system
+ available in /sys/devices/soc/
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 203307fd92c1..02afb7f980f6 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_QUICC_ENGINE) += qe/
obj-$(CONFIG_CPM) += qe/
+obj-$(CONFIG_FSL_GUTS) += guts.o
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
new file mode 100644
index 000000000000..2f30698f5bcf
--- /dev/null
+++ b/drivers/soc/fsl/guts.c
@@ -0,0 +1,130 @@
+/*
+ * Freescale QorIQ Platforms GUTS Driver
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/io.h>
+#include <linux/platform_device.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/sys_soc.h>
+
+#define GUTS_PVR 0x0a0
+#define GUTS_SVR 0x0a4
+
+struct guts {
+ void __iomem *regs;
+ bool little_endian;
+ struct soc_device_attribute soc;
+};
+
+static u32 fsl_guts_get_svr(struct guts *guts)
+{
+ if (guts->little_endian)
+ return ioread32(guts->regs + GUTS_SVR);
+ else
+ return ioread32be(guts->regs + GUTS_SVR);
+}
+
+static u32 fsl_guts_get_pvr(struct guts *guts)
+{
+ if (guts->little_endian)
+ return ioread32(guts->regs + GUTS_PVR);
+ else
+ return ioread32be(guts->regs + GUTS_PVR);
+}
+
+/*
+ * Table for matching compatible strings, for device tree
+ * guts node, for Freescale QorIQ SOCs.
+ */
+static const struct of_device_id fsl_guts_of_match[] = {
+ /* For T4 & B4 Series SOCs */
+ { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4 series" },
+ /* For P Series SOCs */
+ { .compatible = "fsl,p1010-guts", .data = "P1010/P1014" },
+ { .compatible = "fsl,p1020-guts", .data = "P1020/P1011" },
+ { .compatible = "fsl,p1021-guts", .data = "P1021/P1012" },
+ { .compatible = "fsl,p1022-guts", .data = "P1022/P1013" },
+ { .compatible = "fsl,p1023-guts", .data = "P1013/P1017" },
+ { .compatible = "fsl,p2020-guts", .data = "P2010/P2020" },
+ { .compatible = "fsl,qoriq-device-config-2.0", .data = "P series" },
+ /* For BSC Series SOCs */
+ { .compatible = "fsl,bsc9131-guts", .data = "BSC9131 Qonverge" },
+ { .compatible = "fsl,bsc9132-guts", .data = "BSC9132 Qonverge" },
+ /* For MPC85xx Series SOCs */
+ { .compatible = "fsl,mpc8536-guts", .data = "PowerPC MPC8536" },
+ { .compatible = "fsl,mpc8544-guts", .data = "PowerPC MPC8544" },
+ { .compatible = "fsl,mpc8548-guts", .data = "PowerPC MPC8548" },
+ { .compatible = "fsl,mpc8568-guts", .data = "PowerPC MPC8568" },
+ { .compatible = "fsl,mpc8569-guts", .data = "PowerPC MPC8569" },
+ { .compatible = "fsl,mpc8572-guts", .data = "PowerPC MPC8572" },
+ /* For Layerscape Series SOCs */
+ { .compatible = "fsl,ls1021a-dcfg", .data = "Layerscape LS1021A" },
+ { .compatible = "fsl,ls1043a-dcfg", .data = "Layerscape LS1043A" },
+ { .compatible = "fsl,ls2080a-dcfg", .data = "Layerscape LS2080A" },
+ {}
+};
+
+static void fsl_guts_init(struct device *dev, struct guts *guts)
+{
+ const struct of_device_id *id;
+ u32 svr = fsl_guts_get_svr(guts);
+
+ guts->soc.family = "NXP QorIQ";
+ id = of_match_node(fsl_guts_of_match, dev->of_node);
+ guts->soc.soc_id = devm_kasprintf(dev, "%s (ver 0x%06x)" id->data,
+ svr >> 8;
+ guts->soc.revision = devm_kasprintf(dev, GFP_KERNEL, "0x%02x",
+ svr & 0xff);
+}
+
+static int fsl_guts_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct guts *guts;
+ int ret;
+
+ guts = devm_kzalloc(dev, sizeof(*guts), GFP_KERNEL);
+ if (!guts) {
+ ret = -ENOMEM;
+ goto out;
+
+ }
+
+ /*
+ * syscon devices default to little-endian, but on powerpc we have
+ * existing device trees with big-endian maps and an absent endianess
+ * "big-property"
+ */
+ if (!IS_ENABLED(CONFIG_POWERPC) &&
+ !of_property_read_bool(dev->of_node, "big-endian"))
+ guts->little_endian = true;
+
+ guts->regs = devm_ioremap_resource(dev, 0);
+ if (!guts->regs) {
+ ret = -ENOMEM;
+ kfree(guts);
+ goto out;
+ }
+
+ fsl_guts_init(dev, guts);
+ ret = 0;
+out:
+ return ret;
+}
+
+static struct platform_driver fsl_soc_guts = {
+ .probe = fsl_guts_probe,
+ .driver.of_match_table = fsl_guts_of_match,
+};
+
+module_platform_driver(fsl_soc_guts);
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-05-30 13:15 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-30 13:15 UTC (permalink / raw)
To: linuxppc-dev
Cc: Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Scott Wood,
Rob Herring, Santosh Shilimkar, linux-arm-kernel, netdev,
linux-mmc, linux-kernel, Yang-Leo
From: Yangbo Lu <yangbo.lu@nxp.com>
The global utilities block controls power management, I/O device
enabling, power-onreset(POR) configuration monitoring, alternate
function selection for multiplexed signals,and clock control.
This patch adds GUTS driver to manage and access global utilities
block.
[arnd turned this into a platform_driver registering a soc_device
rather than providing an ad-hoc interface for soc-id]
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index cb58ef0d9b2c..7106463f118e 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -2,7 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
source "drivers/soc/bcm/Kconfig"
source "drivers/soc/brcmstb/Kconfig"
-source "drivers/soc/fsl/qe/Kconfig"
+source "drivers/soc/fsl/Kconfig"
source "drivers/soc/mediatek/Kconfig"
source "drivers/soc/qcom/Kconfig"
source "drivers/soc/rockchip/Kconfig"
diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
new file mode 100644
index 000000000000..33d331cac8d6
--- /dev/null
+++ b/drivers/soc/fsl/Kconfig
@@ -0,0 +1,15 @@
+#
+# Freescale SOC drivers
+#
+
+source "drivers/soc/fsl/qe/Kconfig"
+
+config FSL_GUTS
+ bool "NXP Layerscale SoC identification"
+ depends on PPC_FSL || SOC_LS1021A || ARCH_LAYERSCAPE || COMPILE_TEST
+ default PPC_FSL || SOC_LS1021A || ARCH_LAYERSCAPE
+ select SOC_BUS
+ help
+ This registers a SoC device for NXP (formerly Freescale)
+ Layerscape devices, making information about the system
+ available in /sys/devices/soc/
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 203307fd92c1..02afb7f980f6 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_QUICC_ENGINE) += qe/
obj-$(CONFIG_CPM) += qe/
+obj-$(CONFIG_FSL_GUTS) += guts.o
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
new file mode 100644
index 000000000000..2f30698f5bcf
--- /dev/null
+++ b/drivers/soc/fsl/guts.c
@@ -0,0 +1,130 @@
+/*
+ * Freescale QorIQ Platforms GUTS Driver
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/io.h>
+#include <linux/platform_device.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/sys_soc.h>
+
+#define GUTS_PVR 0x0a0
+#define GUTS_SVR 0x0a4
+
+struct guts {
+ void __iomem *regs;
+ bool little_endian;
+ struct soc_device_attribute soc;
+};
+
+static u32 fsl_guts_get_svr(struct guts *guts)
+{
+ if (guts->little_endian)
+ return ioread32(guts->regs + GUTS_SVR);
+ else
+ return ioread32be(guts->regs + GUTS_SVR);
+}
+
+static u32 fsl_guts_get_pvr(struct guts *guts)
+{
+ if (guts->little_endian)
+ return ioread32(guts->regs + GUTS_PVR);
+ else
+ return ioread32be(guts->regs + GUTS_PVR);
+}
+
+/*
+ * Table for matching compatible strings, for device tree
+ * guts node, for Freescale QorIQ SOCs.
+ */
+static const struct of_device_id fsl_guts_of_match[] = {
+ /* For T4 & B4 Series SOCs */
+ { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4 series" },
+ /* For P Series SOCs */
+ { .compatible = "fsl,p1010-guts", .data = "P1010/P1014" },
+ { .compatible = "fsl,p1020-guts", .data = "P1020/P1011" },
+ { .compatible = "fsl,p1021-guts", .data = "P1021/P1012" },
+ { .compatible = "fsl,p1022-guts", .data = "P1022/P1013" },
+ { .compatible = "fsl,p1023-guts", .data = "P1013/P1017" },
+ { .compatible = "fsl,p2020-guts", .data = "P2010/P2020" },
+ { .compatible = "fsl,qoriq-device-config-2.0", .data = "P series" },
+ /* For BSC Series SOCs */
+ { .compatible = "fsl,bsc9131-guts", .data = "BSC9131 Qonverge" },
+ { .compatible = "fsl,bsc9132-guts", .data = "BSC9132 Qonverge" },
+ /* For MPC85xx Series SOCs */
+ { .compatible = "fsl,mpc8536-guts", .data = "PowerPC MPC8536" },
+ { .compatible = "fsl,mpc8544-guts", .data = "PowerPC MPC8544" },
+ { .compatible = "fsl,mpc8548-guts", .data = "PowerPC MPC8548" },
+ { .compatible = "fsl,mpc8568-guts", .data = "PowerPC MPC8568" },
+ { .compatible = "fsl,mpc8569-guts", .data = "PowerPC MPC8569" },
+ { .compatible = "fsl,mpc8572-guts", .data = "PowerPC MPC8572" },
+ /* For Layerscape Series SOCs */
+ { .compatible = "fsl,ls1021a-dcfg", .data = "Layerscape LS1021A" },
+ { .compatible = "fsl,ls1043a-dcfg", .data = "Layerscape LS1043A" },
+ { .compatible = "fsl,ls2080a-dcfg", .data = "Layerscape LS2080A" },
+ {}
+};
+
+static void fsl_guts_init(struct device *dev, struct guts *guts)
+{
+ const struct of_device_id *id;
+ u32 svr = fsl_guts_get_svr(guts);
+
+ guts->soc.family = "NXP QorIQ";
+ id = of_match_node(fsl_guts_of_match, dev->of_node);
+ guts->soc.soc_id = devm_kasprintf(dev, "%s (ver 0x%06x)" id->data,
+ svr >> 8;
+ guts->soc.revision = devm_kasprintf(dev, GFP_KERNEL, "0x%02x",
+ svr & 0xff);
+}
+
+static int fsl_guts_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct guts *guts;
+ int ret;
+
+ guts = devm_kzalloc(dev, sizeof(*guts), GFP_KERNEL);
+ if (!guts) {
+ ret = -ENOMEM;
+ goto out;
+
+ }
+
+ /*
+ * syscon devices default to little-endian, but on powerpc we have
+ * existing device trees with big-endian maps and an absent endianess
+ * "big-property"
+ */
+ if (!IS_ENABLED(CONFIG_POWERPC) &&
+ !of_property_read_bool(dev->of_node, "big-endian"))
+ guts->little_endian = true;
+
+ guts->regs = devm_ioremap_resource(dev, 0);
+ if (!guts->regs) {
+ ret = -ENOMEM;
+ kfree(guts);
+ goto out;
+ }
+
+ fsl_guts_init(dev, guts);
+ ret = 0;
+out:
+ return ret;
+}
+
+static struct platform_driver fsl_soc_guts = {
+ .probe = fsl_guts_probe,
+ .driver.of_match_table = fsl_guts_of_match,
+};
+
+module_platform_driver(fsl_soc_guts);
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-05-30 13:15 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-30 13:15 UTC (permalink / raw)
To: linuxppc-dev
Cc: Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Scott Wood,
Rob Herring, Santosh Shilimkar, linux-arm-kernel, netdev,
linux-mmc, linux-kernel, Yang-Leo Li, iommu, Kumar Gala
From: Yangbo Lu <yangbo.lu@nxp.com>
The global utilities block controls power management, I/O device
enabling, power-onreset(POR) configuration monitoring, alternate
function selection for multiplexed signals,and clock control.
This patch adds GUTS driver to manage and access global utilities
block.
[arnd turned this into a platform_driver registering a soc_device
rather than providing an ad-hoc interface for soc-id]
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index cb58ef0d9b2c..7106463f118e 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -2,7 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
source "drivers/soc/bcm/Kconfig"
source "drivers/soc/brcmstb/Kconfig"
-source "drivers/soc/fsl/qe/Kconfig"
+source "drivers/soc/fsl/Kconfig"
source "drivers/soc/mediatek/Kconfig"
source "drivers/soc/qcom/Kconfig"
source "drivers/soc/rockchip/Kconfig"
diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
new file mode 100644
index 000000000000..33d331cac8d6
--- /dev/null
+++ b/drivers/soc/fsl/Kconfig
@@ -0,0 +1,15 @@
+#
+# Freescale SOC drivers
+#
+
+source "drivers/soc/fsl/qe/Kconfig"
+
+config FSL_GUTS
+ bool "NXP Layerscale SoC identification"
+ depends on PPC_FSL || SOC_LS1021A || ARCH_LAYERSCAPE || COMPILE_TEST
+ default PPC_FSL || SOC_LS1021A || ARCH_LAYERSCAPE
+ select SOC_BUS
+ help
+ This registers a SoC device for NXP (formerly Freescale)
+ Layerscape devices, making information about the system
+ available in /sys/devices/soc/
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 203307fd92c1..02afb7f980f6 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_QUICC_ENGINE) += qe/
obj-$(CONFIG_CPM) += qe/
+obj-$(CONFIG_FSL_GUTS) += guts.o
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
new file mode 100644
index 000000000000..2f30698f5bcf
--- /dev/null
+++ b/drivers/soc/fsl/guts.c
@@ -0,0 +1,130 @@
+/*
+ * Freescale QorIQ Platforms GUTS Driver
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/io.h>
+#include <linux/platform_device.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/sys_soc.h>
+
+#define GUTS_PVR 0x0a0
+#define GUTS_SVR 0x0a4
+
+struct guts {
+ void __iomem *regs;
+ bool little_endian;
+ struct soc_device_attribute soc;
+};
+
+static u32 fsl_guts_get_svr(struct guts *guts)
+{
+ if (guts->little_endian)
+ return ioread32(guts->regs + GUTS_SVR);
+ else
+ return ioread32be(guts->regs + GUTS_SVR);
+}
+
+static u32 fsl_guts_get_pvr(struct guts *guts)
+{
+ if (guts->little_endian)
+ return ioread32(guts->regs + GUTS_PVR);
+ else
+ return ioread32be(guts->regs + GUTS_PVR);
+}
+
+/*
+ * Table for matching compatible strings, for device tree
+ * guts node, for Freescale QorIQ SOCs.
+ */
+static const struct of_device_id fsl_guts_of_match[] = {
+ /* For T4 & B4 Series SOCs */
+ { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4 series" },
+ /* For P Series SOCs */
+ { .compatible = "fsl,p1010-guts", .data = "P1010/P1014" },
+ { .compatible = "fsl,p1020-guts", .data = "P1020/P1011" },
+ { .compatible = "fsl,p1021-guts", .data = "P1021/P1012" },
+ { .compatible = "fsl,p1022-guts", .data = "P1022/P1013" },
+ { .compatible = "fsl,p1023-guts", .data = "P1013/P1017" },
+ { .compatible = "fsl,p2020-guts", .data = "P2010/P2020" },
+ { .compatible = "fsl,qoriq-device-config-2.0", .data = "P series" },
+ /* For BSC Series SOCs */
+ { .compatible = "fsl,bsc9131-guts", .data = "BSC9131 Qonverge" },
+ { .compatible = "fsl,bsc9132-guts", .data = "BSC9132 Qonverge" },
+ /* For MPC85xx Series SOCs */
+ { .compatible = "fsl,mpc8536-guts", .data = "PowerPC MPC8536" },
+ { .compatible = "fsl,mpc8544-guts", .data = "PowerPC MPC8544" },
+ { .compatible = "fsl,mpc8548-guts", .data = "PowerPC MPC8548" },
+ { .compatible = "fsl,mpc8568-guts", .data = "PowerPC MPC8568" },
+ { .compatible = "fsl,mpc8569-guts", .data = "PowerPC MPC8569" },
+ { .compatible = "fsl,mpc8572-guts", .data = "PowerPC MPC8572" },
+ /* For Layerscape Series SOCs */
+ { .compatible = "fsl,ls1021a-dcfg", .data = "Layerscape LS1021A" },
+ { .compatible = "fsl,ls1043a-dcfg", .data = "Layerscape LS1043A" },
+ { .compatible = "fsl,ls2080a-dcfg", .data = "Layerscape LS2080A" },
+ {}
+};
+
+static void fsl_guts_init(struct device *dev, struct guts *guts)
+{
+ const struct of_device_id *id;
+ u32 svr = fsl_guts_get_svr(guts);
+
+ guts->soc.family = "NXP QorIQ";
+ id = of_match_node(fsl_guts_of_match, dev->of_node);
+ guts->soc.soc_id = devm_kasprintf(dev, "%s (ver 0x%06x)" id->data,
+ svr >> 8;
+ guts->soc.revision = devm_kasprintf(dev, GFP_KERNEL, "0x%02x",
+ svr & 0xff);
+}
+
+static int fsl_guts_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct guts *guts;
+ int ret;
+
+ guts = devm_kzalloc(dev, sizeof(*guts), GFP_KERNEL);
+ if (!guts) {
+ ret = -ENOMEM;
+ goto out;
+
+ }
+
+ /*
+ * syscon devices default to little-endian, but on powerpc we have
+ * existing device trees with big-endian maps and an absent endianess
+ * "big-property"
+ */
+ if (!IS_ENABLED(CONFIG_POWERPC) &&
+ !of_property_read_bool(dev->of_node, "big-endian"))
+ guts->little_endian = true;
+
+ guts->regs = devm_ioremap_resource(dev, 0);
+ if (!guts->regs) {
+ ret = -ENOMEM;
+ kfree(guts);
+ goto out;
+ }
+
+ fsl_guts_init(dev, guts);
+ ret = 0;
+out:
+ return ret;
+}
+
+static struct platform_driver fsl_soc_guts = {
+ .probe = fsl_guts_probe,
+ .driver.of_match_table = fsl_guts_of_match,
+};
+
+module_platform_driver(fsl_soc_guts);
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-05-30 13:15 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-30 13:15 UTC (permalink / raw)
To: linux-arm-kernel
From: Yangbo Lu <yangbo.lu@nxp.com>
The global utilities block controls power management, I/O device
enabling, power-onreset(POR) configuration monitoring, alternate
function selection for multiplexed signals,and clock control.
This patch adds GUTS driver to manage and access global utilities
block.
[arnd turned this into a platform_driver registering a soc_device
rather than providing an ad-hoc interface for soc-id]
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index cb58ef0d9b2c..7106463f118e 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -2,7 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
source "drivers/soc/bcm/Kconfig"
source "drivers/soc/brcmstb/Kconfig"
-source "drivers/soc/fsl/qe/Kconfig"
+source "drivers/soc/fsl/Kconfig"
source "drivers/soc/mediatek/Kconfig"
source "drivers/soc/qcom/Kconfig"
source "drivers/soc/rockchip/Kconfig"
diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
new file mode 100644
index 000000000000..33d331cac8d6
--- /dev/null
+++ b/drivers/soc/fsl/Kconfig
@@ -0,0 +1,15 @@
+#
+# Freescale SOC drivers
+#
+
+source "drivers/soc/fsl/qe/Kconfig"
+
+config FSL_GUTS
+ bool "NXP Layerscale SoC identification"
+ depends on PPC_FSL || SOC_LS1021A || ARCH_LAYERSCAPE || COMPILE_TEST
+ default PPC_FSL || SOC_LS1021A || ARCH_LAYERSCAPE
+ select SOC_BUS
+ help
+ This registers a SoC device for NXP (formerly Freescale)
+ Layerscape devices, making information about the system
+ available in /sys/devices/soc/
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 203307fd92c1..02afb7f980f6 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_QUICC_ENGINE) += qe/
obj-$(CONFIG_CPM) += qe/
+obj-$(CONFIG_FSL_GUTS) += guts.o
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
new file mode 100644
index 000000000000..2f30698f5bcf
--- /dev/null
+++ b/drivers/soc/fsl/guts.c
@@ -0,0 +1,130 @@
+/*
+ * Freescale QorIQ Platforms GUTS Driver
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/io.h>
+#include <linux/platform_device.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/sys_soc.h>
+
+#define GUTS_PVR 0x0a0
+#define GUTS_SVR 0x0a4
+
+struct guts {
+ void __iomem *regs;
+ bool little_endian;
+ struct soc_device_attribute soc;
+};
+
+static u32 fsl_guts_get_svr(struct guts *guts)
+{
+ if (guts->little_endian)
+ return ioread32(guts->regs + GUTS_SVR);
+ else
+ return ioread32be(guts->regs + GUTS_SVR);
+}
+
+static u32 fsl_guts_get_pvr(struct guts *guts)
+{
+ if (guts->little_endian)
+ return ioread32(guts->regs + GUTS_PVR);
+ else
+ return ioread32be(guts->regs + GUTS_PVR);
+}
+
+/*
+ * Table for matching compatible strings, for device tree
+ * guts node, for Freescale QorIQ SOCs.
+ */
+static const struct of_device_id fsl_guts_of_match[] = {
+ /* For T4 & B4 Series SOCs */
+ { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4 series" },
+ /* For P Series SOCs */
+ { .compatible = "fsl,p1010-guts", .data = "P1010/P1014" },
+ { .compatible = "fsl,p1020-guts", .data = "P1020/P1011" },
+ { .compatible = "fsl,p1021-guts", .data = "P1021/P1012" },
+ { .compatible = "fsl,p1022-guts", .data = "P1022/P1013" },
+ { .compatible = "fsl,p1023-guts", .data = "P1013/P1017" },
+ { .compatible = "fsl,p2020-guts", .data = "P2010/P2020" },
+ { .compatible = "fsl,qoriq-device-config-2.0", .data = "P series" },
+ /* For BSC Series SOCs */
+ { .compatible = "fsl,bsc9131-guts", .data = "BSC9131 Qonverge" },
+ { .compatible = "fsl,bsc9132-guts", .data = "BSC9132 Qonverge" },
+ /* For MPC85xx Series SOCs */
+ { .compatible = "fsl,mpc8536-guts", .data = "PowerPC MPC8536" },
+ { .compatible = "fsl,mpc8544-guts", .data = "PowerPC MPC8544" },
+ { .compatible = "fsl,mpc8548-guts", .data = "PowerPC MPC8548" },
+ { .compatible = "fsl,mpc8568-guts", .data = "PowerPC MPC8568" },
+ { .compatible = "fsl,mpc8569-guts", .data = "PowerPC MPC8569" },
+ { .compatible = "fsl,mpc8572-guts", .data = "PowerPC MPC8572" },
+ /* For Layerscape Series SOCs */
+ { .compatible = "fsl,ls1021a-dcfg", .data = "Layerscape LS1021A" },
+ { .compatible = "fsl,ls1043a-dcfg", .data = "Layerscape LS1043A" },
+ { .compatible = "fsl,ls2080a-dcfg", .data = "Layerscape LS2080A" },
+ {}
+};
+
+static void fsl_guts_init(struct device *dev, struct guts *guts)
+{
+ const struct of_device_id *id;
+ u32 svr = fsl_guts_get_svr(guts);
+
+ guts->soc.family = "NXP QorIQ";
+ id = of_match_node(fsl_guts_of_match, dev->of_node);
+ guts->soc.soc_id = devm_kasprintf(dev, "%s (ver 0x%06x)" id->data,
+ svr >> 8;
+ guts->soc.revision = devm_kasprintf(dev, GFP_KERNEL, "0x%02x",
+ svr & 0xff);
+}
+
+static int fsl_guts_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct guts *guts;
+ int ret;
+
+ guts = devm_kzalloc(dev, sizeof(*guts), GFP_KERNEL);
+ if (!guts) {
+ ret = -ENOMEM;
+ goto out;
+
+ }
+
+ /*
+ * syscon devices default to little-endian, but on powerpc we have
+ * existing device trees with big-endian maps and an absent endianess
+ * "big-property"
+ */
+ if (!IS_ENABLED(CONFIG_POWERPC) &&
+ !of_property_read_bool(dev->of_node, "big-endian"))
+ guts->little_endian = true;
+
+ guts->regs = devm_ioremap_resource(dev, 0);
+ if (!guts->regs) {
+ ret = -ENOMEM;
+ kfree(guts);
+ goto out;
+ }
+
+ fsl_guts_init(dev, guts);
+ ret = 0;
+out:
+ return ret;
+}
+
+static struct platform_driver fsl_soc_guts = {
+ .probe = fsl_guts_probe,
+ .driver.of_match_table = fsl_guts_of_match,
+};
+
+module_platform_driver(fsl_soc_guts);
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [PATCH 3/4] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
2016-05-26 7:44 ` Ulf Hansson
(?)
(?)
@ 2016-05-30 13:16 ` Arnd Bergmann
-1 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-30 13:16 UTC (permalink / raw)
To: linuxppc-dev
Cc: Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Scott Wood,
Rob Herring, Santosh Shilimkar, linux-arm-kernel, netdev,
linux-mmc, linux-kernel, Yang-Leo Li, iommu, Kumar Gala
This is a rewrite of an earlier patch from Yangbo Lu, adding a quirk
for the NXP QorIQ T4240 in the detection of the host device version.
Unfortunately, this device cannot be detected using the compatible
string, as we have to support existing DTS files that use the generic
"fsl,t4240-esdhc" identifier but that have other host versions that
are correctly detected.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
index 3f34d354f1fc..1d4814fe4cb2 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -73,14 +73,16 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
static u16 esdhc_readw_fixup(struct sdhci_host *host,
int spec_reg, u32 value)
{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
u16 ret;
int shift = (spec_reg & 0x2) * 8;
if (spec_reg == SDHCI_HOST_VERSION)
- ret = value & 0xffff;
- else
- ret = (value >> shift) & 0xffff;
- return ret;
+ return esdhc->vendor_ver << SDHCI_VENDOR_VER_SHIFT |
+ esdhc->spec_ver;
+
+ return (value >> shift) & 0xffff;
}
static u8 esdhc_readb_fixup(struct sdhci_host *host,
@@ -562,16 +564,32 @@ static const struct sdhci_pltfm_data sdhci_esdhc_le_pdata = {
.ops = &sdhci_esdhc_le_ops,
};
+#define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) | SDHCI_SPEC_200)
+static const struct soc_device_attribute esdhc_t4240_quirk = {
+ /* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200 */
+ { .soc_id = "T4*(0x824000)", .revision = "0x[01]?",
+ .data = (void *)(uintptr_t)(T4240_HOST_VER) },
+ { },
+};
+
static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host)
{
struct sdhci_pltfm_host *pltfm_host;
struct sdhci_esdhc *esdhc;
- u16 host_ver;
pltfm_host = sdhci_priv(host);
esdhc = sdhci_pltfm_priv(pltfm_host);
host_ver = sdhci_readw(host, SDHCI_HOST_VERSION);
+
+ if (of_device_is_compatible(pdev->dev.of_node, "fsl,t4240-esdhc")) {
+ struct soc_device_attribute *match;
+
+ match = soc_device_match(&esdhc_t4240_quirk);
+ if (match)
+ host_ver = (uintptr_t)match->data;
+ }
+
esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >>
SDHCI_VENDOR_VER_SHIFT;
esdhc->spec_ver = host_ver & SDHCI_SPEC_VER_MASK;
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [PATCH 3/4] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-30 13:16 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-30 13:16 UTC (permalink / raw)
To: linuxppc-dev
Cc: Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Scott Wood,
Rob Herring, Santosh Shilimkar, linux-arm-kernel, netdev,
linux-mmc, linux-kernel, Yang-Leo
This is a rewrite of an earlier patch from Yangbo Lu, adding a quirk
for the NXP QorIQ T4240 in the detection of the host device version.
Unfortunately, this device cannot be detected using the compatible
string, as we have to support existing DTS files that use the generic
"fsl,t4240-esdhc" identifier but that have other host versions that
are correctly detected.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
index 3f34d354f1fc..1d4814fe4cb2 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -73,14 +73,16 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
static u16 esdhc_readw_fixup(struct sdhci_host *host,
int spec_reg, u32 value)
{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
u16 ret;
int shift = (spec_reg & 0x2) * 8;
if (spec_reg == SDHCI_HOST_VERSION)
- ret = value & 0xffff;
- else
- ret = (value >> shift) & 0xffff;
- return ret;
+ return esdhc->vendor_ver << SDHCI_VENDOR_VER_SHIFT |
+ esdhc->spec_ver;
+
+ return (value >> shift) & 0xffff;
}
static u8 esdhc_readb_fixup(struct sdhci_host *host,
@@ -562,16 +564,32 @@ static const struct sdhci_pltfm_data sdhci_esdhc_le_pdata = {
.ops = &sdhci_esdhc_le_ops,
};
+#define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) | SDHCI_SPEC_200)
+static const struct soc_device_attribute esdhc_t4240_quirk = {
+ /* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200 */
+ { .soc_id = "T4*(0x824000)", .revision = "0x[01]?",
+ .data = (void *)(uintptr_t)(T4240_HOST_VER) },
+ { },
+};
+
static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host)
{
struct sdhci_pltfm_host *pltfm_host;
struct sdhci_esdhc *esdhc;
- u16 host_ver;
pltfm_host = sdhci_priv(host);
esdhc = sdhci_pltfm_priv(pltfm_host);
host_ver = sdhci_readw(host, SDHCI_HOST_VERSION);
+
+ if (of_device_is_compatible(pdev->dev.of_node, "fsl,t4240-esdhc")) {
+ struct soc_device_attribute *match;
+
+ match = soc_device_match(&esdhc_t4240_quirk);
+ if (match)
+ host_ver = (uintptr_t)match->data;
+ }
+
esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >>
SDHCI_VENDOR_VER_SHIFT;
esdhc->spec_ver = host_ver & SDHCI_SPEC_VER_MASK;
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [PATCH 3/4] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-30 13:16 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-30 13:16 UTC (permalink / raw)
To: linuxppc-dev
Cc: Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Scott Wood,
Rob Herring, Santosh Shilimkar, linux-arm-kernel, netdev,
linux-mmc, linux-kernel, Yang-Leo Li, iommu, Kumar Gala
This is a rewrite of an earlier patch from Yangbo Lu, adding a quirk
for the NXP QorIQ T4240 in the detection of the host device version.
Unfortunately, this device cannot be detected using the compatible
string, as we have to support existing DTS files that use the generic
"fsl,t4240-esdhc" identifier but that have other host versions that
are correctly detected.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
index 3f34d354f1fc..1d4814fe4cb2 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -73,14 +73,16 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
static u16 esdhc_readw_fixup(struct sdhci_host *host,
int spec_reg, u32 value)
{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
u16 ret;
int shift = (spec_reg & 0x2) * 8;
if (spec_reg == SDHCI_HOST_VERSION)
- ret = value & 0xffff;
- else
- ret = (value >> shift) & 0xffff;
- return ret;
+ return esdhc->vendor_ver << SDHCI_VENDOR_VER_SHIFT |
+ esdhc->spec_ver;
+
+ return (value >> shift) & 0xffff;
}
static u8 esdhc_readb_fixup(struct sdhci_host *host,
@@ -562,16 +564,32 @@ static const struct sdhci_pltfm_data sdhci_esdhc_le_pdata = {
.ops = &sdhci_esdhc_le_ops,
};
+#define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) | SDHCI_SPEC_200)
+static const struct soc_device_attribute esdhc_t4240_quirk = {
+ /* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200 */
+ { .soc_id = "T4*(0x824000)", .revision = "0x[01]?",
+ .data = (void *)(uintptr_t)(T4240_HOST_VER) },
+ { },
+};
+
static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host)
{
struct sdhci_pltfm_host *pltfm_host;
struct sdhci_esdhc *esdhc;
- u16 host_ver;
pltfm_host = sdhci_priv(host);
esdhc = sdhci_pltfm_priv(pltfm_host);
host_ver = sdhci_readw(host, SDHCI_HOST_VERSION);
+
+ if (of_device_is_compatible(pdev->dev.of_node, "fsl,t4240-esdhc")) {
+ struct soc_device_attribute *match;
+
+ match = soc_device_match(&esdhc_t4240_quirk);
+ if (match)
+ host_ver = (uintptr_t)match->data;
+ }
+
esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >>
SDHCI_VENDOR_VER_SHIFT;
esdhc->spec_ver = host_ver & SDHCI_SPEC_VER_MASK;
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [PATCH 3/4] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-05-30 13:16 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-30 13:16 UTC (permalink / raw)
To: linux-arm-kernel
This is a rewrite of an earlier patch from Yangbo Lu, adding a quirk
for the NXP QorIQ T4240 in the detection of the host device version.
Unfortunately, this device cannot be detected using the compatible
string, as we have to support existing DTS files that use the generic
"fsl,t4240-esdhc" identifier but that have other host versions that
are correctly detected.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
index 3f34d354f1fc..1d4814fe4cb2 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -73,14 +73,16 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
static u16 esdhc_readw_fixup(struct sdhci_host *host,
int spec_reg, u32 value)
{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
u16 ret;
int shift = (spec_reg & 0x2) * 8;
if (spec_reg == SDHCI_HOST_VERSION)
- ret = value & 0xffff;
- else
- ret = (value >> shift) & 0xffff;
- return ret;
+ return esdhc->vendor_ver << SDHCI_VENDOR_VER_SHIFT |
+ esdhc->spec_ver;
+
+ return (value >> shift) & 0xffff;
}
static u8 esdhc_readb_fixup(struct sdhci_host *host,
@@ -562,16 +564,32 @@ static const struct sdhci_pltfm_data sdhci_esdhc_le_pdata = {
.ops = &sdhci_esdhc_le_ops,
};
+#define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) | SDHCI_SPEC_200)
+static const struct soc_device_attribute esdhc_t4240_quirk = {
+ /* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200 */
+ { .soc_id = "T4*(0x824000)", .revision = "0x[01]?",
+ .data = (void *)(uintptr_t)(T4240_HOST_VER) },
+ { },
+};
+
static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host)
{
struct sdhci_pltfm_host *pltfm_host;
struct sdhci_esdhc *esdhc;
- u16 host_ver;
pltfm_host = sdhci_priv(host);
esdhc = sdhci_pltfm_priv(pltfm_host);
host_ver = sdhci_readw(host, SDHCI_HOST_VERSION);
+
+ if (of_device_is_compatible(pdev->dev.of_node, "fsl,t4240-esdhc")) {
+ struct soc_device_attribute *match;
+
+ match = soc_device_match(&esdhc_t4240_quirk);
+ if (match)
+ host_ver = (uintptr_t)match->data;
+ }
+
esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >>
SDHCI_VENDOR_VER_SHIFT;
esdhc->spec_ver = host_ver & SDHCI_SPEC_VER_MASK;
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [PATCH 4/4] Revert "powerpc/fsl: Move fsl_guts.h out of arch/powerpc"
2016-05-26 7:44 ` Ulf Hansson
(?)
(?)
@ 2016-05-30 13:18 ` Arnd Bergmann
-1 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-30 13:18 UTC (permalink / raw)
To: linuxppc-dev
Cc: Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Scott Wood,
Rob Herring, Santosh Shilimkar, linux-arm-kernel, netdev,
linux-mmc, linux-kernel, Yang-Leo Li, iommu, Kumar Gala
All users of this driver are PowerPC specific and the header file
has no business in the global include/linux/ hierarchy, so move
it back before anyone starts using it on ARM.
This reverts commit 948486544713492f00ac8a9572909101ea892cb0.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
This part of the series is not required for the eSDHC quirk,
but it restores the asm/fsl_guts.h header so it doesn't accidentally
get abused for this in the future. I found two drivers outside of
arch/powerpc that already accessed the registers directly, but the
functions look fairly contained, and can be easily hidden in an
#ifdef CONFIG_PPC
diff --git a/include/linux/fsl/guts.h b/arch/powerpc/include/asm/fsl_guts.h
similarity index 99%
rename from include/linux/fsl/guts.h
rename to arch/powerpc/include/asm/fsl_guts.h
index 649e9171a9b3..a67413c52701 100644
--- a/include/linux/fsl/guts.h
+++ b/arch/powerpc/include/asm/fsl_guts.h
@@ -12,10 +12,9 @@
* option) any later version.
*/
-#ifndef __FSL_GUTS_H__
-#define __FSL_GUTS_H__
-
-#include <linux/types.h>
+#ifndef __ASM_POWERPC_FSL_GUTS_H__
+#define __ASM_POWERPC_FSL_GUTS_H__
+#ifdef __KERNEL__
/**
* Global Utility Registers.
@@ -295,3 +294,4 @@ struct ccsr_rcpm_v2 {
};
#endif
+#endif
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index f61cbe235581..00f052e9f2a2 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -34,7 +34,6 @@
#include <linux/of_device.h>
#include <linux/phy.h>
#include <linux/memblock.h>
-#include <linux/fsl/guts.h>
#include <linux/atomic.h>
#include <asm/time.h>
@@ -52,6 +51,7 @@
#include <soc/fsl/qe/qe_ic.h>
#include <asm/mpic.h>
#include <asm/swiotlb.h>
+#include <asm/fsl_guts.h>
#include "smp.h"
#include "mpc85xx.h"
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c b/arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c
index f05325f0cc03..a812c0511252 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c
@@ -14,8 +14,8 @@
#include <linux/kernel.h>
#include <linux/of.h>
#include <linux/of_address.h>
-#include <linux/fsl/guts.h>
+#include <asm/fsl_guts.h>
#include <asm/io.h>
#include <asm/fsl_pm.h>
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index 3f4dad133338..453ddda00fce 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -17,7 +17,6 @@
#include <linux/seq_file.h>
#include <linux/interrupt.h>
#include <linux/of_platform.h>
-#include <linux/fsl/guts.h>
#include <asm/time.h>
#include <asm/machdep.h>
@@ -28,6 +27,7 @@
#include <asm/mpic.h>
#include <soc/fsl/qe/qe.h>
#include <soc/fsl/qe/qe_ic.h>
+#include <asm/fsl_guts.h>
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c b/arch/powerpc/platforms/85xx/p1022_ds.c
index 371df822e88e..6ac986d3f8a3 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -16,7 +16,6 @@
* kind, whether express or implied.
*/
-#include <linux/fsl/guts.h>
#include <linux/pci.h>
#include <linux/of_platform.h>
#include <asm/div64.h>
@@ -26,6 +25,7 @@
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
#include <asm/udbg.h>
+#include <asm/fsl_guts.h>
#include <asm/fsl_lbc.h>
#include "smp.h"
diff --git a/arch/powerpc/platforms/85xx/p1022_rdk.c b/arch/powerpc/platforms/85xx/p1022_rdk.c
index 5087becaa8bc..680232d6ba48 100644
--- a/arch/powerpc/platforms/85xx/p1022_rdk.c
+++ b/arch/powerpc/platforms/85xx/p1022_rdk.c
@@ -12,7 +12,6 @@
* kind, whether express or implied.
*/
-#include <linux/fsl/guts.h>
#include <linux/pci.h>
#include <linux/of_platform.h>
#include <asm/div64.h>
@@ -22,6 +21,7 @@
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
#include <asm/udbg.h>
+#include <asm/fsl_guts.h>
#include "smp.h"
#include "mpc85xx.h"
diff --git a/arch/powerpc/platforms/85xx/smp.c b/arch/powerpc/platforms/85xx/smp.c
index fe9f19e5e935..6bd3a292e790 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -18,7 +18,6 @@
#include <linux/kexec.h>
#include <linux/highmem.h>
#include <linux/cpu.h>
-#include <linux/fsl/guts.h>
#include <asm/machdep.h>
#include <asm/pgtable.h>
@@ -26,6 +25,7 @@
#include <asm/mpic.h>
#include <asm/cacheflush.h>
#include <asm/dbell.h>
+#include <asm/fsl_guts.h>
#include <asm/code-patching.h>
#include <asm/cputhreads.h>
#include <asm/fsl_pm.h>
diff --git a/arch/powerpc/platforms/85xx/twr_p102x.c b/arch/powerpc/platforms/85xx/twr_p102x.c
index 71bc255b4324..2cac45f72d24 100644
--- a/arch/powerpc/platforms/85xx/twr_p102x.c
+++ b/arch/powerpc/platforms/85xx/twr_p102x.c
@@ -15,7 +15,6 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/errno.h>
-#include <linux/fsl/guts.h>
#include <linux/pci.h>
#include <linux/of_platform.h>
@@ -24,6 +23,7 @@
#include <asm/mpic.h>
#include <soc/fsl/qe/qe.h>
#include <soc/fsl/qe/qe_ic.h>
+#include <asm/fsl_guts.h>
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
index 957473e5c8e5..761c81476957 100644
--- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
+++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
@@ -24,7 +24,6 @@
#include <linux/delay.h>
#include <linux/seq_file.h>
#include <linux/of.h>
-#include <linux/fsl/guts.h>
#include <asm/time.h>
#include <asm/machdep.h>
@@ -39,6 +38,7 @@
#include <sysdev/fsl_pci.h>
#include <sysdev/fsl_soc.h>
#include <sysdev/simple_gpio.h>
+#include <asm/fsl_guts.h>
#include "mpc86xx.h"
diff --git a/arch/powerpc/sysdev/fsl_rcpm.c b/arch/powerpc/sysdev/fsl_rcpm.c
index 9259a94f70e1..8af22187cb25 100644
--- a/arch/powerpc/sysdev/fsl_rcpm.c
+++ b/arch/powerpc/sysdev/fsl_rcpm.c
@@ -19,7 +19,7 @@
#include <linux/export.h>
#include <asm/io.h>
-#include <linux/fsl/guts.h>
+#include <asm/fsl_guts.h>
#include <asm/cputhreads.h>
#include <asm/fsl_pm.h>
#include <asm/smp.h>
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
index 58566a17944a..f311bd399672 100644
--- a/drivers/clk/clk-qoriq.c
+++ b/drivers/clk/clk-qoriq.c
@@ -12,7 +12,6 @@
#include <linux/clk.h>
#include <linux/clk-provider.h>
-#include <linux/fsl/guts.h>
#include <linux/io.h>
#include <linux/kernel.h>
#include <linux/module.h>
@@ -21,6 +20,10 @@
#include <linux/of.h>
#include <linux/slab.h>
+#ifdef CONFIG_PPC
+#include <asm/fsl_guts.h>
+#endif
+
#define PLL_DIV1 0
#define PLL_DIV2 1
#define PLL_DIV3 2
@@ -341,6 +344,8 @@ static const struct clockgen_muxinfo t4240_hwa5 = {
},
};
+#ifdef CONFIG_PPC
+
#define RCWSR7_FM1_CLK_SEL 0x40000000
#define RCWSR7_FM2_CLK_SEL 0x20000000
#define RCWSR7_HWA_ASYNC_DIV 0x04000000
@@ -408,6 +413,7 @@ static void __init p5040_init_periph(struct clockgen *cg)
else
cg->fman[1] = cg->pll[PLATFORM_PLL].div[PLL_DIV2].clk;
}
+#endif
static void __init t1023_init_periph(struct clockgen *cg)
{
@@ -499,6 +505,7 @@ static const struct clockgen_chipinfo chipinfo[] = {
.pll_mask = 0x37,
.flags = CG_VER3 | CG_LITTLE_ENDIAN,
},
+#ifdef CONFIG_PPC
{
.compat = "fsl,p2041-clockgen",
.guts_compat = "fsl,qoriq-device-config-1.0",
@@ -559,6 +566,7 @@ static const struct clockgen_chipinfo chipinfo[] = {
},
.pll_mask = 0x0f,
},
+#endif
{
.compat = "fsl,t1023-clockgen",
.guts_compat = "fsl,t1023-device-config",
diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index a34355fca37a..2570f2a25dc4 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -20,11 +20,11 @@
#include "fsl_pamu.h"
-#include <linux/fsl/guts.h>
#include <linux/interrupt.h>
#include <linux/genalloc.h>
#include <asm/mpc85xx.h>
+#include <asm/fsl_guts.h>
/* define indexes for each operation mapping scenario */
#define OMI_QMAN 0x00
diff --git a/drivers/net/ethernet/freescale/fman/fman.c b/drivers/net/ethernet/freescale/fman/fman.c
index 1de2e1e51c2b..dabee93fcadd 100644
--- a/drivers/net/ethernet/freescale/fman/fman.c
+++ b/drivers/net/ethernet/freescale/fman/fman.c
@@ -35,7 +35,6 @@
#include "fman.h"
#include "fman_muram.h"
-#include <linux/fsl/guts.h>
#include <linux/slab.h>
#include <linux/delay.h>
#include <linux/module.h>
@@ -46,6 +45,10 @@
#include <linux/interrupt.h>
#include <linux/libfdt_env.h>
+#ifdef CONFIG_PPC
+#include <asm/fsl_guts.h>
+#endif
+
/* General defines */
#define FMAN_LIODN_TBL 64 /* size of LIODN table */
#define MAX_NUM_OF_MACS 10
@@ -1889,7 +1892,9 @@ static int fman_reset(struct fman *fman)
err = -EBUSY;
goto _return;
- } else {
+ }
+#ifdef CONFIG_PPC
+ else {
struct device_node *guts_node;
struct ccsr_guts __iomem *guts_regs;
u32 devdisr2, reg;
@@ -1952,6 +1957,7 @@ guts_node:
dev_dbg(fman->dev, "%s: Didn't perform FManV3 reset due to Errata A007273!\n",
__func__);
}
+#endif
_return:
return err;
}
diff --git a/sound/soc/fsl/mpc8610_hpcd.c b/sound/soc/fsl/mpc8610_hpcd.c
index ddf49f30b23f..73b2b89d4a3e 100644
--- a/sound/soc/fsl/mpc8610_hpcd.c
+++ b/sound/soc/fsl/mpc8610_hpcd.c
@@ -12,11 +12,11 @@
#include <linux/module.h>
#include <linux/interrupt.h>
-#include <linux/fsl/guts.h>
#include <linux/of_address.h>
#include <linux/of_device.h>
#include <linux/slab.h>
#include <sound/soc.h>
+#include <asm/fsl_guts.h>
#include "fsl_dma.h"
#include "fsl_ssi.h"
diff --git a/sound/soc/fsl/p1022_ds.c b/sound/soc/fsl/p1022_ds.c
index a1f780ecadf5..a24e04919f71 100644
--- a/sound/soc/fsl/p1022_ds.c
+++ b/sound/soc/fsl/p1022_ds.c
@@ -11,12 +11,12 @@
*/
#include <linux/module.h>
-#include <linux/fsl/guts.h>
#include <linux/interrupt.h>
#include <linux/of_address.h>
#include <linux/of_device.h>
#include <linux/slab.h>
#include <sound/soc.h>
+#include <asm/fsl_guts.h>
#include "fsl_dma.h"
#include "fsl_ssi.h"
diff --git a/sound/soc/fsl/p1022_rdk.c b/sound/soc/fsl/p1022_rdk.c
index d4d88a8cb9c0..d8448887bfda 100644
--- a/sound/soc/fsl/p1022_rdk.c
+++ b/sound/soc/fsl/p1022_rdk.c
@@ -18,12 +18,12 @@
*/
#include <linux/module.h>
-#include <linux/fsl/guts.h>
#include <linux/interrupt.h>
#include <linux/of_address.h>
#include <linux/of_device.h>
#include <linux/slab.h>
#include <sound/soc.h>
+#include <asm/fsl_guts.h>
#include "fsl_dma.h"
#include "fsl_ssi.h"
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [PATCH 4/4] Revert "powerpc/fsl: Move fsl_guts.h out of arch/powerpc"
@ 2016-05-30 13:18 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-30 13:18 UTC (permalink / raw)
To: linuxppc-dev
Cc: Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Scott Wood,
Rob Herring, Santosh Shilimkar, linux-arm-kernel, netdev,
linux-mmc, linux-kernel, Yang-Leo
All users of this driver are PowerPC specific and the header file
has no business in the global include/linux/ hierarchy, so move
it back before anyone starts using it on ARM.
This reverts commit 948486544713492f00ac8a9572909101ea892cb0.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
This part of the series is not required for the eSDHC quirk,
but it restores the asm/fsl_guts.h header so it doesn't accidentally
get abused for this in the future. I found two drivers outside of
arch/powerpc that already accessed the registers directly, but the
functions look fairly contained, and can be easily hidden in an
#ifdef CONFIG_PPC
diff --git a/include/linux/fsl/guts.h b/arch/powerpc/include/asm/fsl_guts.h
similarity index 99%
rename from include/linux/fsl/guts.h
rename to arch/powerpc/include/asm/fsl_guts.h
index 649e9171a9b3..a67413c52701 100644
--- a/include/linux/fsl/guts.h
+++ b/arch/powerpc/include/asm/fsl_guts.h
@@ -12,10 +12,9 @@
* option) any later version.
*/
-#ifndef __FSL_GUTS_H__
-#define __FSL_GUTS_H__
-
-#include <linux/types.h>
+#ifndef __ASM_POWERPC_FSL_GUTS_H__
+#define __ASM_POWERPC_FSL_GUTS_H__
+#ifdef __KERNEL__
/**
* Global Utility Registers.
@@ -295,3 +294,4 @@ struct ccsr_rcpm_v2 {
};
#endif
+#endif
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index f61cbe235581..00f052e9f2a2 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -34,7 +34,6 @@
#include <linux/of_device.h>
#include <linux/phy.h>
#include <linux/memblock.h>
-#include <linux/fsl/guts.h>
#include <linux/atomic.h>
#include <asm/time.h>
@@ -52,6 +51,7 @@
#include <soc/fsl/qe/qe_ic.h>
#include <asm/mpic.h>
#include <asm/swiotlb.h>
+#include <asm/fsl_guts.h>
#include "smp.h"
#include "mpc85xx.h"
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c b/arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c
index f05325f0cc03..a812c0511252 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c
@@ -14,8 +14,8 @@
#include <linux/kernel.h>
#include <linux/of.h>
#include <linux/of_address.h>
-#include <linux/fsl/guts.h>
+#include <asm/fsl_guts.h>
#include <asm/io.h>
#include <asm/fsl_pm.h>
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index 3f4dad133338..453ddda00fce 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -17,7 +17,6 @@
#include <linux/seq_file.h>
#include <linux/interrupt.h>
#include <linux/of_platform.h>
-#include <linux/fsl/guts.h>
#include <asm/time.h>
#include <asm/machdep.h>
@@ -28,6 +27,7 @@
#include <asm/mpic.h>
#include <soc/fsl/qe/qe.h>
#include <soc/fsl/qe/qe_ic.h>
+#include <asm/fsl_guts.h>
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c b/arch/powerpc/platforms/85xx/p1022_ds.c
index 371df822e88e..6ac986d3f8a3 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -16,7 +16,6 @@
* kind, whether express or implied.
*/
-#include <linux/fsl/guts.h>
#include <linux/pci.h>
#include <linux/of_platform.h>
#include <asm/div64.h>
@@ -26,6 +25,7 @@
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
#include <asm/udbg.h>
+#include <asm/fsl_guts.h>
#include <asm/fsl_lbc.h>
#include "smp.h"
diff --git a/arch/powerpc/platforms/85xx/p1022_rdk.c b/arch/powerpc/platforms/85xx/p1022_rdk.c
index 5087becaa8bc..680232d6ba48 100644
--- a/arch/powerpc/platforms/85xx/p1022_rdk.c
+++ b/arch/powerpc/platforms/85xx/p1022_rdk.c
@@ -12,7 +12,6 @@
* kind, whether express or implied.
*/
-#include <linux/fsl/guts.h>
#include <linux/pci.h>
#include <linux/of_platform.h>
#include <asm/div64.h>
@@ -22,6 +21,7 @@
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
#include <asm/udbg.h>
+#include <asm/fsl_guts.h>
#include "smp.h"
#include "mpc85xx.h"
diff --git a/arch/powerpc/platforms/85xx/smp.c b/arch/powerpc/platforms/85xx/smp.c
index fe9f19e5e935..6bd3a292e790 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -18,7 +18,6 @@
#include <linux/kexec.h>
#include <linux/highmem.h>
#include <linux/cpu.h>
-#include <linux/fsl/guts.h>
#include <asm/machdep.h>
#include <asm/pgtable.h>
@@ -26,6 +25,7 @@
#include <asm/mpic.h>
#include <asm/cacheflush.h>
#include <asm/dbell.h>
+#include <asm/fsl_guts.h>
#include <asm/code-patching.h>
#include <asm/cputhreads.h>
#include <asm/fsl_pm.h>
diff --git a/arch/powerpc/platforms/85xx/twr_p102x.c b/arch/powerpc/platforms/85xx/twr_p102x.c
index 71bc255b4324..2cac45f72d24 100644
--- a/arch/powerpc/platforms/85xx/twr_p102x.c
+++ b/arch/powerpc/platforms/85xx/twr_p102x.c
@@ -15,7 +15,6 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/errno.h>
-#include <linux/fsl/guts.h>
#include <linux/pci.h>
#include <linux/of_platform.h>
@@ -24,6 +23,7 @@
#include <asm/mpic.h>
#include <soc/fsl/qe/qe.h>
#include <soc/fsl/qe/qe_ic.h>
+#include <asm/fsl_guts.h>
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
index 957473e5c8e5..761c81476957 100644
--- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
+++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
@@ -24,7 +24,6 @@
#include <linux/delay.h>
#include <linux/seq_file.h>
#include <linux/of.h>
-#include <linux/fsl/guts.h>
#include <asm/time.h>
#include <asm/machdep.h>
@@ -39,6 +38,7 @@
#include <sysdev/fsl_pci.h>
#include <sysdev/fsl_soc.h>
#include <sysdev/simple_gpio.h>
+#include <asm/fsl_guts.h>
#include "mpc86xx.h"
diff --git a/arch/powerpc/sysdev/fsl_rcpm.c b/arch/powerpc/sysdev/fsl_rcpm.c
index 9259a94f70e1..8af22187cb25 100644
--- a/arch/powerpc/sysdev/fsl_rcpm.c
+++ b/arch/powerpc/sysdev/fsl_rcpm.c
@@ -19,7 +19,7 @@
#include <linux/export.h>
#include <asm/io.h>
-#include <linux/fsl/guts.h>
+#include <asm/fsl_guts.h>
#include <asm/cputhreads.h>
#include <asm/fsl_pm.h>
#include <asm/smp.h>
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
index 58566a17944a..f311bd399672 100644
--- a/drivers/clk/clk-qoriq.c
+++ b/drivers/clk/clk-qoriq.c
@@ -12,7 +12,6 @@
#include <linux/clk.h>
#include <linux/clk-provider.h>
-#include <linux/fsl/guts.h>
#include <linux/io.h>
#include <linux/kernel.h>
#include <linux/module.h>
@@ -21,6 +20,10 @@
#include <linux/of.h>
#include <linux/slab.h>
+#ifdef CONFIG_PPC
+#include <asm/fsl_guts.h>
+#endif
+
#define PLL_DIV1 0
#define PLL_DIV2 1
#define PLL_DIV3 2
@@ -341,6 +344,8 @@ static const struct clockgen_muxinfo t4240_hwa5 = {
},
};
+#ifdef CONFIG_PPC
+
#define RCWSR7_FM1_CLK_SEL 0x40000000
#define RCWSR7_FM2_CLK_SEL 0x20000000
#define RCWSR7_HWA_ASYNC_DIV 0x04000000
@@ -408,6 +413,7 @@ static void __init p5040_init_periph(struct clockgen *cg)
else
cg->fman[1] = cg->pll[PLATFORM_PLL].div[PLL_DIV2].clk;
}
+#endif
static void __init t1023_init_periph(struct clockgen *cg)
{
@@ -499,6 +505,7 @@ static const struct clockgen_chipinfo chipinfo[] = {
.pll_mask = 0x37,
.flags = CG_VER3 | CG_LITTLE_ENDIAN,
},
+#ifdef CONFIG_PPC
{
.compat = "fsl,p2041-clockgen",
.guts_compat = "fsl,qoriq-device-config-1.0",
@@ -559,6 +566,7 @@ static const struct clockgen_chipinfo chipinfo[] = {
},
.pll_mask = 0x0f,
},
+#endif
{
.compat = "fsl,t1023-clockgen",
.guts_compat = "fsl,t1023-device-config",
diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index a34355fca37a..2570f2a25dc4 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -20,11 +20,11 @@
#include "fsl_pamu.h"
-#include <linux/fsl/guts.h>
#include <linux/interrupt.h>
#include <linux/genalloc.h>
#include <asm/mpc85xx.h>
+#include <asm/fsl_guts.h>
/* define indexes for each operation mapping scenario */
#define OMI_QMAN 0x00
diff --git a/drivers/net/ethernet/freescale/fman/fman.c b/drivers/net/ethernet/freescale/fman/fman.c
index 1de2e1e51c2b..dabee93fcadd 100644
--- a/drivers/net/ethernet/freescale/fman/fman.c
+++ b/drivers/net/ethernet/freescale/fman/fman.c
@@ -35,7 +35,6 @@
#include "fman.h"
#include "fman_muram.h"
-#include <linux/fsl/guts.h>
#include <linux/slab.h>
#include <linux/delay.h>
#include <linux/module.h>
@@ -46,6 +45,10 @@
#include <linux/interrupt.h>
#include <linux/libfdt_env.h>
+#ifdef CONFIG_PPC
+#include <asm/fsl_guts.h>
+#endif
+
/* General defines */
#define FMAN_LIODN_TBL 64 /* size of LIODN table */
#define MAX_NUM_OF_MACS 10
@@ -1889,7 +1892,9 @@ static int fman_reset(struct fman *fman)
err = -EBUSY;
goto _return;
- } else {
+ }
+#ifdef CONFIG_PPC
+ else {
struct device_node *guts_node;
struct ccsr_guts __iomem *guts_regs;
u32 devdisr2, reg;
@@ -1952,6 +1957,7 @@ guts_node:
dev_dbg(fman->dev, "%s: Didn't perform FManV3 reset due to Errata A007273!\n",
__func__);
}
+#endif
_return:
return err;
}
diff --git a/sound/soc/fsl/mpc8610_hpcd.c b/sound/soc/fsl/mpc8610_hpcd.c
index ddf49f30b23f..73b2b89d4a3e 100644
--- a/sound/soc/fsl/mpc8610_hpcd.c
+++ b/sound/soc/fsl/mpc8610_hpcd.c
@@ -12,11 +12,11 @@
#include <linux/module.h>
#include <linux/interrupt.h>
-#include <linux/fsl/guts.h>
#include <linux/of_address.h>
#include <linux/of_device.h>
#include <linux/slab.h>
#include <sound/soc.h>
+#include <asm/fsl_guts.h>
#include "fsl_dma.h"
#include "fsl_ssi.h"
diff --git a/sound/soc/fsl/p1022_ds.c b/sound/soc/fsl/p1022_ds.c
index a1f780ecadf5..a24e04919f71 100644
--- a/sound/soc/fsl/p1022_ds.c
+++ b/sound/soc/fsl/p1022_ds.c
@@ -11,12 +11,12 @@
*/
#include <linux/module.h>
-#include <linux/fsl/guts.h>
#include <linux/interrupt.h>
#include <linux/of_address.h>
#include <linux/of_device.h>
#include <linux/slab.h>
#include <sound/soc.h>
+#include <asm/fsl_guts.h>
#include "fsl_dma.h"
#include "fsl_ssi.h"
diff --git a/sound/soc/fsl/p1022_rdk.c b/sound/soc/fsl/p1022_rdk.c
index d4d88a8cb9c0..d8448887bfda 100644
--- a/sound/soc/fsl/p1022_rdk.c
+++ b/sound/soc/fsl/p1022_rdk.c
@@ -18,12 +18,12 @@
*/
#include <linux/module.h>
-#include <linux/fsl/guts.h>
#include <linux/interrupt.h>
#include <linux/of_address.h>
#include <linux/of_device.h>
#include <linux/slab.h>
#include <sound/soc.h>
+#include <asm/fsl_guts.h>
#include "fsl_dma.h"
#include "fsl_ssi.h"
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [PATCH 4/4] Revert "powerpc/fsl: Move fsl_guts.h out of arch/powerpc"
@ 2016-05-30 13:18 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-30 13:18 UTC (permalink / raw)
To: linuxppc-dev
Cc: Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Scott Wood,
Rob Herring, Santosh Shilimkar, linux-arm-kernel, netdev,
linux-mmc, linux-kernel, Yang-Leo Li, iommu, Kumar Gala
All users of this driver are PowerPC specific and the header file
has no business in the global include/linux/ hierarchy, so move
it back before anyone starts using it on ARM.
This reverts commit 948486544713492f00ac8a9572909101ea892cb0.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
This part of the series is not required for the eSDHC quirk,
but it restores the asm/fsl_guts.h header so it doesn't accidentally
get abused for this in the future. I found two drivers outside of
arch/powerpc that already accessed the registers directly, but the
functions look fairly contained, and can be easily hidden in an
#ifdef CONFIG_PPC
diff --git a/include/linux/fsl/guts.h b/arch/powerpc/include/asm/fsl_guts.h
similarity index 99%
rename from include/linux/fsl/guts.h
rename to arch/powerpc/include/asm/fsl_guts.h
index 649e9171a9b3..a67413c52701 100644
--- a/include/linux/fsl/guts.h
+++ b/arch/powerpc/include/asm/fsl_guts.h
@@ -12,10 +12,9 @@
* option) any later version.
*/
-#ifndef __FSL_GUTS_H__
-#define __FSL_GUTS_H__
-
-#include <linux/types.h>
+#ifndef __ASM_POWERPC_FSL_GUTS_H__
+#define __ASM_POWERPC_FSL_GUTS_H__
+#ifdef __KERNEL__
/**
* Global Utility Registers.
@@ -295,3 +294,4 @@ struct ccsr_rcpm_v2 {
};
#endif
+#endif
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index f61cbe235581..00f052e9f2a2 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -34,7 +34,6 @@
#include <linux/of_device.h>
#include <linux/phy.h>
#include <linux/memblock.h>
-#include <linux/fsl/guts.h>
#include <linux/atomic.h>
#include <asm/time.h>
@@ -52,6 +51,7 @@
#include <soc/fsl/qe/qe_ic.h>
#include <asm/mpic.h>
#include <asm/swiotlb.h>
+#include <asm/fsl_guts.h>
#include "smp.h"
#include "mpc85xx.h"
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c b/arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c
index f05325f0cc03..a812c0511252 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c
@@ -14,8 +14,8 @@
#include <linux/kernel.h>
#include <linux/of.h>
#include <linux/of_address.h>
-#include <linux/fsl/guts.h>
+#include <asm/fsl_guts.h>
#include <asm/io.h>
#include <asm/fsl_pm.h>
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index 3f4dad133338..453ddda00fce 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -17,7 +17,6 @@
#include <linux/seq_file.h>
#include <linux/interrupt.h>
#include <linux/of_platform.h>
-#include <linux/fsl/guts.h>
#include <asm/time.h>
#include <asm/machdep.h>
@@ -28,6 +27,7 @@
#include <asm/mpic.h>
#include <soc/fsl/qe/qe.h>
#include <soc/fsl/qe/qe_ic.h>
+#include <asm/fsl_guts.h>
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c b/arch/powerpc/platforms/85xx/p1022_ds.c
index 371df822e88e..6ac986d3f8a3 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -16,7 +16,6 @@
* kind, whether express or implied.
*/
-#include <linux/fsl/guts.h>
#include <linux/pci.h>
#include <linux/of_platform.h>
#include <asm/div64.h>
@@ -26,6 +25,7 @@
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
#include <asm/udbg.h>
+#include <asm/fsl_guts.h>
#include <asm/fsl_lbc.h>
#include "smp.h"
diff --git a/arch/powerpc/platforms/85xx/p1022_rdk.c b/arch/powerpc/platforms/85xx/p1022_rdk.c
index 5087becaa8bc..680232d6ba48 100644
--- a/arch/powerpc/platforms/85xx/p1022_rdk.c
+++ b/arch/powerpc/platforms/85xx/p1022_rdk.c
@@ -12,7 +12,6 @@
* kind, whether express or implied.
*/
-#include <linux/fsl/guts.h>
#include <linux/pci.h>
#include <linux/of_platform.h>
#include <asm/div64.h>
@@ -22,6 +21,7 @@
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
#include <asm/udbg.h>
+#include <asm/fsl_guts.h>
#include "smp.h"
#include "mpc85xx.h"
diff --git a/arch/powerpc/platforms/85xx/smp.c b/arch/powerpc/platforms/85xx/smp.c
index fe9f19e5e935..6bd3a292e790 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -18,7 +18,6 @@
#include <linux/kexec.h>
#include <linux/highmem.h>
#include <linux/cpu.h>
-#include <linux/fsl/guts.h>
#include <asm/machdep.h>
#include <asm/pgtable.h>
@@ -26,6 +25,7 @@
#include <asm/mpic.h>
#include <asm/cacheflush.h>
#include <asm/dbell.h>
+#include <asm/fsl_guts.h>
#include <asm/code-patching.h>
#include <asm/cputhreads.h>
#include <asm/fsl_pm.h>
diff --git a/arch/powerpc/platforms/85xx/twr_p102x.c b/arch/powerpc/platforms/85xx/twr_p102x.c
index 71bc255b4324..2cac45f72d24 100644
--- a/arch/powerpc/platforms/85xx/twr_p102x.c
+++ b/arch/powerpc/platforms/85xx/twr_p102x.c
@@ -15,7 +15,6 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/errno.h>
-#include <linux/fsl/guts.h>
#include <linux/pci.h>
#include <linux/of_platform.h>
@@ -24,6 +23,7 @@
#include <asm/mpic.h>
#include <soc/fsl/qe/qe.h>
#include <soc/fsl/qe/qe_ic.h>
+#include <asm/fsl_guts.h>
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
index 957473e5c8e5..761c81476957 100644
--- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
+++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
@@ -24,7 +24,6 @@
#include <linux/delay.h>
#include <linux/seq_file.h>
#include <linux/of.h>
-#include <linux/fsl/guts.h>
#include <asm/time.h>
#include <asm/machdep.h>
@@ -39,6 +38,7 @@
#include <sysdev/fsl_pci.h>
#include <sysdev/fsl_soc.h>
#include <sysdev/simple_gpio.h>
+#include <asm/fsl_guts.h>
#include "mpc86xx.h"
diff --git a/arch/powerpc/sysdev/fsl_rcpm.c b/arch/powerpc/sysdev/fsl_rcpm.c
index 9259a94f70e1..8af22187cb25 100644
--- a/arch/powerpc/sysdev/fsl_rcpm.c
+++ b/arch/powerpc/sysdev/fsl_rcpm.c
@@ -19,7 +19,7 @@
#include <linux/export.h>
#include <asm/io.h>
-#include <linux/fsl/guts.h>
+#include <asm/fsl_guts.h>
#include <asm/cputhreads.h>
#include <asm/fsl_pm.h>
#include <asm/smp.h>
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
index 58566a17944a..f311bd399672 100644
--- a/drivers/clk/clk-qoriq.c
+++ b/drivers/clk/clk-qoriq.c
@@ -12,7 +12,6 @@
#include <linux/clk.h>
#include <linux/clk-provider.h>
-#include <linux/fsl/guts.h>
#include <linux/io.h>
#include <linux/kernel.h>
#include <linux/module.h>
@@ -21,6 +20,10 @@
#include <linux/of.h>
#include <linux/slab.h>
+#ifdef CONFIG_PPC
+#include <asm/fsl_guts.h>
+#endif
+
#define PLL_DIV1 0
#define PLL_DIV2 1
#define PLL_DIV3 2
@@ -341,6 +344,8 @@ static const struct clockgen_muxinfo t4240_hwa5 = {
},
};
+#ifdef CONFIG_PPC
+
#define RCWSR7_FM1_CLK_SEL 0x40000000
#define RCWSR7_FM2_CLK_SEL 0x20000000
#define RCWSR7_HWA_ASYNC_DIV 0x04000000
@@ -408,6 +413,7 @@ static void __init p5040_init_periph(struct clockgen *cg)
else
cg->fman[1] = cg->pll[PLATFORM_PLL].div[PLL_DIV2].clk;
}
+#endif
static void __init t1023_init_periph(struct clockgen *cg)
{
@@ -499,6 +505,7 @@ static const struct clockgen_chipinfo chipinfo[] = {
.pll_mask = 0x37,
.flags = CG_VER3 | CG_LITTLE_ENDIAN,
},
+#ifdef CONFIG_PPC
{
.compat = "fsl,p2041-clockgen",
.guts_compat = "fsl,qoriq-device-config-1.0",
@@ -559,6 +566,7 @@ static const struct clockgen_chipinfo chipinfo[] = {
},
.pll_mask = 0x0f,
},
+#endif
{
.compat = "fsl,t1023-clockgen",
.guts_compat = "fsl,t1023-device-config",
diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index a34355fca37a..2570f2a25dc4 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -20,11 +20,11 @@
#include "fsl_pamu.h"
-#include <linux/fsl/guts.h>
#include <linux/interrupt.h>
#include <linux/genalloc.h>
#include <asm/mpc85xx.h>
+#include <asm/fsl_guts.h>
/* define indexes for each operation mapping scenario */
#define OMI_QMAN 0x00
diff --git a/drivers/net/ethernet/freescale/fman/fman.c b/drivers/net/ethernet/freescale/fman/fman.c
index 1de2e1e51c2b..dabee93fcadd 100644
--- a/drivers/net/ethernet/freescale/fman/fman.c
+++ b/drivers/net/ethernet/freescale/fman/fman.c
@@ -35,7 +35,6 @@
#include "fman.h"
#include "fman_muram.h"
-#include <linux/fsl/guts.h>
#include <linux/slab.h>
#include <linux/delay.h>
#include <linux/module.h>
@@ -46,6 +45,10 @@
#include <linux/interrupt.h>
#include <linux/libfdt_env.h>
+#ifdef CONFIG_PPC
+#include <asm/fsl_guts.h>
+#endif
+
/* General defines */
#define FMAN_LIODN_TBL 64 /* size of LIODN table */
#define MAX_NUM_OF_MACS 10
@@ -1889,7 +1892,9 @@ static int fman_reset(struct fman *fman)
err = -EBUSY;
goto _return;
- } else {
+ }
+#ifdef CONFIG_PPC
+ else {
struct device_node *guts_node;
struct ccsr_guts __iomem *guts_regs;
u32 devdisr2, reg;
@@ -1952,6 +1957,7 @@ guts_node:
dev_dbg(fman->dev, "%s: Didn't perform FManV3 reset due to Errata A007273!\n",
__func__);
}
+#endif
_return:
return err;
}
diff --git a/sound/soc/fsl/mpc8610_hpcd.c b/sound/soc/fsl/mpc8610_hpcd.c
index ddf49f30b23f..73b2b89d4a3e 100644
--- a/sound/soc/fsl/mpc8610_hpcd.c
+++ b/sound/soc/fsl/mpc8610_hpcd.c
@@ -12,11 +12,11 @@
#include <linux/module.h>
#include <linux/interrupt.h>
-#include <linux/fsl/guts.h>
#include <linux/of_address.h>
#include <linux/of_device.h>
#include <linux/slab.h>
#include <sound/soc.h>
+#include <asm/fsl_guts.h>
#include "fsl_dma.h"
#include "fsl_ssi.h"
diff --git a/sound/soc/fsl/p1022_ds.c b/sound/soc/fsl/p1022_ds.c
index a1f780ecadf5..a24e04919f71 100644
--- a/sound/soc/fsl/p1022_ds.c
+++ b/sound/soc/fsl/p1022_ds.c
@@ -11,12 +11,12 @@
*/
#include <linux/module.h>
-#include <linux/fsl/guts.h>
#include <linux/interrupt.h>
#include <linux/of_address.h>
#include <linux/of_device.h>
#include <linux/slab.h>
#include <sound/soc.h>
+#include <asm/fsl_guts.h>
#include "fsl_dma.h"
#include "fsl_ssi.h"
diff --git a/sound/soc/fsl/p1022_rdk.c b/sound/soc/fsl/p1022_rdk.c
index d4d88a8cb9c0..d8448887bfda 100644
--- a/sound/soc/fsl/p1022_rdk.c
+++ b/sound/soc/fsl/p1022_rdk.c
@@ -18,12 +18,12 @@
*/
#include <linux/module.h>
-#include <linux/fsl/guts.h>
#include <linux/interrupt.h>
#include <linux/of_address.h>
#include <linux/of_device.h>
#include <linux/slab.h>
#include <sound/soc.h>
+#include <asm/fsl_guts.h>
#include "fsl_dma.h"
#include "fsl_ssi.h"
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [PATCH 4/4] Revert "powerpc/fsl: Move fsl_guts.h out of arch/powerpc"
@ 2016-05-30 13:18 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-30 13:18 UTC (permalink / raw)
To: linux-arm-kernel
All users of this driver are PowerPC specific and the header file
has no business in the global include/linux/ hierarchy, so move
it back before anyone starts using it on ARM.
This reverts commit 948486544713492f00ac8a9572909101ea892cb0.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
This part of the series is not required for the eSDHC quirk,
but it restores the asm/fsl_guts.h header so it doesn't accidentally
get abused for this in the future. I found two drivers outside of
arch/powerpc that already accessed the registers directly, but the
functions look fairly contained, and can be easily hidden in an
#ifdef CONFIG_PPC
diff --git a/include/linux/fsl/guts.h b/arch/powerpc/include/asm/fsl_guts.h
similarity index 99%
rename from include/linux/fsl/guts.h
rename to arch/powerpc/include/asm/fsl_guts.h
index 649e9171a9b3..a67413c52701 100644
--- a/include/linux/fsl/guts.h
+++ b/arch/powerpc/include/asm/fsl_guts.h
@@ -12,10 +12,9 @@
* option) any later version.
*/
-#ifndef __FSL_GUTS_H__
-#define __FSL_GUTS_H__
-
-#include <linux/types.h>
+#ifndef __ASM_POWERPC_FSL_GUTS_H__
+#define __ASM_POWERPC_FSL_GUTS_H__
+#ifdef __KERNEL__
/**
* Global Utility Registers.
@@ -295,3 +294,4 @@ struct ccsr_rcpm_v2 {
};
#endif
+#endif
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index f61cbe235581..00f052e9f2a2 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -34,7 +34,6 @@
#include <linux/of_device.h>
#include <linux/phy.h>
#include <linux/memblock.h>
-#include <linux/fsl/guts.h>
#include <linux/atomic.h>
#include <asm/time.h>
@@ -52,6 +51,7 @@
#include <soc/fsl/qe/qe_ic.h>
#include <asm/mpic.h>
#include <asm/swiotlb.h>
+#include <asm/fsl_guts.h>
#include "smp.h"
#include "mpc85xx.h"
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c b/arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c
index f05325f0cc03..a812c0511252 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c
@@ -14,8 +14,8 @@
#include <linux/kernel.h>
#include <linux/of.h>
#include <linux/of_address.h>
-#include <linux/fsl/guts.h>
+#include <asm/fsl_guts.h>
#include <asm/io.h>
#include <asm/fsl_pm.h>
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index 3f4dad133338..453ddda00fce 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -17,7 +17,6 @@
#include <linux/seq_file.h>
#include <linux/interrupt.h>
#include <linux/of_platform.h>
-#include <linux/fsl/guts.h>
#include <asm/time.h>
#include <asm/machdep.h>
@@ -28,6 +27,7 @@
#include <asm/mpic.h>
#include <soc/fsl/qe/qe.h>
#include <soc/fsl/qe/qe_ic.h>
+#include <asm/fsl_guts.h>
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c b/arch/powerpc/platforms/85xx/p1022_ds.c
index 371df822e88e..6ac986d3f8a3 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -16,7 +16,6 @@
* kind, whether express or implied.
*/
-#include <linux/fsl/guts.h>
#include <linux/pci.h>
#include <linux/of_platform.h>
#include <asm/div64.h>
@@ -26,6 +25,7 @@
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
#include <asm/udbg.h>
+#include <asm/fsl_guts.h>
#include <asm/fsl_lbc.h>
#include "smp.h"
diff --git a/arch/powerpc/platforms/85xx/p1022_rdk.c b/arch/powerpc/platforms/85xx/p1022_rdk.c
index 5087becaa8bc..680232d6ba48 100644
--- a/arch/powerpc/platforms/85xx/p1022_rdk.c
+++ b/arch/powerpc/platforms/85xx/p1022_rdk.c
@@ -12,7 +12,6 @@
* kind, whether express or implied.
*/
-#include <linux/fsl/guts.h>
#include <linux/pci.h>
#include <linux/of_platform.h>
#include <asm/div64.h>
@@ -22,6 +21,7 @@
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
#include <asm/udbg.h>
+#include <asm/fsl_guts.h>
#include "smp.h"
#include "mpc85xx.h"
diff --git a/arch/powerpc/platforms/85xx/smp.c b/arch/powerpc/platforms/85xx/smp.c
index fe9f19e5e935..6bd3a292e790 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -18,7 +18,6 @@
#include <linux/kexec.h>
#include <linux/highmem.h>
#include <linux/cpu.h>
-#include <linux/fsl/guts.h>
#include <asm/machdep.h>
#include <asm/pgtable.h>
@@ -26,6 +25,7 @@
#include <asm/mpic.h>
#include <asm/cacheflush.h>
#include <asm/dbell.h>
+#include <asm/fsl_guts.h>
#include <asm/code-patching.h>
#include <asm/cputhreads.h>
#include <asm/fsl_pm.h>
diff --git a/arch/powerpc/platforms/85xx/twr_p102x.c b/arch/powerpc/platforms/85xx/twr_p102x.c
index 71bc255b4324..2cac45f72d24 100644
--- a/arch/powerpc/platforms/85xx/twr_p102x.c
+++ b/arch/powerpc/platforms/85xx/twr_p102x.c
@@ -15,7 +15,6 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/errno.h>
-#include <linux/fsl/guts.h>
#include <linux/pci.h>
#include <linux/of_platform.h>
@@ -24,6 +23,7 @@
#include <asm/mpic.h>
#include <soc/fsl/qe/qe.h>
#include <soc/fsl/qe/qe_ic.h>
+#include <asm/fsl_guts.h>
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
index 957473e5c8e5..761c81476957 100644
--- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
+++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
@@ -24,7 +24,6 @@
#include <linux/delay.h>
#include <linux/seq_file.h>
#include <linux/of.h>
-#include <linux/fsl/guts.h>
#include <asm/time.h>
#include <asm/machdep.h>
@@ -39,6 +38,7 @@
#include <sysdev/fsl_pci.h>
#include <sysdev/fsl_soc.h>
#include <sysdev/simple_gpio.h>
+#include <asm/fsl_guts.h>
#include "mpc86xx.h"
diff --git a/arch/powerpc/sysdev/fsl_rcpm.c b/arch/powerpc/sysdev/fsl_rcpm.c
index 9259a94f70e1..8af22187cb25 100644
--- a/arch/powerpc/sysdev/fsl_rcpm.c
+++ b/arch/powerpc/sysdev/fsl_rcpm.c
@@ -19,7 +19,7 @@
#include <linux/export.h>
#include <asm/io.h>
-#include <linux/fsl/guts.h>
+#include <asm/fsl_guts.h>
#include <asm/cputhreads.h>
#include <asm/fsl_pm.h>
#include <asm/smp.h>
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
index 58566a17944a..f311bd399672 100644
--- a/drivers/clk/clk-qoriq.c
+++ b/drivers/clk/clk-qoriq.c
@@ -12,7 +12,6 @@
#include <linux/clk.h>
#include <linux/clk-provider.h>
-#include <linux/fsl/guts.h>
#include <linux/io.h>
#include <linux/kernel.h>
#include <linux/module.h>
@@ -21,6 +20,10 @@
#include <linux/of.h>
#include <linux/slab.h>
+#ifdef CONFIG_PPC
+#include <asm/fsl_guts.h>
+#endif
+
#define PLL_DIV1 0
#define PLL_DIV2 1
#define PLL_DIV3 2
@@ -341,6 +344,8 @@ static const struct clockgen_muxinfo t4240_hwa5 = {
},
};
+#ifdef CONFIG_PPC
+
#define RCWSR7_FM1_CLK_SEL 0x40000000
#define RCWSR7_FM2_CLK_SEL 0x20000000
#define RCWSR7_HWA_ASYNC_DIV 0x04000000
@@ -408,6 +413,7 @@ static void __init p5040_init_periph(struct clockgen *cg)
else
cg->fman[1] = cg->pll[PLATFORM_PLL].div[PLL_DIV2].clk;
}
+#endif
static void __init t1023_init_periph(struct clockgen *cg)
{
@@ -499,6 +505,7 @@ static const struct clockgen_chipinfo chipinfo[] = {
.pll_mask = 0x37,
.flags = CG_VER3 | CG_LITTLE_ENDIAN,
},
+#ifdef CONFIG_PPC
{
.compat = "fsl,p2041-clockgen",
.guts_compat = "fsl,qoriq-device-config-1.0",
@@ -559,6 +566,7 @@ static const struct clockgen_chipinfo chipinfo[] = {
},
.pll_mask = 0x0f,
},
+#endif
{
.compat = "fsl,t1023-clockgen",
.guts_compat = "fsl,t1023-device-config",
diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index a34355fca37a..2570f2a25dc4 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -20,11 +20,11 @@
#include "fsl_pamu.h"
-#include <linux/fsl/guts.h>
#include <linux/interrupt.h>
#include <linux/genalloc.h>
#include <asm/mpc85xx.h>
+#include <asm/fsl_guts.h>
/* define indexes for each operation mapping scenario */
#define OMI_QMAN 0x00
diff --git a/drivers/net/ethernet/freescale/fman/fman.c b/drivers/net/ethernet/freescale/fman/fman.c
index 1de2e1e51c2b..dabee93fcadd 100644
--- a/drivers/net/ethernet/freescale/fman/fman.c
+++ b/drivers/net/ethernet/freescale/fman/fman.c
@@ -35,7 +35,6 @@
#include "fman.h"
#include "fman_muram.h"
-#include <linux/fsl/guts.h>
#include <linux/slab.h>
#include <linux/delay.h>
#include <linux/module.h>
@@ -46,6 +45,10 @@
#include <linux/interrupt.h>
#include <linux/libfdt_env.h>
+#ifdef CONFIG_PPC
+#include <asm/fsl_guts.h>
+#endif
+
/* General defines */
#define FMAN_LIODN_TBL 64 /* size of LIODN table */
#define MAX_NUM_OF_MACS 10
@@ -1889,7 +1892,9 @@ static int fman_reset(struct fman *fman)
err = -EBUSY;
goto _return;
- } else {
+ }
+#ifdef CONFIG_PPC
+ else {
struct device_node *guts_node;
struct ccsr_guts __iomem *guts_regs;
u32 devdisr2, reg;
@@ -1952,6 +1957,7 @@ guts_node:
dev_dbg(fman->dev, "%s: Didn't perform FManV3 reset due to Errata A007273!\n",
__func__);
}
+#endif
_return:
return err;
}
diff --git a/sound/soc/fsl/mpc8610_hpcd.c b/sound/soc/fsl/mpc8610_hpcd.c
index ddf49f30b23f..73b2b89d4a3e 100644
--- a/sound/soc/fsl/mpc8610_hpcd.c
+++ b/sound/soc/fsl/mpc8610_hpcd.c
@@ -12,11 +12,11 @@
#include <linux/module.h>
#include <linux/interrupt.h>
-#include <linux/fsl/guts.h>
#include <linux/of_address.h>
#include <linux/of_device.h>
#include <linux/slab.h>
#include <sound/soc.h>
+#include <asm/fsl_guts.h>
#include "fsl_dma.h"
#include "fsl_ssi.h"
diff --git a/sound/soc/fsl/p1022_ds.c b/sound/soc/fsl/p1022_ds.c
index a1f780ecadf5..a24e04919f71 100644
--- a/sound/soc/fsl/p1022_ds.c
+++ b/sound/soc/fsl/p1022_ds.c
@@ -11,12 +11,12 @@
*/
#include <linux/module.h>
-#include <linux/fsl/guts.h>
#include <linux/interrupt.h>
#include <linux/of_address.h>
#include <linux/of_device.h>
#include <linux/slab.h>
#include <sound/soc.h>
+#include <asm/fsl_guts.h>
#include "fsl_dma.h"
#include "fsl_ssi.h"
diff --git a/sound/soc/fsl/p1022_rdk.c b/sound/soc/fsl/p1022_rdk.c
index d4d88a8cb9c0..d8448887bfda 100644
--- a/sound/soc/fsl/p1022_rdk.c
+++ b/sound/soc/fsl/p1022_rdk.c
@@ -18,12 +18,12 @@
*/
#include <linux/module.h>
-#include <linux/fsl/guts.h>
#include <linux/interrupt.h>
#include <linux/of_address.h>
#include <linux/of_device.h>
#include <linux/slab.h>
#include <sound/soc.h>
+#include <asm/fsl_guts.h>
#include "fsl_dma.h"
#include "fsl_ssi.h"
^ permalink raw reply related [flat|nested] 185+ messages in thread
* Re: [PATCH 1/4] base: soc: introduce soc_device_match() interface
2016-05-30 13:14 ` Arnd Bergmann
(?)
(?)
@ 2016-05-30 14:57 ` Arnd Bergmann
-1 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-30 14:57 UTC (permalink / raw)
To: linuxppc-dev
Cc: Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Scott Wood,
Rob Herring, Santosh Shilimkar, linux-arm-kernel, netdev,
linux-mmc, linux-kernel, Yang-Leo Li, iommu, Kumar Gala
On Monday, May 30, 2016 3:14:38 PM CEST Arnd Bergmann wrote:
> We keep running into cases where device drivers want to know the exact
> version of the SoC a they are currently running on. In the past, this
> has usually been done through a vendor specific API that can be called
> by a driver, or by directly accessing some kind of version register
> that is not part of the device itself but that belongs to a global
> register area of the chip.
>
> Common reasons for doing this include:
>
> - A machine is not using devicetree or similar for passing data
> about on-chip devices, but just announces their presence using
> boot-time platform devices, and the machine code itself does
> not care about the revision.
>
> - There is existing firmware or boot loaders with existing DT
> binaries with generic compatible strings that do not identify
> the particular revision of each device, but the driver knows
> which SoC revisions include which part
>
> - A prerelease version of a chip has some quirks and we are
> using the same version of the bootloader and the DT blob
> on both the prerelease and the final version. An update of
> the DT binding seems inappropriate because that would involve
> maintaining multiple copies of the dts and/or bootloader.
>
> This introduces the soc_device_match() interface that is meant
> to work like of_match_node() but instead of identifying the
> version of a device, it identifies the SoC itself using a
> vendor-agnostic interface.
>
> Unlike soc_device_match(), we do not do an exact string compare
> but instead use glob_match() to allow wildcards in strings.
I'm sorry the series introduced build failures (I had done some changes
after testing), here is a quick fixup. I'll resend the whole thing
after someone has looked at it as none of the changes below should
have any influence on the review.
Arnd
diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index e9623c6674a5..c38573249777 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -173,7 +173,7 @@ module_exit(soc_bus_unregister);
static int soc_device_match_one(struct device *dev, void *arg)
{
struct soc_device *soc_dev = container_of(dev, struct soc_device, dev);
- struct soc_device_attribute *match = arg;
+ const struct soc_device_attribute *match = arg;
if (match->machine && !glob_match(match->machine, soc_dev->attr->machine))
return 0;
@@ -208,7 +208,7 @@ static int soc_device_match_one(struct device *dev, void *arg)
* soc_device_attribute to pass a structure or function pointer for
* each entry.
*/
-struct soc_device_attribute *soc_device_match(struct soc_device_attribute *matches)
+const struct soc_device_attribute *soc_device_match(const struct soc_device_attribute *matches)
{
struct device *dev;
int ret;
@@ -219,7 +219,7 @@ struct soc_device_attribute *soc_device_match(struct soc_device_attribute *match
return NULL;
dev = NULL;
- ret = bus_for_each_dev(&soc_bus_type, dev, matches,
+ ret = bus_for_each_dev(&soc_bus_type, dev, (void *)matches,
soc_device_match_one);
}
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
index 1d4814fe4cb2..a7b8b05a13e8 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -19,6 +19,8 @@
#include <linux/delay.h>
#include <linux/module.h>
#include <linux/mmc/host.h>
+#include <linux/sys_soc.h>
+
#include "sdhci-pltfm.h"
#include "sdhci-esdhc.h"
@@ -75,7 +77,6 @@ static u16 esdhc_readw_fixup(struct sdhci_host *host,
{
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
- u16 ret;
int shift = (spec_reg & 0x2) * 8;
if (spec_reg == SDHCI_HOST_VERSION)
@@ -565,7 +566,7 @@ static const struct sdhci_pltfm_data sdhci_esdhc_le_pdata = {
};
#define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) | SDHCI_SPEC_200)
-static const struct soc_device_attribute esdhc_t4240_quirk = {
+static const struct soc_device_attribute esdhc_t4240_quirk[] = {
/* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200 */
{ .soc_id = "T4*(0x824000)", .revision = "0x[01]?",
.data = (void *)(uintptr_t)(T4240_HOST_VER) },
@@ -576,6 +577,7 @@ static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host)
{
struct sdhci_pltfm_host *pltfm_host;
struct sdhci_esdhc *esdhc;
+ u32 host_ver;
pltfm_host = sdhci_priv(host);
esdhc = sdhci_pltfm_priv(pltfm_host);
@@ -583,9 +585,9 @@ static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host)
host_ver = sdhci_readw(host, SDHCI_HOST_VERSION);
if (of_device_is_compatible(pdev->dev.of_node, "fsl,t4240-esdhc")) {
- struct soc_device_attribute *match;
+ const struct soc_device_attribute *match;
- match = soc_device_match(&esdhc_t4240_quirk);
+ match = soc_device_match(esdhc_t4240_quirk);
if (match)
host_ver = (uintptr_t)match->data;
}
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
index 2f30698f5bcf..476969644bed 100644
--- a/drivers/soc/fsl/guts.c
+++ b/drivers/soc/fsl/guts.c
@@ -34,14 +34,6 @@ static u32 fsl_guts_get_svr(struct guts *guts)
return ioread32be(guts->regs + GUTS_SVR);
}
-static u32 fsl_guts_get_pvr(struct guts *guts)
-{
- if (guts->little_endian)
- return ioread32(guts->regs + GUTS_PVR);
- else
- return ioread32be(guts->regs + GUTS_PVR);
-}
-
/*
* Table for matching compatible strings, for device tree
* guts node, for Freescale QorIQ SOCs.
@@ -76,13 +68,15 @@ static const struct of_device_id fsl_guts_of_match[] = {
static void fsl_guts_init(struct device *dev, struct guts *guts)
{
- const struct of_device_id *id;
u32 svr = fsl_guts_get_svr(guts);
+ const struct of_device_id *id;
+ const char *socname;
guts->soc.family = "NXP QorIQ";
id = of_match_node(fsl_guts_of_match, dev->of_node);
- guts->soc.soc_id = devm_kasprintf(dev, "%s (ver 0x%06x)" id->data,
- svr >> 8;
+ socname = id->data;
+ guts->soc.soc_id = devm_kasprintf(dev, GFP_KERNEL, "%s (ver 0x%06x)",
+ socname, svr >> 8);
guts->soc.revision = devm_kasprintf(dev, GFP_KERNEL, "0x%02x",
svr & 0xff);
}
diff --git a/include/linux/sys_soc.h b/include/linux/sys_soc.h
index 02c48c76052b..3dfc8714a88c 100644
--- a/include/linux/sys_soc.h
+++ b/include/linux/sys_soc.h
@@ -36,6 +36,6 @@ void soc_device_unregister(struct soc_device *soc_dev);
*/
struct device *soc_device_to_device(struct soc_device *soc);
-struct soc_device_attribute *soc_device_match(struct soc_device_attribute *matches);
+const struct soc_device_attribute *soc_device_match(const struct soc_device_attribute *matches);
#endif /* __SOC_BUS_H */
^ permalink raw reply related [flat|nested] 185+ messages in thread
* Re: [PATCH 1/4] base: soc: introduce soc_device_match() interface
@ 2016-05-30 14:57 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-30 14:57 UTC (permalink / raw)
To: linuxppc-dev
Cc: Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Scott Wood,
Rob Herring, Santosh Shilimkar, linux-arm-kernel, netdev,
linux-mmc, linux-kernel, Yang-Leo
On Monday, May 30, 2016 3:14:38 PM CEST Arnd Bergmann wrote:
> We keep running into cases where device drivers want to know the exact
> version of the SoC a they are currently running on. In the past, this
> has usually been done through a vendor specific API that can be called
> by a driver, or by directly accessing some kind of version register
> that is not part of the device itself but that belongs to a global
> register area of the chip.
>
> Common reasons for doing this include:
>
> - A machine is not using devicetree or similar for passing data
> about on-chip devices, but just announces their presence using
> boot-time platform devices, and the machine code itself does
> not care about the revision.
>
> - There is existing firmware or boot loaders with existing DT
> binaries with generic compatible strings that do not identify
> the particular revision of each device, but the driver knows
> which SoC revisions include which part
>
> - A prerelease version of a chip has some quirks and we are
> using the same version of the bootloader and the DT blob
> on both the prerelease and the final version. An update of
> the DT binding seems inappropriate because that would involve
> maintaining multiple copies of the dts and/or bootloader.
>
> This introduces the soc_device_match() interface that is meant
> to work like of_match_node() but instead of identifying the
> version of a device, it identifies the SoC itself using a
> vendor-agnostic interface.
>
> Unlike soc_device_match(), we do not do an exact string compare
> but instead use glob_match() to allow wildcards in strings.
I'm sorry the series introduced build failures (I had done some changes
after testing), here is a quick fixup. I'll resend the whole thing
after someone has looked at it as none of the changes below should
have any influence on the review.
Arnd
diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index e9623c6674a5..c38573249777 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -173,7 +173,7 @@ module_exit(soc_bus_unregister);
static int soc_device_match_one(struct device *dev, void *arg)
{
struct soc_device *soc_dev = container_of(dev, struct soc_device, dev);
- struct soc_device_attribute *match = arg;
+ const struct soc_device_attribute *match = arg;
if (match->machine && !glob_match(match->machine, soc_dev->attr->machine))
return 0;
@@ -208,7 +208,7 @@ static int soc_device_match_one(struct device *dev, void *arg)
* soc_device_attribute to pass a structure or function pointer for
* each entry.
*/
-struct soc_device_attribute *soc_device_match(struct soc_device_attribute *matches)
+const struct soc_device_attribute *soc_device_match(const struct soc_device_attribute *matches)
{
struct device *dev;
int ret;
@@ -219,7 +219,7 @@ struct soc_device_attribute *soc_device_match(struct soc_device_attribute *match
return NULL;
dev = NULL;
- ret = bus_for_each_dev(&soc_bus_type, dev, matches,
+ ret = bus_for_each_dev(&soc_bus_type, dev, (void *)matches,
soc_device_match_one);
}
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
index 1d4814fe4cb2..a7b8b05a13e8 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -19,6 +19,8 @@
#include <linux/delay.h>
#include <linux/module.h>
#include <linux/mmc/host.h>
+#include <linux/sys_soc.h>
+
#include "sdhci-pltfm.h"
#include "sdhci-esdhc.h"
@@ -75,7 +77,6 @@ static u16 esdhc_readw_fixup(struct sdhci_host *host,
{
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
- u16 ret;
int shift = (spec_reg & 0x2) * 8;
if (spec_reg == SDHCI_HOST_VERSION)
@@ -565,7 +566,7 @@ static const struct sdhci_pltfm_data sdhci_esdhc_le_pdata = {
};
#define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) | SDHCI_SPEC_200)
-static const struct soc_device_attribute esdhc_t4240_quirk = {
+static const struct soc_device_attribute esdhc_t4240_quirk[] = {
/* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200 */
{ .soc_id = "T4*(0x824000)", .revision = "0x[01]?",
.data = (void *)(uintptr_t)(T4240_HOST_VER) },
@@ -576,6 +577,7 @@ static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host)
{
struct sdhci_pltfm_host *pltfm_host;
struct sdhci_esdhc *esdhc;
+ u32 host_ver;
pltfm_host = sdhci_priv(host);
esdhc = sdhci_pltfm_priv(pltfm_host);
@@ -583,9 +585,9 @@ static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host)
host_ver = sdhci_readw(host, SDHCI_HOST_VERSION);
if (of_device_is_compatible(pdev->dev.of_node, "fsl,t4240-esdhc")) {
- struct soc_device_attribute *match;
+ const struct soc_device_attribute *match;
- match = soc_device_match(&esdhc_t4240_quirk);
+ match = soc_device_match(esdhc_t4240_quirk);
if (match)
host_ver = (uintptr_t)match->data;
}
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
index 2f30698f5bcf..476969644bed 100644
--- a/drivers/soc/fsl/guts.c
+++ b/drivers/soc/fsl/guts.c
@@ -34,14 +34,6 @@ static u32 fsl_guts_get_svr(struct guts *guts)
return ioread32be(guts->regs + GUTS_SVR);
}
-static u32 fsl_guts_get_pvr(struct guts *guts)
-{
- if (guts->little_endian)
- return ioread32(guts->regs + GUTS_PVR);
- else
- return ioread32be(guts->regs + GUTS_PVR);
-}
-
/*
* Table for matching compatible strings, for device tree
* guts node, for Freescale QorIQ SOCs.
@@ -76,13 +68,15 @@ static const struct of_device_id fsl_guts_of_match[] = {
static void fsl_guts_init(struct device *dev, struct guts *guts)
{
- const struct of_device_id *id;
u32 svr = fsl_guts_get_svr(guts);
+ const struct of_device_id *id;
+ const char *socname;
guts->soc.family = "NXP QorIQ";
id = of_match_node(fsl_guts_of_match, dev->of_node);
- guts->soc.soc_id = devm_kasprintf(dev, "%s (ver 0x%06x)" id->data,
- svr >> 8;
+ socname = id->data;
+ guts->soc.soc_id = devm_kasprintf(dev, GFP_KERNEL, "%s (ver 0x%06x)",
+ socname, svr >> 8);
guts->soc.revision = devm_kasprintf(dev, GFP_KERNEL, "0x%02x",
svr & 0xff);
}
diff --git a/include/linux/sys_soc.h b/include/linux/sys_soc.h
index 02c48c76052b..3dfc8714a88c 100644
--- a/include/linux/sys_soc.h
+++ b/include/linux/sys_soc.h
@@ -36,6 +36,6 @@ void soc_device_unregister(struct soc_device *soc_dev);
*/
struct device *soc_device_to_device(struct soc_device *soc);
-struct soc_device_attribute *soc_device_match(struct soc_device_attribute *matches);
+const struct soc_device_attribute *soc_device_match(const struct soc_device_attribute *matches);
#endif /* __SOC_BUS_H */
^ permalink raw reply related [flat|nested] 185+ messages in thread
* Re: [PATCH 1/4] base: soc: introduce soc_device_match() interface
@ 2016-05-30 14:57 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-30 14:57 UTC (permalink / raw)
To: linuxppc-dev
Cc: Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Scott Wood,
Rob Herring, Santosh Shilimkar, linux-arm-kernel, netdev,
linux-mmc, linux-kernel, Yang-Leo Li, iommu, Kumar Gala
On Monday, May 30, 2016 3:14:38 PM CEST Arnd Bergmann wrote:
> We keep running into cases where device drivers want to know the exact
> version of the SoC a they are currently running on. In the past, this
> has usually been done through a vendor specific API that can be called
> by a driver, or by directly accessing some kind of version register
> that is not part of the device itself but that belongs to a global
> register area of the chip.
>
> Common reasons for doing this include:
>
> - A machine is not using devicetree or similar for passing data
> about on-chip devices, but just announces their presence using
> boot-time platform devices, and the machine code itself does
> not care about the revision.
>
> - There is existing firmware or boot loaders with existing DT
> binaries with generic compatible strings that do not identify
> the particular revision of each device, but the driver knows
> which SoC revisions include which part
>
> - A prerelease version of a chip has some quirks and we are
> using the same version of the bootloader and the DT blob
> on both the prerelease and the final version. An update of
> the DT binding seems inappropriate because that would involve
> maintaining multiple copies of the dts and/or bootloader.
>
> This introduces the soc_device_match() interface that is meant
> to work like of_match_node() but instead of identifying the
> version of a device, it identifies the SoC itself using a
> vendor-agnostic interface.
>
> Unlike soc_device_match(), we do not do an exact string compare
> but instead use glob_match() to allow wildcards in strings.
I'm sorry the series introduced build failures (I had done some changes
after testing), here is a quick fixup. I'll resend the whole thing
after someone has looked at it as none of the changes below should
have any influence on the review.
Arnd
diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index e9623c6674a5..c38573249777 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -173,7 +173,7 @@ module_exit(soc_bus_unregister);
static int soc_device_match_one(struct device *dev, void *arg)
{
struct soc_device *soc_dev = container_of(dev, struct soc_device, dev);
- struct soc_device_attribute *match = arg;
+ const struct soc_device_attribute *match = arg;
if (match->machine && !glob_match(match->machine, soc_dev->attr->machine))
return 0;
@@ -208,7 +208,7 @@ static int soc_device_match_one(struct device *dev, void *arg)
* soc_device_attribute to pass a structure or function pointer for
* each entry.
*/
-struct soc_device_attribute *soc_device_match(struct soc_device_attribute *matches)
+const struct soc_device_attribute *soc_device_match(const struct soc_device_attribute *matches)
{
struct device *dev;
int ret;
@@ -219,7 +219,7 @@ struct soc_device_attribute *soc_device_match(struct soc_device_attribute *match
return NULL;
dev = NULL;
- ret = bus_for_each_dev(&soc_bus_type, dev, matches,
+ ret = bus_for_each_dev(&soc_bus_type, dev, (void *)matches,
soc_device_match_one);
}
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
index 1d4814fe4cb2..a7b8b05a13e8 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -19,6 +19,8 @@
#include <linux/delay.h>
#include <linux/module.h>
#include <linux/mmc/host.h>
+#include <linux/sys_soc.h>
+
#include "sdhci-pltfm.h"
#include "sdhci-esdhc.h"
@@ -75,7 +77,6 @@ static u16 esdhc_readw_fixup(struct sdhci_host *host,
{
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
- u16 ret;
int shift = (spec_reg & 0x2) * 8;
if (spec_reg == SDHCI_HOST_VERSION)
@@ -565,7 +566,7 @@ static const struct sdhci_pltfm_data sdhci_esdhc_le_pdata = {
};
#define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) | SDHCI_SPEC_200)
-static const struct soc_device_attribute esdhc_t4240_quirk = {
+static const struct soc_device_attribute esdhc_t4240_quirk[] = {
/* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200 */
{ .soc_id = "T4*(0x824000)", .revision = "0x[01]?",
.data = (void *)(uintptr_t)(T4240_HOST_VER) },
@@ -576,6 +577,7 @@ static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host)
{
struct sdhci_pltfm_host *pltfm_host;
struct sdhci_esdhc *esdhc;
+ u32 host_ver;
pltfm_host = sdhci_priv(host);
esdhc = sdhci_pltfm_priv(pltfm_host);
@@ -583,9 +585,9 @@ static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host)
host_ver = sdhci_readw(host, SDHCI_HOST_VERSION);
if (of_device_is_compatible(pdev->dev.of_node, "fsl,t4240-esdhc")) {
- struct soc_device_attribute *match;
+ const struct soc_device_attribute *match;
- match = soc_device_match(&esdhc_t4240_quirk);
+ match = soc_device_match(esdhc_t4240_quirk);
if (match)
host_ver = (uintptr_t)match->data;
}
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
index 2f30698f5bcf..476969644bed 100644
--- a/drivers/soc/fsl/guts.c
+++ b/drivers/soc/fsl/guts.c
@@ -34,14 +34,6 @@ static u32 fsl_guts_get_svr(struct guts *guts)
return ioread32be(guts->regs + GUTS_SVR);
}
-static u32 fsl_guts_get_pvr(struct guts *guts)
-{
- if (guts->little_endian)
- return ioread32(guts->regs + GUTS_PVR);
- else
- return ioread32be(guts->regs + GUTS_PVR);
-}
-
/*
* Table for matching compatible strings, for device tree
* guts node, for Freescale QorIQ SOCs.
@@ -76,13 +68,15 @@ static const struct of_device_id fsl_guts_of_match[] = {
static void fsl_guts_init(struct device *dev, struct guts *guts)
{
- const struct of_device_id *id;
u32 svr = fsl_guts_get_svr(guts);
+ const struct of_device_id *id;
+ const char *socname;
guts->soc.family = "NXP QorIQ";
id = of_match_node(fsl_guts_of_match, dev->of_node);
- guts->soc.soc_id = devm_kasprintf(dev, "%s (ver 0x%06x)" id->data,
- svr >> 8;
+ socname = id->data;
+ guts->soc.soc_id = devm_kasprintf(dev, GFP_KERNEL, "%s (ver 0x%06x)",
+ socname, svr >> 8);
guts->soc.revision = devm_kasprintf(dev, GFP_KERNEL, "0x%02x",
svr & 0xff);
}
diff --git a/include/linux/sys_soc.h b/include/linux/sys_soc.h
index 02c48c76052b..3dfc8714a88c 100644
--- a/include/linux/sys_soc.h
+++ b/include/linux/sys_soc.h
@@ -36,6 +36,6 @@ void soc_device_unregister(struct soc_device *soc_dev);
*/
struct device *soc_device_to_device(struct soc_device *soc);
-struct soc_device_attribute *soc_device_match(struct soc_device_attribute *matches);
+const struct soc_device_attribute *soc_device_match(const struct soc_device_attribute *matches);
#endif /* __SOC_BUS_H */
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [PATCH 1/4] base: soc: introduce soc_device_match() interface
@ 2016-05-30 14:57 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-05-30 14:57 UTC (permalink / raw)
To: linux-arm-kernel
On Monday, May 30, 2016 3:14:38 PM CEST Arnd Bergmann wrote:
> We keep running into cases where device drivers want to know the exact
> version of the SoC a they are currently running on. In the past, this
> has usually been done through a vendor specific API that can be called
> by a driver, or by directly accessing some kind of version register
> that is not part of the device itself but that belongs to a global
> register area of the chip.
>
> Common reasons for doing this include:
>
> - A machine is not using devicetree or similar for passing data
> about on-chip devices, but just announces their presence using
> boot-time platform devices, and the machine code itself does
> not care about the revision.
>
> - There is existing firmware or boot loaders with existing DT
> binaries with generic compatible strings that do not identify
> the particular revision of each device, but the driver knows
> which SoC revisions include which part
>
> - A prerelease version of a chip has some quirks and we are
> using the same version of the bootloader and the DT blob
> on both the prerelease and the final version. An update of
> the DT binding seems inappropriate because that would involve
> maintaining multiple copies of the dts and/or bootloader.
>
> This introduces the soc_device_match() interface that is meant
> to work like of_match_node() but instead of identifying the
> version of a device, it identifies the SoC itself using a
> vendor-agnostic interface.
>
> Unlike soc_device_match(), we do not do an exact string compare
> but instead use glob_match() to allow wildcards in strings.
I'm sorry the series introduced build failures (I had done some changes
after testing), here is a quick fixup. I'll resend the whole thing
after someone has looked at it as none of the changes below should
have any influence on the review.
Arnd
diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index e9623c6674a5..c38573249777 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -173,7 +173,7 @@ module_exit(soc_bus_unregister);
static int soc_device_match_one(struct device *dev, void *arg)
{
struct soc_device *soc_dev = container_of(dev, struct soc_device, dev);
- struct soc_device_attribute *match = arg;
+ const struct soc_device_attribute *match = arg;
if (match->machine && !glob_match(match->machine, soc_dev->attr->machine))
return 0;
@@ -208,7 +208,7 @@ static int soc_device_match_one(struct device *dev, void *arg)
* soc_device_attribute to pass a structure or function pointer for
* each entry.
*/
-struct soc_device_attribute *soc_device_match(struct soc_device_attribute *matches)
+const struct soc_device_attribute *soc_device_match(const struct soc_device_attribute *matches)
{
struct device *dev;
int ret;
@@ -219,7 +219,7 @@ struct soc_device_attribute *soc_device_match(struct soc_device_attribute *match
return NULL;
dev = NULL;
- ret = bus_for_each_dev(&soc_bus_type, dev, matches,
+ ret = bus_for_each_dev(&soc_bus_type, dev, (void *)matches,
soc_device_match_one);
}
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
index 1d4814fe4cb2..a7b8b05a13e8 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -19,6 +19,8 @@
#include <linux/delay.h>
#include <linux/module.h>
#include <linux/mmc/host.h>
+#include <linux/sys_soc.h>
+
#include "sdhci-pltfm.h"
#include "sdhci-esdhc.h"
@@ -75,7 +77,6 @@ static u16 esdhc_readw_fixup(struct sdhci_host *host,
{
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
- u16 ret;
int shift = (spec_reg & 0x2) * 8;
if (spec_reg == SDHCI_HOST_VERSION)
@@ -565,7 +566,7 @@ static const struct sdhci_pltfm_data sdhci_esdhc_le_pdata = {
};
#define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) | SDHCI_SPEC_200)
-static const struct soc_device_attribute esdhc_t4240_quirk = {
+static const struct soc_device_attribute esdhc_t4240_quirk[] = {
/* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200 */
{ .soc_id = "T4*(0x824000)", .revision = "0x[01]?",
.data = (void *)(uintptr_t)(T4240_HOST_VER) },
@@ -576,6 +577,7 @@ static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host)
{
struct sdhci_pltfm_host *pltfm_host;
struct sdhci_esdhc *esdhc;
+ u32 host_ver;
pltfm_host = sdhci_priv(host);
esdhc = sdhci_pltfm_priv(pltfm_host);
@@ -583,9 +585,9 @@ static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host)
host_ver = sdhci_readw(host, SDHCI_HOST_VERSION);
if (of_device_is_compatible(pdev->dev.of_node, "fsl,t4240-esdhc")) {
- struct soc_device_attribute *match;
+ const struct soc_device_attribute *match;
- match = soc_device_match(&esdhc_t4240_quirk);
+ match = soc_device_match(esdhc_t4240_quirk);
if (match)
host_ver = (uintptr_t)match->data;
}
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
index 2f30698f5bcf..476969644bed 100644
--- a/drivers/soc/fsl/guts.c
+++ b/drivers/soc/fsl/guts.c
@@ -34,14 +34,6 @@ static u32 fsl_guts_get_svr(struct guts *guts)
return ioread32be(guts->regs + GUTS_SVR);
}
-static u32 fsl_guts_get_pvr(struct guts *guts)
-{
- if (guts->little_endian)
- return ioread32(guts->regs + GUTS_PVR);
- else
- return ioread32be(guts->regs + GUTS_PVR);
-}
-
/*
* Table for matching compatible strings, for device tree
* guts node, for Freescale QorIQ SOCs.
@@ -76,13 +68,15 @@ static const struct of_device_id fsl_guts_of_match[] = {
static void fsl_guts_init(struct device *dev, struct guts *guts)
{
- const struct of_device_id *id;
u32 svr = fsl_guts_get_svr(guts);
+ const struct of_device_id *id;
+ const char *socname;
guts->soc.family = "NXP QorIQ";
id = of_match_node(fsl_guts_of_match, dev->of_node);
- guts->soc.soc_id = devm_kasprintf(dev, "%s (ver 0x%06x)" id->data,
- svr >> 8;
+ socname = id->data;
+ guts->soc.soc_id = devm_kasprintf(dev, GFP_KERNEL, "%s (ver 0x%06x)",
+ socname, svr >> 8);
guts->soc.revision = devm_kasprintf(dev, GFP_KERNEL, "0x%02x",
svr & 0xff);
}
diff --git a/include/linux/sys_soc.h b/include/linux/sys_soc.h
index 02c48c76052b..3dfc8714a88c 100644
--- a/include/linux/sys_soc.h
+++ b/include/linux/sys_soc.h
@@ -36,6 +36,6 @@ void soc_device_unregister(struct soc_device *soc_dev);
*/
struct device *soc_device_to_device(struct soc_device *soc);
-struct soc_device_attribute *soc_device_match(struct soc_device_attribute *matches);
+const struct soc_device_attribute *soc_device_match(const struct soc_device_attribute *matches);
#endif /* __SOC_BUS_H */
^ permalink raw reply related [flat|nested] 185+ messages in thread
* Re: [PATCH 3/4] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
2016-05-30 13:16 ` Arnd Bergmann
` (2 preceding siblings ...)
(?)
@ 2016-06-02 1:11 ` Scott Wood
-1 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-02 1:11 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev
Cc: Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Rob Herring,
Santosh Shilimkar, linux-arm-kernel, netdev, linux-mmc,
linux-kernel, Yang-Leo Li, iommu, Kumar Gala
On Mon, 2016-05-30 at 15:16 +0200, Arnd Bergmann wrote:
> This is a rewrite of an earlier patch from Yangbo Lu, adding a quirk
> for the NXP QorIQ T4240 in the detection of the host device version.
>
> Unfortunately, this device cannot be detected using the compatible
> string, as we have to support existing DTS files that use the generic
> "fsl,t4240-esdhc" identifier but that have other host versions that
> are correctly detected.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of
> -esdhc.c
> index 3f34d354f1fc..1d4814fe4cb2 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -73,14 +73,16 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
> static u16 esdhc_readw_fixup(struct sdhci_host *host,
> int spec_reg, u32 value)
> {
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
> u16 ret;
> int shift = (spec_reg & 0x2) * 8;
>
> if (spec_reg == SDHCI_HOST_VERSION)
> - ret = value & 0xffff;
> - else
> - ret = (value >> shift) & 0xffff;
> - return ret;
> + return esdhc->vendor_ver << SDHCI_VENDOR_VER_SHIFT |
> + esdhc->spec_ver;
> +
> + return (value >> shift) & 0xffff;
> }
>
> static u8 esdhc_readb_fixup(struct sdhci_host *host,
> @@ -562,16 +564,32 @@ static const struct sdhci_pltfm_data
> sdhci_esdhc_le_pdata = {
> .ops = &sdhci_esdhc_le_ops,
> };
>
> +#define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) |
> SDHCI_SPEC_200)
> +static const struct soc_device_attribute esdhc_t4240_quirk = {
> + /* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200
> */
> + { .soc_id = "T4*(0x824000)", .revision = "0x[01]?",
> + .data = (void *)(uintptr_t)(T4240_HOST_VER) },
Why should this code need to care that the string begins with "T4"? This
creates dual maintenance if that were to change. It's also broken because
T4240 has compatible = "fsl,t4240-device-config", "fsl,qoriq-device-config
-2.0" and thus with these patches it would incorrectly show up as "P series
(0x824000)". The compatible string of this node was never meant to be a key
for choosing a string to describe the system to userspace.
0x824000 is a magic number which should be represented symbolically.
If T4240 is affected, then so are the reduced-core variants T4160 and T4080,
but 0x824000 doesn't match them (Yangbo's patch had the same problem). And
please don't respond with "0x824*"
You also didn't strip out the E bit of SVR which indicates encryption
capability and nothing else (Yangbo's patch did not have this problem because
it used SVR_SOC_VER).
What happens if the revision condition is more complicated, such as <= 0x20
with 0x21 being fine? Multiple quirk entries where before we had as simple
comparison?
I fail to see how this approach is an improvement (much less one that needs to
hold up a patchset that is fixing a problem and is not touching any generic
code). Why does this need to be a string?
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 3/4] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-06-02 1:11 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-02 1:11 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev
Cc: Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Rob Herring,
Santosh Shilimkar, linux-arm-kernel, netdev, linux-mmc,
linux-kernel, Yang-Leo Li,
On Mon, 2016-05-30 at 15:16 +0200, Arnd Bergmann wrote:
> This is a rewrite of an earlier patch from Yangbo Lu, adding a quirk
> for the NXP QorIQ T4240 in the detection of the host device version.
>
> Unfortunately, this device cannot be detected using the compatible
> string, as we have to support existing DTS files that use the generic
> "fsl,t4240-esdhc" identifier but that have other host versions that
> are correctly detected.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of
> -esdhc.c
> index 3f34d354f1fc..1d4814fe4cb2 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -73,14 +73,16 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
> static u16 esdhc_readw_fixup(struct sdhci_host *host,
> int spec_reg, u32 value)
> {
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
> u16 ret;
> int shift = (spec_reg & 0x2) * 8;
>
> if (spec_reg == SDHCI_HOST_VERSION)
> - ret = value & 0xffff;
> - else
> - ret = (value >> shift) & 0xffff;
> - return ret;
> + return esdhc->vendor_ver << SDHCI_VENDOR_VER_SHIFT |
> + esdhc->spec_ver;
> +
> + return (value >> shift) & 0xffff;
> }
>
> static u8 esdhc_readb_fixup(struct sdhci_host *host,
> @@ -562,16 +564,32 @@ static const struct sdhci_pltfm_data
> sdhci_esdhc_le_pdata = {
> .ops = &sdhci_esdhc_le_ops,
> };
>
> +#define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) |
> SDHCI_SPEC_200)
> +static const struct soc_device_attribute esdhc_t4240_quirk = {
> + /* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200
> */
> + { .soc_id = "T4*(0x824000)", .revision = "0x[01]?",
> + .data = (void *)(uintptr_t)(T4240_HOST_VER) },
Why should this code need to care that the string begins with "T4"? This
creates dual maintenance if that were to change. It's also broken because
T4240 has compatible = "fsl,t4240-device-config", "fsl,qoriq-device-config
-2.0" and thus with these patches it would incorrectly show up as "P series
(0x824000)". The compatible string of this node was never meant to be a key
for choosing a string to describe the system to userspace.
0x824000 is a magic number which should be represented symbolically.
If T4240 is affected, then so are the reduced-core variants T4160 and T4080,
but 0x824000 doesn't match them (Yangbo's patch had the same problem). And
please don't respond with "0x824*"
You also didn't strip out the E bit of SVR which indicates encryption
capability and nothing else (Yangbo's patch did not have this problem because
it used SVR_SOC_VER).
What happens if the revision condition is more complicated, such as <= 0x20
with 0x21 being fine? Multiple quirk entries where before we had as simple
comparison?
I fail to see how this approach is an improvement (much less one that needs to
hold up a patchset that is fixing a problem and is not touching any generic
code). Why does this need to be a string?
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 3/4] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-06-02 1:11 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-02 1:11 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev
Cc: Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Rob Herring,
Santosh Shilimkar, linux-arm-kernel, netdev, linux-mmc,
linux-kernel, Yang-Leo Li, iommu, Kumar Gala
On Mon, 2016-05-30 at 15:16 +0200, Arnd Bergmann wrote:
> This is a rewrite of an earlier patch from Yangbo Lu, adding a quirk
> for the NXP QorIQ T4240 in the detection of the host device version.
>
> Unfortunately, this device cannot be detected using the compatible
> string, as we have to support existing DTS files that use the generic
> "fsl,t4240-esdhc" identifier but that have other host versions that
> are correctly detected.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of
> -esdhc.c
> index 3f34d354f1fc..1d4814fe4cb2 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -73,14 +73,16 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
> static u16 esdhc_readw_fixup(struct sdhci_host *host,
> int spec_reg, u32 value)
> {
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
> u16 ret;
> int shift = (spec_reg & 0x2) * 8;
>
> if (spec_reg == SDHCI_HOST_VERSION)
> - ret = value & 0xffff;
> - else
> - ret = (value >> shift) & 0xffff;
> - return ret;
> + return esdhc->vendor_ver << SDHCI_VENDOR_VER_SHIFT |
> + esdhc->spec_ver;
> +
> + return (value >> shift) & 0xffff;
> }
>
> static u8 esdhc_readb_fixup(struct sdhci_host *host,
> @@ -562,16 +564,32 @@ static const struct sdhci_pltfm_data
> sdhci_esdhc_le_pdata = {
> .ops = &sdhci_esdhc_le_ops,
> };
>
> +#define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) |
> SDHCI_SPEC_200)
> +static const struct soc_device_attribute esdhc_t4240_quirk = {
> + /* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200
> */
> + { .soc_id = "T4*(0x824000)", .revision = "0x[01]?",
> + .data = (void *)(uintptr_t)(T4240_HOST_VER) },
Why should this code need to care that the string begins with "T4"? This
creates dual maintenance if that were to change. It's also broken because
T4240 has compatible = "fsl,t4240-device-config", "fsl,qoriq-device-config
-2.0" and thus with these patches it would incorrectly show up as "P series
(0x824000)". The compatible string of this node was never meant to be a key
for choosing a string to describe the system to userspace.
0x824000 is a magic number which should be represented symbolically.
If T4240 is affected, then so are the reduced-core variants T4160 and T4080,
but 0x824000 doesn't match them (Yangbo's patch had the same problem). And
please don't respond with "0x824*"
You also didn't strip out the E bit of SVR which indicates encryption
capability and nothing else (Yangbo's patch did not have this problem because
it used SVR_SOC_VER).
What happens if the revision condition is more complicated, such as <= 0x20
with 0x21 being fine? Multiple quirk entries where before we had as simple
comparison?
I fail to see how this approach is an improvement (much less one that needs to
hold up a patchset that is fixing a problem and is not touching any generic
code). Why does this need to be a string?
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 3/4] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-06-02 1:11 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-02 1:11 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev
Cc: Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Rob Herring,
Santosh Shilimkar, linux-arm-kernel, netdev, linux-mmc,
linux-kernel, Yang-Leo Li, iommu, Kumar Gala
On Mon, 2016-05-30 at 15:16 +0200, Arnd Bergmann wrote:
> This is a rewrite of an earlier patch from Yangbo Lu, adding a quirk
> for the NXP QorIQ T4240 in the detection of the host device version.
>
> Unfortunately, this device cannot be detected using the compatible
> string, as we have to support existing DTS files that use the generic
> "fsl,t4240-esdhc" identifier but that have other host versions that
> are correctly detected.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of
> -esdhc.c
> index 3f34d354f1fc..1d4814fe4cb2 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -73,14 +73,16 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
> static u16 esdhc_readw_fixup(struct sdhci_host *host,
> int spec_reg, u32 value)
> {
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
> u16 ret;
> int shift = (spec_reg & 0x2) * 8;
>
> if (spec_reg == SDHCI_HOST_VERSION)
> - ret = value & 0xffff;
> - else
> - ret = (value >> shift) & 0xffff;
> - return ret;
> + return esdhc->vendor_ver << SDHCI_VENDOR_VER_SHIFT |
> + esdhc->spec_ver;
> +
> + return (value >> shift) & 0xffff;
> }
>
> static u8 esdhc_readb_fixup(struct sdhci_host *host,
> @@ -562,16 +564,32 @@ static const struct sdhci_pltfm_data
> sdhci_esdhc_le_pdata = {
> .ops = &sdhci_esdhc_le_ops,
> };
>
> +#define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) |
> SDHCI_SPEC_200)
> +static const struct soc_device_attribute esdhc_t4240_quirk = {
> + /* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200
> */
> + { .soc_id = "T4*(0x824000)", .revision = "0x[01]?",
> + .data = (void *)(uintptr_t)(T4240_HOST_VER) },
Why should this code need to care that the string begins with "T4"? This
creates dual maintenance if that were to change. It's also broken because
T4240 has compatible = "fsl,t4240-device-config", "fsl,qoriq-device-config
-2.0" and thus with these patches it would incorrectly show up as "P series
(0x824000)". The compatible string of this node was never meant to be a key
for choosing a string to describe the system to userspace.
0x824000 is a magic number which should be represented symbolically.
If T4240 is affected, then so are the reduced-core variants T4160 and T4080,
but 0x824000 doesn't match them (Yangbo's patch had the same problem). And
please don't respond with "0x824*"
You also didn't strip out the E bit of SVR which indicates encryption
capability and nothing else (Yangbo's patch did not have this problem because
it used SVR_SOC_VER).
What happens if the revision condition is more complicated, such as <= 0x20
with 0x21 being fine? Multiple quirk entries where before we had as simple
comparison?
I fail to see how this approach is an improvement (much less one that needs to
hold up a patchset that is fixing a problem and is not touching any generic
code). Why does this need to be a string?
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH 3/4] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-06-02 1:11 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-02 1:11 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 2016-05-30 at 15:16 +0200, Arnd Bergmann wrote:
> This is a rewrite of an earlier patch from Yangbo Lu, adding a quirk
> for the NXP QorIQ T4240 in the detection of the host device version.
>
> Unfortunately, this device cannot be detected using the compatible
> string, as we have to support existing DTS files that use the generic
> "fsl,t4240-esdhc" identifier but that have other host versions that
> are correctly detected.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of
> -esdhc.c
> index 3f34d354f1fc..1d4814fe4cb2 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -73,14 +73,16 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
> static u16 esdhc_readw_fixup(struct sdhci_host *host,
> int spec_reg, u32 value)
> {
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
> u16 ret;
> int shift = (spec_reg & 0x2) * 8;
>
> if (spec_reg == SDHCI_HOST_VERSION)
> - ret = value & 0xffff;
> - else
> - ret = (value >> shift) & 0xffff;
> - return ret;
> + return esdhc->vendor_ver << SDHCI_VENDOR_VER_SHIFT |
> + esdhc->spec_ver;
> +
> + return (value >> shift) & 0xffff;
> }
>
> static u8 esdhc_readb_fixup(struct sdhci_host *host,
> @@ -562,16 +564,32 @@ static const struct sdhci_pltfm_data
> sdhci_esdhc_le_pdata = {
> .ops = &sdhci_esdhc_le_ops,
> };
>
> +#define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) |
> SDHCI_SPEC_200)
> +static const struct soc_device_attribute esdhc_t4240_quirk = {
> + /* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200
> */
> + { .soc_id = "T4*(0x824000)", .revision = "0x[01]?",
> + .data = (void *)(uintptr_t)(T4240_HOST_VER) },
Why should this code need to care that the string begins with "T4"? This
creates dual maintenance if that were to change. It's also broken because
T4240 has compatible = "fsl,t4240-device-config", "fsl,qoriq-device-config
-2.0" and thus with these patches it would incorrectly show up as "P series
(0x824000)". The compatible string of this node was never meant to be a key
for choosing a string to describe the system to userspace.
0x824000 is a magic number which should be represented symbolically.
If T4240 is affected, then so are the reduced-core variants T4160 and T4080,
but 0x824000 doesn't match them (Yangbo's patch had the same problem). And
please don't respond with "0x824*"
You also didn't strip out the E bit of SVR which indicates encryption
capability and nothing else (Yangbo's patch did not have this problem because
it used SVR_SOC_VER).
What happens if the revision condition is more complicated, such as <= 0x20
with 0x21 being fine? Multiple quirk entries where before we had as simple
comparison?
I fail to see how this approach is an improvement (much less one that needs to
hold up a patchset that is fixing a problem and is not touching any generic
code). Why does this need to be a string?
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 4/4] Revert "powerpc/fsl: Move fsl_guts.h out of arch/powerpc"
2016-05-30 13:18 ` Arnd Bergmann
` (2 preceding siblings ...)
(?)
@ 2016-06-02 1:24 ` Scott Wood
-1 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-02 1:24 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev
Cc: Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Rob Herring,
Santosh Shilimkar, linux-arm-kernel, netdev, linux-mmc,
linux-kernel, Yang-Leo Li, iommu, Kumar Gala, linuxppc-dev
On Mon, 2016-05-30 at 15:18 +0200, Arnd Bergmann wrote:
> All users of this driver are PowerPC specific and the header file
> has no business in the global include/linux/ hierarchy, so move
> it back before anyone starts using it on ARM.
>
> This reverts commit 948486544713492f00ac8a9572909101ea892cb0.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> This part of the series is not required for the eSDHC quirk,
> but it restores the asm/fsl_guts.h header so it doesn't accidentally
> get abused for this in the future. I found two drivers outside of
> arch/powerpc that already accessed the registers directly, but the
> functions look fairly contained, and can be easily hidden in an
> #ifdef CONFIG_PPC
NACK
Besides adding ifdef pollution for no good reason, this register block is used
on some ARM chips as well. Why is it a problem if "anyone starts using it on
ARM"?
BTW, of all the mailing lists you included on this CC, you seem to have left
off the PPC list (I've added it).
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 4/4] Revert "powerpc/fsl: Move fsl_guts.h out of arch/powerpc"
@ 2016-06-02 1:24 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-02 1:24 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev
Cc: Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Rob Herring,
Santosh Shilimkar, linux-arm-kernel, netdev, linux-mmc,
linux-kernel, Yang-Leo Li,
On Mon, 2016-05-30 at 15:18 +0200, Arnd Bergmann wrote:
> All users of this driver are PowerPC specific and the header file
> has no business in the global include/linux/ hierarchy, so move
> it back before anyone starts using it on ARM.
>
> This reverts commit 948486544713492f00ac8a9572909101ea892cb0.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> This part of the series is not required for the eSDHC quirk,
> but it restores the asm/fsl_guts.h header so it doesn't accidentally
> get abused for this in the future. I found two drivers outside of
> arch/powerpc that already accessed the registers directly, but the
> functions look fairly contained, and can be easily hidden in an
> #ifdef CONFIG_PPC
NACK
Besides adding ifdef pollution for no good reason, this register block is used
on some ARM chips as well. Why is it a problem if "anyone starts using it on
ARM"?
BTW, of all the mailing lists you included on this CC, you seem to have left
off the PPC list (I've added it).
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 4/4] Revert "powerpc/fsl: Move fsl_guts.h out of arch/powerpc"
@ 2016-06-02 1:24 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-02 1:24 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev
Cc: Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Rob Herring,
Santosh Shilimkar, linux-arm-kernel, netdev, linux-mmc,
linux-kernel, Yang-Leo Li, iommu, Kumar Gala, linuxppc-dev
On Mon, 2016-05-30 at 15:18 +0200, Arnd Bergmann wrote:
> All users of this driver are PowerPC specific and the header file
> has no business in the global include/linux/ hierarchy, so move
> it back before anyone starts using it on ARM.
>
> This reverts commit 948486544713492f00ac8a9572909101ea892cb0.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> This part of the series is not required for the eSDHC quirk,
> but it restores the asm/fsl_guts.h header so it doesn't accidentally
> get abused for this in the future. I found two drivers outside of
> arch/powerpc that already accessed the registers directly, but the
> functions look fairly contained, and can be easily hidden in an
> #ifdef CONFIG_PPC
NACK
Besides adding ifdef pollution for no good reason, this register block is used
on some ARM chips as well. Why is it a problem if "anyone starts using it on
ARM"?
BTW, of all the mailing lists you included on this CC, you seem to have left
off the PPC list (I've added it).
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 4/4] Revert "powerpc/fsl: Move fsl_guts.h out of arch/powerpc"
@ 2016-06-02 1:24 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-02 1:24 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev
Cc: Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Rob Herring,
Santosh Shilimkar, linux-arm-kernel, netdev, linux-mmc,
linux-kernel, Yang-Leo Li, iommu, Kumar Gala, linuxppc-dev
On Mon, 2016-05-30 at 15:18 +0200, Arnd Bergmann wrote:
> All users of this driver are PowerPC specific and the header file
> has no business in the global include/linux/ hierarchy, so move
> it back before anyone starts using it on ARM.
>
> This reverts commit 948486544713492f00ac8a9572909101ea892cb0.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> This part of the series is not required for the eSDHC quirk,
> but it restores the asm/fsl_guts.h header so it doesn't accidentally
> get abused for this in the future. I found two drivers outside of
> arch/powerpc that already accessed the registers directly, but the
> functions look fairly contained, and can be easily hidden in an
> #ifdef CONFIG_PPC
NACK
Besides adding ifdef pollution for no good reason, this register block is used
on some ARM chips as well. Why is it a problem if "anyone starts using it on
ARM"?
BTW, of all the mailing lists you included on this CC, you seem to have left
off the PPC list (I've added it).
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH 4/4] Revert "powerpc/fsl: Move fsl_guts.h out of arch/powerpc"
@ 2016-06-02 1:24 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-02 1:24 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 2016-05-30 at 15:18 +0200, Arnd Bergmann wrote:
> All users of this driver are PowerPC specific and the header file
> has no business in the global include/linux/ hierarchy, so move
> it back before anyone starts using it on ARM.
>
> This reverts commit 948486544713492f00ac8a9572909101ea892cb0.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> This part of the series is not required for the eSDHC quirk,
> but it restores the asm/fsl_guts.h header so it doesn't accidentally
> get abused for this in the future. I found two drivers outside of
> arch/powerpc that already accessed the registers directly, but the
> functions look fairly contained, and can be easily hidden in an
> #ifdef CONFIG_PPC
NACK
Besides adding ifdef pollution for no good reason, this register block is used
on some ARM chips as well. Why is it a problem if "anyone starts using it on
ARM"?
BTW, of all the mailing lists you included on this CC, you seem to have left
off the PPC list (I've added it).
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
2016-05-30 13:15 ` Arnd Bergmann
` (3 preceding siblings ...)
(?)
@ 2016-06-02 1:47 ` Scott Wood
-1 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-02 1:47 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev
Cc: Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Rob Herring,
Santosh Shilimkar, linux-arm-kernel, netdev, linux-mmc,
linux-kernel, Yang-Leo Li, iommu, Kumar Gala, linuxppc-dev
On Mon, 2016-05-30 at 15:15 +0200, Arnd Bergmann wrote:
> diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> new file mode 100644
> index 000000000000..2f30698f5bcf
> --- /dev/null
> +++ b/drivers/soc/fsl/guts.c
> @@ -0,0 +1,130 @@
> +/*
> + * Freescale QorIQ Platforms GUTS Driver
> + *
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <linux/io.h>
> +#include <linux/platform_device.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <linux/of_address.h>
> +#include <linux/of_platform.h>
> +#include <linux/sys_soc.h>
> +
> +#define GUTS_PVR 0x0a0
> +#define GUTS_SVR 0x0a4
> +
> +struct guts {
> + void __iomem *regs;
We already have a struct to define guts. Why are you not using it? Why do
you consider using it to be "abuse"? What if we want to move more guts
functionality into this driver?
> + bool little_endian;
> + struct soc_device_attribute soc;
> +};
> +
> +static u32 fsl_guts_get_svr(struct guts *guts)
> +{
> + if (guts->little_endian)
> + return ioread32(guts->regs + GUTS_SVR);
> + else
> + return ioread32be(guts->regs + GUTS_SVR);
> +}
> +
> +static u32 fsl_guts_get_pvr(struct guts *guts)
> +{
> + if (guts->little_endian)
> + return ioread32(guts->regs + GUTS_PVR);
> + else
> + return ioread32be(guts->regs + GUTS_PVR);
> +}
You've removed the fallback to mfspr() on PPC, which would be helpful in some
virtualized environments where we don't have the guts node (but do have other
directly assigned devices). Of course, this is a consequence of the
conversion into a platform device.
> +
> +/*
> + * Table for matching compatible strings, for device tree
> + * guts node, for Freescale QorIQ SOCs.
> + */
> +static const struct of_device_id fsl_guts_of_match[] = {
> + /* For T4 & B4 Series SOCs */
> + { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4
> series" },
[snip]
> + { .compatible = "fsl,qoriq-device-config-2.0", .data = "P series"
As noted in my comment on patch 3/4, these descriptions are reversed.
They're also incomplete. t2080 has device config 2.0. t1040 is described as
2.0 though it should probably be 2.1 (or better, drop the generic compatible
altogether).
> + /*
> + * syscon devices default to little-endian, but on powerpc we have
> + * existing device trees with big-endian maps and an absent
> endianess
> + * "big-property"
> + */
> + if (!IS_ENABLED(CONFIG_POWERPC) &&
> + !of_property_read_bool(dev->of_node, "big-endian"))
> + guts->little_endian = true;
This is not a syscon device (Yangbo's patch to add a guts node on ls2080 is
the only guts node that says "syscon", and that was a leftover from earlier
revisions and should probably be removed). Even if it were, where is it
documented that syscon defaults to little-endian?
Documentation/devicetree/bindings/common-properties.txt says that the
individual binding specifies the default. The default for this node should be
big-endian because that's what existed before there was a need to describe the
endianness. And we need an update to the guts binding to specify that.
> +
> + guts->regs = devm_ioremap_resource(dev, 0);
> + if (!guts->regs) {
> + ret = -ENOMEM;
> + kfree(guts);
> + goto out;
> + }
> +
> + fsl_guts_init(dev, guts);
> + ret = 0;
> +out:
> + return ret;
> +}
> +
> +static struct platform_driver fsl_soc_guts = {
> + .probe = fsl_guts_probe,
> + .driver.of_match_table = fsl_guts_of_match,
> +};
> +
> +module_platform_driver(fsl_soc_guts);
Again, this means that the information is not available during early boot,
such as in the clock driver. Thus we would not be able to convert clk-qoriq's
direct mfspr(SPRN_SVR) into an soc_device_match() (or anything else that makes
use of this file), nor would we be able to move its access of the guts RCW
registers into this driver.
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-06-02 1:47 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-02 1:47 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
Cc: Mark Rutland, Ulf Hansson, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Qiang Zhao, Russell King,
Bhupesh Sharma, Claudiu Manoil,
devicetree-u79uwXL29TY76Z2rM5mHXA, Kumar Gala, Rob Herring,
Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
Xiaobo Xie, Yang-Leo Li,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
On Mon, 2016-05-30 at 15:15 +0200, Arnd Bergmann wrote:
> diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> new file mode 100644
> index 000000000000..2f30698f5bcf
> --- /dev/null
> +++ b/drivers/soc/fsl/guts.c
> @@ -0,0 +1,130 @@
> +/*
> + * Freescale QorIQ Platforms GUTS Driver
> + *
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <linux/io.h>
> +#include <linux/platform_device.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <linux/of_address.h>
> +#include <linux/of_platform.h>
> +#include <linux/sys_soc.h>
> +
> +#define GUTS_PVR 0x0a0
> +#define GUTS_SVR 0x0a4
> +
> +struct guts {
> + void __iomem *regs;
We already have a struct to define guts. Why are you not using it? Why do
you consider using it to be "abuse"? What if we want to move more guts
functionality into this driver?
> + bool little_endian;
> + struct soc_device_attribute soc;
> +};
> +
> +static u32 fsl_guts_get_svr(struct guts *guts)
> +{
> + if (guts->little_endian)
> + return ioread32(guts->regs + GUTS_SVR);
> + else
> + return ioread32be(guts->regs + GUTS_SVR);
> +}
> +
> +static u32 fsl_guts_get_pvr(struct guts *guts)
> +{
> + if (guts->little_endian)
> + return ioread32(guts->regs + GUTS_PVR);
> + else
> + return ioread32be(guts->regs + GUTS_PVR);
> +}
You've removed the fallback to mfspr() on PPC, which would be helpful in some
virtualized environments where we don't have the guts node (but do have other
directly assigned devices). Of course, this is a consequence of the
conversion into a platform device.
> +
> +/*
> + * Table for matching compatible strings, for device tree
> + * guts node, for Freescale QorIQ SOCs.
> + */
> +static const struct of_device_id fsl_guts_of_match[] = {
> + /* For T4 & B4 Series SOCs */
> + { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4
> series" },
[snip]
> + { .compatible = "fsl,qoriq-device-config-2.0", .data = "P series"
As noted in my comment on patch 3/4, these descriptions are reversed.
They're also incomplete. t2080 has device config 2.0. t1040 is described as
2.0 though it should probably be 2.1 (or better, drop the generic compatible
altogether).
> + /*
> + * syscon devices default to little-endian, but on powerpc we have
> + * existing device trees with big-endian maps and an absent
> endianess
> + * "big-property"
> + */
> + if (!IS_ENABLED(CONFIG_POWERPC) &&
> + !of_property_read_bool(dev->of_node, "big-endian"))
> + guts->little_endian = true;
This is not a syscon device (Yangbo's patch to add a guts node on ls2080 is
the only guts node that says "syscon", and that was a leftover from earlier
revisions and should probably be removed). Even if it were, where is it
documented that syscon defaults to little-endian?
Documentation/devicetree/bindings/common-properties.txt says that the
individual binding specifies the default. The default for this node should be
big-endian because that's what existed before there was a need to describe the
endianness. And we need an update to the guts binding to specify that.
> +
> + guts->regs = devm_ioremap_resource(dev, 0);
> + if (!guts->regs) {
> + ret = -ENOMEM;
> + kfree(guts);
> + goto out;
> + }
> +
> + fsl_guts_init(dev, guts);
> + ret = 0;
> +out:
> + return ret;
> +}
> +
> +static struct platform_driver fsl_soc_guts = {
> + .probe = fsl_guts_probe,
> + .driver.of_match_table = fsl_guts_of_match,
> +};
> +
> +module_platform_driver(fsl_soc_guts);
Again, this means that the information is not available during early boot,
such as in the clock driver. Thus we would not be able to convert clk-qoriq's
direct mfspr(SPRN_SVR) into an soc_device_match() (or anything else that makes
use of this file), nor would we be able to move its access of the guts RCW
registers into this driver.
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-06-02 1:47 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-02 1:47 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
Cc: Mark Rutland, Ulf Hansson, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Qiang Zhao, Russell King,
Bhupesh Sharma, Claudiu Manoil,
devicetree-u79uwXL29TY76Z2rM5mHXA, Kumar Gala, Rob Herring,
Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
Xiaobo Xie, Yang-Leo Li,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
On Mon, 2016-05-30 at 15:15 +0200, Arnd Bergmann wrote:
> diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> new file mode 100644
> index 000000000000..2f30698f5bcf
> --- /dev/null
> +++ b/drivers/soc/fsl/guts.c
> @@ -0,0 +1,130 @@
> +/*
> + * Freescale QorIQ Platforms GUTS Driver
> + *
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <linux/io.h>
> +#include <linux/platform_device.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <linux/of_address.h>
> +#include <linux/of_platform.h>
> +#include <linux/sys_soc.h>
> +
> +#define GUTS_PVR 0x0a0
> +#define GUTS_SVR 0x0a4
> +
> +struct guts {
> + void __iomem *regs;
We already have a struct to define guts. Why are you not using it? Why do
you consider using it to be "abuse"? What if we want to move more guts
functionality into this driver?
> + bool little_endian;
> + struct soc_device_attribute soc;
> +};
> +
> +static u32 fsl_guts_get_svr(struct guts *guts)
> +{
> + if (guts->little_endian)
> + return ioread32(guts->regs + GUTS_SVR);
> + else
> + return ioread32be(guts->regs + GUTS_SVR);
> +}
> +
> +static u32 fsl_guts_get_pvr(struct guts *guts)
> +{
> + if (guts->little_endian)
> + return ioread32(guts->regs + GUTS_PVR);
> + else
> + return ioread32be(guts->regs + GUTS_PVR);
> +}
You've removed the fallback to mfspr() on PPC, which would be helpful in some
virtualized environments where we don't have the guts node (but do have other
directly assigned devices). Of course, this is a consequence of the
conversion into a platform device.
> +
> +/*
> + * Table for matching compatible strings, for device tree
> + * guts node, for Freescale QorIQ SOCs.
> + */
> +static const struct of_device_id fsl_guts_of_match[] = {
> + /* For T4 & B4 Series SOCs */
> + { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4
> series" },
[snip]
> + { .compatible = "fsl,qoriq-device-config-2.0", .data = "P series"
As noted in my comment on patch 3/4, these descriptions are reversed.
They're also incomplete. t2080 has device config 2.0. t1040 is described as
2.0 though it should probably be 2.1 (or better, drop the generic compatible
altogether).
> + /*
> + * syscon devices default to little-endian, but on powerpc we have
> + * existing device trees with big-endian maps and an absent
> endianess
> + * "big-property"
> + */
> + if (!IS_ENABLED(CONFIG_POWERPC) &&
> + !of_property_read_bool(dev->of_node, "big-endian"))
> + guts->little_endian = true;
This is not a syscon device (Yangbo's patch to add a guts node on ls2080 is
the only guts node that says "syscon", and that was a leftover from earlier
revisions and should probably be removed). Even if it were, where is it
documented that syscon defaults to little-endian?
Documentation/devicetree/bindings/common-properties.txt says that the
individual binding specifies the default. The default for this node should be
big-endian because that's what existed before there was a need to describe the
endianness. And we need an update to the guts binding to specify that.
> +
> + guts->regs = devm_ioremap_resource(dev, 0);
> + if (!guts->regs) {
> + ret = -ENOMEM;
> + kfree(guts);
> + goto out;
> + }
> +
> + fsl_guts_init(dev, guts);
> + ret = 0;
> +out:
> + return ret;
> +}
> +
> +static struct platform_driver fsl_soc_guts = {
> + .probe = fsl_guts_probe,
> + .driver.of_match_table = fsl_guts_of_match,
> +};
> +
> +module_platform_driver(fsl_soc_guts);
Again, this means that the information is not available during early boot,
such as in the clock driver. Thus we would not be able to convert clk-qoriq's
direct mfspr(SPRN_SVR) into an soc_device_match() (or anything else that makes
use of this file), nor would we be able to move its access of the guts RCW
registers into this driver.
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-06-02 1:47 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-02 1:47 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev
Cc: Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Rob Herring,
Santosh Shilimkar, linux-arm-kernel, netdev, linux-mmc,
linux-kernel, Yang-Leo Li, iommu, Kumar Gala, linuxppc-dev
On Mon, 2016-05-30 at 15:15 +0200, Arnd Bergmann wrote:
> diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> new file mode 100644
> index 000000000000..2f30698f5bcf
> --- /dev/null
> +++ b/drivers/soc/fsl/guts.c
> @@ -0,0 +1,130 @@
> +/*
> + * Freescale QorIQ Platforms GUTS Driver
> + *
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <linux/io.h>
> +#include <linux/platform_device.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <linux/of_address.h>
> +#include <linux/of_platform.h>
> +#include <linux/sys_soc.h>
> +
> +#define GUTS_PVR 0x0a0
> +#define GUTS_SVR 0x0a4
> +
> +struct guts {
> + void __iomem *regs;
We already have a struct to define guts. Why are you not using it? Why do
you consider using it to be "abuse"? What if we want to move more guts
functionality into this driver?
> + bool little_endian;
> + struct soc_device_attribute soc;
> +};
> +
> +static u32 fsl_guts_get_svr(struct guts *guts)
> +{
> + if (guts->little_endian)
> + return ioread32(guts->regs + GUTS_SVR);
> + else
> + return ioread32be(guts->regs + GUTS_SVR);
> +}
> +
> +static u32 fsl_guts_get_pvr(struct guts *guts)
> +{
> + if (guts->little_endian)
> + return ioread32(guts->regs + GUTS_PVR);
> + else
> + return ioread32be(guts->regs + GUTS_PVR);
> +}
You've removed the fallback to mfspr() on PPC, which would be helpful in some
virtualized environments where we don't have the guts node (but do have other
directly assigned devices). Of course, this is a consequence of the
conversion into a platform device.
> +
> +/*
> + * Table for matching compatible strings, for device tree
> + * guts node, for Freescale QorIQ SOCs.
> + */
> +static const struct of_device_id fsl_guts_of_match[] = {
> + /* For T4 & B4 Series SOCs */
> + { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4
> series" },
[snip]
> + { .compatible = "fsl,qoriq-device-config-2.0", .data = "P series"
As noted in my comment on patch 3/4, these descriptions are reversed.
They're also incomplete. t2080 has device config 2.0. t1040 is described as
2.0 though it should probably be 2.1 (or better, drop the generic compatible
altogether).
> + /*
> + * syscon devices default to little-endian, but on powerpc we have
> + * existing device trees with big-endian maps and an absent
> endianess
> + * "big-property"
> + */
> + if (!IS_ENABLED(CONFIG_POWERPC) &&
> + !of_property_read_bool(dev->of_node, "big-endian"))
> + guts->little_endian = true;
This is not a syscon device (Yangbo's patch to add a guts node on ls2080 is
the only guts node that says "syscon", and that was a leftover from earlier
revisions and should probably be removed). Even if it were, where is it
documented that syscon defaults to little-endian?
Documentation/devicetree/bindings/common-properties.txt says that the
individual binding specifies the default. The default for this node should be
big-endian because that's what existed before there was a need to describe the
endianness. And we need an update to the guts binding to specify that.
> +
> + guts->regs = devm_ioremap_resource(dev, 0);
> + if (!guts->regs) {
> + ret = -ENOMEM;
> + kfree(guts);
> + goto out;
> + }
> +
> + fsl_guts_init(dev, guts);
> + ret = 0;
> +out:
> + return ret;
> +}
> +
> +static struct platform_driver fsl_soc_guts = {
> + .probe = fsl_guts_probe,
> + .driver.of_match_table = fsl_guts_of_match,
> +};
> +
> +module_platform_driver(fsl_soc_guts);
Again, this means that the information is not available during early boot,
such as in the clock driver. Thus we would not be able to convert clk-qoriq's
direct mfspr(SPRN_SVR) into an soc_device_match() (or anything else that makes
use of this file), nor would we be able to move its access of the guts RCW
registers into this driver.
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-06-02 1:47 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-02 1:47 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev
Cc: Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Rob Herring,
Santosh Shilimkar, linux-arm-kernel, netdev, linux-mmc,
linux-kernel, Yang-Leo Li, iommu, Kumar Gala, linuxppc-dev
On Mon, 2016-05-30 at 15:15 +0200, Arnd Bergmann wrote:
> diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> new file mode 100644
> index 000000000000..2f30698f5bcf
> --- /dev/null
> +++ b/drivers/soc/fsl/guts.c
> @@ -0,0 +1,130 @@
> +/*
> + * Freescale QorIQ Platforms GUTS Driver
> + *
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <linux/io.h>
> +#include <linux/platform_device.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <linux/of_address.h>
> +#include <linux/of_platform.h>
> +#include <linux/sys_soc.h>
> +
> +#define GUTS_PVR 0x0a0
> +#define GUTS_SVR 0x0a4
> +
> +struct guts {
> + void __iomem *regs;
We already have a struct to define guts. Why are you not using it? Why do
you consider using it to be "abuse"? What if we want to move more guts
functionality into this driver?
> + bool little_endian;
> + struct soc_device_attribute soc;
> +};
> +
> +static u32 fsl_guts_get_svr(struct guts *guts)
> +{
> + if (guts->little_endian)
> + return ioread32(guts->regs + GUTS_SVR);
> + else
> + return ioread32be(guts->regs + GUTS_SVR);
> +}
> +
> +static u32 fsl_guts_get_pvr(struct guts *guts)
> +{
> + if (guts->little_endian)
> + return ioread32(guts->regs + GUTS_PVR);
> + else
> + return ioread32be(guts->regs + GUTS_PVR);
> +}
You've removed the fallback to mfspr() on PPC, which would be helpful in some
virtualized environments where we don't have the guts node (but do have other
directly assigned devices). Of course, this is a consequence of the
conversion into a platform device.
> +
> +/*
> + * Table for matching compatible strings, for device tree
> + * guts node, for Freescale QorIQ SOCs.
> + */
> +static const struct of_device_id fsl_guts_of_match[] = {
> + /* For T4 & B4 Series SOCs */
> + { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4
> series" },
[snip]
> + { .compatible = "fsl,qoriq-device-config-2.0", .data = "P series"
As noted in my comment on patch 3/4, these descriptions are reversed.
They're also incomplete. t2080 has device config 2.0. t1040 is described as
2.0 though it should probably be 2.1 (or better, drop the generic compatible
altogether).
> + /*
> + * syscon devices default to little-endian, but on powerpc we have
> + * existing device trees with big-endian maps and an absent
> endianess
> + * "big-property"
> + */
> + if (!IS_ENABLED(CONFIG_POWERPC) &&
> + !of_property_read_bool(dev->of_node, "big-endian"))
> + guts->little_endian = true;
This is not a syscon device (Yangbo's patch to add a guts node on ls2080 is
the only guts node that says "syscon", and that was a leftover from earlier
revisions and should probably be removed). Even if it were, where is it
documented that syscon defaults to little-endian?
Documentation/devicetree/bindings/common-properties.txt says that the
individual binding specifies the default. The default for this node should be
big-endian because that's what existed before there was a need to describe the
endianness. And we need an update to the guts binding to specify that.
> +
> + guts->regs = devm_ioremap_resource(dev, 0);
> + if (!guts->regs) {
> + ret = -ENOMEM;
> + kfree(guts);
> + goto out;
> + }
> +
> + fsl_guts_init(dev, guts);
> + ret = 0;
> +out:
> + return ret;
> +}
> +
> +static struct platform_driver fsl_soc_guts = {
> + .probe = fsl_guts_probe,
> + .driver.of_match_table = fsl_guts_of_match,
> +};
> +
> +module_platform_driver(fsl_soc_guts);
Again, this means that the information is not available during early boot,
such as in the clock driver. Thus we would not be able to convert clk-qoriq's
direct mfspr(SPRN_SVR) into an soc_device_match() (or anything else that makes
use of this file), nor would we be able to move its access of the guts RCW
registers into this driver.
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-06-02 1:47 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-02 1:47 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 2016-05-30 at 15:15 +0200, Arnd Bergmann wrote:
> diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> new file mode 100644
> index 000000000000..2f30698f5bcf
> --- /dev/null
> +++ b/drivers/soc/fsl/guts.c
> @@ -0,0 +1,130 @@
> +/*
> + * Freescale QorIQ Platforms GUTS Driver
> + *
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <linux/io.h>
> +#include <linux/platform_device.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <linux/of_address.h>
> +#include <linux/of_platform.h>
> +#include <linux/sys_soc.h>
> +
> +#define GUTS_PVR 0x0a0
> +#define GUTS_SVR 0x0a4
> +
> +struct guts {
> + void __iomem *regs;
We already have a struct to define guts. Why are you not using it? Why do
you consider using it to be "abuse"? What if we want to move more guts
functionality into this driver?
> + bool little_endian;
> + struct soc_device_attribute soc;
> +};
> +
> +static u32 fsl_guts_get_svr(struct guts *guts)
> +{
> + if (guts->little_endian)
> + return ioread32(guts->regs + GUTS_SVR);
> + else
> + return ioread32be(guts->regs + GUTS_SVR);
> +}
> +
> +static u32 fsl_guts_get_pvr(struct guts *guts)
> +{
> + if (guts->little_endian)
> + return ioread32(guts->regs + GUTS_PVR);
> + else
> + return ioread32be(guts->regs + GUTS_PVR);
> +}
You've removed the fallback to mfspr() on PPC, which would be helpful in some
virtualized environments where we don't have the guts node (but do have other
directly assigned devices). Of course, this is a consequence of the
conversion into a platform device.
> +
> +/*
> + * Table for matching compatible strings, for device tree
> + * guts node, for Freescale QorIQ SOCs.
> + */
> +static const struct of_device_id fsl_guts_of_match[] = {
> + /* For T4 & B4 Series SOCs */
> + { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4
> series" },
[snip]
> + { .compatible = "fsl,qoriq-device-config-2.0", .data = "P series"
As noted in my comment on patch 3/4, these descriptions are reversed.
They're also incomplete. t2080 has device config 2.0. t1040 is described as
2.0 though it should probably be 2.1 (or better, drop the generic compatible
altogether).
> + /*
> + * syscon devices default to little-endian, but on powerpc we have
> + * existing device trees with big-endian maps and an absent
> endianess
> + * "big-property"
> + */
> + if (!IS_ENABLED(CONFIG_POWERPC) &&
> + !of_property_read_bool(dev->of_node, "big-endian"))
> + guts->little_endian = true;
This is not a syscon device (Yangbo's patch to add a guts node on ls2080 is
the only guts node that says "syscon", and that was a leftover from earlier
revisions and should probably be removed). Even if it were, where is it
documented that syscon defaults to little-endian?
Documentation/devicetree/bindings/common-properties.txt says that the
individual binding specifies the default. The default for this node should be
big-endian because that's what existed before there was a need to describe the
endianness. And we need an update to the guts binding to specify that.
> +
> + guts->regs = devm_ioremap_resource(dev, 0);
> + if (!guts->regs) {
> + ret = -ENOMEM;
> + kfree(guts);
> + goto out;
> + }
> +
> + fsl_guts_init(dev, guts);
> + ret = 0;
> +out:
> + return ret;
> +}
> +
> +static struct platform_driver fsl_soc_guts = {
> + .probe = fsl_guts_probe,
> + .driver.of_match_table = fsl_guts_of_match,
> +};
> +
> +module_platform_driver(fsl_soc_guts);
Again, this means that the information is not available during early boot,
such as in the clock driver. Thus we would not be able to convert clk-qoriq's
direct mfspr(SPRN_SVR) into an soc_device_match() (or anything else that makes
use of this file), nor would we be able to move its access of the guts RCW
registers into this driver.
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
2016-06-02 1:47 ` Scott Wood
(?)
(?)
@ 2016-06-02 8:43 ` Arnd Bergmann
-1 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-06-02 8:43 UTC (permalink / raw)
To: linuxppc-dev
Cc: Scott Wood, Mark Rutland, Ulf Hansson, linux-kernel, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Kumar Gala,
Rob Herring, Santosh Shilimkar, linux-arm-kernel, netdev,
linux-mmc, Xiaobo Xie, Yang-Leo Li, iommu, Yangbo Lu
On Wednesday, June 1, 2016 8:47:22 PM CEST Scott Wood wrote:
> On Mon, 2016-05-30 at 15:15 +0200, Arnd Bergmann wrote:
> > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> > new file mode 100644
> > index 000000000000..2f30698f5bcf
> > --- /dev/null
> > +++ b/drivers/soc/fsl/guts.c
> > @@ -0,0 +1,130 @@
> > +/*
> > + * Freescale QorIQ Platforms GUTS Driver
> > + *
> > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +
> > +#include <linux/io.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/module.h>
> > +#include <linux/slab.h>
> > +#include <linux/of_address.h>
> > +#include <linux/of_platform.h>
> > +#include <linux/sys_soc.h>
> > +
> > +#define GUTS_PVR 0x0a0
> > +#define GUTS_SVR 0x0a4
> > +
> > +struct guts {
> > + void __iomem *regs;
>
> We already have a struct to define guts. Why are you not using it? Why do
> you consider using it to be "abuse"? What if we want to move more guts
> functionality into this driver?
This structure was in the original patch, I left it in there, only
removed the inclusion of the powerpc header file, which seemed to
be misplaced.
> > + bool little_endian;
> > + struct soc_device_attribute soc;
> > +};
> > +
> > +static u32 fsl_guts_get_svr(struct guts *guts)
> > +{
> > + if (guts->little_endian)
> > + return ioread32(guts->regs + GUTS_SVR);
> > + else
> > + return ioread32be(guts->regs + GUTS_SVR);
> > +}
> > +
> > +static u32 fsl_guts_get_pvr(struct guts *guts)
> > +{
> > + if (guts->little_endian)
> > + return ioread32(guts->regs + GUTS_PVR);
> > + else
> > + return ioread32be(guts->regs + GUTS_PVR);
> > +}
>
> You've removed the fallback to mfspr() on PPC, which would be helpful in some
> virtualized environments where we don't have the guts node (but do have other
> directly assigned devices). Of course, this is a consequence of the
> conversion into a platform device.
Right, it just didn't make any sense after the conversion. I couldn't
figure out what the intention was for the fallback. Virtualized environments
are an interesting case, but I'd also argue that a virtualized system is
not the original SoC anyway, so reporting the physical SoC as the
main system in the guest is a bit strange and we probably want to
come up with a different solution there.
In soc_device, we probably want to just report the type of hypervisor
in this case, which is what most users would expect there. For the
specific case of the mmc driver (are there any real use cases where
you'd pass on the mmc controller to a guest, as opposed to passing either
an emulated block device or the mmc device on an emulated mmc host?),
that means we have to come up with a different solution, but then
we'd be free to work around this by modifying the DT node of the mmc
device.
> > +/*
> > + * Table for matching compatible strings, for device tree
> > + * guts node, for Freescale QorIQ SOCs.
> > + */
> > +static const struct of_device_id fsl_guts_of_match[] = {
> > + /* For T4 & B4 Series SOCs */
> > + { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4
> > series" },
> [snip]
> > + { .compatible = "fsl,qoriq-device-config-2.0", .data = "P series"
>
> As noted in my comment on patch 3/4, these descriptions are reversed.
>
> They're also incomplete. t2080 has device config 2.0. t1040 is described as
> 2.0 though it should probably be 2.1 (or better, drop the generic compatible
> altogether).
Ok. Ideally I think we'd even look up the specific SoC names from the
SVC rather than the compatible string. I just didn't have a good list
for those to put in the driver.
> > + /*
> > + * syscon devices default to little-endian, but on powerpc we have
> > + * existing device trees with big-endian maps and an absent
> > endianess
> > + * "big-property"
> > + */
> > + if (!IS_ENABLED(CONFIG_POWERPC) &&
> > + !of_property_read_bool(dev->of_node, "big-endian"))
> > + guts->little_endian = true;
>
> This is not a syscon device (Yangbo's patch to add a guts node on ls2080 is
> the only guts node that says "syscon", and that was a leftover from earlier
> revisions and should probably be removed). Even if it were, where is it
> documented that syscon defaults to little-endian?
Documentation/devicetree/bindings/regmap/regmap.txt
We had a little screwup here, basically regmap (and by consequence, syscon)
always defaulted to little-endian way before that was documented, so it's
too late to change it, although I agree it would have made sense to document
regmap to default to big-endian on powerpc.
> Documentation/devicetree/bindings/common-properties.txt says that the
> individual binding specifies the default. The default for this node should be
> big-endian because that's what existed before there was a need to describe the
> endianness. And we need an update to the guts binding to specify that.
Good point. This proably means that specifying both the "guts" and "syscon"
compatible strings implies having to also specify the endianess explicitly
both ways, because otherwise we break one of the two bindings.
> > +
> > + guts->regs = devm_ioremap_resource(dev, 0);
> > + if (!guts->regs) {
> > + ret = -ENOMEM;
> > + kfree(guts);
> > + goto out;
> > + }
> > +
> > + fsl_guts_init(dev, guts);
> > + ret = 0;
> > +out:
> > + return ret;
> > +}
> > +
> > +static struct platform_driver fsl_soc_guts = {
> > + .probe = fsl_guts_probe,
> > + .driver.of_match_table = fsl_guts_of_match,
> > +};
> > +
> > +module_platform_driver(fsl_soc_guts);
>
> Again, this means that the information is not available during early boot,
> such as in the clock driver. Thus we would not be able to convert clk-qoriq's
> direct mfspr(SPRN_SVR) into an soc_device_match() (or anything else that makes
> use of this file), nor would we be able to move its access of the guts RCW
> registers into this driver.
Correct. Do we have a reason to convert the mfspr() though? I don't really
see an improvement over the current state if we do that, and for new devices
that might need the erratum workaround, we could add a DT property that would
be preferred to both.
Arnd
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-06-02 8:43 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-06-02 8:43 UTC (permalink / raw)
To: linuxppc-dev
Cc: Scott Wood, Mark Rutland, Ulf Hansson, linux-kernel, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Kumar Gala,
Rob Herring, Santosh Shilimkar, linux-arm-kernel, netdev,
linux-mmc, Xiaobo Xie, Yang-L
On Wednesday, June 1, 2016 8:47:22 PM CEST Scott Wood wrote:
> On Mon, 2016-05-30 at 15:15 +0200, Arnd Bergmann wrote:
> > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> > new file mode 100644
> > index 000000000000..2f30698f5bcf
> > --- /dev/null
> > +++ b/drivers/soc/fsl/guts.c
> > @@ -0,0 +1,130 @@
> > +/*
> > + * Freescale QorIQ Platforms GUTS Driver
> > + *
> > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +
> > +#include <linux/io.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/module.h>
> > +#include <linux/slab.h>
> > +#include <linux/of_address.h>
> > +#include <linux/of_platform.h>
> > +#include <linux/sys_soc.h>
> > +
> > +#define GUTS_PVR 0x0a0
> > +#define GUTS_SVR 0x0a4
> > +
> > +struct guts {
> > + void __iomem *regs;
>
> We already have a struct to define guts. Why are you not using it? Why do
> you consider using it to be "abuse"? What if we want to move more guts
> functionality into this driver?
This structure was in the original patch, I left it in there, only
removed the inclusion of the powerpc header file, which seemed to
be misplaced.
> > + bool little_endian;
> > + struct soc_device_attribute soc;
> > +};
> > +
> > +static u32 fsl_guts_get_svr(struct guts *guts)
> > +{
> > + if (guts->little_endian)
> > + return ioread32(guts->regs + GUTS_SVR);
> > + else
> > + return ioread32be(guts->regs + GUTS_SVR);
> > +}
> > +
> > +static u32 fsl_guts_get_pvr(struct guts *guts)
> > +{
> > + if (guts->little_endian)
> > + return ioread32(guts->regs + GUTS_PVR);
> > + else
> > + return ioread32be(guts->regs + GUTS_PVR);
> > +}
>
> You've removed the fallback to mfspr() on PPC, which would be helpful in some
> virtualized environments where we don't have the guts node (but do have other
> directly assigned devices). Of course, this is a consequence of the
> conversion into a platform device.
Right, it just didn't make any sense after the conversion. I couldn't
figure out what the intention was for the fallback. Virtualized environments
are an interesting case, but I'd also argue that a virtualized system is
not the original SoC anyway, so reporting the physical SoC as the
main system in the guest is a bit strange and we probably want to
come up with a different solution there.
In soc_device, we probably want to just report the type of hypervisor
in this case, which is what most users would expect there. For the
specific case of the mmc driver (are there any real use cases where
you'd pass on the mmc controller to a guest, as opposed to passing either
an emulated block device or the mmc device on an emulated mmc host?),
that means we have to come up with a different solution, but then
we'd be free to work around this by modifying the DT node of the mmc
device.
> > +/*
> > + * Table for matching compatible strings, for device tree
> > + * guts node, for Freescale QorIQ SOCs.
> > + */
> > +static const struct of_device_id fsl_guts_of_match[] = {
> > + /* For T4 & B4 Series SOCs */
> > + { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4
> > series" },
> [snip]
> > + { .compatible = "fsl,qoriq-device-config-2.0", .data = "P series"
>
> As noted in my comment on patch 3/4, these descriptions are reversed.
>
> They're also incomplete. t2080 has device config 2.0. t1040 is described as
> 2.0 though it should probably be 2.1 (or better, drop the generic compatible
> altogether).
Ok. Ideally I think we'd even look up the specific SoC names from the
SVC rather than the compatible string. I just didn't have a good list
for those to put in the driver.
> > + /*
> > + * syscon devices default to little-endian, but on powerpc we have
> > + * existing device trees with big-endian maps and an absent
> > endianess
> > + * "big-property"
> > + */
> > + if (!IS_ENABLED(CONFIG_POWERPC) &&
> > + !of_property_read_bool(dev->of_node, "big-endian"))
> > + guts->little_endian = true;
>
> This is not a syscon device (Yangbo's patch to add a guts node on ls2080 is
> the only guts node that says "syscon", and that was a leftover from earlier
> revisions and should probably be removed). Even if it were, where is it
> documented that syscon defaults to little-endian?
Documentation/devicetree/bindings/regmap/regmap.txt
We had a little screwup here, basically regmap (and by consequence, syscon)
always defaulted to little-endian way before that was documented, so it's
too late to change it, although I agree it would have made sense to document
regmap to default to big-endian on powerpc.
> Documentation/devicetree/bindings/common-properties.txt says that the
> individual binding specifies the default. The default for this node should be
> big-endian because that's what existed before there was a need to describe the
> endianness. And we need an update to the guts binding to specify that.
Good point. This proably means that specifying both the "guts" and "syscon"
compatible strings implies having to also specify the endianess explicitly
both ways, because otherwise we break one of the two bindings.
> > +
> > + guts->regs = devm_ioremap_resource(dev, 0);
> > + if (!guts->regs) {
> > + ret = -ENOMEM;
> > + kfree(guts);
> > + goto out;
> > + }
> > +
> > + fsl_guts_init(dev, guts);
> > + ret = 0;
> > +out:
> > + return ret;
> > +}
> > +
> > +static struct platform_driver fsl_soc_guts = {
> > + .probe = fsl_guts_probe,
> > + .driver.of_match_table = fsl_guts_of_match,
> > +};
> > +
> > +module_platform_driver(fsl_soc_guts);
>
> Again, this means that the information is not available during early boot,
> such as in the clock driver. Thus we would not be able to convert clk-qoriq's
> direct mfspr(SPRN_SVR) into an soc_device_match() (or anything else that makes
> use of this file), nor would we be able to move its access of the guts RCW
> registers into this driver.
Correct. Do we have a reason to convert the mfspr() though? I don't really
see an improvement over the current state if we do that, and for new devices
that might need the erratum workaround, we could add a DT property that would
be preferred to both.
Arnd
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-06-02 8:43 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-06-02 8:43 UTC (permalink / raw)
To: linuxppc-dev
Cc: Scott Wood, Mark Rutland, Ulf Hansson, linux-kernel, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Kumar Gala,
Rob Herring, Santosh Shilimkar, linux-arm-kernel, netdev,
linux-mmc, Xiaobo Xie, Yang-Leo Li, iommu, Yangbo Lu
On Wednesday, June 1, 2016 8:47:22 PM CEST Scott Wood wrote:
> On Mon, 2016-05-30 at 15:15 +0200, Arnd Bergmann wrote:
> > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> > new file mode 100644
> > index 000000000000..2f30698f5bcf
> > --- /dev/null
> > +++ b/drivers/soc/fsl/guts.c
> > @@ -0,0 +1,130 @@
> > +/*
> > + * Freescale QorIQ Platforms GUTS Driver
> > + *
> > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +
> > +#include <linux/io.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/module.h>
> > +#include <linux/slab.h>
> > +#include <linux/of_address.h>
> > +#include <linux/of_platform.h>
> > +#include <linux/sys_soc.h>
> > +
> > +#define GUTS_PVR 0x0a0
> > +#define GUTS_SVR 0x0a4
> > +
> > +struct guts {
> > + void __iomem *regs;
>
> We already have a struct to define guts. Why are you not using it? Why do
> you consider using it to be "abuse"? What if we want to move more guts
> functionality into this driver?
This structure was in the original patch, I left it in there, only
removed the inclusion of the powerpc header file, which seemed to
be misplaced.
> > + bool little_endian;
> > + struct soc_device_attribute soc;
> > +};
> > +
> > +static u32 fsl_guts_get_svr(struct guts *guts)
> > +{
> > + if (guts->little_endian)
> > + return ioread32(guts->regs + GUTS_SVR);
> > + else
> > + return ioread32be(guts->regs + GUTS_SVR);
> > +}
> > +
> > +static u32 fsl_guts_get_pvr(struct guts *guts)
> > +{
> > + if (guts->little_endian)
> > + return ioread32(guts->regs + GUTS_PVR);
> > + else
> > + return ioread32be(guts->regs + GUTS_PVR);
> > +}
>
> You've removed the fallback to mfspr() on PPC, which would be helpful in some
> virtualized environments where we don't have the guts node (but do have other
> directly assigned devices). Of course, this is a consequence of the
> conversion into a platform device.
Right, it just didn't make any sense after the conversion. I couldn't
figure out what the intention was for the fallback. Virtualized environments
are an interesting case, but I'd also argue that a virtualized system is
not the original SoC anyway, so reporting the physical SoC as the
main system in the guest is a bit strange and we probably want to
come up with a different solution there.
In soc_device, we probably want to just report the type of hypervisor
in this case, which is what most users would expect there. For the
specific case of the mmc driver (are there any real use cases where
you'd pass on the mmc controller to a guest, as opposed to passing either
an emulated block device or the mmc device on an emulated mmc host?),
that means we have to come up with a different solution, but then
we'd be free to work around this by modifying the DT node of the mmc
device.
> > +/*
> > + * Table for matching compatible strings, for device tree
> > + * guts node, for Freescale QorIQ SOCs.
> > + */
> > +static const struct of_device_id fsl_guts_of_match[] = {
> > + /* For T4 & B4 Series SOCs */
> > + { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4
> > series" },
> [snip]
> > + { .compatible = "fsl,qoriq-device-config-2.0", .data = "P series"
>
> As noted in my comment on patch 3/4, these descriptions are reversed.
>
> They're also incomplete. t2080 has device config 2.0. t1040 is described as
> 2.0 though it should probably be 2.1 (or better, drop the generic compatible
> altogether).
Ok. Ideally I think we'd even look up the specific SoC names from the
SVC rather than the compatible string. I just didn't have a good list
for those to put in the driver.
> > + /*
> > + * syscon devices default to little-endian, but on powerpc we have
> > + * existing device trees with big-endian maps and an absent
> > endianess
> > + * "big-property"
> > + */
> > + if (!IS_ENABLED(CONFIG_POWERPC) &&
> > + !of_property_read_bool(dev->of_node, "big-endian"))
> > + guts->little_endian = true;
>
> This is not a syscon device (Yangbo's patch to add a guts node on ls2080 is
> the only guts node that says "syscon", and that was a leftover from earlier
> revisions and should probably be removed). Even if it were, where is it
> documented that syscon defaults to little-endian?
Documentation/devicetree/bindings/regmap/regmap.txt
We had a little screwup here, basically regmap (and by consequence, syscon)
always defaulted to little-endian way before that was documented, so it's
too late to change it, although I agree it would have made sense to document
regmap to default to big-endian on powerpc.
> Documentation/devicetree/bindings/common-properties.txt says that the
> individual binding specifies the default. The default for this node should be
> big-endian because that's what existed before there was a need to describe the
> endianness. And we need an update to the guts binding to specify that.
Good point. This proably means that specifying both the "guts" and "syscon"
compatible strings implies having to also specify the endianess explicitly
both ways, because otherwise we break one of the two bindings.
> > +
> > + guts->regs = devm_ioremap_resource(dev, 0);
> > + if (!guts->regs) {
> > + ret = -ENOMEM;
> > + kfree(guts);
> > + goto out;
> > + }
> > +
> > + fsl_guts_init(dev, guts);
> > + ret = 0;
> > +out:
> > + return ret;
> > +}
> > +
> > +static struct platform_driver fsl_soc_guts = {
> > + .probe = fsl_guts_probe,
> > + .driver.of_match_table = fsl_guts_of_match,
> > +};
> > +
> > +module_platform_driver(fsl_soc_guts);
>
> Again, this means that the information is not available during early boot,
> such as in the clock driver. Thus we would not be able to convert clk-qoriq's
> direct mfspr(SPRN_SVR) into an soc_device_match() (or anything else that makes
> use of this file), nor would we be able to move its access of the guts RCW
> registers into this driver.
Correct. Do we have a reason to convert the mfspr() though? I don't really
see an improvement over the current state if we do that, and for new devices
that might need the erratum workaround, we could add a DT property that would
be preferred to both.
Arnd
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-06-02 8:43 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-06-02 8:43 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday, June 1, 2016 8:47:22 PM CEST Scott Wood wrote:
> On Mon, 2016-05-30 at 15:15 +0200, Arnd Bergmann wrote:
> > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> > new file mode 100644
> > index 000000000000..2f30698f5bcf
> > --- /dev/null
> > +++ b/drivers/soc/fsl/guts.c
> > @@ -0,0 +1,130 @@
> > +/*
> > + * Freescale QorIQ Platforms GUTS Driver
> > + *
> > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +
> > +#include <linux/io.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/module.h>
> > +#include <linux/slab.h>
> > +#include <linux/of_address.h>
> > +#include <linux/of_platform.h>
> > +#include <linux/sys_soc.h>
> > +
> > +#define GUTS_PVR 0x0a0
> > +#define GUTS_SVR 0x0a4
> > +
> > +struct guts {
> > + void __iomem *regs;
>
> We already have a struct to define guts. Why are you not using it? Why do
> you consider using it to be "abuse"? What if we want to move more guts
> functionality into this driver?
This structure was in the original patch, I left it in there, only
removed the inclusion of the powerpc header file, which seemed to
be misplaced.
> > + bool little_endian;
> > + struct soc_device_attribute soc;
> > +};
> > +
> > +static u32 fsl_guts_get_svr(struct guts *guts)
> > +{
> > + if (guts->little_endian)
> > + return ioread32(guts->regs + GUTS_SVR);
> > + else
> > + return ioread32be(guts->regs + GUTS_SVR);
> > +}
> > +
> > +static u32 fsl_guts_get_pvr(struct guts *guts)
> > +{
> > + if (guts->little_endian)
> > + return ioread32(guts->regs + GUTS_PVR);
> > + else
> > + return ioread32be(guts->regs + GUTS_PVR);
> > +}
>
> You've removed the fallback to mfspr() on PPC, which would be helpful in some
> virtualized environments where we don't have the guts node (but do have other
> directly assigned devices). Of course, this is a consequence of the
> conversion into a platform device.
Right, it just didn't make any sense after the conversion. I couldn't
figure out what the intention was for the fallback. Virtualized environments
are an interesting case, but I'd also argue that a virtualized system is
not the original SoC anyway, so reporting the physical SoC as the
main system in the guest is a bit strange and we probably want to
come up with a different solution there.
In soc_device, we probably want to just report the type of hypervisor
in this case, which is what most users would expect there. For the
specific case of the mmc driver (are there any real use cases where
you'd pass on the mmc controller to a guest, as opposed to passing either
an emulated block device or the mmc device on an emulated mmc host?),
that means we have to come up with a different solution, but then
we'd be free to work around this by modifying the DT node of the mmc
device.
> > +/*
> > + * Table for matching compatible strings, for device tree
> > + * guts node, for Freescale QorIQ SOCs.
> > + */
> > +static const struct of_device_id fsl_guts_of_match[] = {
> > + /* For T4 & B4 Series SOCs */
> > + { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4
> > series" },
> [snip]
> > + { .compatible = "fsl,qoriq-device-config-2.0", .data = "P series"
>
> As noted in my comment on patch 3/4, these descriptions are reversed.
>
> They're also incomplete. t2080 has device config 2.0. t1040 is described as
> 2.0 though it should probably be 2.1 (or better, drop the generic compatible
> altogether).
Ok. Ideally I think we'd even look up the specific SoC names from the
SVC rather than the compatible string. I just didn't have a good list
for those to put in the driver.
> > + /*
> > + * syscon devices default to little-endian, but on powerpc we have
> > + * existing device trees with big-endian maps and an absent
> > endianess
> > + * "big-property"
> > + */
> > + if (!IS_ENABLED(CONFIG_POWERPC) &&
> > + !of_property_read_bool(dev->of_node, "big-endian"))
> > + guts->little_endian = true;
>
> This is not a syscon device (Yangbo's patch to add a guts node on ls2080 is
> the only guts node that says "syscon", and that was a leftover from earlier
> revisions and should probably be removed). Even if it were, where is it
> documented that syscon defaults to little-endian?
Documentation/devicetree/bindings/regmap/regmap.txt
We had a little screwup here, basically regmap (and by consequence, syscon)
always defaulted to little-endian way before that was documented, so it's
too late to change it, although I agree it would have made sense to document
regmap to default to big-endian on powerpc.
> Documentation/devicetree/bindings/common-properties.txt says that the
> individual binding specifies the default. The default for this node should be
> big-endian because that's what existed before there was a need to describe the
> endianness. And we need an update to the guts binding to specify that.
Good point. This proably means that specifying both the "guts" and "syscon"
compatible strings implies having to also specify the endianess explicitly
both ways, because otherwise we break one of the two bindings.
> > +
> > + guts->regs = devm_ioremap_resource(dev, 0);
> > + if (!guts->regs) {
> > + ret = -ENOMEM;
> > + kfree(guts);
> > + goto out;
> > + }
> > +
> > + fsl_guts_init(dev, guts);
> > + ret = 0;
> > +out:
> > + return ret;
> > +}
> > +
> > +static struct platform_driver fsl_soc_guts = {
> > + .probe = fsl_guts_probe,
> > + .driver.of_match_table = fsl_guts_of_match,
> > +};
> > +
> > +module_platform_driver(fsl_soc_guts);
>
> Again, this means that the information is not available during early boot,
> such as in the clock driver. Thus we would not be able to convert clk-qoriq's
> direct mfspr(SPRN_SVR) into an soc_device_match() (or anything else that makes
> use of this file), nor would we be able to move its access of the guts RCW
> registers into this driver.
Correct. Do we have a reason to convert the mfspr() though? I don't really
see an improvement over the current state if we do that, and for new devices
that might need the erratum workaround, we could add a DT property that would
be preferred to both.
Arnd
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 3/4] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
2016-06-02 1:11 ` Scott Wood
` (2 preceding siblings ...)
(?)
@ 2016-06-02 8:52 ` Arnd Bergmann
-1 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-06-02 8:52 UTC (permalink / raw)
To: linuxppc-dev
Cc: Scott Wood, Mark Rutland, devicetree, Ulf Hansson, Russell King,
Bhupesh Sharma, netdev, Joerg Roedel, Santosh Shilimkar,
linux-mmc, Xiaobo Xie, linux-kernel, iommu, Rob Herring,
linux-i2c, Claudiu Manoil, Yangbo Lu, Kumar Gala, Yang-Leo Li,
linux-clk, linux-arm-kernel, Qiang Zhao
On Wednesday, June 1, 2016 8:11:14 PM CEST Scott Wood wrote:
> > +#define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) |
> > SDHCI_SPEC_200)
> > +static const struct soc_device_attribute esdhc_t4240_quirk = {
> > + /* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200
> > */
> > + { .soc_id = "T4*(0x824000)", .revision = "0x[01]?",
> > + .data = (void *)(uintptr_t)(T4240_HOST_VER) },
>
> Why should this code need to care that the string begins with "T4"? This
> creates dual maintenance if that were to change. It's also broken because
> T4240 has compatible = "fsl,t4240-device-config", "fsl,qoriq-device-config
> -2.0" and thus with these patches it would incorrectly show up as "P series
> (0x824000)". The compatible string of this node was never meant to be a key
> for choosing a string to describe the system to userspace.
This is an artifact of not knowing the specific SoC name, and we can change
that by looking up the name from the SVR value in the soc_device driver.
> 0x824000 is a magic number which should be represented symbolically.
Sure, feel free to change the format of the soc_device string in any
name, I just converted the information I had available in the comments.
The only thing that is important here is that the string matches what
the soc_device driver calls it.
> If T4240 is affected, then so are the reduced-core variants T4160 and T4080,
> but 0x824000 doesn't match them (Yangbo's patch had the same problem). And
> please don't respond with "0x824*"
>
> You also didn't strip out the E bit of SVR which indicates encryption
> capability and nothing else (Yangbo's patch did not have this problem because
> it used SVR_SOC_VER).
Ok, that should be easy enough to fix in the soc_device driver.
> What happens if the revision condition is more complicated, such as <= 0x20
> with 0x21 being fine? Multiple quirk entries where before we had as simple
> comparison?
I guess yes. I would really hope that there is no need to use this interface
pervasively, it's really just to work around the cases where there is no
way to pass the information in DT otherwise.
> I fail to see how this approach is an improvement (much less one that needs to
> hold up a patchset that is fixing a problem and is not touching any generic
> code). Why does this need to be a string?
A string is what user space gets in /sys/devices/soc/*, and we already have
code that does the same things there to work around quirks, here we just
use the same interface in a completely generic way. Note that not every
SoC family uses numbers in the same way, some have multiple subrevisions,
some have names etc.
Arnd
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 3/4] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-06-02 8:52 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-06-02 8:52 UTC (permalink / raw)
To: linuxppc-dev
Cc: Scott Wood, Mark Rutland, devicetree, Ulf Hansson, Russell King,
Bhupesh Sharma, netdev, Joerg Roedel, Santosh Shilimkar,
linux-mmc, Xiaobo Xie, linux-kernel, iommu, Rob Herring,
linux-i2c, Claudiu Manoil, Yangbo Lu, Kumar Gala, Yang-Leo Li,
linux-clk@vger.kernel.org
On Wednesday, June 1, 2016 8:11:14 PM CEST Scott Wood wrote:
> > +#define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) |
> > SDHCI_SPEC_200)
> > +static const struct soc_device_attribute esdhc_t4240_quirk = {
> > + /* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200
> > */
> > + { .soc_id = "T4*(0x824000)", .revision = "0x[01]?",
> > + .data = (void *)(uintptr_t)(T4240_HOST_VER) },
>
> Why should this code need to care that the string begins with "T4"? This
> creates dual maintenance if that were to change. It's also broken because
> T4240 has compatible = "fsl,t4240-device-config", "fsl,qoriq-device-config
> -2.0" and thus with these patches it would incorrectly show up as "P series
> (0x824000)". The compatible string of this node was never meant to be a key
> for choosing a string to describe the system to userspace.
This is an artifact of not knowing the specific SoC name, and we can change
that by looking up the name from the SVR value in the soc_device driver.
> 0x824000 is a magic number which should be represented symbolically.
Sure, feel free to change the format of the soc_device string in any
name, I just converted the information I had available in the comments.
The only thing that is important here is that the string matches what
the soc_device driver calls it.
> If T4240 is affected, then so are the reduced-core variants T4160 and T4080,
> but 0x824000 doesn't match them (Yangbo's patch had the same problem). And
> please don't respond with "0x824*"
>
> You also didn't strip out the E bit of SVR which indicates encryption
> capability and nothing else (Yangbo's patch did not have this problem because
> it used SVR_SOC_VER).
Ok, that should be easy enough to fix in the soc_device driver.
> What happens if the revision condition is more complicated, such as <= 0x20
> with 0x21 being fine? Multiple quirk entries where before we had as simple
> comparison?
I guess yes. I would really hope that there is no need to use this interface
pervasively, it's really just to work around the cases where there is no
way to pass the information in DT otherwise.
> I fail to see how this approach is an improvement (much less one that needs to
> hold up a patchset that is fixing a problem and is not touching any generic
> code). Why does this need to be a string?
A string is what user space gets in /sys/devices/soc/*, and we already have
code that does the same things there to work around quirks, here we just
use the same interface in a completely generic way. Note that not every
SoC family uses numbers in the same way, some have multiple subrevisions,
some have names etc.
Arnd
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 3/4] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-06-02 8:52 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-06-02 8:52 UTC (permalink / raw)
To: linuxppc-dev
Cc: Scott Wood, Mark Rutland, devicetree, Ulf Hansson, Russell King,
Bhupesh Sharma, netdev, Joerg Roedel, Santosh Shilimkar,
linux-mmc, Xiaobo Xie, linux-kernel, iommu, Rob Herring,
linux-i2c, Claudiu Manoil, Yangbo Lu, Kumar Gala, Yang-Leo Li,
linux-clk@vger.kernel.org
On Wednesday, June 1, 2016 8:11:14 PM CEST Scott Wood wrote:
> > +#define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) |
> > SDHCI_SPEC_200)
> > +static const struct soc_device_attribute esdhc_t4240_quirk = {
> > + /* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200
> > */
> > + { .soc_id = "T4*(0x824000)", .revision = "0x[01]?",
> > + .data = (void *)(uintptr_t)(T4240_HOST_VER) },
>
> Why should this code need to care that the string begins with "T4"? This
> creates dual maintenance if that were to change. It's also broken because
> T4240 has compatible = "fsl,t4240-device-config", "fsl,qoriq-device-config
> -2.0" and thus with these patches it would incorrectly show up as "P series
> (0x824000)". The compatible string of this node was never meant to be a key
> for choosing a string to describe the system to userspace.
This is an artifact of not knowing the specific SoC name, and we can change
that by looking up the name from the SVR value in the soc_device driver.
> 0x824000 is a magic number which should be represented symbolically.
Sure, feel free to change the format of the soc_device string in any
name, I just converted the information I had available in the comments.
The only thing that is important here is that the string matches what
the soc_device driver calls it.
> If T4240 is affected, then so are the reduced-core variants T4160 and T4080,
> but 0x824000 doesn't match them (Yangbo's patch had the same problem). And
> please don't respond with "0x824*"
>
> You also didn't strip out the E bit of SVR which indicates encryption
> capability and nothing else (Yangbo's patch did not have this problem because
> it used SVR_SOC_VER).
Ok, that should be easy enough to fix in the soc_device driver.
> What happens if the revision condition is more complicated, such as <= 0x20
> with 0x21 being fine? Multiple quirk entries where before we had as simple
> comparison?
I guess yes. I would really hope that there is no need to use this interface
pervasively, it's really just to work around the cases where there is no
way to pass the information in DT otherwise.
> I fail to see how this approach is an improvement (much less one that needs to
> hold up a patchset that is fixing a problem and is not touching any generic
> code). Why does this need to be a string?
A string is what user space gets in /sys/devices/soc/*, and we already have
code that does the same things there to work around quirks, here we just
use the same interface in a completely generic way. Note that not every
SoC family uses numbers in the same way, some have multiple subrevisions,
some have names etc.
Arnd
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 3/4] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-06-02 8:52 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-06-02 8:52 UTC (permalink / raw)
To: linuxppc-dev
Cc: Scott Wood, Mark Rutland, devicetree, Ulf Hansson, Russell King,
Bhupesh Sharma, netdev, Joerg Roedel, Santosh Shilimkar,
linux-mmc, Xiaobo Xie, linux-kernel, iommu, Rob Herring,
linux-i2c, Claudiu Manoil, Yangbo Lu, Kumar Gala, Yang-Leo Li,
linux-clk, linux-arm-kernel, Qiang Zhao
On Wednesday, June 1, 2016 8:11:14 PM CEST Scott Wood wrote:
> > +#define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) |
> > SDHCI_SPEC_200)
> > +static const struct soc_device_attribute esdhc_t4240_quirk = {
> > + /* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200
> > */
> > + { .soc_id = "T4*(0x824000)", .revision = "0x[01]?",
> > + .data = (void *)(uintptr_t)(T4240_HOST_VER) },
>
> Why should this code need to care that the string begins with "T4"? This
> creates dual maintenance if that were to change. It's also broken because
> T4240 has compatible = "fsl,t4240-device-config", "fsl,qoriq-device-config
> -2.0" and thus with these patches it would incorrectly show up as "P series
> (0x824000)". The compatible string of this node was never meant to be a key
> for choosing a string to describe the system to userspace.
This is an artifact of not knowing the specific SoC name, and we can change
that by looking up the name from the SVR value in the soc_device driver.
> 0x824000 is a magic number which should be represented symbolically.
Sure, feel free to change the format of the soc_device string in any
name, I just converted the information I had available in the comments.
The only thing that is important here is that the string matches what
the soc_device driver calls it.
> If T4240 is affected, then so are the reduced-core variants T4160 and T4080,
> but 0x824000 doesn't match them (Yangbo's patch had the same problem). And
> please don't respond with "0x824*"
>
> You also didn't strip out the E bit of SVR which indicates encryption
> capability and nothing else (Yangbo's patch did not have this problem because
> it used SVR_SOC_VER).
Ok, that should be easy enough to fix in the soc_device driver.
> What happens if the revision condition is more complicated, such as <= 0x20
> with 0x21 being fine? Multiple quirk entries where before we had as simple
> comparison?
I guess yes. I would really hope that there is no need to use this interface
pervasively, it's really just to work around the cases where there is no
way to pass the information in DT otherwise.
> I fail to see how this approach is an improvement (much less one that needs to
> hold up a patchset that is fixing a problem and is not touching any generic
> code). Why does this need to be a string?
A string is what user space gets in /sys/devices/soc/*, and we already have
code that does the same things there to work around quirks, here we just
use the same interface in a completely generic way. Note that not every
SoC family uses numbers in the same way, some have multiple subrevisions,
some have names etc.
Arnd
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH 3/4] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-06-02 8:52 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-06-02 8:52 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday, June 1, 2016 8:11:14 PM CEST Scott Wood wrote:
> > +#define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) |
> > SDHCI_SPEC_200)
> > +static const struct soc_device_attribute esdhc_t4240_quirk = {
> > + /* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200
> > */
> > + { .soc_id = "T4*(0x824000)", .revision = "0x[01]?",
> > + .data = (void *)(uintptr_t)(T4240_HOST_VER) },
>
> Why should this code need to care that the string begins with "T4"? This
> creates dual maintenance if that were to change. It's also broken because
> T4240 has compatible = "fsl,t4240-device-config", "fsl,qoriq-device-config
> -2.0" and thus with these patches it would incorrectly show up as "P series
> (0x824000)". The compatible string of this node was never meant to be a key
> for choosing a string to describe the system to userspace.
This is an artifact of not knowing the specific SoC name, and we can change
that by looking up the name from the SVR value in the soc_device driver.
> 0x824000 is a magic number which should be represented symbolically.
Sure, feel free to change the format of the soc_device string in any
name, I just converted the information I had available in the comments.
The only thing that is important here is that the string matches what
the soc_device driver calls it.
> If T4240 is affected, then so are the reduced-core variants T4160 and T4080,
> but 0x824000 doesn't match them (Yangbo's patch had the same problem). And
> please don't respond with "0x824*"
>
> You also didn't strip out the E bit of SVR which indicates encryption
> capability and nothing else (Yangbo's patch did not have this problem because
> it used SVR_SOC_VER).
Ok, that should be easy enough to fix in the soc_device driver.
> What happens if the revision condition is more complicated, such as <= 0x20
> with 0x21 being fine? Multiple quirk entries where before we had as simple
> comparison?
I guess yes. I would really hope that there is no need to use this interface
pervasively, it's really just to work around the cases where there is no
way to pass the information in DT otherwise.
> I fail to see how this approach is an improvement (much less one that needs to
> hold up a patchset that is fixing a problem and is not touching any generic
> code). Why does this need to be a string?
A string is what user space gets in /sys/devices/soc/*, and we already have
code that does the same things there to work around quirks, here we just
use the same interface in a completely generic way. Note that not every
SoC family uses numbers in the same way, some have multiple subrevisions,
some have names etc.
Arnd
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 4/4] Revert "powerpc/fsl: Move fsl_guts.h out of arch/powerpc"
@ 2016-06-02 9:01 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-06-02 9:01 UTC (permalink / raw)
To: Scott Wood
Cc: linuxppc-dev, Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie,
linux-i2c, linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Rob Herring,
Santosh Shilimkar, linux-arm-kernel, netdev, linux-mmc,
linux-kernel, Yang-Leo Li, iommu, Kumar Gala
On Wednesday, June 1, 2016 8:24:20 PM CEST Scott Wood wrote:
> On Mon, 2016-05-30 at 15:18 +0200, Arnd Bergmann wrote:
> > All users of this driver are PowerPC specific and the header file
> > has no business in the global include/linux/ hierarchy, so move
> > it back before anyone starts using it on ARM.
> >
> > This reverts commit 948486544713492f00ac8a9572909101ea892cb0.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > This part of the series is not required for the eSDHC quirk,
> > but it restores the asm/fsl_guts.h header so it doesn't accidentally
> > get abused for this in the future. I found two drivers outside of
> > arch/powerpc that already accessed the registers directly, but the
> > functions look fairly contained, and can be easily hidden in an
> > #ifdef CONFIG_PPC
>
> NACK
>
> Besides adding ifdef pollution for no good reason, this register block is used
> on some ARM chips as well. Why is it a problem if "anyone starts using it on
> ARM"?
It's just not a good interface when it's defined as "this is the layout of
a register area that any driver can ioremap() if they can figure out the
device node". It's not uncommon to have register areas like that, but
normally you have at the minimum a 'syscon' device to handle locking
between drivers accessing the same registers and to avoid having to map
the same area multiple times.
If we need to use 'guts' registers on ARM, we can find a way to abstract
them properly for the given use cases, using a syscon or a driver with
exported functions, but just making a PowerPC platform specific header
global to all Linux drivers by putting it into include/linux doesn't seem
right.
Note that the header file uses a structure definition rather than the more
common macros with register offsets, which is fine for a driver that has
its own registers and abstracts them, but it doesn't really work with
the regmap interface, so if we want to use it with syscon, it also needs to
be rewritten.
> BTW, of all the mailing lists you included on this CC, you seem to have left
> off the PPC list (I've added it).
Sorry, my mistake.
Arnd
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 4/4] Revert "powerpc/fsl: Move fsl_guts.h out of arch/powerpc"
@ 2016-06-02 9:01 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-06-02 9:01 UTC (permalink / raw)
To: Scott Wood
Cc: Mark Rutland, Ulf Hansson, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Qiang Zhao, Russell King,
Bhupesh Sharma, Claudiu Manoil,
devicetree-u79uwXL29TY76Z2rM5mHXA, Kumar Gala, Rob Herring,
Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
Xiaobo Xie, Yang-Leo Li,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
On Wednesday, June 1, 2016 8:24:20 PM CEST Scott Wood wrote:
> On Mon, 2016-05-30 at 15:18 +0200, Arnd Bergmann wrote:
> > All users of this driver are PowerPC specific and the header file
> > has no business in the global include/linux/ hierarchy, so move
> > it back before anyone starts using it on ARM.
> >
> > This reverts commit 948486544713492f00ac8a9572909101ea892cb0.
> >
> > Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> > ---
> > This part of the series is not required for the eSDHC quirk,
> > but it restores the asm/fsl_guts.h header so it doesn't accidentally
> > get abused for this in the future. I found two drivers outside of
> > arch/powerpc that already accessed the registers directly, but the
> > functions look fairly contained, and can be easily hidden in an
> > #ifdef CONFIG_PPC
>
> NACK
>
> Besides adding ifdef pollution for no good reason, this register block is used
> on some ARM chips as well. Why is it a problem if "anyone starts using it on
> ARM"?
It's just not a good interface when it's defined as "this is the layout of
a register area that any driver can ioremap() if they can figure out the
device node". It's not uncommon to have register areas like that, but
normally you have at the minimum a 'syscon' device to handle locking
between drivers accessing the same registers and to avoid having to map
the same area multiple times.
If we need to use 'guts' registers on ARM, we can find a way to abstract
them properly for the given use cases, using a syscon or a driver with
exported functions, but just making a PowerPC platform specific header
global to all Linux drivers by putting it into include/linux doesn't seem
right.
Note that the header file uses a structure definition rather than the more
common macros with register offsets, which is fine for a driver that has
its own registers and abstracts them, but it doesn't really work with
the regmap interface, so if we want to use it with syscon, it also needs to
be rewritten.
> BTW, of all the mailing lists you included on this CC, you seem to have left
> off the PPC list (I've added it).
Sorry, my mistake.
Arnd
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 4/4] Revert "powerpc/fsl: Move fsl_guts.h out of arch/powerpc"
@ 2016-06-02 9:01 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-06-02 9:01 UTC (permalink / raw)
To: Scott Wood
Cc: Mark Rutland, Ulf Hansson, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Qiang Zhao, Russell King,
Bhupesh Sharma, Claudiu Manoil,
devicetree-u79uwXL29TY76Z2rM5mHXA, Kumar Gala, Rob Herring,
Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
Xiaobo Xie, Yang-Leo Li,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
On Wednesday, June 1, 2016 8:24:20 PM CEST Scott Wood wrote:
> On Mon, 2016-05-30 at 15:18 +0200, Arnd Bergmann wrote:
> > All users of this driver are PowerPC specific and the header file
> > has no business in the global include/linux/ hierarchy, so move
> > it back before anyone starts using it on ARM.
> >
> > This reverts commit 948486544713492f00ac8a9572909101ea892cb0.
> >
> > Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> > ---
> > This part of the series is not required for the eSDHC quirk,
> > but it restores the asm/fsl_guts.h header so it doesn't accidentally
> > get abused for this in the future. I found two drivers outside of
> > arch/powerpc that already accessed the registers directly, but the
> > functions look fairly contained, and can be easily hidden in an
> > #ifdef CONFIG_PPC
>
> NACK
>
> Besides adding ifdef pollution for no good reason, this register block is used
> on some ARM chips as well. Why is it a problem if "anyone starts using it on
> ARM"?
It's just not a good interface when it's defined as "this is the layout of
a register area that any driver can ioremap() if they can figure out the
device node". It's not uncommon to have register areas like that, but
normally you have at the minimum a 'syscon' device to handle locking
between drivers accessing the same registers and to avoid having to map
the same area multiple times.
If we need to use 'guts' registers on ARM, we can find a way to abstract
them properly for the given use cases, using a syscon or a driver with
exported functions, but just making a PowerPC platform specific header
global to all Linux drivers by putting it into include/linux doesn't seem
right.
Note that the header file uses a structure definition rather than the more
common macros with register offsets, which is fine for a driver that has
its own registers and abstracts them, but it doesn't really work with
the regmap interface, so if we want to use it with syscon, it also needs to
be rewritten.
> BTW, of all the mailing lists you included on this CC, you seem to have left
> off the PPC list (I've added it).
Sorry, my mistake.
Arnd
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 4/4] Revert "powerpc/fsl: Move fsl_guts.h out of arch/powerpc"
@ 2016-06-02 9:01 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-06-02 9:01 UTC (permalink / raw)
To: Scott Wood
Cc: linuxppc-dev, Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie,
linux-i2c, linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Rob Herring,
Santosh Shilimkar, linux-arm-kernel, netdev, linux-mmc,
linux-kernel, Yang-Leo Li, iommu, Kumar Gala
On Wednesday, June 1, 2016 8:24:20 PM CEST Scott Wood wrote:
> On Mon, 2016-05-30 at 15:18 +0200, Arnd Bergmann wrote:
> > All users of this driver are PowerPC specific and the header file
> > has no business in the global include/linux/ hierarchy, so move
> > it back before anyone starts using it on ARM.
> >
> > This reverts commit 948486544713492f00ac8a9572909101ea892cb0.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > This part of the series is not required for the eSDHC quirk,
> > but it restores the asm/fsl_guts.h header so it doesn't accidentally
> > get abused for this in the future. I found two drivers outside of
> > arch/powerpc that already accessed the registers directly, but the
> > functions look fairly contained, and can be easily hidden in an
> > #ifdef CONFIG_PPC
>
> NACK
>
> Besides adding ifdef pollution for no good reason, this register block is used
> on some ARM chips as well. Why is it a problem if "anyone starts using it on
> ARM"?
It's just not a good interface when it's defined as "this is the layout of
a register area that any driver can ioremap() if they can figure out the
device node". It's not uncommon to have register areas like that, but
normally you have at the minimum a 'syscon' device to handle locking
between drivers accessing the same registers and to avoid having to map
the same area multiple times.
If we need to use 'guts' registers on ARM, we can find a way to abstract
them properly for the given use cases, using a syscon or a driver with
exported functions, but just making a PowerPC platform specific header
global to all Linux drivers by putting it into include/linux doesn't seem
right.
Note that the header file uses a structure definition rather than the more
common macros with register offsets, which is fine for a driver that has
its own registers and abstracts them, but it doesn't really work with
the regmap interface, so if we want to use it with syscon, it also needs to
be rewritten.
> BTW, of all the mailing lists you included on this CC, you seem to have left
> off the PPC list (I've added it).
Sorry, my mistake.
Arnd
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH 4/4] Revert "powerpc/fsl: Move fsl_guts.h out of arch/powerpc"
@ 2016-06-02 9:01 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-06-02 9:01 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday, June 1, 2016 8:24:20 PM CEST Scott Wood wrote:
> On Mon, 2016-05-30 at 15:18 +0200, Arnd Bergmann wrote:
> > All users of this driver are PowerPC specific and the header file
> > has no business in the global include/linux/ hierarchy, so move
> > it back before anyone starts using it on ARM.
> >
> > This reverts commit 948486544713492f00ac8a9572909101ea892cb0.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > This part of the series is not required for the eSDHC quirk,
> > but it restores the asm/fsl_guts.h header so it doesn't accidentally
> > get abused for this in the future. I found two drivers outside of
> > arch/powerpc that already accessed the registers directly, but the
> > functions look fairly contained, and can be easily hidden in an
> > #ifdef CONFIG_PPC
>
> NACK
>
> Besides adding ifdef pollution for no good reason, this register block is used
> on some ARM chips as well. Why is it a problem if "anyone starts using it on
> ARM"?
It's just not a good interface when it's defined as "this is the layout of
a register area that any driver can ioremap() if they can figure out the
device node". It's not uncommon to have register areas like that, but
normally you have at the minimum a 'syscon' device to handle locking
between drivers accessing the same registers and to avoid having to map
the same area multiple times.
If we need to use 'guts' registers on ARM, we can find a way to abstract
them properly for the given use cases, using a syscon or a driver with
exported functions, but just making a PowerPC platform specific header
global to all Linux drivers by putting it into include/linux doesn't seem
right.
Note that the header file uses a structure definition rather than the more
common macros with register offsets, which is fine for a driver that has
its own registers and abstracts them, but it doesn't really work with
the regmap interface, so if we want to use it with syscon, it also needs to
be rewritten.
> BTW, of all the mailing lists you included on this CC, you seem to have left
> off the PPC list (I've added it).
Sorry, my mistake.
Arnd
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
2016-06-02 8:43 ` Arnd Bergmann
` (3 preceding siblings ...)
(?)
@ 2016-06-11 1:50 ` Scott Wood
-1 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-11 1:50 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev
Cc: Mark Rutland, Ulf Hansson, linux-kernel, linux-i2c, linux-clk,
Qiang Zhao, Russell King, Bhupesh Sharma, Joerg Roedel,
Claudiu Manoil, devicetree, Kumar Gala, Rob Herring,
Santosh Shilimkar, linux-arm-kernel, netdev, linux-mmc,
Xiaobo Xie, Yang-Leo Li, iommu, Yangbo Lu
On Thu, 2016-06-02 at 10:43 +0200, Arnd Bergmann wrote:
> On Wednesday, June 1, 2016 8:47:22 PM CEST Scott Wood wrote:
> > On Mon, 2016-05-30 at 15:15 +0200, Arnd Bergmann wrote:
> > > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> > > new file mode 100644
> > > index 000000000000..2f30698f5bcf
> > > --- /dev/null
> > > +++ b/drivers/soc/fsl/guts.c
> > > @@ -0,0 +1,130 @@
> > > +/*
> > > + * Freescale QorIQ Platforms GUTS Driver
> > > + *
> > > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License as published by
> > > + * the Free Software Foundation; either version 2 of the License, or
> > > + * (at your option) any later version.
> > > + */
> > > +
> > > +#include <linux/io.h>
> > > +#include <linux/platform_device.h>
> > > +#include <linux/module.h>
> > > +#include <linux/slab.h>
> > > +#include <linux/of_address.h>
> > > +#include <linux/of_platform.h>
> > > +#include <linux/sys_soc.h>
> > > +
> > > +#define GUTS_PVR 0x0a0
> > > +#define GUTS_SVR 0x0a4
> > > +
> > > +struct guts {
> > > + void __iomem *regs;
> >
> > We already have a struct to define guts. Why are you not using it? Why
> > do
> > you consider using it to be "abuse"? What if we want to move more guts
> > functionality into this driver?
>
> This structure was in the original patch, I left it in there, only
> removed the inclusion of the powerpc header file, which seemed to
> be misplaced.
I'm not refering "struct guts". I'm referring to changing
"struct ccsr_guts __iomem *regs" into "void __iomem *regs".
And it's not a powerpc header file.
> > > +/*
> > > + * Table for matching compatible strings, for device tree
> > > + * guts node, for Freescale QorIQ SOCs.
> > > + */
> > > +static const struct of_device_id fsl_guts_of_match[] = {
> > > + /* For T4 & B4 Series SOCs */
> > > + { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4
> > > series" },
> > [snip]
> > > + { .compatible = "fsl,qoriq-device-config-2.0", .data = "P
> > > series"
> >
> > As noted in my comment on patch 3/4, these descriptions are reversed.
> >
> > They're also incomplete. t2080 has device config 2.0. t1040 is described
> > as
> > 2.0 though it should probably be 2.1 (or better, drop the generic
> > compatible
> > altogether).
>
> Ok. Ideally I think we'd even look up the specific SoC names from the
> SVC rather than the compatible string. I just didn't have a good list
> for those to put in the driver.
The list is in arch/powerpc/include/asm/mpc85xx.h but I don't know why we need
to convert it to a string in the first place.
>
> > > + /*
> > > + * syscon devices default to little-endian, but on powerpc we
> > > have
> > > + * existing device trees with big-endian maps and an absent
> > > endianess
> > > + * "big-property"
> > > + */
> > > + if (!IS_ENABLED(CONFIG_POWERPC) &&
> > > + !of_property_read_bool(dev->of_node, "big-endian"))
> > > + guts->little_endian = true;
> >
> > This is not a syscon device (Yangbo's patch to add a guts node on ls2080
> > is
> > the only guts node that says "syscon", and that was a leftover from
> > earlier
> > revisions and should probably be removed). Even if it were, where is it
> > documented that syscon defaults to little-endian?
>
> Documentation/devicetree/bindings/regmap/regmap.txt
>
> We had a little screwup here, basically regmap (and by consequence, syscon)
> always defaulted to little-endian way before that was documented, so it's
> too late to change it,
What causes a device node to fall under the jurisdiction of regmap.txt?
Again, these nodes do not claim "syscon" compatibility.
> although I agree it would have made sense to document
> regmap to default to big-endian on powerpc.
Please don't. It's enough of a mess as is; no need to start throwing in
architecture ifdefs.
> > Documentation/devicetree/bindings/common-properties.txt says that the
> > individual binding specifies the default. The default for this node
> > should be
> > big-endian because that's what existed before there was a need to describe
> > the
> > endianness. And we need an update to the guts binding to specify that.
>
> Good point. This proably means that specifying both the "guts" and "syscon"
> compatible strings implies having to also specify the endianess explicitly
> both ways, because otherwise we break one of the two bindings.
Yes, but the node should only specify "guts".
>
> > > +
> > > + guts->regs = devm_ioremap_resource(dev, 0);
> > > + if (!guts->regs) {
> > > + ret = -ENOMEM;
> > > + kfree(guts);
> > > + goto out;
> > > + }
> > > +
> > > + fsl_guts_init(dev, guts);
> > > + ret = 0;
> > > +out:
> > > + return ret;
> > > +}
> > > +
> > > +static struct platform_driver fsl_soc_guts = {
> > > + .probe = fsl_guts_probe,
> > > + .driver.of_match_table = fsl_guts_of_match,
> > > +};
> > > +
> > > +module_platform_driver(fsl_soc_guts);
> >
> > Again, this means that the information is not available during early boot,
> > such as in the clock driver. Thus we would not be able to convert clk
> > -qoriq's
> > direct mfspr(SPRN_SVR) into an soc_device_match() (or anything else that
> > makes
> > use of this file), nor would we be able to move its access of the guts RCW
> > registers into this driver.
>
> Correct. Do we have a reason to convert the mfspr() though? I don't really
> see an improvement over the current state if we do that,
Then should we drop this patchset and put a similar PPC ifdef in
drivers/mmc/host/sdhci-of-esdhc.c?
There's also the RCW access. You said in the patch 4/4 discussion that you di
dn't like any random driver ioremapping the registers...
> and for new devices
> that might need the erratum workaround, we could add a DT property that
> would
> be preferred to both.
It's unlikely that we would know the erratum exists at the time the device
tree is created. We also generally don't have separate device trees for each
revision of a chip (and if we did, we'd have users that use the wrong one).
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-06-11 1:50 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-11 1:50 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev
Cc: Mark Rutland, Ulf Hansson, linux-kernel, linux-i2c, linux-clk,
Qiang Zhao, Russell King, Bhupesh Sharma, Joerg Roedel,
Claudiu Manoil, devicetree, Kumar Gala, Rob Herring,
Santosh Shilimkar, linux-arm-kernel, netdev, linux-mmc,
Xiaobo Xie, Yang-Leo Li,
On Thu, 2016-06-02 at 10:43 +0200, Arnd Bergmann wrote:
> On Wednesday, June 1, 2016 8:47:22 PM CEST Scott Wood wrote:
> > On Mon, 2016-05-30 at 15:15 +0200, Arnd Bergmann wrote:
> > > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> > > new file mode 100644
> > > index 000000000000..2f30698f5bcf
> > > --- /dev/null
> > > +++ b/drivers/soc/fsl/guts.c
> > > @@ -0,0 +1,130 @@
> > > +/*
> > > + * Freescale QorIQ Platforms GUTS Driver
> > > + *
> > > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License as published by
> > > + * the Free Software Foundation; either version 2 of the License, or
> > > + * (at your option) any later version.
> > > + */
> > > +
> > > +#include <linux/io.h>
> > > +#include <linux/platform_device.h>
> > > +#include <linux/module.h>
> > > +#include <linux/slab.h>
> > > +#include <linux/of_address.h>
> > > +#include <linux/of_platform.h>
> > > +#include <linux/sys_soc.h>
> > > +
> > > +#define GUTS_PVR 0x0a0
> > > +#define GUTS_SVR 0x0a4
> > > +
> > > +struct guts {
> > > + void __iomem *regs;
> >
> > We already have a struct to define guts. Why are you not using it? Why
> > do
> > you consider using it to be "abuse"? What if we want to move more guts
> > functionality into this driver?
>
> This structure was in the original patch, I left it in there, only
> removed the inclusion of the powerpc header file, which seemed to
> be misplaced.
I'm not refering "struct guts". I'm referring to changing
"struct ccsr_guts __iomem *regs" into "void __iomem *regs".
And it's not a powerpc header file.
> > > +/*
> > > + * Table for matching compatible strings, for device tree
> > > + * guts node, for Freescale QorIQ SOCs.
> > > + */
> > > +static const struct of_device_id fsl_guts_of_match[] = {
> > > + /* For T4 & B4 Series SOCs */
> > > + { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4
> > > series" },
> > [snip]
> > > + { .compatible = "fsl,qoriq-device-config-2.0", .data = "P
> > > series"
> >
> > As noted in my comment on patch 3/4, these descriptions are reversed.
> >
> > They're also incomplete. t2080 has device config 2.0. t1040 is described
> > as
> > 2.0 though it should probably be 2.1 (or better, drop the generic
> > compatible
> > altogether).
>
> Ok. Ideally I think we'd even look up the specific SoC names from the
> SVC rather than the compatible string. I just didn't have a good list
> for those to put in the driver.
The list is in arch/powerpc/include/asm/mpc85xx.h but I don't know why we need
to convert it to a string in the first place.
>
> > > + /*
> > > + * syscon devices default to little-endian, but on powerpc we
> > > have
> > > + * existing device trees with big-endian maps and an absent
> > > endianess
> > > + * "big-property"
> > > + */
> > > + if (!IS_ENABLED(CONFIG_POWERPC) &&
> > > + !of_property_read_bool(dev->of_node, "big-endian"))
> > > + guts->little_endian = true;
> >
> > This is not a syscon device (Yangbo's patch to add a guts node on ls2080
> > is
> > the only guts node that says "syscon", and that was a leftover from
> > earlier
> > revisions and should probably be removed). Even if it were, where is it
> > documented that syscon defaults to little-endian?
>
> Documentation/devicetree/bindings/regmap/regmap.txt
>
> We had a little screwup here, basically regmap (and by consequence, syscon)
> always defaulted to little-endian way before that was documented, so it's
> too late to change it,
What causes a device node to fall under the jurisdiction of regmap.txt?
Again, these nodes do not claim "syscon" compatibility.
> although I agree it would have made sense to document
> regmap to default to big-endian on powerpc.
Please don't. It's enough of a mess as is; no need to start throwing in
architecture ifdefs.
> > Documentation/devicetree/bindings/common-properties.txt says that the
> > individual binding specifies the default. The default for this node
> > should be
> > big-endian because that's what existed before there was a need to describe
> > the
> > endianness. And we need an update to the guts binding to specify that.
>
> Good point. This proably means that specifying both the "guts" and "syscon"
> compatible strings implies having to also specify the endianess explicitly
> both ways, because otherwise we break one of the two bindings.
Yes, but the node should only specify "guts".
>
> > > +
> > > + guts->regs = devm_ioremap_resource(dev, 0);
> > > + if (!guts->regs) {
> > > + ret = -ENOMEM;
> > > + kfree(guts);
> > > + goto out;
> > > + }
> > > +
> > > + fsl_guts_init(dev, guts);
> > > + ret = 0;
> > > +out:
> > > + return ret;
> > > +}
> > > +
> > > +static struct platform_driver fsl_soc_guts = {
> > > + .probe = fsl_guts_probe,
> > > + .driver.of_match_table = fsl_guts_of_match,
> > > +};
> > > +
> > > +module_platform_driver(fsl_soc_guts);
> >
> > Again, this means that the information is not available during early boot,
> > such as in the clock driver. Thus we would not be able to convert clk
> > -qoriq's
> > direct mfspr(SPRN_SVR) into an soc_device_match() (or anything else that
> > makes
> > use of this file), nor would we be able to move its access of the guts RCW
> > registers into this driver.
>
> Correct. Do we have a reason to convert the mfspr() though? I don't really
> see an improvement over the current state if we do that,
Then should we drop this patchset and put a similar PPC ifdef in
drivers/mmc/host/sdhci-of-esdhc.c?
There's also the RCW access. You said in the patch 4/4 discussion that you di
dn't like any random driver ioremapping the registers...
> and for new devices
> that might need the erratum workaround, we could add a DT property that
> would
> be preferred to both.
It's unlikely that we would know the erratum exists at the time the device
tree is created. We also generally don't have separate device trees for each
revision of a chip (and if we did, we'd have users that use the wrong one).
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-06-11 1:50 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-11 1:50 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev
Cc: Mark Rutland, Ulf Hansson, linux-kernel, linux-i2c, linux-clk,
Qiang Zhao, Russell King, Bhupesh Sharma, Joerg Roedel,
Claudiu Manoil, devicetree, Kumar Gala, Rob Herring,
Santosh Shilimkar, linux-arm-kernel, netdev, linux-mmc,
Xiaobo Xie, Yang-Leo Li
On Thu, 2016-06-02 at 10:43 +0200, Arnd Bergmann wrote:
> On Wednesday, June 1, 2016 8:47:22 PM CEST Scott Wood wrote:
> > On Mon, 2016-05-30 at 15:15 +0200, Arnd Bergmann wrote:
> > > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> > > new file mode 100644
> > > index 000000000000..2f30698f5bcf
> > > --- /dev/null
> > > +++ b/drivers/soc/fsl/guts.c
> > > @@ -0,0 +1,130 @@
> > > +/*
> > > + * Freescale QorIQ Platforms GUTS Driver
> > > + *
> > > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License as published by
> > > + * the Free Software Foundation; either version 2 of the License, or
> > > + * (at your option) any later version.
> > > + */
> > > +
> > > +#include <linux/io.h>
> > > +#include <linux/platform_device.h>
> > > +#include <linux/module.h>
> > > +#include <linux/slab.h>
> > > +#include <linux/of_address.h>
> > > +#include <linux/of_platform.h>
> > > +#include <linux/sys_soc.h>
> > > +
> > > +#define GUTS_PVR 0x0a0
> > > +#define GUTS_SVR 0x0a4
> > > +
> > > +struct guts {
> > > + void __iomem *regs;
> >
> > We already have a struct to define guts. Why are you not using it? Why
> > do
> > you consider using it to be "abuse"? What if we want to move more guts
> > functionality into this driver?
>
> This structure was in the original patch, I left it in there, only
> removed the inclusion of the powerpc header file, which seemed to
> be misplaced.
I'm not refering "struct guts". I'm referring to changing
"struct ccsr_guts __iomem *regs" into "void __iomem *regs".
And it's not a powerpc header file.
> > > +/*
> > > + * Table for matching compatible strings, for device tree
> > > + * guts node, for Freescale QorIQ SOCs.
> > > + */
> > > +static const struct of_device_id fsl_guts_of_match[] = {
> > > + /* For T4 & B4 Series SOCs */
> > > + { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4
> > > series" },
> > [snip]
> > > + { .compatible = "fsl,qoriq-device-config-2.0", .data = "P
> > > series"
> >
> > As noted in my comment on patch 3/4, these descriptions are reversed.
> >
> > They're also incomplete. t2080 has device config 2.0. t1040 is described
> > as
> > 2.0 though it should probably be 2.1 (or better, drop the generic
> > compatible
> > altogether).
>
> Ok. Ideally I think we'd even look up the specific SoC names from the
> SVC rather than the compatible string. I just didn't have a good list
> for those to put in the driver.
The list is in arch/powerpc/include/asm/mpc85xx.h but I don't know why we need
to convert it to a string in the first place.
>
> > > + /*
> > > + * syscon devices default to little-endian, but on powerpc we
> > > have
> > > + * existing device trees with big-endian maps and an absent
> > > endianess
> > > + * "big-property"
> > > + */
> > > + if (!IS_ENABLED(CONFIG_POWERPC) &&
> > > + !of_property_read_bool(dev->of_node, "big-endian"))
> > > + guts->little_endian = true;
> >
> > This is not a syscon device (Yangbo's patch to add a guts node on ls2080
> > is
> > the only guts node that says "syscon", and that was a leftover from
> > earlier
> > revisions and should probably be removed). Even if it were, where is it
> > documented that syscon defaults to little-endian?
>
> Documentation/devicetree/bindings/regmap/regmap.txt
>
> We had a little screwup here, basically regmap (and by consequence, syscon)
> always defaulted to little-endian way before that was documented, so it's
> too late to change it,
What causes a device node to fall under the jurisdiction of regmap.txt?
Again, these nodes do not claim "syscon" compatibility.
> although I agree it would have made sense to document
> regmap to default to big-endian on powerpc.
Please don't. It's enough of a mess as is; no need to start throwing in
architecture ifdefs.
> > Documentation/devicetree/bindings/common-properties.txt says that the
> > individual binding specifies the default. The default for this node
> > should be
> > big-endian because that's what existed before there was a need to describe
> > the
> > endianness. And we need an update to the guts binding to specify that.
>
> Good point. This proably means that specifying both the "guts" and "syscon"
> compatible strings implies having to also specify the endianess explicitly
> both ways, because otherwise we break one of the two bindings.
Yes, but the node should only specify "guts".
>
> > > +
> > > + guts->regs = devm_ioremap_resource(dev, 0);
> > > + if (!guts->regs) {
> > > + ret = -ENOMEM;
> > > + kfree(guts);
> > > + goto out;
> > > + }
> > > +
> > > + fsl_guts_init(dev, guts);
> > > + ret = 0;
> > > +out:
> > > + return ret;
> > > +}
> > > +
> > > +static struct platform_driver fsl_soc_guts = {
> > > + .probe = fsl_guts_probe,
> > > + .driver.of_match_table = fsl_guts_of_match,
> > > +};
> > > +
> > > +module_platform_driver(fsl_soc_guts);
> >
> > Again, this means that the information is not available during early boot,
> > such as in the clock driver. Thus we would not be able to convert clk
> > -qoriq's
> > direct mfspr(SPRN_SVR) into an soc_device_match() (or anything else that
> > makes
> > use of this file), nor would we be able to move its access of the guts RCW
> > registers into this driver.
>
> Correct. Do we have a reason to convert the mfspr() though? I don't really
> see an improvement over the current state if we do that,
Then should we drop this patchset and put a similar PPC ifdef in
drivers/mmc/host/sdhci-of-esdhc.c?
There's also the RCW access. You said in the patch 4/4 discussion that you di
dn't like any random driver ioremapping the registers...
> and for new devices
> that might need the erratum workaround, we could add a DT property that
> would
> be preferred to both.
It's unlikely that we would know the erratum exists at the time the device
tree is created. We also generally don't have separate device trees for each
revision of a chip (and if we did, we'd have users that use the wrong one).
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-06-11 1:50 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-11 1:50 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev
Cc: Mark Rutland, Ulf Hansson, linux-kernel, linux-i2c, linux-clk,
Qiang Zhao, Russell King, Bhupesh Sharma, Joerg Roedel,
Claudiu Manoil, devicetree, Kumar Gala, Rob Herring,
Santosh Shilimkar, linux-arm-kernel, netdev, linux-mmc,
Xiaobo Xie, Yang-Leo Li, iommu, Yangbo Lu
On Thu, 2016-06-02 at 10:43 +0200, Arnd Bergmann wrote:
> On Wednesday, June 1, 2016 8:47:22 PM CEST Scott Wood wrote:
> > On Mon, 2016-05-30 at 15:15 +0200, Arnd Bergmann wrote:
> > > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> > > new file mode 100644
> > > index 000000000000..2f30698f5bcf
> > > --- /dev/null
> > > +++ b/drivers/soc/fsl/guts.c
> > > @@ -0,0 +1,130 @@
> > > +/*
> > > + * Freescale QorIQ Platforms GUTS Driver
> > > + *
> > > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License as published by
> > > + * the Free Software Foundation; either version 2 of the License, or
> > > + * (at your option) any later version.
> > > + */
> > > +
> > > +#include <linux/io.h>
> > > +#include <linux/platform_device.h>
> > > +#include <linux/module.h>
> > > +#include <linux/slab.h>
> > > +#include <linux/of_address.h>
> > > +#include <linux/of_platform.h>
> > > +#include <linux/sys_soc.h>
> > > +
> > > +#define GUTS_PVR 0x0a0
> > > +#define GUTS_SVR 0x0a4
> > > +
> > > +struct guts {
> > > + void __iomem *regs;
> >
> > We already have a struct to define guts. Why are you not using it? Why
> > do
> > you consider using it to be "abuse"? What if we want to move more guts
> > functionality into this driver?
>
> This structure was in the original patch, I left it in there, only
> removed the inclusion of the powerpc header file, which seemed to
> be misplaced.
I'm not refering "struct guts". I'm referring to changing
"struct ccsr_guts __iomem *regs" into "void __iomem *regs".
And it's not a powerpc header file.
> > > +/*
> > > + * Table for matching compatible strings, for device tree
> > > + * guts node, for Freescale QorIQ SOCs.
> > > + */
> > > +static const struct of_device_id fsl_guts_of_match[] = {
> > > + /* For T4 & B4 Series SOCs */
> > > + { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4
> > > series" },
> > [snip]
> > > + { .compatible = "fsl,qoriq-device-config-2.0", .data = "P
> > > series"
> >
> > As noted in my comment on patch 3/4, these descriptions are reversed.
> >
> > They're also incomplete. t2080 has device config 2.0. t1040 is described
> > as
> > 2.0 though it should probably be 2.1 (or better, drop the generic
> > compatible
> > altogether).
>
> Ok. Ideally I think we'd even look up the specific SoC names from the
> SVC rather than the compatible string. I just didn't have a good list
> for those to put in the driver.
The list is in arch/powerpc/include/asm/mpc85xx.h but I don't know why we need
to convert it to a string in the first place.
>
> > > + /*
> > > + * syscon devices default to little-endian, but on powerpc we
> > > have
> > > + * existing device trees with big-endian maps and an absent
> > > endianess
> > > + * "big-property"
> > > + */
> > > + if (!IS_ENABLED(CONFIG_POWERPC) &&
> > > + !of_property_read_bool(dev->of_node, "big-endian"))
> > > + guts->little_endian = true;
> >
> > This is not a syscon device (Yangbo's patch to add a guts node on ls2080
> > is
> > the only guts node that says "syscon", and that was a leftover from
> > earlier
> > revisions and should probably be removed). Even if it were, where is it
> > documented that syscon defaults to little-endian?
>
> Documentation/devicetree/bindings/regmap/regmap.txt
>
> We had a little screwup here, basically regmap (and by consequence, syscon)
> always defaulted to little-endian way before that was documented, so it's
> too late to change it,
What causes a device node to fall under the jurisdiction of regmap.txt?
Again, these nodes do not claim "syscon" compatibility.
> although I agree it would have made sense to document
> regmap to default to big-endian on powerpc.
Please don't. It's enough of a mess as is; no need to start throwing in
architecture ifdefs.
> > Documentation/devicetree/bindings/common-properties.txt says that the
> > individual binding specifies the default. The default for this node
> > should be
> > big-endian because that's what existed before there was a need to describe
> > the
> > endianness. And we need an update to the guts binding to specify that.
>
> Good point. This proably means that specifying both the "guts" and "syscon"
> compatible strings implies having to also specify the endianess explicitly
> both ways, because otherwise we break one of the two bindings.
Yes, but the node should only specify "guts".
>
> > > +
> > > + guts->regs = devm_ioremap_resource(dev, 0);
> > > + if (!guts->regs) {
> > > + ret = -ENOMEM;
> > > + kfree(guts);
> > > + goto out;
> > > + }
> > > +
> > > + fsl_guts_init(dev, guts);
> > > + ret = 0;
> > > +out:
> > > + return ret;
> > > +}
> > > +
> > > +static struct platform_driver fsl_soc_guts = {
> > > + .probe = fsl_guts_probe,
> > > + .driver.of_match_table = fsl_guts_of_match,
> > > +};
> > > +
> > > +module_platform_driver(fsl_soc_guts);
> >
> > Again, this means that the information is not available during early boot,
> > such as in the clock driver. Thus we would not be able to convert clk
> > -qoriq's
> > direct mfspr(SPRN_SVR) into an soc_device_match() (or anything else that
> > makes
> > use of this file), nor would we be able to move its access of the guts RCW
> > registers into this driver.
>
> Correct. Do we have a reason to convert the mfspr() though? I don't really
> see an improvement over the current state if we do that,
Then should we drop this patchset and put a similar PPC ifdef in
drivers/mmc/host/sdhci-of-esdhc.c?
There's also the RCW access. You said in the patch 4/4 discussion that you di
dn't like any random driver ioremapping the registers...
> and for new devices
> that might need the erratum workaround, we could add a DT property that
> would
> be preferred to both.
It's unlikely that we would know the erratum exists at the time the device
tree is created. We also generally don't have separate device trees for each
revision of a chip (and if we did, we'd have users that use the wrong one).
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-06-11 1:50 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-11 1:50 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev
Cc: Mark Rutland, Ulf Hansson, linux-kernel, linux-i2c, linux-clk,
Qiang Zhao, Russell King, Bhupesh Sharma, Joerg Roedel,
Claudiu Manoil, devicetree, Kumar Gala, Rob Herring,
Santosh Shilimkar, linux-arm-kernel, netdev, linux-mmc,
Xiaobo Xie, Yang-Leo Li, iommu, Yangbo Lu
On Thu, 2016-06-02 at 10:43 +0200, Arnd Bergmann wrote:
> On Wednesday, June 1, 2016 8:47:22 PM CEST Scott Wood wrote:
> > On Mon, 2016-05-30 at 15:15 +0200, Arnd Bergmann wrote:
> > > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> > > new file mode 100644
> > > index 000000000000..2f30698f5bcf
> > > --- /dev/null
> > > +++ b/drivers/soc/fsl/guts.c
> > > @@ -0,0 +1,130 @@
> > > +/*
> > > + * Freescale QorIQ Platforms GUTS Driver
> > > + *
> > > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License as published by
> > > + * the Free Software Foundation; either version 2 of the License, or
> > > + * (at your option) any later version.
> > > + */
> > > +
> > > +#include <linux/io.h>
> > > +#include <linux/platform_device.h>
> > > +#include <linux/module.h>
> > > +#include <linux/slab.h>
> > > +#include <linux/of_address.h>
> > > +#include <linux/of_platform.h>
> > > +#include <linux/sys_soc.h>
> > > +
> > > +#define GUTS_PVR 0x0a0
> > > +#define GUTS_SVR 0x0a4
> > > +
> > > +struct guts {
> > > + void __iomem *regs;
> >
> > We already have a struct to define guts. Why are you not using it? Why
> > do
> > you consider using it to be "abuse"? What if we want to move more guts
> > functionality into this driver?
>
> This structure was in the original patch, I left it in there, only
> removed the inclusion of the powerpc header file, which seemed to
> be misplaced.
I'm not refering "struct guts". I'm referring to changing
"struct ccsr_guts __iomem *regs" into "void __iomem *regs".
And it's not a powerpc header file.
> > > +/*
> > > + * Table for matching compatible strings, for device tree
> > > + * guts node, for Freescale QorIQ SOCs.
> > > + */
> > > +static const struct of_device_id fsl_guts_of_match[] = {
> > > + /* For T4 & B4 Series SOCs */
> > > + { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4
> > > series" },
> > [snip]
> > > + { .compatible = "fsl,qoriq-device-config-2.0", .data = "P
> > > series"
> >
> > As noted in my comment on patch 3/4, these descriptions are reversed.
> >
> > They're also incomplete. t2080 has device config 2.0. t1040 is described
> > as
> > 2.0 though it should probably be 2.1 (or better, drop the generic
> > compatible
> > altogether).
>
> Ok. Ideally I think we'd even look up the specific SoC names from the
> SVC rather than the compatible string. I just didn't have a good list
> for those to put in the driver.
The list is in arch/powerpc/include/asm/mpc85xx.h but I don't know why we need
to convert it to a string in the first place.
>
> > > + /*
> > > + * syscon devices default to little-endian, but on powerpc we
> > > have
> > > + * existing device trees with big-endian maps and an absent
> > > endianess
> > > + * "big-property"
> > > + */
> > > + if (!IS_ENABLED(CONFIG_POWERPC) &&
> > > + !of_property_read_bool(dev->of_node, "big-endian"))
> > > + guts->little_endian = true;
> >
> > This is not a syscon device (Yangbo's patch to add a guts node on ls2080
> > is
> > the only guts node that says "syscon", and that was a leftover from
> > earlier
> > revisions and should probably be removed). Even if it were, where is it
> > documented that syscon defaults to little-endian?
>
> Documentation/devicetree/bindings/regmap/regmap.txt
>
> We had a little screwup here, basically regmap (and by consequence, syscon)
> always defaulted to little-endian way before that was documented, so it's
> too late to change it,
What causes a device node to fall under the jurisdiction of regmap.txt?
Again, these nodes do not claim "syscon" compatibility.
> although I agree it would have made sense to document
> regmap to default to big-endian on powerpc.
Please don't. It's enough of a mess as is; no need to start throwing in
architecture ifdefs.
> > Documentation/devicetree/bindings/common-properties.txt says that the
> > individual binding specifies the default. The default for this node
> > should be
> > big-endian because that's what existed before there was a need to describe
> > the
> > endianness. And we need an update to the guts binding to specify that.
>
> Good point. This proably means that specifying both the "guts" and "syscon"
> compatible strings implies having to also specify the endianess explicitly
> both ways, because otherwise we break one of the two bindings.
Yes, but the node should only specify "guts".
>
> > > +
> > > + guts->regs = devm_ioremap_resource(dev, 0);
> > > + if (!guts->regs) {
> > > + ret = -ENOMEM;
> > > + kfree(guts);
> > > + goto out;
> > > + }
> > > +
> > > + fsl_guts_init(dev, guts);
> > > + ret = 0;
> > > +out:
> > > + return ret;
> > > +}
> > > +
> > > +static struct platform_driver fsl_soc_guts = {
> > > + .probe = fsl_guts_probe,
> > > + .driver.of_match_table = fsl_guts_of_match,
> > > +};
> > > +
> > > +module_platform_driver(fsl_soc_guts);
> >
> > Again, this means that the information is not available during early boot,
> > such as in the clock driver. Thus we would not be able to convert clk
> > -qoriq's
> > direct mfspr(SPRN_SVR) into an soc_device_match() (or anything else that
> > makes
> > use of this file), nor would we be able to move its access of the guts RCW
> > registers into this driver.
>
> Correct. Do we have a reason to convert the mfspr() though? I don't really
> see an improvement over the current state if we do that,
Then should we drop this patchset and put a similar PPC ifdef in
drivers/mmc/host/sdhci-of-esdhc.c?
There's also the RCW access. You said in the patch 4/4 discussion that you di
dn't like any random driver ioremapping the registers...
> and for new devices
> that might need the erratum workaround, we could add a DT property that
> would
> be preferred to both.
It's unlikely that we would know the erratum exists at the time the device
tree is created. We also generally don't have separate device trees for each
revision of a chip (and if we did, we'd have users that use the wrong one).
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-06-11 1:50 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-11 1:50 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 2016-06-02 at 10:43 +0200, Arnd Bergmann wrote:
> On Wednesday, June 1, 2016 8:47:22 PM CEST Scott Wood wrote:
> > On Mon, 2016-05-30 at 15:15 +0200, Arnd Bergmann wrote:
> > > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> > > new file mode 100644
> > > index 000000000000..2f30698f5bcf
> > > --- /dev/null
> > > +++ b/drivers/soc/fsl/guts.c
> > > @@ -0,0 +1,130 @@
> > > +/*
> > > + * Freescale QorIQ Platforms GUTS Driver
> > > + *
> > > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License as published by
> > > + * the Free Software Foundation; either version 2 of the License, or
> > > + * (at your option) any later version.
> > > + */
> > > +
> > > +#include <linux/io.h>
> > > +#include <linux/platform_device.h>
> > > +#include <linux/module.h>
> > > +#include <linux/slab.h>
> > > +#include <linux/of_address.h>
> > > +#include <linux/of_platform.h>
> > > +#include <linux/sys_soc.h>
> > > +
> > > +#define GUTS_PVR 0x0a0
> > > +#define GUTS_SVR 0x0a4
> > > +
> > > +struct guts {
> > > + void __iomem *regs;
> >
> > We already have a struct to define guts. Why are you not using it? Why
> > do
> > you consider using it to be "abuse"? What if we want to move more guts
> > functionality into this driver?
>
> This structure was in the original patch, I left it in there, only
> removed the inclusion of the powerpc header file, which seemed to
> be misplaced.
I'm not refering "struct guts". I'm referring to changing
"struct ccsr_guts __iomem *regs" into "void __iomem *regs".
And it's not a powerpc header file.
> > > +/*
> > > + * Table for matching compatible strings, for device tree
> > > + * guts node, for Freescale QorIQ SOCs.
> > > + */
> > > +static const struct of_device_id fsl_guts_of_match[] = {
> > > + /* For T4 & B4 Series SOCs */
> > > + { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4
> > > series" },
> > [snip]
> > > + { .compatible = "fsl,qoriq-device-config-2.0", .data = "P
> > > series"
> >
> > As noted in my comment on patch 3/4, these descriptions are reversed.
> >
> > They're also incomplete. t2080 has device config 2.0. t1040 is described
> > as
> > 2.0 though it should probably be 2.1 (or better, drop the generic
> > compatible
> > altogether).
>
> Ok. Ideally I think we'd even look up the specific SoC names from the
> SVC rather than the compatible string. I just didn't have a good list
> for those to put in the driver.
The list is in arch/powerpc/include/asm/mpc85xx.h but I don't know why we need
to convert it to a string in the first place.
>
> > > + /*
> > > + * syscon devices default to little-endian, but on powerpc we
> > > have
> > > + * existing device trees with big-endian maps and an absent
> > > endianess
> > > + * "big-property"
> > > + */
> > > + if (!IS_ENABLED(CONFIG_POWERPC) &&
> > > + !of_property_read_bool(dev->of_node, "big-endian"))
> > > + guts->little_endian = true;
> >
> > This is not a syscon device (Yangbo's patch to add a guts node on ls2080
> > is
> > the only guts node that says "syscon", and that was a leftover from
> > earlier
> > revisions and should probably be removed). Even if it were, where is it
> > documented that syscon defaults to little-endian?
>
> Documentation/devicetree/bindings/regmap/regmap.txt
>
> We had a little screwup here, basically regmap (and by consequence, syscon)
> always defaulted to little-endian way before that was documented, so it's
> too late to change it,
What causes a device node to fall under the jurisdiction of regmap.txt?
Again, these nodes do not claim "syscon" compatibility.
> although I agree it would have made sense to document
> regmap to default to big-endian on powerpc.
Please don't. It's enough of a mess as is; no need to start throwing in
architecture ifdefs.
> > Documentation/devicetree/bindings/common-properties.txt says that the
> > individual binding specifies the default. The default for this node
> > should be
> > big-endian because that's what existed before there was a need to describe
> > the
> > endianness. And we need an update to the guts binding to specify that.
>
> Good point. This proably means that specifying both the "guts" and "syscon"
> compatible strings implies having to also specify the endianess explicitly
> both ways, because otherwise we break one of the two bindings.
Yes, but the node should only specify "guts".
>
> > > +
> > > + guts->regs = devm_ioremap_resource(dev, 0);
> > > + if (!guts->regs) {
> > > + ret = -ENOMEM;
> > > + kfree(guts);
> > > + goto out;
> > > + }
> > > +
> > > + fsl_guts_init(dev, guts);
> > > + ret = 0;
> > > +out:
> > > + return ret;
> > > +}
> > > +
> > > +static struct platform_driver fsl_soc_guts = {
> > > + .probe = fsl_guts_probe,
> > > + .driver.of_match_table = fsl_guts_of_match,
> > > +};
> > > +
> > > +module_platform_driver(fsl_soc_guts);
> >
> > Again, this means that the information is not available during early boot,
> > such as in the clock driver. Thus we would not be able to convert clk
> > -qoriq's
> > direct mfspr(SPRN_SVR) into an soc_device_match() (or anything else that
> > makes
> > use of this file), nor would we be able to move its access of the guts RCW
> > registers into this driver.
>
> Correct. Do we have a reason to convert the mfspr() though? I don't really
> see an improvement over the current state if we do that,
Then should we drop this patchset and put a similar PPC ifdef in
drivers/mmc/host/sdhci-of-esdhc.c?
There's also the RCW access. You said in the patch 4/4 discussion that you di
dn't like any random driver ioremapping the registers...
> and for new devices
> that might need the erratum workaround, we could add a DT property that
> would
> be preferred to both.
It's unlikely that we would know the erratum exists at the time the device
tree is created. We also generally don't have separate device trees for each
revision of a chip (and if we did, we'd have users that use the wrong one).
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 3/4] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
2016-06-02 8:52 ` Arnd Bergmann
` (3 preceding siblings ...)
(?)
@ 2016-06-11 2:00 ` Scott Wood
-1 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-11 2:00 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev
Cc: Mark Rutland, devicetree, Ulf Hansson, Russell King,
Bhupesh Sharma, netdev, Joerg Roedel, Santosh Shilimkar,
linux-mmc, Xiaobo Xie, linux-kernel, iommu, Rob Herring,
linux-i2c, Claudiu Manoil, Yangbo Lu, Kumar Gala, Yang-Leo Li,
linux-clk, linux-arm-kernel, Qiang Zhao
On Thu, 2016-06-02 at 10:52 +0200, Arnd Bergmann wrote:
> On Wednesday, June 1, 2016 8:11:14 PM CEST Scott Wood wrote:
> > > +#define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) |
> > > SDHCI_SPEC_200)
> > > +static const struct soc_device_attribute esdhc_t4240_quirk = {
> > > + /* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200
> > > */
> > > + { .soc_id = "T4*(0x824000)", .revision = "0x[01]?",
> > > + .data = (void *)(uintptr_t)(T4240_HOST_VER) },
> >
> > Why should this code need to care that the string begins with "T4"? This
> > creates dual maintenance if that were to change. It's also broken because
> > T4240 has compatible = "fsl,t4240-device-config", "fsl,qoriq-device-config
> > -2.0" and thus with these patches it would incorrectly show up as "P
> > series
> > (0x824000)". The compatible string of this node was never meant to be a
> > key
> > for choosing a string to describe the system to userspace.
>
> This is an artifact of not knowing the specific SoC name, and we can change
> that by looking up the name from the SVR value in the soc_device driver.
...or we could keep it simple and just match the number.
> > 0x824000 is a magic number which should be represented symbolically.
>
> Sure, feel free to change the format of the soc_device string in any
> name,
That's not what I was asking for... The match should be numeric but the
knowledge of what the number is should come from a symbolic #define.
> > If T4240 is affected, then so are the reduced-core variants T4160 and
> > T4080,
> > but 0x824000 doesn't match them (Yangbo's patch had the same problem).
> > And
> > please don't respond with "0x824*"
> >
> > You also didn't strip out the E bit of SVR which indicates encryption
> > capability and nothing else (Yangbo's patch did not have this problem
> > because
> > it used SVR_SOC_VER).
>
> Ok, that should be easy enough to fix in the soc_device driver.
No, because the soc_device driver doesn't know whether the consumer of the ID
cares about the E bit.
> > What happens if the revision condition is more complicated, such as <=
> > 0x20
> > with 0x21 being fine? Multiple quirk entries where before we had as
> > simple
> > comparison?
>
> I guess yes. I would really hope that there is no need to use this interface
> pervasively, it's really just to work around the cases where there is no
> way to pass the information in DT otherwise.
How does putting it in the DT work when you have multiple versions of the same
SoC, some of which have the bug and some which don't?
> > I fail to see how this approach is an improvement (much less one that
> > needs to
> > hold up a patchset that is fixing a problem and is not touching any
> > generic
> > code). Why does this need to be a string?
>
> A string is what user space gets in /sys/devices/soc/*,
It is rare that the kernel accesses information in the exact same way that
userspace does. And once we expose this to userspace we're stuck with it, so
exporting anything other than a simple number is even less desirable.
> and we already have
> code that does the same things there to work around quirks, here we just
> use the same interface in a completely generic way. Note that not every
> SoC family uses numbers in the same way, some have multiple subrevisions,
> some have names etc.
Where is the need for a "completely generic way" for one piece of vendor
-specific code to get information that is inherently specific to that vendor,
that is supplied by code specific to that vendor?
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 3/4] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-06-11 2:00 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-11 2:00 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Ulf Hansson,
Russell King, Bhupesh Sharma, netdev-u79uwXL29TY76Z2rM5mHXA,
Yangbo Lu, linux-mmc-u79uwXL29TY76Z2rM5mHXA, Xiaobo Xie,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Rob Herring,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Claudiu Manoil,
Santosh Shilimkar, Kumar Gala, Yang-Leo Li,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
On Thu, 2016-06-02 at 10:52 +0200, Arnd Bergmann wrote:
> On Wednesday, June 1, 2016 8:11:14 PM CEST Scott Wood wrote:
> > > +#define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) |
> > > SDHCI_SPEC_200)
> > > +static const struct soc_device_attribute esdhc_t4240_quirk = {
> > > + /* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200
> > > */
> > > + { .soc_id = "T4*(0x824000)", .revision = "0x[01]?",
> > > + .data = (void *)(uintptr_t)(T4240_HOST_VER) },
> >
> > Why should this code need to care that the string begins with "T4"? This
> > creates dual maintenance if that were to change. It's also broken because
> > T4240 has compatible = "fsl,t4240-device-config", "fsl,qoriq-device-config
> > -2.0" and thus with these patches it would incorrectly show up as "P
> > series
> > (0x824000)". The compatible string of this node was never meant to be a
> > key
> > for choosing a string to describe the system to userspace.
>
> This is an artifact of not knowing the specific SoC name, and we can change
> that by looking up the name from the SVR value in the soc_device driver.
...or we could keep it simple and just match the number.
> > 0x824000 is a magic number which should be represented symbolically.
>
> Sure, feel free to change the format of the soc_device string in any
> name,
That's not what I was asking for... The match should be numeric but the
knowledge of what the number is should come from a symbolic #define.
> > If T4240 is affected, then so are the reduced-core variants T4160 and
> > T4080,
> > but 0x824000 doesn't match them (Yangbo's patch had the same problem).
> > And
> > please don't respond with "0x824*"
> >
> > You also didn't strip out the E bit of SVR which indicates encryption
> > capability and nothing else (Yangbo's patch did not have this problem
> > because
> > it used SVR_SOC_VER).
>
> Ok, that should be easy enough to fix in the soc_device driver.
No, because the soc_device driver doesn't know whether the consumer of the ID
cares about the E bit.
> > What happens if the revision condition is more complicated, such as <=
> > 0x20
> > with 0x21 being fine? Multiple quirk entries where before we had as
> > simple
> > comparison?
>
> I guess yes. I would really hope that there is no need to use this interface
> pervasively, it's really just to work around the cases where there is no
> way to pass the information in DT otherwise.
How does putting it in the DT work when you have multiple versions of the same
SoC, some of which have the bug and some which don't?
> > I fail to see how this approach is an improvement (much less one that
> > needs to
> > hold up a patchset that is fixing a problem and is not touching any
> > generic
> > code). Why does this need to be a string?
>
> A string is what user space gets in /sys/devices/soc/*,
It is rare that the kernel accesses information in the exact same way that
userspace does. And once we expose this to userspace we're stuck with it, so
exporting anything other than a simple number is even less desirable.
> and we already have
> code that does the same things there to work around quirks, here we just
> use the same interface in a completely generic way. Note that not every
> SoC family uses numbers in the same way, some have multiple subrevisions,
> some have names etc.
Where is the need for a "completely generic way" for one piece of vendor
-specific code to get information that is inherently specific to that vendor,
that is supplied by code specific to that vendor?
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 3/4] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-06-11 2:00 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-11 2:00 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Ulf Hansson,
Russell King, Bhupesh Sharma, netdev-u79uwXL29TY76Z2rM5mHXA,
Yangbo Lu, linux-mmc-u79uwXL29TY76Z2rM5mHXA, Xiaobo Xie,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Rob Herring,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Claudiu Manoil,
Santosh Shilimkar, Kumar Gala, Yang-Leo Li,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
On Thu, 2016-06-02 at 10:52 +0200, Arnd Bergmann wrote:
> On Wednesday, June 1, 2016 8:11:14 PM CEST Scott Wood wrote:
> > > +#define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) |
> > > SDHCI_SPEC_200)
> > > +static const struct soc_device_attribute esdhc_t4240_quirk = {
> > > + /* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200
> > > */
> > > + { .soc_id = "T4*(0x824000)", .revision = "0x[01]?",
> > > + .data = (void *)(uintptr_t)(T4240_HOST_VER) },
> >
> > Why should this code need to care that the string begins with "T4"? This
> > creates dual maintenance if that were to change. It's also broken because
> > T4240 has compatible = "fsl,t4240-device-config", "fsl,qoriq-device-config
> > -2.0" and thus with these patches it would incorrectly show up as "P
> > series
> > (0x824000)". The compatible string of this node was never meant to be a
> > key
> > for choosing a string to describe the system to userspace.
>
> This is an artifact of not knowing the specific SoC name, and we can change
> that by looking up the name from the SVR value in the soc_device driver.
...or we could keep it simple and just match the number.
> > 0x824000 is a magic number which should be represented symbolically.
>
> Sure, feel free to change the format of the soc_device string in any
> name,
That's not what I was asking for... The match should be numeric but the
knowledge of what the number is should come from a symbolic #define.
> > If T4240 is affected, then so are the reduced-core variants T4160 and
> > T4080,
> > but 0x824000 doesn't match them (Yangbo's patch had the same problem).
> > And
> > please don't respond with "0x824*"
> >
> > You also didn't strip out the E bit of SVR which indicates encryption
> > capability and nothing else (Yangbo's patch did not have this problem
> > because
> > it used SVR_SOC_VER).
>
> Ok, that should be easy enough to fix in the soc_device driver.
No, because the soc_device driver doesn't know whether the consumer of the ID
cares about the E bit.
> > What happens if the revision condition is more complicated, such as <=
> > 0x20
> > with 0x21 being fine? Multiple quirk entries where before we had as
> > simple
> > comparison?
>
> I guess yes. I would really hope that there is no need to use this interface
> pervasively, it's really just to work around the cases where there is no
> way to pass the information in DT otherwise.
How does putting it in the DT work when you have multiple versions of the same
SoC, some of which have the bug and some which don't?
> > I fail to see how this approach is an improvement (much less one that
> > needs to
> > hold up a patchset that is fixing a problem and is not touching any
> > generic
> > code). Why does this need to be a string?
>
> A string is what user space gets in /sys/devices/soc/*,
It is rare that the kernel accesses information in the exact same way that
userspace does. And once we expose this to userspace we're stuck with it, so
exporting anything other than a simple number is even less desirable.
> and we already have
> code that does the same things there to work around quirks, here we just
> use the same interface in a completely generic way. Note that not every
> SoC family uses numbers in the same way, some have multiple subrevisions,
> some have names etc.
Where is the need for a "completely generic way" for one piece of vendor
-specific code to get information that is inherently specific to that vendor,
that is supplied by code specific to that vendor?
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 3/4] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-06-11 2:00 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-11 2:00 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev
Cc: Mark Rutland, devicetree, Ulf Hansson, Russell King,
Bhupesh Sharma, netdev, Joerg Roedel, Santosh Shilimkar,
linux-mmc, Xiaobo Xie, linux-kernel, iommu, Rob Herring,
linux-i2c, Claudiu Manoil, Yangbo Lu, Kumar Gala, Yang-Leo Li,
linux-clk, linux-arm-kernel, Qiang Zhao
On Thu, 2016-06-02 at 10:52 +0200, Arnd Bergmann wrote:
> On Wednesday, June 1, 2016 8:11:14 PM CEST Scott Wood wrote:
> > > +#define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) |
> > > SDHCI_SPEC_200)
> > > +static const struct soc_device_attribute esdhc_t4240_quirk = {
> > > + /* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200
> > > */
> > > + { .soc_id = "T4*(0x824000)", .revision = "0x[01]?",
> > > + .data = (void *)(uintptr_t)(T4240_HOST_VER) },
> >
> > Why should this code need to care that the string begins with "T4"? This
> > creates dual maintenance if that were to change. It's also broken because
> > T4240 has compatible = "fsl,t4240-device-config", "fsl,qoriq-device-config
> > -2.0" and thus with these patches it would incorrectly show up as "P
> > series
> > (0x824000)". The compatible string of this node was never meant to be a
> > key
> > for choosing a string to describe the system to userspace.
>
> This is an artifact of not knowing the specific SoC name, and we can change
> that by looking up the name from the SVR value in the soc_device driver.
...or we could keep it simple and just match the number.
> > 0x824000 is a magic number which should be represented symbolically.
>
> Sure, feel free to change the format of the soc_device string in any
> name,
That's not what I was asking for... The match should be numeric but the
knowledge of what the number is should come from a symbolic #define.
> > If T4240 is affected, then so are the reduced-core variants T4160 and
> > T4080,
> > but 0x824000 doesn't match them (Yangbo's patch had the same problem).
> > And
> > please don't respond with "0x824*"
> >
> > You also didn't strip out the E bit of SVR which indicates encryption
> > capability and nothing else (Yangbo's patch did not have this problem
> > because
> > it used SVR_SOC_VER).
>
> Ok, that should be easy enough to fix in the soc_device driver.
No, because the soc_device driver doesn't know whether the consumer of the ID
cares about the E bit.
> > What happens if the revision condition is more complicated, such as <=
> > 0x20
> > with 0x21 being fine? Multiple quirk entries where before we had as
> > simple
> > comparison?
>
> I guess yes. I would really hope that there is no need to use this interface
> pervasively, it's really just to work around the cases where there is no
> way to pass the information in DT otherwise.
How does putting it in the DT work when you have multiple versions of the same
SoC, some of which have the bug and some which don't?
> > I fail to see how this approach is an improvement (much less one that
> > needs to
> > hold up a patchset that is fixing a problem and is not touching any
> > generic
> > code). Why does this need to be a string?
>
> A string is what user space gets in /sys/devices/soc/*,
It is rare that the kernel accesses information in the exact same way that
userspace does. And once we expose this to userspace we're stuck with it, so
exporting anything other than a simple number is even less desirable.
> and we already have
> code that does the same things there to work around quirks, here we just
> use the same interface in a completely generic way. Note that not every
> SoC family uses numbers in the same way, some have multiple subrevisions,
> some have names etc.
Where is the need for a "completely generic way" for one piece of vendor
-specific code to get information that is inherently specific to that vendor,
that is supplied by code specific to that vendor?
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 3/4] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-06-11 2:00 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-11 2:00 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev
Cc: Mark Rutland, devicetree, Ulf Hansson, Russell King,
Bhupesh Sharma, netdev, Joerg Roedel, Santosh Shilimkar,
linux-mmc, Xiaobo Xie, linux-kernel, iommu, Rob Herring,
linux-i2c, Claudiu Manoil, Yangbo Lu, Kumar Gala, Yang-Leo Li,
linux-clk, linux-arm-kernel, Qiang Zhao
On Thu, 2016-06-02 at 10:52 +0200, Arnd Bergmann wrote:
> On Wednesday, June 1, 2016 8:11:14 PM CEST Scott Wood wrote:
> > > +#define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) |
> > > SDHCI_SPEC_200)
> > > +static const struct soc_device_attribute esdhc_t4240_quirk = {
> > > + /* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200
> > > */
> > > + { .soc_id = "T4*(0x824000)", .revision = "0x[01]?",
> > > + .data = (void *)(uintptr_t)(T4240_HOST_VER) },
> >
> > Why should this code need to care that the string begins with "T4"? This
> > creates dual maintenance if that were to change. It's also broken because
> > T4240 has compatible = "fsl,t4240-device-config", "fsl,qoriq-device-config
> > -2.0" and thus with these patches it would incorrectly show up as "P
> > series
> > (0x824000)". The compatible string of this node was never meant to be a
> > key
> > for choosing a string to describe the system to userspace.
>
> This is an artifact of not knowing the specific SoC name, and we can change
> that by looking up the name from the SVR value in the soc_device driver.
...or we could keep it simple and just match the number.
> > 0x824000 is a magic number which should be represented symbolically.
>
> Sure, feel free to change the format of the soc_device string in any
> name,
That's not what I was asking for... The match should be numeric but the
knowledge of what the number is should come from a symbolic #define.
> > If T4240 is affected, then so are the reduced-core variants T4160 and
> > T4080,
> > but 0x824000 doesn't match them (Yangbo's patch had the same problem).
> > And
> > please don't respond with "0x824*"
> >
> > You also didn't strip out the E bit of SVR which indicates encryption
> > capability and nothing else (Yangbo's patch did not have this problem
> > because
> > it used SVR_SOC_VER).
>
> Ok, that should be easy enough to fix in the soc_device driver.
No, because the soc_device driver doesn't know whether the consumer of the ID
cares about the E bit.
> > What happens if the revision condition is more complicated, such as <=
> > 0x20
> > with 0x21 being fine? Multiple quirk entries where before we had as
> > simple
> > comparison?
>
> I guess yes. I would really hope that there is no need to use this interface
> pervasively, it's really just to work around the cases where there is no
> way to pass the information in DT otherwise.
How does putting it in the DT work when you have multiple versions of the same
SoC, some of which have the bug and some which don't?
> > I fail to see how this approach is an improvement (much less one that
> > needs to
> > hold up a patchset that is fixing a problem and is not touching any
> > generic
> > code). Why does this need to be a string?
>
> A string is what user space gets in /sys/devices/soc/*,
It is rare that the kernel accesses information in the exact same way that
userspace does. And once we expose this to userspace we're stuck with it, so
exporting anything other than a simple number is even less desirable.
> and we already have
> code that does the same things there to work around quirks, here we just
> use the same interface in a completely generic way. Note that not every
> SoC family uses numbers in the same way, some have multiple subrevisions,
> some have names etc.
Where is the need for a "completely generic way" for one piece of vendor
-specific code to get information that is inherently specific to that vendor,
that is supplied by code specific to that vendor?
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH 3/4] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2016-06-11 2:00 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-11 2:00 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 2016-06-02 at 10:52 +0200, Arnd Bergmann wrote:
> On Wednesday, June 1, 2016 8:11:14 PM CEST Scott Wood wrote:
> > > +#define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) |
> > > SDHCI_SPEC_200)
> > > +static const struct soc_device_attribute esdhc_t4240_quirk = {
> > > + /* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200
> > > */
> > > + { .soc_id = "T4*(0x824000)", .revision = "0x[01]?",
> > > + .data = (void *)(uintptr_t)(T4240_HOST_VER) },
> >
> > Why should this code need to care that the string begins with "T4"? This
> > creates dual maintenance if that were to change. It's also broken because
> > T4240 has compatible = "fsl,t4240-device-config", "fsl,qoriq-device-config
> > -2.0" and thus with these patches it would incorrectly show up as "P
> > series
> > (0x824000)". The compatible string of this node was never meant to be a
> > key
> > for choosing a string to describe the system to userspace.
>
> This is an artifact of not knowing the specific SoC name, and we can change
> that by looking up the name from the SVR value in the soc_device driver.
...or we could keep it simple and just match the number.
> > 0x824000 is a magic number which should be represented symbolically.
>
> Sure, feel free to change the format of the soc_device string in any
> name,
That's not what I was asking for... The match should be numeric but the
knowledge of what the number is should come from a symbolic #define.
> > If T4240 is affected, then so are the reduced-core variants T4160 and
> > T4080,
> > but 0x824000 doesn't match them (Yangbo's patch had the same problem).
> > And
> > please don't respond with "0x824*"
> >
> > You also didn't strip out the E bit of SVR which indicates encryption
> > capability and nothing else (Yangbo's patch did not have this problem
> > because
> > it used SVR_SOC_VER).
>
> Ok, that should be easy enough to fix in the soc_device driver.
No, because the soc_device driver doesn't know whether the consumer of the ID
cares about the E bit.
> > What happens if the revision condition is more complicated, such as <=
> > 0x20
> > with 0x21 being fine? Multiple quirk entries where before we had as
> > simple
> > comparison?
>
> I guess yes. I would really hope that there is no need to use this interface
> pervasively, it's really just to work around the cases where there is no
> way to pass the information in DT otherwise.
How does putting it in the DT work when you have multiple versions of the same
SoC, some of which have the bug and some which don't?
> > I fail to see how this approach is an improvement (much less one that
> > needs to
> > hold up a patchset that is fixing a problem and is not touching any
> > generic
> > code). Why does this need to be a string?
>
> A string is what user space gets in /sys/devices/soc/*,
It is rare that the kernel accesses information in the exact same way that
userspace does. And once we expose this to userspace we're stuck with it, so
exporting anything other than a simple number is even less desirable.
> and we already have
> code that does the same things there to work around quirks, here we just
> use the same interface in a completely generic way. Note that not every
> SoC family uses numbers in the same way, some have multiple subrevisions,
> some have names etc.
Where is the need for a "completely generic way" for one piece of vendor
-specific code to get information that is inherently specific to that vendor,
that is supplied by code specific to that vendor?
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 4/4] Revert "powerpc/fsl: Move fsl_guts.h out of arch/powerpc"
2016-06-02 9:01 ` Arnd Bergmann
` (2 preceding siblings ...)
(?)
@ 2016-06-11 2:13 ` Scott Wood
-1 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-11 2:13 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linuxppc-dev, Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie,
linux-i2c, linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Rob Herring,
Santosh Shilimkar, linux-arm-kernel, netdev, linux-mmc,
linux-kernel, Yang-Leo Li, iommu, Kumar Gala
On Thu, 2016-06-02 at 11:01 +0200, Arnd Bergmann wrote:
> On Wednesday, June 1, 2016 8:24:20 PM CEST Scott Wood wrote:
> > On Mon, 2016-05-30 at 15:18 +0200, Arnd Bergmann wrote:
> > > All users of this driver are PowerPC specific and the header file
> > > has no business in the global include/linux/ hierarchy, so move
> > > it back before anyone starts using it on ARM.
> > >
> > > This reverts commit 948486544713492f00ac8a9572909101ea892cb0.
> > >
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > ---
> > > This part of the series is not required for the eSDHC quirk,
> > > but it restores the asm/fsl_guts.h header so it doesn't accidentally
> > > get abused for this in the future. I found two drivers outside of
> > > arch/powerpc that already accessed the registers directly, but the
> > > functions look fairly contained, and can be easily hidden in an
> > > #ifdef CONFIG_PPC
> >
> > NACK
> >
> > Besides adding ifdef pollution for no good reason, this register block is
> > used
> > on some ARM chips as well. Why is it a problem if "anyone starts using it
> > on
> > ARM"?
>
> It's just not a good interface when it's defined as "this is the layout of
> a register area that any driver can ioremap() if they can figure out the
> device node".
That's why I want to move accesses into one guts driver.
> It's not uncommon to have register areas like that, but
> normally you have at the minimum a 'syscon' device to handle locking
> between drivers accessing the same registers and to avoid having to map
> the same area multiple times.
syscon requires device tree changes.
I don't see read-modify-write operations in regmap -- how does locking around
an individual, inherently-atomic load or store help?
> If we need to use 'guts' registers on ARM, we can find a way to abstract
> them properly for the given use cases, using a syscon or a driver with
> exported functions, but just making a PowerPC platform specific header
> global to all Linux drivers by putting it into include/linux doesn't seem
> right.
Again, it's not PowerPC-specific! It started that way but then the same
register block got put onto some ARM chips.
It's not global to "all Linux drivers", just the ones that choose to include
an fsl-specific header.
If and when all uses of guts are moved into the guts driver, the header can be
moved into drivers/soc/fsl.
> Note that the header file uses a structure definition rather than the more
> common macros with register offsets, which is fine for a driver that has
> its own registers and abstracts them, but it doesn't really work with
> the regmap interface, so if we want to use it with syscon, it also needs to
> be rewritten.
We don't want to use it with syscon. If we did, the solution wouldn't be to
move the header back to arch/powerpc, but to convert the struct into offsets.
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 4/4] Revert "powerpc/fsl: Move fsl_guts.h out of arch/powerpc"
@ 2016-06-11 2:13 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-11 2:13 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linuxppc-dev, Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie,
linux-i2c, linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Rob Herring,
Santosh Shilimkar, linux-arm-kernel, netdev, linux-mmc,
linux-kernel, Yang-Leo
On Thu, 2016-06-02 at 11:01 +0200, Arnd Bergmann wrote:
> On Wednesday, June 1, 2016 8:24:20 PM CEST Scott Wood wrote:
> > On Mon, 2016-05-30 at 15:18 +0200, Arnd Bergmann wrote:
> > > All users of this driver are PowerPC specific and the header file
> > > has no business in the global include/linux/ hierarchy, so move
> > > it back before anyone starts using it on ARM.
> > >
> > > This reverts commit 948486544713492f00ac8a9572909101ea892cb0.
> > >
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > ---
> > > This part of the series is not required for the eSDHC quirk,
> > > but it restores the asm/fsl_guts.h header so it doesn't accidentally
> > > get abused for this in the future. I found two drivers outside of
> > > arch/powerpc that already accessed the registers directly, but the
> > > functions look fairly contained, and can be easily hidden in an
> > > #ifdef CONFIG_PPC
> >
> > NACK
> >
> > Besides adding ifdef pollution for no good reason, this register block is
> > used
> > on some ARM chips as well. Why is it a problem if "anyone starts using it
> > on
> > ARM"?
>
> It's just not a good interface when it's defined as "this is the layout of
> a register area that any driver can ioremap() if they can figure out the
> device node".
That's why I want to move accesses into one guts driver.
> It's not uncommon to have register areas like that, but
> normally you have at the minimum a 'syscon' device to handle locking
> between drivers accessing the same registers and to avoid having to map
> the same area multiple times.
syscon requires device tree changes.
I don't see read-modify-write operations in regmap -- how does locking around
an individual, inherently-atomic load or store help?
> If we need to use 'guts' registers on ARM, we can find a way to abstract
> them properly for the given use cases, using a syscon or a driver with
> exported functions, but just making a PowerPC platform specific header
> global to all Linux drivers by putting it into include/linux doesn't seem
> right.
Again, it's not PowerPC-specific! It started that way but then the same
register block got put onto some ARM chips.
It's not global to "all Linux drivers", just the ones that choose to include
an fsl-specific header.
If and when all uses of guts are moved into the guts driver, the header can be
moved into drivers/soc/fsl.
> Note that the header file uses a structure definition rather than the more
> common macros with register offsets, which is fine for a driver that has
> its own registers and abstracts them, but it doesn't really work with
> the regmap interface, so if we want to use it with syscon, it also needs to
> be rewritten.
We don't want to use it with syscon. If we did, the solution wouldn't be to
move the header back to arch/powerpc, but to convert the struct into offsets.
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 4/4] Revert "powerpc/fsl: Move fsl_guts.h out of arch/powerpc"
@ 2016-06-11 2:13 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-11 2:13 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linuxppc-dev, Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie,
linux-i2c, linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Rob Herring,
Santosh Shilimkar, linux-arm-kernel, netdev, linux-mmc,
linux-kernel, Yang-Leo Li, iommu, Kumar Gala
On Thu, 2016-06-02 at 11:01 +0200, Arnd Bergmann wrote:
> On Wednesday, June 1, 2016 8:24:20 PM CEST Scott Wood wrote:
> > On Mon, 2016-05-30 at 15:18 +0200, Arnd Bergmann wrote:
> > > All users of this driver are PowerPC specific and the header file
> > > has no business in the global include/linux/ hierarchy, so move
> > > it back before anyone starts using it on ARM.
> > >
> > > This reverts commit 948486544713492f00ac8a9572909101ea892cb0.
> > >
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > ---
> > > This part of the series is not required for the eSDHC quirk,
> > > but it restores the asm/fsl_guts.h header so it doesn't accidentally
> > > get abused for this in the future. I found two drivers outside of
> > > arch/powerpc that already accessed the registers directly, but the
> > > functions look fairly contained, and can be easily hidden in an
> > > #ifdef CONFIG_PPC
> >
> > NACK
> >
> > Besides adding ifdef pollution for no good reason, this register block is
> > used
> > on some ARM chips as well. Why is it a problem if "anyone starts using it
> > on
> > ARM"?
>
> It's just not a good interface when it's defined as "this is the layout of
> a register area that any driver can ioremap() if they can figure out the
> device node".
That's why I want to move accesses into one guts driver.
> It's not uncommon to have register areas like that, but
> normally you have at the minimum a 'syscon' device to handle locking
> between drivers accessing the same registers and to avoid having to map
> the same area multiple times.
syscon requires device tree changes.
I don't see read-modify-write operations in regmap -- how does locking around
an individual, inherently-atomic load or store help?
> If we need to use 'guts' registers on ARM, we can find a way to abstract
> them properly for the given use cases, using a syscon or a driver with
> exported functions, but just making a PowerPC platform specific header
> global to all Linux drivers by putting it into include/linux doesn't seem
> right.
Again, it's not PowerPC-specific! It started that way but then the same
register block got put onto some ARM chips.
It's not global to "all Linux drivers", just the ones that choose to include
an fsl-specific header.
If and when all uses of guts are moved into the guts driver, the header can be
moved into drivers/soc/fsl.
> Note that the header file uses a structure definition rather than the more
> common macros with register offsets, which is fine for a driver that has
> its own registers and abstracts them, but it doesn't really work with
> the regmap interface, so if we want to use it with syscon, it also needs to
> be rewritten.
We don't want to use it with syscon. If we did, the solution wouldn't be to
move the header back to arch/powerpc, but to convert the struct into offsets.
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 4/4] Revert "powerpc/fsl: Move fsl_guts.h out of arch/powerpc"
@ 2016-06-11 2:13 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-11 2:13 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linuxppc-dev, Ulf Hansson, Yangbo Lu, Mark Rutland, Xiaobo Xie,
linux-i2c, linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Rob Herring,
Santosh Shilimkar, linux-arm-kernel, netdev, linux-mmc,
linux-kernel, Yang-Leo Li, iommu, Kumar Gala
On Thu, 2016-06-02 at 11:01 +0200, Arnd Bergmann wrote:
> On Wednesday, June 1, 2016 8:24:20 PM CEST Scott Wood wrote:
> > On Mon, 2016-05-30 at 15:18 +0200, Arnd Bergmann wrote:
> > > All users of this driver are PowerPC specific and the header file
> > > has no business in the global include/linux/ hierarchy, so move
> > > it back before anyone starts using it on ARM.
> > >
> > > This reverts commit 948486544713492f00ac8a9572909101ea892cb0.
> > >
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > ---
> > > This part of the series is not required for the eSDHC quirk,
> > > but it restores the asm/fsl_guts.h header so it doesn't accidentally
> > > get abused for this in the future. I found two drivers outside of
> > > arch/powerpc that already accessed the registers directly, but the
> > > functions look fairly contained, and can be easily hidden in an
> > > #ifdef CONFIG_PPC
> >
> > NACK
> >
> > Besides adding ifdef pollution for no good reason, this register block is
> > used
> > on some ARM chips as well. Why is it a problem if "anyone starts using it
> > on
> > ARM"?
>
> It's just not a good interface when it's defined as "this is the layout of
> a register area that any driver can ioremap() if they can figure out the
> device node".
That's why I want to move accesses into one guts driver.
> It's not uncommon to have register areas like that, but
> normally you have at the minimum a 'syscon' device to handle locking
> between drivers accessing the same registers and to avoid having to map
> the same area multiple times.
syscon requires device tree changes.
I don't see read-modify-write operations in regmap -- how does locking around
an individual, inherently-atomic load or store help?
> If we need to use 'guts' registers on ARM, we can find a way to abstract
> them properly for the given use cases, using a syscon or a driver with
> exported functions, but just making a PowerPC platform specific header
> global to all Linux drivers by putting it into include/linux doesn't seem
> right.
Again, it's not PowerPC-specific! It started that way but then the same
register block got put onto some ARM chips.
It's not global to "all Linux drivers", just the ones that choose to include
an fsl-specific header.
If and when all uses of guts are moved into the guts driver, the header can be
moved into drivers/soc/fsl.
> Note that the header file uses a structure definition rather than the more
> common macros with register offsets, which is fine for a driver that has
> its own registers and abstracts them, but it doesn't really work with
> the regmap interface, so if we want to use it with syscon, it also needs to
> be rewritten.
We don't want to use it with syscon. If we did, the solution wouldn't be to
move the header back to arch/powerpc, but to convert the struct into offsets.
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH 4/4] Revert "powerpc/fsl: Move fsl_guts.h out of arch/powerpc"
@ 2016-06-11 2:13 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-06-11 2:13 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 2016-06-02 at 11:01 +0200, Arnd Bergmann wrote:
> On Wednesday, June 1, 2016 8:24:20 PM CEST Scott Wood wrote:
> > On Mon, 2016-05-30 at 15:18 +0200, Arnd Bergmann wrote:
> > > All users of this driver are PowerPC specific and the header file
> > > has no business in the global include/linux/ hierarchy, so move
> > > it back before anyone starts using it on ARM.
> > >
> > > This reverts commit 948486544713492f00ac8a9572909101ea892cb0.
> > >
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > ---
> > > This part of the series is not required for the eSDHC quirk,
> > > but it restores the asm/fsl_guts.h header so it doesn't accidentally
> > > get abused for this in the future. I found two drivers outside of
> > > arch/powerpc that already accessed the registers directly, but the
> > > functions look fairly contained, and can be easily hidden in an
> > > #ifdef CONFIG_PPC
> >
> > NACK
> >
> > Besides adding ifdef pollution for no good reason, this register block is
> > used
> > on some ARM chips as well. Why is it a problem if "anyone starts using it
> > on
> > ARM"?
>
> It's just not a good interface when it's defined as "this is the layout of
> a register area that any driver can ioremap() if they can figure out the
> device node".
That's why I want to move accesses into one guts driver.
> It's not uncommon to have register areas like that, but
> normally you have at the minimum a 'syscon' device to handle locking
> between drivers accessing the same registers and to avoid having to map
> the same area multiple times.
syscon requires device tree changes.
I don't see read-modify-write operations in regmap -- how does locking around
an individual, inherently-atomic load or store help?
> If we need to use 'guts' registers on ARM, we can find a way to abstract
> them properly for the given use cases, using a syscon or a driver with
> exported functions, but just making a PowerPC platform specific header
> global to all Linux drivers by putting it into include/linux doesn't seem
> right.
Again, it's not PowerPC-specific! It started that way but then the same
register block got put onto some ARM chips.
It's not global to "all Linux drivers", just the ones that choose to include
an fsl-specific header.
If and when all uses of guts are moved into the guts driver, the header can be
moved into drivers/soc/fsl.
> Note that the header file uses a structure definition rather than the more
> common macros with register offsets, which is fine for a driver that has
> its own registers and abstracts them, but it doesn't really work with
> the regmap interface, so if we want to use it with syscon, it also needs to
> be rewritten.
We don't want to use it with syscon. If we did, the solution wouldn't be to
move the header back to arch/powerpc, but to convert the struct into offsets.
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-06-23 2:46 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-06-23 2:46 UTC (permalink / raw)
To: Scott Wood, Arnd Bergmann, linuxppc-dev
Cc: Mark Rutland, Ulf Hansson, linux-kernel, linux-i2c, linux-clk,
Qiang Zhao, Russell King, Bhupesh Sharma, Joerg Roedel,
Claudiu Manoil, devicetree, Kumar Gala, Rob Herring,
Santosh Shilimkar, linux-arm-kernel, netdev, linux-mmc,
Xiaobo Xie, Yang-Leo Li, iommu
Hi Arnd,
Could you comment on these?
Thanks.
Best regards,
Yangbo Lu
> -----Original Message-----
> From: Scott Wood [mailto:oss@buserror.net]
> Sent: Saturday, June 11, 2016 9:51 AM
> To: Arnd Bergmann; linuxppc-dev@lists.ozlabs.org
> Cc: Mark Rutland; Ulf Hansson; linux-kernel@vger.kernel.org; linux-
> i2c@vger.kernel.org; linux-clk@vger.kernel.org; Qiang Zhao; Russell King;
> Bhupesh Sharma; Joerg Roedel; Claudiu Manoil; devicetree@vger.kernel.org;
> Kumar Gala; Rob Herring; Santosh Shilimkar; linux-arm-
> kernel@lists.infradead.org; netdev@vger.kernel.org; linux-
> mmc@vger.kernel.org; Xiaobo Xie; Yang-Leo Li; iommu@lists.linux-
> foundation.org; Yangbo Lu
> Subject: Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
>
> On Thu, 2016-06-02 at 10:43 +0200, Arnd Bergmann wrote:
> > On Wednesday, June 1, 2016 8:47:22 PM CEST Scott Wood wrote:
> > > On Mon, 2016-05-30 at 15:15 +0200, Arnd Bergmann wrote:
> > > > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c new
> > > > file mode 100644 index 000000000000..2f30698f5bcf
> > > > --- /dev/null
> > > > +++ b/drivers/soc/fsl/guts.c
> > > > @@ -0,0 +1,130 @@
> > > > +/*
> > > > + * Freescale QorIQ Platforms GUTS Driver
> > > > + *
> > > > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > > > + *
> > > > + * This program is free software; you can redistribute it and/or
> > > > +modify
> > > > + * it under the terms of the GNU General Public License as
> > > > +published by
> > > > + * the Free Software Foundation; either version 2 of the License,
> > > > +or
> > > > + * (at your option) any later version.
> > > > + */
> > > > +
> > > > +#include <linux/io.h>
> > > > +#include <linux/platform_device.h> #include <linux/module.h>
> > > > +#include <linux/slab.h> #include <linux/of_address.h> #include
> > > > +<linux/of_platform.h> #include <linux/sys_soc.h>
> > > > +
> > > > +#define GUTS_PVR 0x0a0
> > > > +#define GUTS_SVR 0x0a4
> > > > +
> > > > +struct guts {
> > > > + void __iomem *regs;
> > >
> > > We already have a struct to define guts. Why are you not using it?
> > > Why do you consider using it to be "abuse"? What if we want to move
> > > more guts functionality into this driver?
> >
> > This structure was in the original patch, I left it in there, only
> > removed the inclusion of the powerpc header file, which seemed to be
> > misplaced.
>
> I'm not refering "struct guts". I'm referring to changing "struct
> ccsr_guts __iomem *regs" into "void __iomem *regs".
>
> And it's not a powerpc header file.
>
> > > > +/*
> > > > + * Table for matching compatible strings, for device tree
> > > > + * guts node, for Freescale QorIQ SOCs.
> > > > + */
> > > > +static const struct of_device_id fsl_guts_of_match[] = {
> > > > + /* For T4 & B4 Series SOCs */
> > > > + { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4
> > > > series" },
> > > [snip]
> > > > + { .compatible = "fsl,qoriq-device-config-2.0", .data = "P
> > > > series"
> > >
> > > As noted in my comment on patch 3/4, these descriptions are reversed.
> > >
> > > They're also incomplete. t2080 has device config 2.0. t1040 is
> > > described as
> > > 2.0 though it should probably be 2.1 (or better, drop the generic
> > > compatible altogether).
> >
> > Ok. Ideally I think we'd even look up the specific SoC names from the
> > SVC rather than the compatible string. I just didn't have a good list
> > for those to put in the driver.
>
> The list is in arch/powerpc/include/asm/mpc85xx.h but I don't know why we
> need to convert it to a string in the first place.
>
> >
> > > > + /*
> > > > + * syscon devices default to little-endian, but on powerpc we
> > > > have
> > > > + * existing device trees with big-endian maps and an absent
> > > > endianess
> > > > + * "big-property"
> > > > + */
> > > > + if (!IS_ENABLED(CONFIG_POWERPC) &&
> > > > + !of_property_read_bool(dev->of_node, "big-endian"))
> > > > + guts->little_endian = true;
> > >
> > > This is not a syscon device (Yangbo's patch to add a guts node on
> > > ls2080 is the only guts node that says "syscon", and that was a
> > > leftover from earlier revisions and should probably be removed).
> > > Even if it were, where is it documented that syscon defaults to
> > > little-endian?
> >
> > Documentation/devicetree/bindings/regmap/regmap.txt
> >
> > We had a little screwup here, basically regmap (and by consequence,
> > syscon) always defaulted to little-endian way before that was
> > documented, so it's too late to change it,
>
> What causes a device node to fall under the jurisdiction of regmap.txt?
> Again, these nodes do not claim "syscon" compatibility.
>
> > although I agree it would have made sense to document regmap to
> > default to big-endian on powerpc.
>
> Please don't. It's enough of a mess as is; no need to start throwing in
> architecture ifdefs.
>
> > > Documentation/devicetree/bindings/common-properties.txt says that
> > > the individual binding specifies the default. The default for this
> > > node should be big-endian because that's what existed before there
> > > was a need to describe the endianness. And we need an update to the
> > > guts binding to specify that.
> >
> > Good point. This proably means that specifying both the "guts" and
> "syscon"
> > compatible strings implies having to also specify the endianess
> > explicitly both ways, because otherwise we break one of the two
> bindings.
>
> Yes, but the node should only specify "guts".
>
> >
> > > > +
> > > > + guts->regs = devm_ioremap_resource(dev, 0);
> > > > + if (!guts->regs) {
> > > > + ret = -ENOMEM;
> > > > + kfree(guts);
> > > > + goto out;
> > > > + }
> > > > +
> > > > + fsl_guts_init(dev, guts);
> > > > + ret = 0;
> > > > +out:
> > > > + return ret;
> > > > +}
> > > > +
> > > > +static struct platform_driver fsl_soc_guts = {
> > > > + .probe = fsl_guts_probe,
> > > > + .driver.of_match_table = fsl_guts_of_match, };
> > > > +
> > > > +module_platform_driver(fsl_soc_guts);
> > >
> > > Again, this means that the information is not available during early
> > > boot, such as in the clock driver. Thus we would not be able to
> > > convert clk -qoriq's direct mfspr(SPRN_SVR) into an
> > > soc_device_match() (or anything else that makes use of this file),
> > > nor would we be able to move its access of the guts RCW registers
> > > into this driver.
> >
> > Correct. Do we have a reason to convert the mfspr() though? I don't
> > really see an improvement over the current state if we do that,
>
> Then should we drop this patchset and put a similar PPC ifdef in
> drivers/mmc/host/sdhci-of-esdhc.c?
>
> There's also the RCW access. You said in the patch 4/4 discussion that
> you di dn't like any random driver ioremapping the registers...
>
> > and for new devices
> > that might need the erratum workaround, we could add a DT property
> > that would be preferred to both.
>
> It's unlikely that we would know the erratum exists at the time the
> device tree is created. We also generally don't have separate device
> trees for each revision of a chip (and if we did, we'd have users that
> use the wrong one).
>
> -Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-06-23 2:46 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-06-23 2:46 UTC (permalink / raw)
To: Scott Wood, Arnd Bergmann, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Ulf Hansson,
Russell King, Bhupesh Sharma, netdev-u79uwXL29TY76Z2rM5mHXA,
Santosh Shilimkar, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Xiaobo Xie,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Rob Herring,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Claudiu Manoil, Kumar Gala,
Yang-Leo Li, linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Hi Arnd,
Could you comment on these?
Thanks.
Best regards,
Yangbo Lu
> -----Original Message-----
> From: Scott Wood [mailto:oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org]
> Sent: Saturday, June 11, 2016 9:51 AM
> To: Arnd Bergmann; linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> Cc: Mark Rutland; Ulf Hansson; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-
> i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Qiang Zhao; Russell King;
> Bhupesh Sharma; Joerg Roedel; Claudiu Manoil; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> Kumar Gala; Rob Herring; Santosh Shilimkar; linux-arm-
> kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-
> mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Xiaobo Xie; Yang-Leo Li; iommu-cunTk1MwBs/ROKNJybVBZg@public.gmane.org
> foundation.org; Yangbo Lu
> Subject: Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
>
> On Thu, 2016-06-02 at 10:43 +0200, Arnd Bergmann wrote:
> > On Wednesday, June 1, 2016 8:47:22 PM CEST Scott Wood wrote:
> > > On Mon, 2016-05-30 at 15:15 +0200, Arnd Bergmann wrote:
> > > > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c new
> > > > file mode 100644 index 000000000000..2f30698f5bcf
> > > > --- /dev/null
> > > > +++ b/drivers/soc/fsl/guts.c
> > > > @@ -0,0 +1,130 @@
> > > > +/*
> > > > + * Freescale QorIQ Platforms GUTS Driver
> > > > + *
> > > > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > > > + *
> > > > + * This program is free software; you can redistribute it and/or
> > > > +modify
> > > > + * it under the terms of the GNU General Public License as
> > > > +published by
> > > > + * the Free Software Foundation; either version 2 of the License,
> > > > +or
> > > > + * (at your option) any later version.
> > > > + */
> > > > +
> > > > +#include <linux/io.h>
> > > > +#include <linux/platform_device.h> #include <linux/module.h>
> > > > +#include <linux/slab.h> #include <linux/of_address.h> #include
> > > > +<linux/of_platform.h> #include <linux/sys_soc.h>
> > > > +
> > > > +#define GUTS_PVR 0x0a0
> > > > +#define GUTS_SVR 0x0a4
> > > > +
> > > > +struct guts {
> > > > + void __iomem *regs;
> > >
> > > We already have a struct to define guts. Why are you not using it?
> > > Why do you consider using it to be "abuse"? What if we want to move
> > > more guts functionality into this driver?
> >
> > This structure was in the original patch, I left it in there, only
> > removed the inclusion of the powerpc header file, which seemed to be
> > misplaced.
>
> I'm not refering "struct guts". I'm referring to changing "struct
> ccsr_guts __iomem *regs" into "void __iomem *regs".
>
> And it's not a powerpc header file.
>
> > > > +/*
> > > > + * Table for matching compatible strings, for device tree
> > > > + * guts node, for Freescale QorIQ SOCs.
> > > > + */
> > > > +static const struct of_device_id fsl_guts_of_match[] = {
> > > > + /* For T4 & B4 Series SOCs */
> > > > + { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4
> > > > series" },
> > > [snip]
> > > > + { .compatible = "fsl,qoriq-device-config-2.0", .data = "P
> > > > series"
> > >
> > > As noted in my comment on patch 3/4, these descriptions are reversed.
> > >
> > > They're also incomplete. t2080 has device config 2.0. t1040 is
> > > described as
> > > 2.0 though it should probably be 2.1 (or better, drop the generic
> > > compatible altogether).
> >
> > Ok. Ideally I think we'd even look up the specific SoC names from the
> > SVC rather than the compatible string. I just didn't have a good list
> > for those to put in the driver.
>
> The list is in arch/powerpc/include/asm/mpc85xx.h but I don't know why we
> need to convert it to a string in the first place.
>
> >
> > > > + /*
> > > > + * syscon devices default to little-endian, but on powerpc we
> > > > have
> > > > + * existing device trees with big-endian maps and an absent
> > > > endianess
> > > > + * "big-property"
> > > > + */
> > > > + if (!IS_ENABLED(CONFIG_POWERPC) &&
> > > > + !of_property_read_bool(dev->of_node, "big-endian"))
> > > > + guts->little_endian = true;
> > >
> > > This is not a syscon device (Yangbo's patch to add a guts node on
> > > ls2080 is the only guts node that says "syscon", and that was a
> > > leftover from earlier revisions and should probably be removed).
> > > Even if it were, where is it documented that syscon defaults to
> > > little-endian?
> >
> > Documentation/devicetree/bindings/regmap/regmap.txt
> >
> > We had a little screwup here, basically regmap (and by consequence,
> > syscon) always defaulted to little-endian way before that was
> > documented, so it's too late to change it,
>
> What causes a device node to fall under the jurisdiction of regmap.txt?
> Again, these nodes do not claim "syscon" compatibility.
>
> > although I agree it would have made sense to document regmap to
> > default to big-endian on powerpc.
>
> Please don't. It's enough of a mess as is; no need to start throwing in
> architecture ifdefs.
>
> > > Documentation/devicetree/bindings/common-properties.txt says that
> > > the individual binding specifies the default. The default for this
> > > node should be big-endian because that's what existed before there
> > > was a need to describe the endianness. And we need an update to the
> > > guts binding to specify that.
> >
> > Good point. This proably means that specifying both the "guts" and
> "syscon"
> > compatible strings implies having to also specify the endianess
> > explicitly both ways, because otherwise we break one of the two
> bindings.
>
> Yes, but the node should only specify "guts".
>
> >
> > > > +
> > > > + guts->regs = devm_ioremap_resource(dev, 0);
> > > > + if (!guts->regs) {
> > > > + ret = -ENOMEM;
> > > > + kfree(guts);
> > > > + goto out;
> > > > + }
> > > > +
> > > > + fsl_guts_init(dev, guts);
> > > > + ret = 0;
> > > > +out:
> > > > + return ret;
> > > > +}
> > > > +
> > > > +static struct platform_driver fsl_soc_guts = {
> > > > + .probe = fsl_guts_probe,
> > > > + .driver.of_match_table = fsl_guts_of_match, };
> > > > +
> > > > +module_platform_driver(fsl_soc_guts);
> > >
> > > Again, this means that the information is not available during early
> > > boot, such as in the clock driver. Thus we would not be able to
> > > convert clk -qoriq's direct mfspr(SPRN_SVR) into an
> > > soc_device_match() (or anything else that makes use of this file),
> > > nor would we be able to move its access of the guts RCW registers
> > > into this driver.
> >
> > Correct. Do we have a reason to convert the mfspr() though? I don't
> > really see an improvement over the current state if we do that,
>
> Then should we drop this patchset and put a similar PPC ifdef in
> drivers/mmc/host/sdhci-of-esdhc.c?
>
> There's also the RCW access. You said in the patch 4/4 discussion that
> you di dn't like any random driver ioremapping the registers...
>
> > and for new devices
> > that might need the erratum workaround, we could add a DT property
> > that would be preferred to both.
>
> It's unlikely that we would know the erratum exists at the time the
> device tree is created. We also generally don't have separate device
> trees for each revision of a chip (and if we did, we'd have users that
> use the wrong one).
>
> -Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-06-23 2:46 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-06-23 2:46 UTC (permalink / raw)
To: Scott Wood, Arnd Bergmann, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Ulf Hansson,
Russell King, Bhupesh Sharma, netdev-u79uwXL29TY76Z2rM5mHXA,
Santosh Shilimkar, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Xiaobo Xie,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Rob Herring,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Claudiu Manoil, Kumar Gala,
Yang-Leo Li, linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Hi Arnd,
Could you comment on these?
Thanks.
Best regards,
Yangbo Lu
> -----Original Message-----
> From: Scott Wood [mailto:oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org]
> Sent: Saturday, June 11, 2016 9:51 AM
> To: Arnd Bergmann; linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> Cc: Mark Rutland; Ulf Hansson; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-
> i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Qiang Zhao; Russell King;
> Bhupesh Sharma; Joerg Roedel; Claudiu Manoil; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> Kumar Gala; Rob Herring; Santosh Shilimkar; linux-arm-
> kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-
> mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Xiaobo Xie; Yang-Leo Li; iommu-cunTk1MwBs/ROKNJybVBZg@public.gmane.org
> foundation.org; Yangbo Lu
> Subject: Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
>
> On Thu, 2016-06-02 at 10:43 +0200, Arnd Bergmann wrote:
> > On Wednesday, June 1, 2016 8:47:22 PM CEST Scott Wood wrote:
> > > On Mon, 2016-05-30 at 15:15 +0200, Arnd Bergmann wrote:
> > > > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c new
> > > > file mode 100644 index 000000000000..2f30698f5bcf
> > > > --- /dev/null
> > > > +++ b/drivers/soc/fsl/guts.c
> > > > @@ -0,0 +1,130 @@
> > > > +/*
> > > > + * Freescale QorIQ Platforms GUTS Driver
> > > > + *
> > > > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > > > + *
> > > > + * This program is free software; you can redistribute it and/or
> > > > +modify
> > > > + * it under the terms of the GNU General Public License as
> > > > +published by
> > > > + * the Free Software Foundation; either version 2 of the License,
> > > > +or
> > > > + * (at your option) any later version.
> > > > + */
> > > > +
> > > > +#include <linux/io.h>
> > > > +#include <linux/platform_device.h> #include <linux/module.h>
> > > > +#include <linux/slab.h> #include <linux/of_address.h> #include
> > > > +<linux/of_platform.h> #include <linux/sys_soc.h>
> > > > +
> > > > +#define GUTS_PVR 0x0a0
> > > > +#define GUTS_SVR 0x0a4
> > > > +
> > > > +struct guts {
> > > > + void __iomem *regs;
> > >
> > > We already have a struct to define guts. Why are you not using it?
> > > Why do you consider using it to be "abuse"? What if we want to move
> > > more guts functionality into this driver?
> >
> > This structure was in the original patch, I left it in there, only
> > removed the inclusion of the powerpc header file, which seemed to be
> > misplaced.
>
> I'm not refering "struct guts". I'm referring to changing "struct
> ccsr_guts __iomem *regs" into "void __iomem *regs".
>
> And it's not a powerpc header file.
>
> > > > +/*
> > > > + * Table for matching compatible strings, for device tree
> > > > + * guts node, for Freescale QorIQ SOCs.
> > > > + */
> > > > +static const struct of_device_id fsl_guts_of_match[] = {
> > > > + /* For T4 & B4 Series SOCs */
> > > > + { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4
> > > > series" },
> > > [snip]
> > > > + { .compatible = "fsl,qoriq-device-config-2.0", .data = "P
> > > > series"
> > >
> > > As noted in my comment on patch 3/4, these descriptions are reversed.
> > >
> > > They're also incomplete. t2080 has device config 2.0. t1040 is
> > > described as
> > > 2.0 though it should probably be 2.1 (or better, drop the generic
> > > compatible altogether).
> >
> > Ok. Ideally I think we'd even look up the specific SoC names from the
> > SVC rather than the compatible string. I just didn't have a good list
> > for those to put in the driver.
>
> The list is in arch/powerpc/include/asm/mpc85xx.h but I don't know why we
> need to convert it to a string in the first place.
>
> >
> > > > + /*
> > > > + * syscon devices default to little-endian, but on powerpc we
> > > > have
> > > > + * existing device trees with big-endian maps and an absent
> > > > endianess
> > > > + * "big-property"
> > > > + */
> > > > + if (!IS_ENABLED(CONFIG_POWERPC) &&
> > > > + !of_property_read_bool(dev->of_node, "big-endian"))
> > > > + guts->little_endian = true;
> > >
> > > This is not a syscon device (Yangbo's patch to add a guts node on
> > > ls2080 is the only guts node that says "syscon", and that was a
> > > leftover from earlier revisions and should probably be removed).
> > > Even if it were, where is it documented that syscon defaults to
> > > little-endian?
> >
> > Documentation/devicetree/bindings/regmap/regmap.txt
> >
> > We had a little screwup here, basically regmap (and by consequence,
> > syscon) always defaulted to little-endian way before that was
> > documented, so it's too late to change it,
>
> What causes a device node to fall under the jurisdiction of regmap.txt?
> Again, these nodes do not claim "syscon" compatibility.
>
> > although I agree it would have made sense to document regmap to
> > default to big-endian on powerpc.
>
> Please don't. It's enough of a mess as is; no need to start throwing in
> architecture ifdefs.
>
> > > Documentation/devicetree/bindings/common-properties.txt says that
> > > the individual binding specifies the default. The default for this
> > > node should be big-endian because that's what existed before there
> > > was a need to describe the endianness. And we need an update to the
> > > guts binding to specify that.
> >
> > Good point. This proably means that specifying both the "guts" and
> "syscon"
> > compatible strings implies having to also specify the endianess
> > explicitly both ways, because otherwise we break one of the two
> bindings.
>
> Yes, but the node should only specify "guts".
>
> >
> > > > +
> > > > + guts->regs = devm_ioremap_resource(dev, 0);
> > > > + if (!guts->regs) {
> > > > + ret = -ENOMEM;
> > > > + kfree(guts);
> > > > + goto out;
> > > > + }
> > > > +
> > > > + fsl_guts_init(dev, guts);
> > > > + ret = 0;
> > > > +out:
> > > > + return ret;
> > > > +}
> > > > +
> > > > +static struct platform_driver fsl_soc_guts = {
> > > > + .probe = fsl_guts_probe,
> > > > + .driver.of_match_table = fsl_guts_of_match, };
> > > > +
> > > > +module_platform_driver(fsl_soc_guts);
> > >
> > > Again, this means that the information is not available during early
> > > boot, such as in the clock driver. Thus we would not be able to
> > > convert clk -qoriq's direct mfspr(SPRN_SVR) into an
> > > soc_device_match() (or anything else that makes use of this file),
> > > nor would we be able to move its access of the guts RCW registers
> > > into this driver.
> >
> > Correct. Do we have a reason to convert the mfspr() though? I don't
> > really see an improvement over the current state if we do that,
>
> Then should we drop this patchset and put a similar PPC ifdef in
> drivers/mmc/host/sdhci-of-esdhc.c?
>
> There's also the RCW access. You said in the patch 4/4 discussion that
> you di dn't like any random driver ioremapping the registers...
>
> > and for new devices
> > that might need the erratum workaround, we could add a DT property
> > that would be preferred to both.
>
> It's unlikely that we would know the erratum exists at the time the
> device tree is created. We also generally don't have separate device
> trees for each revision of a chip (and if we did, we'd have users that
> use the wrong one).
>
> -Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-06-23 2:46 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-06-23 2:46 UTC (permalink / raw)
To: Scott Wood, Arnd Bergmann, linuxppc-dev
Cc: Mark Rutland, Ulf Hansson, linux-kernel, linux-i2c, linux-clk,
Qiang Zhao, Russell King, Bhupesh Sharma, Joerg Roedel,
Claudiu Manoil, devicetree, Kumar Gala, Rob Herring,
Santosh Shilimkar, linux-arm-kernel, netdev, linux-mmc,
Xiaobo Xie, Yang-Leo Li, iommu
SGkgQXJuZCwNCg0KQ291bGQgeW91IGNvbW1lbnQgb24gdGhlc2U/DQpUaGFua3MuDQoNCg0KQmVz
dCByZWdhcmRzLA0KWWFuZ2JvIEx1DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
PiBGcm9tOiBTY290dCBXb29kIFttYWlsdG86b3NzQGJ1c2Vycm9yLm5ldF0NCj4gU2VudDogU2F0
dXJkYXksIEp1bmUgMTEsIDIwMTYgOTo1MSBBTQ0KPiBUbzogQXJuZCBCZXJnbWFubjsgbGludXhw
cGMtZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gQ2M6IE1hcmsgUnV0bGFuZDsgVWxmIEhhbnNzb247
IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LQ0KPiBpMmNAdmdlci5rZXJuZWwu
b3JnOyBsaW51eC1jbGtAdmdlci5rZXJuZWwub3JnOyBRaWFuZyBaaGFvOyBSdXNzZWxsIEtpbmc7
DQo+IEJodXBlc2ggU2hhcm1hOyBKb2VyZyBSb2VkZWw7IENsYXVkaXUgTWFub2lsOyBkZXZpY2V0
cmVlQHZnZXIua2VybmVsLm9yZzsNCj4gS3VtYXIgR2FsYTsgUm9iIEhlcnJpbmc7IFNhbnRvc2gg
U2hpbGlta2FyOyBsaW51eC1hcm0tDQo+IGtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnOyBuZXRk
ZXZAdmdlci5rZXJuZWwub3JnOyBsaW51eC0NCj4gbW1jQHZnZXIua2VybmVsLm9yZzsgWGlhb2Jv
IFhpZTsgWWFuZy1MZW8gTGk7IGlvbW11QGxpc3RzLmxpbnV4LQ0KPiBmb3VuZGF0aW9uLm9yZzsg
WWFuZ2JvIEx1DQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMi80XSBzb2M6IGZzbDogYWRkIEdVVFMg
ZHJpdmVyIGZvciBRb3JJUSBwbGF0Zm9ybXMNCj4gDQo+IE9uIFRodSwgMjAxNi0wNi0wMiBhdCAx
MDo0MyArMDIwMCwgQXJuZCBCZXJnbWFubiB3cm90ZToNCj4gPiBPbiBXZWRuZXNkYXksIEp1bmUg
MSwgMjAxNiA4OjQ3OjIyIFBNIENFU1QgU2NvdHQgV29vZCB3cm90ZToNCj4gPiA+IE9uIE1vbiwg
MjAxNi0wNS0zMCBhdCAxNToxNSArMDIwMCwgQXJuZCBCZXJnbWFubiB3cm90ZToNCj4gPiA+ID4g
ZGlmZiAtLWdpdCBhL2RyaXZlcnMvc29jL2ZzbC9ndXRzLmMgYi9kcml2ZXJzL3NvYy9mc2wvZ3V0
cy5jIG5ldw0KPiA+ID4gPiBmaWxlIG1vZGUgMTAwNjQ0IGluZGV4IDAwMDAwMDAwMDAwMC4uMmYz
MDY5OGY1YmNmDQo+ID4gPiA+IC0tLSAvZGV2L251bGwNCj4gPiA+ID4gKysrIGIvZHJpdmVycy9z
b2MvZnNsL2d1dHMuYw0KPiA+ID4gPiBAQCAtMCwwICsxLDEzMCBAQA0KPiA+ID4gPiArLyoNCj4g
PiA+ID4gKyAqIEZyZWVzY2FsZSBRb3JJUSBQbGF0Zm9ybXMgR1VUUyBEcml2ZXINCj4gPiA+ID4g
KyAqDQo+ID4gPiA+ICsgKiBDb3B5cmlnaHQgKEMpIDIwMTYgRnJlZXNjYWxlIFNlbWljb25kdWN0
b3IsIEluYy4NCj4gPiA+ID4gKyAqDQo+ID4gPiA+ICsgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBz
b2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yDQo+ID4gPiA+ICttb2RpZnkN
Cj4gPiA+ID4gKyAqIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGlj
IExpY2Vuc2UgYXMNCj4gPiA+ID4gK3B1Ymxpc2hlZCBieQ0KPiA+ID4gPiArICogdGhlIEZyZWUg
U29mdHdhcmUgRm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMiBvZiB0aGUgTGljZW5zZSwNCj4g
PiA+ID4gK29yDQo+ID4gPiA+ICsgKiAoYXQgeW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9u
Lg0KPiA+ID4gPiArICovDQo+ID4gPiA+ICsNCj4gPiA+ID4gKyNpbmNsdWRlIDxsaW51eC9pby5o
Pg0KPiA+ID4gPiArI2luY2x1ZGUgPGxpbnV4L3BsYXRmb3JtX2RldmljZS5oPiAjaW5jbHVkZSA8
bGludXgvbW9kdWxlLmg+DQo+ID4gPiA+ICsjaW5jbHVkZSA8bGludXgvc2xhYi5oPiAjaW5jbHVk
ZSA8bGludXgvb2ZfYWRkcmVzcy5oPiAjaW5jbHVkZQ0KPiA+ID4gPiArPGxpbnV4L29mX3BsYXRm
b3JtLmg+ICNpbmNsdWRlIDxsaW51eC9zeXNfc29jLmg+DQo+ID4gPiA+ICsNCj4gPiA+ID4gKyNk
ZWZpbmUgR1VUU19QVlIJMHgwYTANCj4gPiA+ID4gKyNkZWZpbmUgR1VUU19TVlIJMHgwYTQNCj4g
PiA+ID4gKw0KPiA+ID4gPiArc3RydWN0IGd1dHMgew0KPiA+ID4gPiArCXZvaWQgX19pb21lbSAq
cmVnczsNCj4gPiA+DQo+ID4gPiBXZSBhbHJlYWR5IGhhdmUgYSBzdHJ1Y3QgdG8gZGVmaW5lIGd1
dHMuICBXaHkgYXJlIHlvdSBub3QgdXNpbmcgaXQ/DQo+ID4gPiBXaHkgZG8geW91IGNvbnNpZGVy
IHVzaW5nIGl0IHRvIGJlICJhYnVzZSI/ICBXaGF0IGlmIHdlIHdhbnQgdG8gbW92ZQ0KPiA+ID4g
bW9yZSBndXRzIGZ1bmN0aW9uYWxpdHkgaW50byB0aGlzIGRyaXZlcj8NCj4gPg0KPiA+IFRoaXMg
c3RydWN0dXJlIHdhcyBpbiB0aGUgb3JpZ2luYWwgcGF0Y2gsIEkgbGVmdCBpdCBpbiB0aGVyZSwg
b25seQ0KPiA+IHJlbW92ZWQgdGhlIGluY2x1c2lvbiBvZiB0aGUgcG93ZXJwYyBoZWFkZXIgZmls
ZSwgd2hpY2ggc2VlbWVkIHRvIGJlDQo+ID4gbWlzcGxhY2VkLg0KPiANCj4gSSdtIG5vdCByZWZl
cmluZyAic3RydWN0IGd1dHMiLiAgSSdtIHJlZmVycmluZyB0byBjaGFuZ2luZyAic3RydWN0DQo+
IGNjc3JfZ3V0cyBfX2lvbWVtICpyZWdzIiBpbnRvICJ2b2lkIF9faW9tZW0gKnJlZ3MiLg0KPiAN
Cj4gQW5kIGl0J3Mgbm90IGEgcG93ZXJwYyBoZWFkZXIgZmlsZS4NCj4gDQo+ID4gPiA+ICsvKg0K
PiA+ID4gPiArICogVGFibGUgZm9yIG1hdGNoaW5nIGNvbXBhdGlibGUgc3RyaW5ncywgZm9yIGRl
dmljZSB0cmVlDQo+ID4gPiA+ICsgKiBndXRzIG5vZGUsIGZvciBGcmVlc2NhbGUgUW9ySVEgU09D
cy4NCj4gPiA+ID4gKyAqLw0KPiA+ID4gPiArc3RhdGljIGNvbnN0IHN0cnVjdCBvZl9kZXZpY2Vf
aWQgZnNsX2d1dHNfb2ZfbWF0Y2hbXSA9IHsNCj4gPiA+ID4gKwkvKiBGb3IgVDQgJiBCNCBTZXJp
ZXMgU09DcyAqLw0KPiA+ID4gPiArCXsgLmNvbXBhdGlibGUgPSAiZnNsLHFvcmlxLWRldmljZS1j
b25maWctMS4wIiwgLmRhdGEgPSAiVDQvQjQNCj4gPiA+ID4gc2VyaWVzIiB9LA0KPiA+ID4gW3Nu
aXBdDQo+ID4gPiA+ICsJeyAuY29tcGF0aWJsZSA9ICJmc2wscW9yaXEtZGV2aWNlLWNvbmZpZy0y
LjAiLCAuZGF0YSA9ICJQDQo+ID4gPiA+IHNlcmllcyINCj4gPiA+DQo+ID4gPiBBcyBub3RlZCBp
biBteSBjb21tZW50IG9uIHBhdGNoIDMvNCwgdGhlc2UgZGVzY3JpcHRpb25zIGFyZSByZXZlcnNl
ZC4NCj4gPiA+DQo+ID4gPiBUaGV5J3JlIGFsc28gaW5jb21wbGV0ZS4gIHQyMDgwIGhhcyBkZXZp
Y2UgY29uZmlnIDIuMC4gIHQxMDQwIGlzDQo+ID4gPiBkZXNjcmliZWQgYXMNCj4gPiA+IDIuMCB0
aG91Z2ggaXQgc2hvdWxkIHByb2JhYmx5IGJlIDIuMSAob3IgYmV0dGVyLCBkcm9wIHRoZSBnZW5l
cmljDQo+ID4gPiBjb21wYXRpYmxlIGFsdG9nZXRoZXIpLg0KPiA+DQo+ID4gT2suIElkZWFsbHkg
SSB0aGluayB3ZSdkIGV2ZW4gbG9vayB1cCB0aGUgc3BlY2lmaWMgU29DIG5hbWVzIGZyb20gdGhl
DQo+ID4gU1ZDIHJhdGhlciB0aGFuIHRoZSBjb21wYXRpYmxlIHN0cmluZy4gSSBqdXN0IGRpZG4n
dCBoYXZlIGEgZ29vZCBsaXN0DQo+ID4gZm9yIHRob3NlIHRvIHB1dCBpbiB0aGUgZHJpdmVyLg0K
PiANCj4gVGhlIGxpc3QgaXMgaW4gYXJjaC9wb3dlcnBjL2luY2x1ZGUvYXNtL21wYzg1eHguaCBi
dXQgSSBkb24ndCBrbm93IHdoeSB3ZQ0KPiBuZWVkIHRvIGNvbnZlcnQgaXQgdG8gYSBzdHJpbmcg
aW4gdGhlIGZpcnN0IHBsYWNlLg0KPiANCj4gPg0KPiA+ID4gPiArCS8qDQo+ID4gPiA+ICsJICog
c3lzY29uIGRldmljZXMgZGVmYXVsdCB0byBsaXR0bGUtZW5kaWFuLCBidXQgb24gcG93ZXJwYyB3
ZQ0KPiA+ID4gPiBoYXZlDQo+ID4gPiA+ICsJICogZXhpc3RpbmcgZGV2aWNlIHRyZWVzIHdpdGgg
YmlnLWVuZGlhbiBtYXBzIGFuZCBhbiBhYnNlbnQNCj4gPiA+ID4gZW5kaWFuZXNzDQo+ID4gPiA+
ICsJICogImJpZy1wcm9wZXJ0eSINCj4gPiA+ID4gKwkgKi8NCj4gPiA+ID4gKwlpZiAoIUlTX0VO
QUJMRUQoQ09ORklHX1BPV0VSUEMpICYmDQo+ID4gPiA+ICsJICAgICFvZl9wcm9wZXJ0eV9yZWFk
X2Jvb2woZGV2LT5vZl9ub2RlLCAiYmlnLWVuZGlhbiIpKQ0KPiA+ID4gPiArCQlndXRzLT5saXR0
bGVfZW5kaWFuID0gdHJ1ZTsNCj4gPiA+DQo+ID4gPiBUaGlzIGlzIG5vdCBhIHN5c2NvbiBkZXZp
Y2UgKFlhbmdibydzIHBhdGNoIHRvIGFkZCBhIGd1dHMgbm9kZSBvbg0KPiA+ID4gbHMyMDgwIGlz
IHRoZSBvbmx5IGd1dHMgbm9kZSB0aGF0IHNheXMgInN5c2NvbiIsIGFuZCB0aGF0IHdhcyBhDQo+
ID4gPiBsZWZ0b3ZlciBmcm9tIGVhcmxpZXIgcmV2aXNpb25zIGFuZCBzaG91bGQgcHJvYmFibHkg
YmUgcmVtb3ZlZCkuDQo+ID4gPiBFdmVuIGlmIGl0IHdlcmUsIHdoZXJlIGlzIGl0IGRvY3VtZW50
ZWQgdGhhdCBzeXNjb24gZGVmYXVsdHMgdG8NCj4gPiA+IGxpdHRsZS1lbmRpYW4/DQo+ID4NCj4g
PiBEb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvcmVnbWFwL3JlZ21hcC50eHQNCj4g
Pg0KPiA+IFdlIGhhZCBhIGxpdHRsZSBzY3Jld3VwIGhlcmUsIGJhc2ljYWxseSByZWdtYXAgKGFu
ZCBieSBjb25zZXF1ZW5jZSwNCj4gPiBzeXNjb24pIGFsd2F5cyBkZWZhdWx0ZWQgdG8gbGl0dGxl
LWVuZGlhbiB3YXkgYmVmb3JlIHRoYXQgd2FzDQo+ID4gZG9jdW1lbnRlZCwgc28gaXQncyB0b28g
bGF0ZSB0byBjaGFuZ2UgaXQsDQo+IA0KPiBXaGF0IGNhdXNlcyBhIGRldmljZSBub2RlIHRvIGZh
bGwgdW5kZXIgdGhlIGp1cmlzZGljdGlvbiBvZiByZWdtYXAudHh0Pw0KPiAgQWdhaW4sIHRoZXNl
IG5vZGVzIGRvIG5vdCBjbGFpbSAic3lzY29uIiBjb21wYXRpYmlsaXR5Lg0KPiANCj4gPiBhbHRo
b3VnaCBJIGFncmVlIGl0IHdvdWxkIGhhdmUgbWFkZSBzZW5zZSB0byBkb2N1bWVudCByZWdtYXAg
dG8NCj4gPiBkZWZhdWx0IHRvIGJpZy1lbmRpYW4gb24gcG93ZXJwYy4NCj4gDQo+IFBsZWFzZSBk
b24ndC4gIEl0J3MgZW5vdWdoIG9mIGEgbWVzcyBhcyBpczsgbm8gbmVlZCB0byBzdGFydCB0aHJv
d2luZyBpbg0KPiBhcmNoaXRlY3R1cmUgaWZkZWZzLg0KPiANCj4gPiA+IERvY3VtZW50YXRpb24v
ZGV2aWNldHJlZS9iaW5kaW5ncy9jb21tb24tcHJvcGVydGllcy50eHQgc2F5cyB0aGF0DQo+ID4g
PiB0aGUgaW5kaXZpZHVhbCBiaW5kaW5nIHNwZWNpZmllcyB0aGUgZGVmYXVsdC4gIFRoZSBkZWZh
dWx0IGZvciB0aGlzDQo+ID4gPiBub2RlIHNob3VsZCBiZSBiaWctZW5kaWFuIGJlY2F1c2UgdGhh
dCdzIHdoYXQgZXhpc3RlZCBiZWZvcmUgdGhlcmUNCj4gPiA+IHdhcyBhIG5lZWQgdG8gZGVzY3Jp
YmUgdGhlIGVuZGlhbm5lc3MuICBBbmQgd2UgbmVlZCBhbiB1cGRhdGUgdG8gdGhlDQo+ID4gPiBn
dXRzIGJpbmRpbmcgdG8gc3BlY2lmeSB0aGF0Lg0KPiA+DQo+ID4gR29vZCBwb2ludC4gVGhpcyBw
cm9hYmx5IG1lYW5zIHRoYXQgc3BlY2lmeWluZyBib3RoIHRoZSAiZ3V0cyIgYW5kDQo+ICJzeXNj
b24iDQo+ID4gY29tcGF0aWJsZSBzdHJpbmdzIGltcGxpZXMgaGF2aW5nIHRvIGFsc28gc3BlY2lm
eSB0aGUgZW5kaWFuZXNzDQo+ID4gZXhwbGljaXRseSBib3RoIHdheXMsIGJlY2F1c2Ugb3RoZXJ3
aXNlIHdlIGJyZWFrIG9uZSBvZiB0aGUgdHdvDQo+IGJpbmRpbmdzLg0KPiANCj4gWWVzLCBidXQg
dGhlIG5vZGUgc2hvdWxkIG9ubHkgc3BlY2lmeSAiZ3V0cyIuDQo+IA0KPiA+DQo+ID4gPiA+ICsN
Cj4gPiA+ID4gKwlndXRzLT5yZWdzID0gZGV2bV9pb3JlbWFwX3Jlc291cmNlKGRldiwgMCk7DQo+
ID4gPiA+ICsJaWYgKCFndXRzLT5yZWdzKSB7DQo+ID4gPiA+ICsJCXJldCA9IC1FTk9NRU07DQo+
ID4gPiA+ICsJCWtmcmVlKGd1dHMpOw0KPiA+ID4gPiArCQlnb3RvIG91dDsNCj4gPiA+ID4gKwl9
DQo+ID4gPiA+ICsNCj4gPiA+ID4gKwlmc2xfZ3V0c19pbml0KGRldiwgZ3V0cyk7DQo+ID4gPiA+
ICsJcmV0ID0gMDsNCj4gPiA+ID4gK291dDoNCj4gPiA+ID4gKwlyZXR1cm4gcmV0Ow0KPiA+ID4g
PiArfQ0KPiA+ID4gPiArDQo+ID4gPiA+ICtzdGF0aWMgc3RydWN0IHBsYXRmb3JtX2RyaXZlciBm
c2xfc29jX2d1dHMgPSB7DQo+ID4gPiA+ICsJLnByb2JlID0gZnNsX2d1dHNfcHJvYmUsDQo+ID4g
PiA+ICsJLmRyaXZlci5vZl9tYXRjaF90YWJsZSA9IGZzbF9ndXRzX29mX21hdGNoLCB9Ow0KPiA+
ID4gPiArDQo+ID4gPiA+ICttb2R1bGVfcGxhdGZvcm1fZHJpdmVyKGZzbF9zb2NfZ3V0cyk7DQo+
ID4gPg0KPiA+ID4gQWdhaW4sIHRoaXMgbWVhbnMgdGhhdCB0aGUgaW5mb3JtYXRpb24gaXMgbm90
IGF2YWlsYWJsZSBkdXJpbmcgZWFybHkNCj4gPiA+IGJvb3QsIHN1Y2ggYXMgaW4gdGhlIGNsb2Nr
IGRyaXZlci4gIFRodXMgd2Ugd291bGQgbm90IGJlIGFibGUgdG8NCj4gPiA+IGNvbnZlcnQgY2xr
IC1xb3JpcSdzIGRpcmVjdCBtZnNwcihTUFJOX1NWUikgaW50byBhbg0KPiA+ID4gc29jX2Rldmlj
ZV9tYXRjaCgpIChvciBhbnl0aGluZyBlbHNlIHRoYXQgbWFrZXMgdXNlIG9mIHRoaXMgZmlsZSks
DQo+ID4gPiBub3Igd291bGQgd2UgYmUgYWJsZSB0byBtb3ZlIGl0cyBhY2Nlc3Mgb2YgdGhlIGd1
dHMgUkNXIHJlZ2lzdGVycw0KPiA+ID4gaW50byB0aGlzIGRyaXZlci4NCj4gPg0KPiA+IENvcnJl
Y3QuIERvIHdlIGhhdmUgYSByZWFzb24gdG8gY29udmVydCB0aGUgbWZzcHIoKSB0aG91Z2g/IEkg
ZG9uJ3QNCj4gPiByZWFsbHkgc2VlIGFuIGltcHJvdmVtZW50IG92ZXIgdGhlIGN1cnJlbnQgc3Rh
dGUgaWYgd2UgZG8gdGhhdCwNCj4gDQo+IFRoZW4gc2hvdWxkIHdlIGRyb3AgdGhpcyBwYXRjaHNl
dCBhbmQgcHV0IGEgc2ltaWxhciBQUEMgaWZkZWYgaW4NCj4gZHJpdmVycy9tbWMvaG9zdC9zZGhj
aS1vZi1lc2RoYy5jPw0KPiANCj4gVGhlcmUncyBhbHNvIHRoZSBSQ1cgYWNjZXNzLiAgWW91IHNh
aWQgaW4gdGhlIHBhdGNoIDQvNCBkaXNjdXNzaW9uIHRoYXQNCj4geW91IGRpIGRuJ3QgbGlrZSBh
bnkgcmFuZG9tIGRyaXZlciBpb3JlbWFwcGluZyB0aGUgcmVnaXN0ZXJzLi4uDQo+IA0KPiA+IGFu
ZCBmb3IgbmV3IGRldmljZXMNCj4gPiB0aGF0IG1pZ2h0IG5lZWQgdGhlIGVycmF0dW0gd29ya2Fy
b3VuZCwgd2UgY291bGQgYWRkIGEgRFQgcHJvcGVydHkNCj4gPiB0aGF0IHdvdWxkIGJlIHByZWZl
cnJlZCB0byBib3RoLg0KPiANCj4gSXQncyB1bmxpa2VseSB0aGF0IHdlIHdvdWxkIGtub3cgdGhl
IGVycmF0dW0gZXhpc3RzIGF0IHRoZSB0aW1lIHRoZQ0KPiBkZXZpY2UgdHJlZSBpcyBjcmVhdGVk
LiAgV2UgYWxzbyBnZW5lcmFsbHkgZG9uJ3QgaGF2ZSBzZXBhcmF0ZSBkZXZpY2UNCj4gdHJlZXMg
Zm9yIGVhY2ggcmV2aXNpb24gb2YgYSBjaGlwIChhbmQgaWYgd2UgZGlkLCB3ZSdkIGhhdmUgdXNl
cnMgdGhhdA0KPiB1c2UgdGhlIHdyb25nIG9uZSkuDQo+IA0KPiAtU2NvdHQNCg0K
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-06-23 2:46 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-06-23 2:46 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
Could you comment on these?
Thanks.
Best regards,
Yangbo Lu
> -----Original Message-----
> From: Scott Wood [mailto:oss at buserror.net]
> Sent: Saturday, June 11, 2016 9:51 AM
> To: Arnd Bergmann; linuxppc-dev at lists.ozlabs.org
> Cc: Mark Rutland; Ulf Hansson; linux-kernel at vger.kernel.org; linux-
> i2c at vger.kernel.org; linux-clk at vger.kernel.org; Qiang Zhao; Russell King;
> Bhupesh Sharma; Joerg Roedel; Claudiu Manoil; devicetree at vger.kernel.org;
> Kumar Gala; Rob Herring; Santosh Shilimkar; linux-arm-
> kernel at lists.infradead.org; netdev at vger.kernel.org; linux-
> mmc at vger.kernel.org; Xiaobo Xie; Yang-Leo Li; iommu at lists.linux-
> foundation.org; Yangbo Lu
> Subject: Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
>
> On Thu, 2016-06-02 at 10:43 +0200, Arnd Bergmann wrote:
> > On Wednesday, June 1, 2016 8:47:22 PM CEST Scott Wood wrote:
> > > On Mon, 2016-05-30 at 15:15 +0200, Arnd Bergmann wrote:
> > > > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c new
> > > > file mode 100644 index 000000000000..2f30698f5bcf
> > > > --- /dev/null
> > > > +++ b/drivers/soc/fsl/guts.c
> > > > @@ -0,0 +1,130 @@
> > > > +/*
> > > > + * Freescale QorIQ Platforms GUTS Driver
> > > > + *
> > > > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > > > + *
> > > > + * This program is free software; you can redistribute it and/or
> > > > +modify
> > > > + * it under the terms of the GNU General Public License as
> > > > +published by
> > > > + * the Free Software Foundation; either version 2 of the License,
> > > > +or
> > > > + * (at your option) any later version.
> > > > + */
> > > > +
> > > > +#include <linux/io.h>
> > > > +#include <linux/platform_device.h> #include <linux/module.h>
> > > > +#include <linux/slab.h> #include <linux/of_address.h> #include
> > > > +<linux/of_platform.h> #include <linux/sys_soc.h>
> > > > +
> > > > +#define GUTS_PVR 0x0a0
> > > > +#define GUTS_SVR 0x0a4
> > > > +
> > > > +struct guts {
> > > > + void __iomem *regs;
> > >
> > > We already have a struct to define guts. Why are you not using it?
> > > Why do you consider using it to be "abuse"? What if we want to move
> > > more guts functionality into this driver?
> >
> > This structure was in the original patch, I left it in there, only
> > removed the inclusion of the powerpc header file, which seemed to be
> > misplaced.
>
> I'm not refering "struct guts". I'm referring to changing "struct
> ccsr_guts __iomem *regs" into "void __iomem *regs".
>
> And it's not a powerpc header file.
>
> > > > +/*
> > > > + * Table for matching compatible strings, for device tree
> > > > + * guts node, for Freescale QorIQ SOCs.
> > > > + */
> > > > +static const struct of_device_id fsl_guts_of_match[] = {
> > > > + /* For T4 & B4 Series SOCs */
> > > > + { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4
> > > > series" },
> > > [snip]
> > > > + { .compatible = "fsl,qoriq-device-config-2.0", .data = "P
> > > > series"
> > >
> > > As noted in my comment on patch 3/4, these descriptions are reversed.
> > >
> > > They're also incomplete. t2080 has device config 2.0. t1040 is
> > > described as
> > > 2.0 though it should probably be 2.1 (or better, drop the generic
> > > compatible altogether).
> >
> > Ok. Ideally I think we'd even look up the specific SoC names from the
> > SVC rather than the compatible string. I just didn't have a good list
> > for those to put in the driver.
>
> The list is in arch/powerpc/include/asm/mpc85xx.h but I don't know why we
> need to convert it to a string in the first place.
>
> >
> > > > + /*
> > > > + * syscon devices default to little-endian, but on powerpc we
> > > > have
> > > > + * existing device trees with big-endian maps and an absent
> > > > endianess
> > > > + * "big-property"
> > > > + */
> > > > + if (!IS_ENABLED(CONFIG_POWERPC) &&
> > > > + !of_property_read_bool(dev->of_node, "big-endian"))
> > > > + guts->little_endian = true;
> > >
> > > This is not a syscon device (Yangbo's patch to add a guts node on
> > > ls2080 is the only guts node that says "syscon", and that was a
> > > leftover from earlier revisions and should probably be removed).
> > > Even if it were, where is it documented that syscon defaults to
> > > little-endian?
> >
> > Documentation/devicetree/bindings/regmap/regmap.txt
> >
> > We had a little screwup here, basically regmap (and by consequence,
> > syscon) always defaulted to little-endian way before that was
> > documented, so it's too late to change it,
>
> What causes a device node to fall under the jurisdiction of regmap.txt?
> Again, these nodes do not claim "syscon" compatibility.
>
> > although I agree it would have made sense to document regmap to
> > default to big-endian on powerpc.
>
> Please don't. It's enough of a mess as is; no need to start throwing in
> architecture ifdefs.
>
> > > Documentation/devicetree/bindings/common-properties.txt says that
> > > the individual binding specifies the default. The default for this
> > > node should be big-endian because that's what existed before there
> > > was a need to describe the endianness. And we need an update to the
> > > guts binding to specify that.
> >
> > Good point. This proably means that specifying both the "guts" and
> "syscon"
> > compatible strings implies having to also specify the endianess
> > explicitly both ways, because otherwise we break one of the two
> bindings.
>
> Yes, but the node should only specify "guts".
>
> >
> > > > +
> > > > + guts->regs = devm_ioremap_resource(dev, 0);
> > > > + if (!guts->regs) {
> > > > + ret = -ENOMEM;
> > > > + kfree(guts);
> > > > + goto out;
> > > > + }
> > > > +
> > > > + fsl_guts_init(dev, guts);
> > > > + ret = 0;
> > > > +out:
> > > > + return ret;
> > > > +}
> > > > +
> > > > +static struct platform_driver fsl_soc_guts = {
> > > > + .probe = fsl_guts_probe,
> > > > + .driver.of_match_table = fsl_guts_of_match, };
> > > > +
> > > > +module_platform_driver(fsl_soc_guts);
> > >
> > > Again, this means that the information is not available during early
> > > boot, such as in the clock driver. Thus we would not be able to
> > > convert clk -qoriq's direct mfspr(SPRN_SVR) into an
> > > soc_device_match() (or anything else that makes use of this file),
> > > nor would we be able to move its access of the guts RCW registers
> > > into this driver.
> >
> > Correct. Do we have a reason to convert the mfspr() though? I don't
> > really see an improvement over the current state if we do that,
>
> Then should we drop this patchset and put a similar PPC ifdef in
> drivers/mmc/host/sdhci-of-esdhc.c?
>
> There's also the RCW access. You said in the patch 4/4 discussion that
> you di dn't like any random driver ioremapping the registers...
>
> > and for new devices
> > that might need the erratum workaround, we could add a DT property
> > that would be preferred to both.
>
> It's unlikely that we would know the erratum exists at the time the
> device tree is created. We also generally don't have separate device
> trees for each revision of a chip (and if we did, we'd have users that
> use the wrong one).
>
> -Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
2016-06-11 1:50 ` Scott Wood
` (3 preceding siblings ...)
(?)
@ 2016-07-07 2:35 ` Yangbo Lu
-1 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-07-07 2:35 UTC (permalink / raw)
To: Scott Wood, Arnd Bergmann, linuxppc-dev
Cc: Mark Rutland, Ulf Hansson, linux-kernel, linux-i2c, linux-clk,
Qiang Zhao, Russell King, Bhupesh Sharma, Joerg Roedel,
Claudiu Manoil, devicetree, Kumar Gala, Rob Herring,
Santosh Shilimkar, linux-arm-kernel, netdev, linux-mmc,
Xiaobo Xie, Yang-Leo Li, iommu
Hi Arnd,
Could you reply when you see the email?
If your method doesn’t resolve the problem, we still want to use our old patchset.
This guts driver had been discussed about one year and blocked many workaround upstream.
So please help to review and comment soon.
Thanks a lot.
Best regards,
Yangbo Lu
> -----Original Message-----
> From: Yangbo Lu
> Sent: Thursday, June 23, 2016 10:46 AM
> To: 'Scott Wood'; Arnd Bergmann; linuxppc-dev@lists.ozlabs.org
> Cc: Mark Rutland; Ulf Hansson; linux-kernel@vger.kernel.org; linux-
> i2c@vger.kernel.org; linux-clk@vger.kernel.org; Qiang Zhao; Russell King;
> Bhupesh Sharma; Joerg Roedel; Claudiu Manoil; devicetree@vger.kernel.org;
> Kumar Gala; Rob Herring; Santosh Shilimkar; linux-arm-
> kernel@lists.infradead.org; netdev@vger.kernel.org; linux-
> mmc@vger.kernel.org; Xiaobo Xie; Yang-Leo Li; iommu@lists.linux-
> foundation.org
> Subject: RE: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
>
> Hi Arnd,
>
> Could you comment on these?
> Thanks.
>
>
> Best regards,
> Yangbo Lu
>
>
> > -----Original Message-----
> > From: Scott Wood [mailto:oss@buserror.net]
> > Sent: Saturday, June 11, 2016 9:51 AM
> > To: Arnd Bergmann; linuxppc-dev@lists.ozlabs.org
> > Cc: Mark Rutland; Ulf Hansson; linux-kernel@vger.kernel.org; linux-
> > i2c@vger.kernel.org; linux-clk@vger.kernel.org; Qiang Zhao; Russell
> > King; Bhupesh Sharma; Joerg Roedel; Claudiu Manoil;
> > devicetree@vger.kernel.org; Kumar Gala; Rob Herring; Santosh
> > Shilimkar; linux-arm- kernel@lists.infradead.org;
> > netdev@vger.kernel.org; linux- mmc@vger.kernel.org; Xiaobo Xie;
> > Yang-Leo Li; iommu@lists.linux- foundation.org; Yangbo Lu
> > Subject: Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
> >
> > On Thu, 2016-06-02 at 10:43 +0200, Arnd Bergmann wrote:
> > > On Wednesday, June 1, 2016 8:47:22 PM CEST Scott Wood wrote:
> > > > On Mon, 2016-05-30 at 15:15 +0200, Arnd Bergmann wrote:
> > > > > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c new
> > > > > file mode 100644 index 000000000000..2f30698f5bcf
> > > > > --- /dev/null
> > > > > +++ b/drivers/soc/fsl/guts.c
> > > > > @@ -0,0 +1,130 @@
> > > > > +/*
> > > > > + * Freescale QorIQ Platforms GUTS Driver
> > > > > + *
> > > > > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > > > > + *
> > > > > + * This program is free software; you can redistribute it
> > > > > +and/or modify
> > > > > + * it under the terms of the GNU General Public License as
> > > > > +published by
> > > > > + * the Free Software Foundation; either version 2 of the
> > > > > +License, or
> > > > > + * (at your option) any later version.
> > > > > + */
> > > > > +
> > > > > +#include <linux/io.h>
> > > > > +#include <linux/platform_device.h> #include <linux/module.h>
> > > > > +#include <linux/slab.h> #include <linux/of_address.h> #include
> > > > > +<linux/of_platform.h> #include <linux/sys_soc.h>
> > > > > +
> > > > > +#define GUTS_PVR 0x0a0
> > > > > +#define GUTS_SVR 0x0a4
> > > > > +
> > > > > +struct guts {
> > > > > + void __iomem *regs;
> > > >
> > > > We already have a struct to define guts. Why are you not using it?
> > > > Why do you consider using it to be "abuse"? What if we want to
> > > > move more guts functionality into this driver?
> > >
> > > This structure was in the original patch, I left it in there, only
> > > removed the inclusion of the powerpc header file, which seemed to be
> > > misplaced.
> >
> > I'm not refering "struct guts". I'm referring to changing "struct
> > ccsr_guts __iomem *regs" into "void __iomem *regs".
> >
> > And it's not a powerpc header file.
> >
> > > > > +/*
> > > > > + * Table for matching compatible strings, for device tree
> > > > > + * guts node, for Freescale QorIQ SOCs.
> > > > > + */
> > > > > +static const struct of_device_id fsl_guts_of_match[] = {
> > > > > + /* For T4 & B4 Series SOCs */
> > > > > + { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4
> > > > > series" },
> > > > [snip]
> > > > > + { .compatible = "fsl,qoriq-device-config-2.0", .data = "P
> > > > > series"
> > > >
> > > > As noted in my comment on patch 3/4, these descriptions are
> reversed.
> > > >
> > > > They're also incomplete. t2080 has device config 2.0. t1040 is
> > > > described as
> > > > 2.0 though it should probably be 2.1 (or better, drop the generic
> > > > compatible altogether).
> > >
> > > Ok. Ideally I think we'd even look up the specific SoC names from
> > > the SVC rather than the compatible string. I just didn't have a good
> > > list for those to put in the driver.
> >
> > The list is in arch/powerpc/include/asm/mpc85xx.h but I don't know why
> > we need to convert it to a string in the first place.
> >
> > >
> > > > > + /*
> > > > > + * syscon devices default to little-endian, but on powerpc we
> > > > > have
> > > > > + * existing device trees with big-endian maps and an absent
> > > > > endianess
> > > > > + * "big-property"
> > > > > + */
> > > > > + if (!IS_ENABLED(CONFIG_POWERPC) &&
> > > > > + !of_property_read_bool(dev->of_node, "big-endian"))
> > > > > + guts->little_endian = true;
> > > >
> > > > This is not a syscon device (Yangbo's patch to add a guts node on
> > > > ls2080 is the only guts node that says "syscon", and that was a
> > > > leftover from earlier revisions and should probably be removed).
> > > > Even if it were, where is it documented that syscon defaults to
> > > > little-endian?
> > >
> > > Documentation/devicetree/bindings/regmap/regmap.txt
> > >
> > > We had a little screwup here, basically regmap (and by consequence,
> > > syscon) always defaulted to little-endian way before that was
> > > documented, so it's too late to change it,
> >
> > What causes a device node to fall under the jurisdiction of regmap.txt?
> > Again, these nodes do not claim "syscon" compatibility.
> >
> > > although I agree it would have made sense to document regmap to
> > > default to big-endian on powerpc.
> >
> > Please don't. It's enough of a mess as is; no need to start throwing
> > in architecture ifdefs.
> >
> > > > Documentation/devicetree/bindings/common-properties.txt says that
> > > > the individual binding specifies the default. The default for
> > > > this node should be big-endian because that's what existed before
> > > > there was a need to describe the endianness. And we need an
> > > > update to the guts binding to specify that.
> > >
> > > Good point. This proably means that specifying both the "guts" and
> > "syscon"
> > > compatible strings implies having to also specify the endianess
> > > explicitly both ways, because otherwise we break one of the two
> > bindings.
> >
> > Yes, but the node should only specify "guts".
> >
> > >
> > > > > +
> > > > > + guts->regs = devm_ioremap_resource(dev, 0);
> > > > > + if (!guts->regs) {
> > > > > + ret = -ENOMEM;
> > > > > + kfree(guts);
> > > > > + goto out;
> > > > > + }
> > > > > +
> > > > > + fsl_guts_init(dev, guts);
> > > > > + ret = 0;
> > > > > +out:
> > > > > + return ret;
> > > > > +}
> > > > > +
> > > > > +static struct platform_driver fsl_soc_guts = {
> > > > > + .probe = fsl_guts_probe,
> > > > > + .driver.of_match_table = fsl_guts_of_match, };
> > > > > +
> > > > > +module_platform_driver(fsl_soc_guts);
> > > >
> > > > Again, this means that the information is not available during
> > > > early boot, such as in the clock driver. Thus we would not be
> > > > able to convert clk -qoriq's direct mfspr(SPRN_SVR) into an
> > > > soc_device_match() (or anything else that makes use of this file),
> > > > nor would we be able to move its access of the guts RCW registers
> > > > into this driver.
> > >
> > > Correct. Do we have a reason to convert the mfspr() though? I don't
> > > really see an improvement over the current state if we do that,
> >
> > Then should we drop this patchset and put a similar PPC ifdef in
> > drivers/mmc/host/sdhci-of-esdhc.c?
> >
> > There's also the RCW access. You said in the patch 4/4 discussion
> > that you di dn't like any random driver ioremapping the registers...
> >
> > > and for new devices
> > > that might need the erratum workaround, we could add a DT property
> > > that would be preferred to both.
> >
> > It's unlikely that we would know the erratum exists at the time the
> > device tree is created. We also generally don't have separate device
> > trees for each revision of a chip (and if we did, we'd have users that
> > use the wrong one).
> >
> > -Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-07-07 2:35 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-07-07 2:35 UTC (permalink / raw)
To: Scott Wood, Arnd Bergmann, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Ulf Hansson,
Russell King, Bhupesh Sharma, netdev-u79uwXL29TY76Z2rM5mHXA,
Santosh Shilimkar, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Xiaobo Xie,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Rob Herring,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Claudiu Manoil, Kumar Gala,
Yang-Leo Li, linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Hi Arnd,
Could you reply when you see the email?
If your method doesn’t resolve the problem, we still want to use our old patchset.
This guts driver had been discussed about one year and blocked many workaround upstream.
So please help to review and comment soon.
Thanks a lot.
Best regards,
Yangbo Lu
> -----Original Message-----
> From: Yangbo Lu
> Sent: Thursday, June 23, 2016 10:46 AM
> To: 'Scott Wood'; Arnd Bergmann; linuxppc-dev@lists.ozlabs.org
> Cc: Mark Rutland; Ulf Hansson; linux-kernel@vger.kernel.org; linux-
> i2c@vger.kernel.org; linux-clk@vger.kernel.org; Qiang Zhao; Russell King;
> Bhupesh Sharma; Joerg Roedel; Claudiu Manoil; devicetree@vger.kernel.org;
> Kumar Gala; Rob Herring; Santosh Shilimkar; linux-arm-
> kernel@lists.infradead.org; netdev@vger.kernel.org; linux-
> mmc@vger.kernel.org; Xiaobo Xie; Yang-Leo Li; iommu@lists.linux-
> foundation.org
> Subject: RE: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
>
> Hi Arnd,
>
> Could you comment on these?
> Thanks.
>
>
> Best regards,
> Yangbo Lu
>
>
> > -----Original Message-----
> > From: Scott Wood [mailto:oss@buserror.net]
> > Sent: Saturday, June 11, 2016 9:51 AM
> > To: Arnd Bergmann; linuxppc-dev@lists.ozlabs.org
> > Cc: Mark Rutland; Ulf Hansson; linux-kernel@vger.kernel.org; linux-
> > i2c@vger.kernel.org; linux-clk@vger.kernel.org; Qiang Zhao; Russell
> > King; Bhupesh Sharma; Joerg Roedel; Claudiu Manoil;
> > devicetree@vger.kernel.org; Kumar Gala; Rob Herring; Santosh
> > Shilimkar; linux-arm- kernel@lists.infradead.org;
> > netdev@vger.kernel.org; linux- mmc@vger.kernel.org; Xiaobo Xie;
> > Yang-Leo Li; iommu@lists.linux- foundation.org; Yangbo Lu
> > Subject: Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
> >
> > On Thu, 2016-06-02 at 10:43 +0200, Arnd Bergmann wrote:
> > > On Wednesday, June 1, 2016 8:47:22 PM CEST Scott Wood wrote:
> > > > On Mon, 2016-05-30 at 15:15 +0200, Arnd Bergmann wrote:
> > > > > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c new
> > > > > file mode 100644 index 000000000000..2f30698f5bcf
> > > > > --- /dev/null
> > > > > +++ b/drivers/soc/fsl/guts.c
> > > > > @@ -0,0 +1,130 @@
> > > > > +/*
> > > > > + * Freescale QorIQ Platforms GUTS Driver
> > > > > + *
> > > > > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > > > > + *
> > > > > + * This program is free software; you can redistribute it
> > > > > +and/or modify
> > > > > + * it under the terms of the GNU General Public License as
> > > > > +published by
> > > > > + * the Free Software Foundation; either version 2 of the
> > > > > +License, or
> > > > > + * (at your option) any later version.
> > > > > + */
> > > > > +
> > > > > +#include <linux/io.h>
> > > > > +#include <linux/platform_device.h> #include <linux/module.h>
> > > > > +#include <linux/slab.h> #include <linux/of_address.h> #include
> > > > > +<linux/of_platform.h> #include <linux/sys_soc.h>
> > > > > +
> > > > > +#define GUTS_PVR 0x0a0
> > > > > +#define GUTS_SVR 0x0a4
> > > > > +
> > > > > +struct guts {
> > > > > + void __iomem *regs;
> > > >
> > > > We already have a struct to define guts. Why are you not using it?
> > > > Why do you consider using it to be "abuse"? What if we want to
> > > > move more guts functionality into this driver?
> > >
> > > This structure was in the original patch, I left it in there, only
> > > removed the inclusion of the powerpc header file, which seemed to be
> > > misplaced.
> >
> > I'm not refering "struct guts". I'm referring to changing "struct
> > ccsr_guts __iomem *regs" into "void __iomem *regs".
> >
> > And it's not a powerpc header file.
> >
> > > > > +/*
> > > > > + * Table for matching compatible strings, for device tree
> > > > > + * guts node, for Freescale QorIQ SOCs.
> > > > > + */
> > > > > +static const struct of_device_id fsl_guts_of_match[] = {
> > > > > + /* For T4 & B4 Series SOCs */
> > > > > + { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4
> > > > > series" },
> > > > [snip]
> > > > > + { .compatible = "fsl,qoriq-device-config-2.0", .data = "P
> > > > > series"
> > > >
> > > > As noted in my comment on patch 3/4, these descriptions are
> reversed.
> > > >
> > > > They're also incomplete. t2080 has device config 2.0. t1040 is
> > > > described as
> > > > 2.0 though it should probably be 2.1 (or better, drop the generic
> > > > compatible altogether).
> > >
> > > Ok. Ideally I think we'd even look up the specific SoC names from
> > > the SVC rather than the compatible string. I just didn't have a good
> > > list for those to put in the driver.
> >
> > The list is in arch/powerpc/include/asm/mpc85xx.h but I don't know why
> > we need to convert it to a string in the first place.
> >
> > >
> > > > > + /*
> > > > > + * syscon devices default to little-endian, but on powerpc we
> > > > > have
> > > > > + * existing device trees with big-endian maps and an absent
> > > > > endianess
> > > > > + * "big-property"
> > > > > + */
> > > > > + if (!IS_ENABLED(CONFIG_POWERPC) &&
> > > > > + !of_property_read_bool(dev->of_node, "big-endian"))
> > > > > + guts->little_endian = true;
> > > >
> > > > This is not a syscon device (Yangbo's patch to add a guts node on
> > > > ls2080 is the only guts node that says "syscon", and that was a
> > > > leftover from earlier revisions and should probably be removed).
> > > > Even if it were, where is it documented that syscon defaults to
> > > > little-endian?
> > >
> > > Documentation/devicetree/bindings/regmap/regmap.txt
> > >
> > > We had a little screwup here, basically regmap (and by consequence,
> > > syscon) always defaulted to little-endian way before that was
> > > documented, so it's too late to change it,
> >
> > What causes a device node to fall under the jurisdiction of regmap.txt?
> > Again, these nodes do not claim "syscon" compatibility.
> >
> > > although I agree it would have made sense to document regmap to
> > > default to big-endian on powerpc.
> >
> > Please don't. It's enough of a mess as is; no need to start throwing
> > in architecture ifdefs.
> >
> > > > Documentation/devicetree/bindings/common-properties.txt says that
> > > > the individual binding specifies the default. The default for
> > > > this node should be big-endian because that's what existed before
> > > > there was a need to describe the endianness. And we need an
> > > > update to the guts binding to specify that.
> > >
> > > Good point. This proably means that specifying both the "guts" and
> > "syscon"
> > > compatible strings implies having to also specify the endianess
> > > explicitly both ways, because otherwise we break one of the two
> > bindings.
> >
> > Yes, but the node should only specify "guts".
> >
> > >
> > > > > +
> > > > > + guts->regs = devm_ioremap_resource(dev, 0);
> > > > > + if (!guts->regs) {
> > > > > + ret = -ENOMEM;
> > > > > + kfree(guts);
> > > > > + goto out;
> > > > > + }
> > > > > +
> > > > > + fsl_guts_init(dev, guts);
> > > > > + ret = 0;
> > > > > +out:
> > > > > + return ret;
> > > > > +}
> > > > > +
> > > > > +static struct platform_driver fsl_soc_guts = {
> > > > > + .probe = fsl_guts_probe,
> > > > > + .driver.of_match_table = fsl_guts_of_match, };
> > > > > +
> > > > > +module_platform_driver(fsl_soc_guts);
> > > >
> > > > Again, this means that the information is not available during
> > > > early boot, such as in the clock driver. Thus we would not be
> > > > able to convert clk -qoriq's direct mfspr(SPRN_SVR) into an
> > > > soc_device_match() (or anything else that makes use of this file),
> > > > nor would we be able to move its access of the guts RCW registers
> > > > into this driver.
> > >
> > > Correct. Do we have a reason to convert the mfspr() though? I don't
> > > really see an improvement over the current state if we do that,
> >
> > Then should we drop this patchset and put a similar PPC ifdef in
> > drivers/mmc/host/sdhci-of-esdhc.c?
> >
> > There's also the RCW access. You said in the patch 4/4 discussion
> > that you di dn't like any random driver ioremapping the registers...
> >
> > > and for new devices
> > > that might need the erratum workaround, we could add a DT property
> > > that would be preferred to both.
> >
> > It's unlikely that we would know the erratum exists at the time the
> > device tree is created. We also generally don't have separate device
> > trees for each revision of a chip (and if we did, we'd have users that
> > use the wrong one).
> >
> > -Scott
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-07-07 2:35 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-07-07 2:35 UTC (permalink / raw)
To: Scott Wood, Arnd Bergmann, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Ulf Hansson,
Russell King, Bhupesh Sharma, netdev-u79uwXL29TY76Z2rM5mHXA,
Santosh Shilimkar, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Xiaobo Xie,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Rob Herring,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Claudiu Manoil, Kumar Gala,
Yang-Leo Li, linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Hi Arnd,
Could you reply when you see the email?
If your method doesn’t resolve the problem, we still want to use our old patchset.
This guts driver had been discussed about one year and blocked many workaround upstream.
So please help to review and comment soon.
Thanks a lot.
Best regards,
Yangbo Lu
> -----Original Message-----
> From: Yangbo Lu
> Sent: Thursday, June 23, 2016 10:46 AM
> To: 'Scott Wood'; Arnd Bergmann; linuxppc-dev@lists.ozlabs.org
> Cc: Mark Rutland; Ulf Hansson; linux-kernel@vger.kernel.org; linux-
> i2c@vger.kernel.org; linux-clk@vger.kernel.org; Qiang Zhao; Russell King;
> Bhupesh Sharma; Joerg Roedel; Claudiu Manoil; devicetree@vger.kernel.org;
> Kumar Gala; Rob Herring; Santosh Shilimkar; linux-arm-
> kernel@lists.infradead.org; netdev@vger.kernel.org; linux-
> mmc@vger.kernel.org; Xiaobo Xie; Yang-Leo Li; iommu@lists.linux-
> foundation.org
> Subject: RE: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
>
> Hi Arnd,
>
> Could you comment on these?
> Thanks.
>
>
> Best regards,
> Yangbo Lu
>
>
> > -----Original Message-----
> > From: Scott Wood [mailto:oss@buserror.net]
> > Sent: Saturday, June 11, 2016 9:51 AM
> > To: Arnd Bergmann; linuxppc-dev@lists.ozlabs.org
> > Cc: Mark Rutland; Ulf Hansson; linux-kernel@vger.kernel.org; linux-
> > i2c@vger.kernel.org; linux-clk@vger.kernel.org; Qiang Zhao; Russell
> > King; Bhupesh Sharma; Joerg Roedel; Claudiu Manoil;
> > devicetree@vger.kernel.org; Kumar Gala; Rob Herring; Santosh
> > Shilimkar; linux-arm- kernel@lists.infradead.org;
> > netdev@vger.kernel.org; linux- mmc@vger.kernel.org; Xiaobo Xie;
> > Yang-Leo Li; iommu@lists.linux- foundation.org; Yangbo Lu
> > Subject: Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
> >
> > On Thu, 2016-06-02 at 10:43 +0200, Arnd Bergmann wrote:
> > > On Wednesday, June 1, 2016 8:47:22 PM CEST Scott Wood wrote:
> > > > On Mon, 2016-05-30 at 15:15 +0200, Arnd Bergmann wrote:
> > > > > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c new
> > > > > file mode 100644 index 000000000000..2f30698f5bcf
> > > > > --- /dev/null
> > > > > +++ b/drivers/soc/fsl/guts.c
> > > > > @@ -0,0 +1,130 @@
> > > > > +/*
> > > > > + * Freescale QorIQ Platforms GUTS Driver
> > > > > + *
> > > > > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > > > > + *
> > > > > + * This program is free software; you can redistribute it
> > > > > +and/or modify
> > > > > + * it under the terms of the GNU General Public License as
> > > > > +published by
> > > > > + * the Free Software Foundation; either version 2 of the
> > > > > +License, or
> > > > > + * (at your option) any later version.
> > > > > + */
> > > > > +
> > > > > +#include <linux/io.h>
> > > > > +#include <linux/platform_device.h> #include <linux/module.h>
> > > > > +#include <linux/slab.h> #include <linux/of_address.h> #include
> > > > > +<linux/of_platform.h> #include <linux/sys_soc.h>
> > > > > +
> > > > > +#define GUTS_PVR 0x0a0
> > > > > +#define GUTS_SVR 0x0a4
> > > > > +
> > > > > +struct guts {
> > > > > + void __iomem *regs;
> > > >
> > > > We already have a struct to define guts. Why are you not using it?
> > > > Why do you consider using it to be "abuse"? What if we want to
> > > > move more guts functionality into this driver?
> > >
> > > This structure was in the original patch, I left it in there, only
> > > removed the inclusion of the powerpc header file, which seemed to be
> > > misplaced.
> >
> > I'm not refering "struct guts". I'm referring to changing "struct
> > ccsr_guts __iomem *regs" into "void __iomem *regs".
> >
> > And it's not a powerpc header file.
> >
> > > > > +/*
> > > > > + * Table for matching compatible strings, for device tree
> > > > > + * guts node, for Freescale QorIQ SOCs.
> > > > > + */
> > > > > +static const struct of_device_id fsl_guts_of_match[] = {
> > > > > + /* For T4 & B4 Series SOCs */
> > > > > + { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4
> > > > > series" },
> > > > [snip]
> > > > > + { .compatible = "fsl,qoriq-device-config-2.0", .data = "P
> > > > > series"
> > > >
> > > > As noted in my comment on patch 3/4, these descriptions are
> reversed.
> > > >
> > > > They're also incomplete. t2080 has device config 2.0. t1040 is
> > > > described as
> > > > 2.0 though it should probably be 2.1 (or better, drop the generic
> > > > compatible altogether).
> > >
> > > Ok. Ideally I think we'd even look up the specific SoC names from
> > > the SVC rather than the compatible string. I just didn't have a good
> > > list for those to put in the driver.
> >
> > The list is in arch/powerpc/include/asm/mpc85xx.h but I don't know why
> > we need to convert it to a string in the first place.
> >
> > >
> > > > > + /*
> > > > > + * syscon devices default to little-endian, but on powerpc we
> > > > > have
> > > > > + * existing device trees with big-endian maps and an absent
> > > > > endianess
> > > > > + * "big-property"
> > > > > + */
> > > > > + if (!IS_ENABLED(CONFIG_POWERPC) &&
> > > > > + !of_property_read_bool(dev->of_node, "big-endian"))
> > > > > + guts->little_endian = true;
> > > >
> > > > This is not a syscon device (Yangbo's patch to add a guts node on
> > > > ls2080 is the only guts node that says "syscon", and that was a
> > > > leftover from earlier revisions and should probably be removed).
> > > > Even if it were, where is it documented that syscon defaults to
> > > > little-endian?
> > >
> > > Documentation/devicetree/bindings/regmap/regmap.txt
> > >
> > > We had a little screwup here, basically regmap (and by consequence,
> > > syscon) always defaulted to little-endian way before that was
> > > documented, so it's too late to change it,
> >
> > What causes a device node to fall under the jurisdiction of regmap.txt?
> > Again, these nodes do not claim "syscon" compatibility.
> >
> > > although I agree it would have made sense to document regmap to
> > > default to big-endian on powerpc.
> >
> > Please don't. It's enough of a mess as is; no need to start throwing
> > in architecture ifdefs.
> >
> > > > Documentation/devicetree/bindings/common-properties.txt says that
> > > > the individual binding specifies the default. The default for
> > > > this node should be big-endian because that's what existed before
> > > > there was a need to describe the endianness. And we need an
> > > > update to the guts binding to specify that.
> > >
> > > Good point. This proably means that specifying both the "guts" and
> > "syscon"
> > > compatible strings implies having to also specify the endianess
> > > explicitly both ways, because otherwise we break one of the two
> > bindings.
> >
> > Yes, but the node should only specify "guts".
> >
> > >
> > > > > +
> > > > > + guts->regs = devm_ioremap_resource(dev, 0);
> > > > > + if (!guts->regs) {
> > > > > + ret = -ENOMEM;
> > > > > + kfree(guts);
> > > > > + goto out;
> > > > > + }
> > > > > +
> > > > > + fsl_guts_init(dev, guts);
> > > > > + ret = 0;
> > > > > +out:
> > > > > + return ret;
> > > > > +}
> > > > > +
> > > > > +static struct platform_driver fsl_soc_guts = {
> > > > > + .probe = fsl_guts_probe,
> > > > > + .driver.of_match_table = fsl_guts_of_match, };
> > > > > +
> > > > > +module_platform_driver(fsl_soc_guts);
> > > >
> > > > Again, this means that the information is not available during
> > > > early boot, such as in the clock driver. Thus we would not be
> > > > able to convert clk -qoriq's direct mfspr(SPRN_SVR) into an
> > > > soc_device_match() (or anything else that makes use of this file),
> > > > nor would we be able to move its access of the guts RCW registers
> > > > into this driver.
> > >
> > > Correct. Do we have a reason to convert the mfspr() though? I don't
> > > really see an improvement over the current state if we do that,
> >
> > Then should we drop this patchset and put a similar PPC ifdef in
> > drivers/mmc/host/sdhci-of-esdhc.c?
> >
> > There's also the RCW access. You said in the patch 4/4 discussion
> > that you di dn't like any random driver ioremapping the registers...
> >
> > > and for new devices
> > > that might need the erratum workaround, we could add a DT property
> > > that would be preferred to both.
> >
> > It's unlikely that we would know the erratum exists at the time the
> > device tree is created. We also generally don't have separate device
> > trees for each revision of a chip (and if we did, we'd have users that
> > use the wrong one).
> >
> > -Scott
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-07-07 2:35 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-07-07 2:35 UTC (permalink / raw)
To: Scott Wood, Arnd Bergmann, linuxppc-dev
Cc: Mark Rutland, devicetree, Ulf Hansson, Russell King,
Bhupesh Sharma, netdev, Joerg Roedel, Santosh Shilimkar,
linux-mmc, linux-kernel, Xiaobo Xie, iommu, Rob Herring,
linux-i2c, Claudiu Manoil, Kumar Gala, Yang-Leo Li, linux-clk,
linux-arm-kernel, Qiang Zhao
SGkgQXJuZCwNCg0KQ291bGQgeW91IHJlcGx5IHdoZW4geW91IHNlZSB0aGUgZW1haWw/DQpJZiB5
b3VyIG1ldGhvZCBkb2VzbuKAmXQgcmVzb2x2ZSB0aGUgcHJvYmxlbSwgd2Ugc3RpbGwgd2FudCB0
byB1c2Ugb3VyIG9sZCBwYXRjaHNldC4NCg0KVGhpcyBndXRzIGRyaXZlciBoYWQgYmVlbiBkaXNj
dXNzZWQgYWJvdXQgb25lIHllYXIgYW5kIGJsb2NrZWQgbWFueSB3b3JrYXJvdW5kIHVwc3RyZWFt
Lg0KU28gcGxlYXNlIGhlbHAgdG8gcmV2aWV3IGFuZCBjb21tZW50IHNvb24uDQoNClRoYW5rcyBh
IGxvdC4NCg0KDQpCZXN0IHJlZ2FyZHMsDQpZYW5nYm8gTHUNCg0KPiAtLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KPiBGcm9tOiBZYW5nYm8gTHUNCj4gU2VudDogVGh1cnNkYXksIEp1bmUgMjMs
IDIwMTYgMTA6NDYgQU0NCj4gVG86ICdTY290dCBXb29kJzsgQXJuZCBCZXJnbWFubjsgbGludXhw
cGMtZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gQ2M6IE1hcmsgUnV0bGFuZDsgVWxmIEhhbnNzb247
IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LQ0KPiBpMmNAdmdlci5rZXJuZWwu
b3JnOyBsaW51eC1jbGtAdmdlci5rZXJuZWwub3JnOyBRaWFuZyBaaGFvOyBSdXNzZWxsIEtpbmc7
DQo+IEJodXBlc2ggU2hhcm1hOyBKb2VyZyBSb2VkZWw7IENsYXVkaXUgTWFub2lsOyBkZXZpY2V0
cmVlQHZnZXIua2VybmVsLm9yZzsNCj4gS3VtYXIgR2FsYTsgUm9iIEhlcnJpbmc7IFNhbnRvc2gg
U2hpbGlta2FyOyBsaW51eC1hcm0tDQo+IGtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnOyBuZXRk
ZXZAdmdlci5rZXJuZWwub3JnOyBsaW51eC0NCj4gbW1jQHZnZXIua2VybmVsLm9yZzsgWGlhb2Jv
IFhpZTsgWWFuZy1MZW8gTGk7IGlvbW11QGxpc3RzLmxpbnV4LQ0KPiBmb3VuZGF0aW9uLm9yZw0K
PiBTdWJqZWN0OiBSRTogW1BBVENIIDIvNF0gc29jOiBmc2w6IGFkZCBHVVRTIGRyaXZlciBmb3Ig
UW9ySVEgcGxhdGZvcm1zDQo+IA0KPiBIaSBBcm5kLA0KPiANCj4gQ291bGQgeW91IGNvbW1lbnQg
b24gdGhlc2U/DQo+IFRoYW5rcy4NCj4gDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IFlhbmdibyBM
dQ0KPiANCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBTY290
dCBXb29kIFttYWlsdG86b3NzQGJ1c2Vycm9yLm5ldF0NCj4gPiBTZW50OiBTYXR1cmRheSwgSnVu
ZSAxMSwgMjAxNiA5OjUxIEFNDQo+ID4gVG86IEFybmQgQmVyZ21hbm47IGxpbnV4cHBjLWRldkBs
aXN0cy5vemxhYnMub3JnDQo+ID4gQ2M6IE1hcmsgUnV0bGFuZDsgVWxmIEhhbnNzb247IGxpbnV4
LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LQ0KPiA+IGkyY0B2Z2VyLmtlcm5lbC5vcmc7
IGxpbnV4LWNsa0B2Z2VyLmtlcm5lbC5vcmc7IFFpYW5nIFpoYW87IFJ1c3NlbGwNCj4gPiBLaW5n
OyBCaHVwZXNoIFNoYXJtYTsgSm9lcmcgUm9lZGVsOyBDbGF1ZGl1IE1hbm9pbDsNCj4gPiBkZXZp
Y2V0cmVlQHZnZXIua2VybmVsLm9yZzsgS3VtYXIgR2FsYTsgUm9iIEhlcnJpbmc7IFNhbnRvc2gN
Cj4gPiBTaGlsaW1rYXI7IGxpbnV4LWFybS0ga2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmc7DQo+
ID4gbmV0ZGV2QHZnZXIua2VybmVsLm9yZzsgbGludXgtIG1tY0B2Z2VyLmtlcm5lbC5vcmc7IFhp
YW9ibyBYaWU7DQo+ID4gWWFuZy1MZW8gTGk7IGlvbW11QGxpc3RzLmxpbnV4LSBmb3VuZGF0aW9u
Lm9yZzsgWWFuZ2JvIEx1DQo+ID4gU3ViamVjdDogUmU6IFtQQVRDSCAyLzRdIHNvYzogZnNsOiBh
ZGQgR1VUUyBkcml2ZXIgZm9yIFFvcklRIHBsYXRmb3Jtcw0KPiA+DQo+ID4gT24gVGh1LCAyMDE2
LTA2LTAyIGF0IDEwOjQzICswMjAwLCBBcm5kIEJlcmdtYW5uIHdyb3RlOg0KPiA+ID4gT24gV2Vk
bmVzZGF5LCBKdW5lIDEsIDIwMTYgODo0NzoyMiBQTSBDRVNUIFNjb3R0IFdvb2Qgd3JvdGU6DQo+
ID4gPiA+IE9uIE1vbiwgMjAxNi0wNS0zMCBhdCAxNToxNSArMDIwMCwgQXJuZCBCZXJnbWFubiB3
cm90ZToNCj4gPiA+ID4gPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9zb2MvZnNsL2d1dHMuYyBiL2Ry
aXZlcnMvc29jL2ZzbC9ndXRzLmMgbmV3DQo+ID4gPiA+ID4gZmlsZSBtb2RlIDEwMDY0NCBpbmRl
eCAwMDAwMDAwMDAwMDAuLjJmMzA2OThmNWJjZg0KPiA+ID4gPiA+IC0tLSAvZGV2L251bGwNCj4g
PiA+ID4gPiArKysgYi9kcml2ZXJzL3NvYy9mc2wvZ3V0cy5jDQo+ID4gPiA+ID4gQEAgLTAsMCAr
MSwxMzAgQEANCj4gPiA+ID4gPiArLyoNCj4gPiA+ID4gPiArICogRnJlZXNjYWxlIFFvcklRIFBs
YXRmb3JtcyBHVVRTIERyaXZlcg0KPiA+ID4gPiA+ICsgKg0KPiA+ID4gPiA+ICsgKiBDb3B5cmln
aHQgKEMpIDIwMTYgRnJlZXNjYWxlIFNlbWljb25kdWN0b3IsIEluYy4NCj4gPiA+ID4gPiArICoN
Cj4gPiA+ID4gPiArICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVk
aXN0cmlidXRlIGl0DQo+ID4gPiA+ID4gK2FuZC9vciBtb2RpZnkNCj4gPiA+ID4gPiArICogaXQg
dW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcw0KPiA+
ID4gPiA+ICtwdWJsaXNoZWQgYnkNCj4gPiA+ID4gPiArICogdGhlIEZyZWUgU29mdHdhcmUgRm91
bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMiBvZiB0aGUNCj4gPiA+ID4gPiArTGljZW5zZSwgb3IN
Cj4gPiA+ID4gPiArICogKGF0IHlvdXIgb3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4NCj4gPiA+
ID4gPiArICovDQo+ID4gPiA+ID4gKw0KPiA+ID4gPiA+ICsjaW5jbHVkZSA8bGludXgvaW8uaD4N
Cj4gPiA+ID4gPiArI2luY2x1ZGUgPGxpbnV4L3BsYXRmb3JtX2RldmljZS5oPiAjaW5jbHVkZSA8
bGludXgvbW9kdWxlLmg+DQo+ID4gPiA+ID4gKyNpbmNsdWRlIDxsaW51eC9zbGFiLmg+ICNpbmNs
dWRlIDxsaW51eC9vZl9hZGRyZXNzLmg+ICNpbmNsdWRlDQo+ID4gPiA+ID4gKzxsaW51eC9vZl9w
bGF0Zm9ybS5oPiAjaW5jbHVkZSA8bGludXgvc3lzX3NvYy5oPg0KPiA+ID4gPiA+ICsNCj4gPiA+
ID4gPiArI2RlZmluZSBHVVRTX1BWUgkweDBhMA0KPiA+ID4gPiA+ICsjZGVmaW5lIEdVVFNfU1ZS
CTB4MGE0DQo+ID4gPiA+ID4gKw0KPiA+ID4gPiA+ICtzdHJ1Y3QgZ3V0cyB7DQo+ID4gPiA+ID4g
Kwl2b2lkIF9faW9tZW0gKnJlZ3M7DQo+ID4gPiA+DQo+ID4gPiA+IFdlIGFscmVhZHkgaGF2ZSBh
IHN0cnVjdCB0byBkZWZpbmUgZ3V0cy4gIFdoeSBhcmUgeW91IG5vdCB1c2luZyBpdD8NCj4gPiA+
ID4gV2h5IGRvIHlvdSBjb25zaWRlciB1c2luZyBpdCB0byBiZSAiYWJ1c2UiPyAgV2hhdCBpZiB3
ZSB3YW50IHRvDQo+ID4gPiA+IG1vdmUgbW9yZSBndXRzIGZ1bmN0aW9uYWxpdHkgaW50byB0aGlz
IGRyaXZlcj8NCj4gPiA+DQo+ID4gPiBUaGlzIHN0cnVjdHVyZSB3YXMgaW4gdGhlIG9yaWdpbmFs
IHBhdGNoLCBJIGxlZnQgaXQgaW4gdGhlcmUsIG9ubHkNCj4gPiA+IHJlbW92ZWQgdGhlIGluY2x1
c2lvbiBvZiB0aGUgcG93ZXJwYyBoZWFkZXIgZmlsZSwgd2hpY2ggc2VlbWVkIHRvIGJlDQo+ID4g
PiBtaXNwbGFjZWQuDQo+ID4NCj4gPiBJJ20gbm90IHJlZmVyaW5nICJzdHJ1Y3QgZ3V0cyIuICBJ
J20gcmVmZXJyaW5nIHRvIGNoYW5naW5nICJzdHJ1Y3QNCj4gPiBjY3NyX2d1dHMgX19pb21lbSAq
cmVncyIgaW50byAidm9pZCBfX2lvbWVtICpyZWdzIi4NCj4gPg0KPiA+IEFuZCBpdCdzIG5vdCBh
IHBvd2VycGMgaGVhZGVyIGZpbGUuDQo+ID4NCj4gPiA+ID4gPiArLyoNCj4gPiA+ID4gPiArICog
VGFibGUgZm9yIG1hdGNoaW5nIGNvbXBhdGlibGUgc3RyaW5ncywgZm9yIGRldmljZSB0cmVlDQo+
ID4gPiA+ID4gKyAqIGd1dHMgbm9kZSwgZm9yIEZyZWVzY2FsZSBRb3JJUSBTT0NzLg0KPiA+ID4g
PiA+ICsgKi8NCj4gPiA+ID4gPiArc3RhdGljIGNvbnN0IHN0cnVjdCBvZl9kZXZpY2VfaWQgZnNs
X2d1dHNfb2ZfbWF0Y2hbXSA9IHsNCj4gPiA+ID4gPiArCS8qIEZvciBUNCAmIEI0IFNlcmllcyBT
T0NzICovDQo+ID4gPiA+ID4gKwl7IC5jb21wYXRpYmxlID0gImZzbCxxb3JpcS1kZXZpY2UtY29u
ZmlnLTEuMCIsIC5kYXRhID0gIlQ0L0I0DQo+ID4gPiA+ID4gc2VyaWVzIiB9LA0KPiA+ID4gPiBb
c25pcF0NCj4gPiA+ID4gPiArCXsgLmNvbXBhdGlibGUgPSAiZnNsLHFvcmlxLWRldmljZS1jb25m
aWctMi4wIiwgLmRhdGEgPSAiUA0KPiA+ID4gPiA+IHNlcmllcyINCj4gPiA+ID4NCj4gPiA+ID4g
QXMgbm90ZWQgaW4gbXkgY29tbWVudCBvbiBwYXRjaCAzLzQsIHRoZXNlIGRlc2NyaXB0aW9ucyBh
cmUNCj4gcmV2ZXJzZWQuDQo+ID4gPiA+DQo+ID4gPiA+IFRoZXkncmUgYWxzbyBpbmNvbXBsZXRl
LiAgdDIwODAgaGFzIGRldmljZSBjb25maWcgMi4wLiAgdDEwNDAgaXMNCj4gPiA+ID4gZGVzY3Jp
YmVkIGFzDQo+ID4gPiA+IDIuMCB0aG91Z2ggaXQgc2hvdWxkIHByb2JhYmx5IGJlIDIuMSAob3Ig
YmV0dGVyLCBkcm9wIHRoZSBnZW5lcmljDQo+ID4gPiA+IGNvbXBhdGlibGUgYWx0b2dldGhlciku
DQo+ID4gPg0KPiA+ID4gT2suIElkZWFsbHkgSSB0aGluayB3ZSdkIGV2ZW4gbG9vayB1cCB0aGUg
c3BlY2lmaWMgU29DIG5hbWVzIGZyb20NCj4gPiA+IHRoZSBTVkMgcmF0aGVyIHRoYW4gdGhlIGNv
bXBhdGlibGUgc3RyaW5nLiBJIGp1c3QgZGlkbid0IGhhdmUgYSBnb29kDQo+ID4gPiBsaXN0IGZv
ciB0aG9zZSB0byBwdXQgaW4gdGhlIGRyaXZlci4NCj4gPg0KPiA+IFRoZSBsaXN0IGlzIGluIGFy
Y2gvcG93ZXJwYy9pbmNsdWRlL2FzbS9tcGM4NXh4LmggYnV0IEkgZG9uJ3Qga25vdyB3aHkNCj4g
PiB3ZSBuZWVkIHRvIGNvbnZlcnQgaXQgdG8gYSBzdHJpbmcgaW4gdGhlIGZpcnN0IHBsYWNlLg0K
PiA+DQo+ID4gPg0KPiA+ID4gPiA+ICsJLyoNCj4gPiA+ID4gPiArCSAqIHN5c2NvbiBkZXZpY2Vz
IGRlZmF1bHQgdG8gbGl0dGxlLWVuZGlhbiwgYnV0IG9uIHBvd2VycGMgd2UNCj4gPiA+ID4gPiBo
YXZlDQo+ID4gPiA+ID4gKwkgKiBleGlzdGluZyBkZXZpY2UgdHJlZXMgd2l0aCBiaWctZW5kaWFu
IG1hcHMgYW5kIGFuIGFic2VudA0KPiA+ID4gPiA+IGVuZGlhbmVzcw0KPiA+ID4gPiA+ICsJICog
ImJpZy1wcm9wZXJ0eSINCj4gPiA+ID4gPiArCSAqLw0KPiA+ID4gPiA+ICsJaWYgKCFJU19FTkFC
TEVEKENPTkZJR19QT1dFUlBDKSAmJg0KPiA+ID4gPiA+ICsJICAgICFvZl9wcm9wZXJ0eV9yZWFk
X2Jvb2woZGV2LT5vZl9ub2RlLCAiYmlnLWVuZGlhbiIpKQ0KPiA+ID4gPiA+ICsJCWd1dHMtPmxp
dHRsZV9lbmRpYW4gPSB0cnVlOw0KPiA+ID4gPg0KPiA+ID4gPiBUaGlzIGlzIG5vdCBhIHN5c2Nv
biBkZXZpY2UgKFlhbmdibydzIHBhdGNoIHRvIGFkZCBhIGd1dHMgbm9kZSBvbg0KPiA+ID4gPiBs
czIwODAgaXMgdGhlIG9ubHkgZ3V0cyBub2RlIHRoYXQgc2F5cyAic3lzY29uIiwgYW5kIHRoYXQg
d2FzIGENCj4gPiA+ID4gbGVmdG92ZXIgZnJvbSBlYXJsaWVyIHJldmlzaW9ucyBhbmQgc2hvdWxk
IHByb2JhYmx5IGJlIHJlbW92ZWQpLg0KPiA+ID4gPiBFdmVuIGlmIGl0IHdlcmUsIHdoZXJlIGlz
IGl0IGRvY3VtZW50ZWQgdGhhdCBzeXNjb24gZGVmYXVsdHMgdG8NCj4gPiA+ID4gbGl0dGxlLWVu
ZGlhbj8NCj4gPiA+DQo+ID4gPiBEb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvcmVn
bWFwL3JlZ21hcC50eHQNCj4gPiA+DQo+ID4gPiBXZSBoYWQgYSBsaXR0bGUgc2NyZXd1cCBoZXJl
LCBiYXNpY2FsbHkgcmVnbWFwIChhbmQgYnkgY29uc2VxdWVuY2UsDQo+ID4gPiBzeXNjb24pIGFs
d2F5cyBkZWZhdWx0ZWQgdG8gbGl0dGxlLWVuZGlhbiB3YXkgYmVmb3JlIHRoYXQgd2FzDQo+ID4g
PiBkb2N1bWVudGVkLCBzbyBpdCdzIHRvbyBsYXRlIHRvIGNoYW5nZSBpdCwNCj4gPg0KPiA+IFdo
YXQgY2F1c2VzIGEgZGV2aWNlIG5vZGUgdG8gZmFsbCB1bmRlciB0aGUganVyaXNkaWN0aW9uIG9m
IHJlZ21hcC50eHQ/DQo+ID4gIEFnYWluLCB0aGVzZSBub2RlcyBkbyBub3QgY2xhaW0gInN5c2Nv
biIgY29tcGF0aWJpbGl0eS4NCj4gPg0KPiA+ID4gYWx0aG91Z2ggSSBhZ3JlZSBpdCB3b3VsZCBo
YXZlIG1hZGUgc2Vuc2UgdG8gZG9jdW1lbnQgcmVnbWFwIHRvDQo+ID4gPiBkZWZhdWx0IHRvIGJp
Zy1lbmRpYW4gb24gcG93ZXJwYy4NCj4gPg0KPiA+IFBsZWFzZSBkb24ndC4gIEl0J3MgZW5vdWdo
IG9mIGEgbWVzcyBhcyBpczsgbm8gbmVlZCB0byBzdGFydCB0aHJvd2luZw0KPiA+IGluIGFyY2hp
dGVjdHVyZSBpZmRlZnMuDQo+ID4NCj4gPiA+ID4gRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2Jp
bmRpbmdzL2NvbW1vbi1wcm9wZXJ0aWVzLnR4dCBzYXlzIHRoYXQNCj4gPiA+ID4gdGhlIGluZGl2
aWR1YWwgYmluZGluZyBzcGVjaWZpZXMgdGhlIGRlZmF1bHQuICBUaGUgZGVmYXVsdCBmb3INCj4g
PiA+ID4gdGhpcyBub2RlIHNob3VsZCBiZSBiaWctZW5kaWFuIGJlY2F1c2UgdGhhdCdzIHdoYXQg
ZXhpc3RlZCBiZWZvcmUNCj4gPiA+ID4gdGhlcmUgd2FzIGEgbmVlZCB0byBkZXNjcmliZSB0aGUg
ZW5kaWFubmVzcy4gIEFuZCB3ZSBuZWVkIGFuDQo+ID4gPiA+IHVwZGF0ZSB0byB0aGUgZ3V0cyBi
aW5kaW5nIHRvIHNwZWNpZnkgdGhhdC4NCj4gPiA+DQo+ID4gPiBHb29kIHBvaW50LiBUaGlzIHBy
b2FibHkgbWVhbnMgdGhhdCBzcGVjaWZ5aW5nIGJvdGggdGhlICJndXRzIiBhbmQNCj4gPiAic3lz
Y29uIg0KPiA+ID4gY29tcGF0aWJsZSBzdHJpbmdzIGltcGxpZXMgaGF2aW5nIHRvIGFsc28gc3Bl
Y2lmeSB0aGUgZW5kaWFuZXNzDQo+ID4gPiBleHBsaWNpdGx5IGJvdGggd2F5cywgYmVjYXVzZSBv
dGhlcndpc2Ugd2UgYnJlYWsgb25lIG9mIHRoZSB0d28NCj4gPiBiaW5kaW5ncy4NCj4gPg0KPiA+
IFllcywgYnV0IHRoZSBub2RlIHNob3VsZCBvbmx5IHNwZWNpZnkgImd1dHMiLg0KPiA+DQo+ID4g
Pg0KPiA+ID4gPiA+ICsNCj4gPiA+ID4gPiArCWd1dHMtPnJlZ3MgPSBkZXZtX2lvcmVtYXBfcmVz
b3VyY2UoZGV2LCAwKTsNCj4gPiA+ID4gPiArCWlmICghZ3V0cy0+cmVncykgew0KPiA+ID4gPiA+
ICsJCXJldCA9IC1FTk9NRU07DQo+ID4gPiA+ID4gKwkJa2ZyZWUoZ3V0cyk7DQo+ID4gPiA+ID4g
KwkJZ290byBvdXQ7DQo+ID4gPiA+ID4gKwl9DQo+ID4gPiA+ID4gKw0KPiA+ID4gPiA+ICsJZnNs
X2d1dHNfaW5pdChkZXYsIGd1dHMpOw0KPiA+ID4gPiA+ICsJcmV0ID0gMDsNCj4gPiA+ID4gPiAr
b3V0Og0KPiA+ID4gPiA+ICsJcmV0dXJuIHJldDsNCj4gPiA+ID4gPiArfQ0KPiA+ID4gPiA+ICsN
Cj4gPiA+ID4gPiArc3RhdGljIHN0cnVjdCBwbGF0Zm9ybV9kcml2ZXIgZnNsX3NvY19ndXRzID0g
ew0KPiA+ID4gPiA+ICsJLnByb2JlID0gZnNsX2d1dHNfcHJvYmUsDQo+ID4gPiA+ID4gKwkuZHJp
dmVyLm9mX21hdGNoX3RhYmxlID0gZnNsX2d1dHNfb2ZfbWF0Y2gsIH07DQo+ID4gPiA+ID4gKw0K
PiA+ID4gPiA+ICttb2R1bGVfcGxhdGZvcm1fZHJpdmVyKGZzbF9zb2NfZ3V0cyk7DQo+ID4gPiA+
DQo+ID4gPiA+IEFnYWluLCB0aGlzIG1lYW5zIHRoYXQgdGhlIGluZm9ybWF0aW9uIGlzIG5vdCBh
dmFpbGFibGUgZHVyaW5nDQo+ID4gPiA+IGVhcmx5IGJvb3QsIHN1Y2ggYXMgaW4gdGhlIGNsb2Nr
IGRyaXZlci4gIFRodXMgd2Ugd291bGQgbm90IGJlDQo+ID4gPiA+IGFibGUgdG8gY29udmVydCBj
bGsgLXFvcmlxJ3MgZGlyZWN0IG1mc3ByKFNQUk5fU1ZSKSBpbnRvIGFuDQo+ID4gPiA+IHNvY19k
ZXZpY2VfbWF0Y2goKSAob3IgYW55dGhpbmcgZWxzZSB0aGF0IG1ha2VzIHVzZSBvZiB0aGlzIGZp
bGUpLA0KPiA+ID4gPiBub3Igd291bGQgd2UgYmUgYWJsZSB0byBtb3ZlIGl0cyBhY2Nlc3Mgb2Yg
dGhlIGd1dHMgUkNXIHJlZ2lzdGVycw0KPiA+ID4gPiBpbnRvIHRoaXMgZHJpdmVyLg0KPiA+ID4N
Cj4gPiA+IENvcnJlY3QuIERvIHdlIGhhdmUgYSByZWFzb24gdG8gY29udmVydCB0aGUgbWZzcHIo
KSB0aG91Z2g/IEkgZG9uJ3QNCj4gPiA+IHJlYWxseSBzZWUgYW4gaW1wcm92ZW1lbnQgb3ZlciB0
aGUgY3VycmVudCBzdGF0ZSBpZiB3ZSBkbyB0aGF0LA0KPiA+DQo+ID4gVGhlbiBzaG91bGQgd2Ug
ZHJvcCB0aGlzIHBhdGNoc2V0IGFuZCBwdXQgYSBzaW1pbGFyIFBQQyBpZmRlZiBpbg0KPiA+IGRy
aXZlcnMvbW1jL2hvc3Qvc2RoY2ktb2YtZXNkaGMuYz8NCj4gPg0KPiA+IFRoZXJlJ3MgYWxzbyB0
aGUgUkNXIGFjY2Vzcy4gIFlvdSBzYWlkIGluIHRoZSBwYXRjaCA0LzQgZGlzY3Vzc2lvbg0KPiA+
IHRoYXQgeW91IGRpIGRuJ3QgbGlrZSBhbnkgcmFuZG9tIGRyaXZlciBpb3JlbWFwcGluZyB0aGUg
cmVnaXN0ZXJzLi4uDQo+ID4NCj4gPiA+IGFuZCBmb3IgbmV3IGRldmljZXMNCj4gPiA+IHRoYXQg
bWlnaHQgbmVlZCB0aGUgZXJyYXR1bSB3b3JrYXJvdW5kLCB3ZSBjb3VsZCBhZGQgYSBEVCBwcm9w
ZXJ0eQ0KPiA+ID4gdGhhdCB3b3VsZCBiZSBwcmVmZXJyZWQgdG8gYm90aC4NCj4gPg0KPiA+IEl0
J3MgdW5saWtlbHkgdGhhdCB3ZSB3b3VsZCBrbm93IHRoZSBlcnJhdHVtIGV4aXN0cyBhdCB0aGUg
dGltZSB0aGUNCj4gPiBkZXZpY2UgdHJlZSBpcyBjcmVhdGVkLiAgV2UgYWxzbyBnZW5lcmFsbHkg
ZG9uJ3QgaGF2ZSBzZXBhcmF0ZSBkZXZpY2UNCj4gPiB0cmVlcyBmb3IgZWFjaCByZXZpc2lvbiBv
ZiBhIGNoaXAgKGFuZCBpZiB3ZSBkaWQsIHdlJ2QgaGF2ZSB1c2VycyB0aGF0DQo+ID4gdXNlIHRo
ZSB3cm9uZyBvbmUpLg0KPiA+DQo+ID4gLVNjb3R0DQoNCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBsaXN0Cmxp
bnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFk
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-07-07 2:35 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-07-07 2:35 UTC (permalink / raw)
To: Scott Wood, Arnd Bergmann, linuxppc-dev
Cc: Mark Rutland, Ulf Hansson, linux-kernel, linux-i2c, linux-clk,
Qiang Zhao, Russell King, Bhupesh Sharma, Joerg Roedel,
Claudiu Manoil, devicetree, Kumar Gala, Rob Herring,
Santosh Shilimkar, linux-arm-kernel, netdev, linux-mmc,
Xiaobo Xie, Yang-Leo Li, iommu
SGkgQXJuZCwNCg0KQ291bGQgeW91IHJlcGx5IHdoZW4geW91IHNlZSB0aGUgZW1haWw/DQpJZiB5
b3VyIG1ldGhvZCBkb2VzbuKAmXQgcmVzb2x2ZSB0aGUgcHJvYmxlbSwgd2Ugc3RpbGwgd2FudCB0
byB1c2Ugb3VyIG9sZCBwYXRjaHNldC4NCg0KVGhpcyBndXRzIGRyaXZlciBoYWQgYmVlbiBkaXNj
dXNzZWQgYWJvdXQgb25lIHllYXIgYW5kIGJsb2NrZWQgbWFueSB3b3JrYXJvdW5kIHVwc3RyZWFt
Lg0KU28gcGxlYXNlIGhlbHAgdG8gcmV2aWV3IGFuZCBjb21tZW50IHNvb24uDQoNClRoYW5rcyBh
IGxvdC4NCg0KDQpCZXN0IHJlZ2FyZHMsDQpZYW5nYm8gTHUNCg0KPiAtLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KPiBGcm9tOiBZYW5nYm8gTHUNCj4gU2VudDogVGh1cnNkYXksIEp1bmUgMjMs
IDIwMTYgMTA6NDYgQU0NCj4gVG86ICdTY290dCBXb29kJzsgQXJuZCBCZXJnbWFubjsgbGludXhw
cGMtZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gQ2M6IE1hcmsgUnV0bGFuZDsgVWxmIEhhbnNzb247
IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LQ0KPiBpMmNAdmdlci5rZXJuZWwu
b3JnOyBsaW51eC1jbGtAdmdlci5rZXJuZWwub3JnOyBRaWFuZyBaaGFvOyBSdXNzZWxsIEtpbmc7
DQo+IEJodXBlc2ggU2hhcm1hOyBKb2VyZyBSb2VkZWw7IENsYXVkaXUgTWFub2lsOyBkZXZpY2V0
cmVlQHZnZXIua2VybmVsLm9yZzsNCj4gS3VtYXIgR2FsYTsgUm9iIEhlcnJpbmc7IFNhbnRvc2gg
U2hpbGlta2FyOyBsaW51eC1hcm0tDQo+IGtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnOyBuZXRk
ZXZAdmdlci5rZXJuZWwub3JnOyBsaW51eC0NCj4gbW1jQHZnZXIua2VybmVsLm9yZzsgWGlhb2Jv
IFhpZTsgWWFuZy1MZW8gTGk7IGlvbW11QGxpc3RzLmxpbnV4LQ0KPiBmb3VuZGF0aW9uLm9yZw0K
PiBTdWJqZWN0OiBSRTogW1BBVENIIDIvNF0gc29jOiBmc2w6IGFkZCBHVVRTIGRyaXZlciBmb3Ig
UW9ySVEgcGxhdGZvcm1zDQo+IA0KPiBIaSBBcm5kLA0KPiANCj4gQ291bGQgeW91IGNvbW1lbnQg
b24gdGhlc2U/DQo+IFRoYW5rcy4NCj4gDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IFlhbmdibyBM
dQ0KPiANCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBTY290
dCBXb29kIFttYWlsdG86b3NzQGJ1c2Vycm9yLm5ldF0NCj4gPiBTZW50OiBTYXR1cmRheSwgSnVu
ZSAxMSwgMjAxNiA5OjUxIEFNDQo+ID4gVG86IEFybmQgQmVyZ21hbm47IGxpbnV4cHBjLWRldkBs
aXN0cy5vemxhYnMub3JnDQo+ID4gQ2M6IE1hcmsgUnV0bGFuZDsgVWxmIEhhbnNzb247IGxpbnV4
LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LQ0KPiA+IGkyY0B2Z2VyLmtlcm5lbC5vcmc7
IGxpbnV4LWNsa0B2Z2VyLmtlcm5lbC5vcmc7IFFpYW5nIFpoYW87IFJ1c3NlbGwNCj4gPiBLaW5n
OyBCaHVwZXNoIFNoYXJtYTsgSm9lcmcgUm9lZGVsOyBDbGF1ZGl1IE1hbm9pbDsNCj4gPiBkZXZp
Y2V0cmVlQHZnZXIua2VybmVsLm9yZzsgS3VtYXIgR2FsYTsgUm9iIEhlcnJpbmc7IFNhbnRvc2gN
Cj4gPiBTaGlsaW1rYXI7IGxpbnV4LWFybS0ga2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmc7DQo+
ID4gbmV0ZGV2QHZnZXIua2VybmVsLm9yZzsgbGludXgtIG1tY0B2Z2VyLmtlcm5lbC5vcmc7IFhp
YW9ibyBYaWU7DQo+ID4gWWFuZy1MZW8gTGk7IGlvbW11QGxpc3RzLmxpbnV4LSBmb3VuZGF0aW9u
Lm9yZzsgWWFuZ2JvIEx1DQo+ID4gU3ViamVjdDogUmU6IFtQQVRDSCAyLzRdIHNvYzogZnNsOiBh
ZGQgR1VUUyBkcml2ZXIgZm9yIFFvcklRIHBsYXRmb3Jtcw0KPiA+DQo+ID4gT24gVGh1LCAyMDE2
LTA2LTAyIGF0IDEwOjQzICswMjAwLCBBcm5kIEJlcmdtYW5uIHdyb3RlOg0KPiA+ID4gT24gV2Vk
bmVzZGF5LCBKdW5lIDEsIDIwMTYgODo0NzoyMiBQTSBDRVNUIFNjb3R0IFdvb2Qgd3JvdGU6DQo+
ID4gPiA+IE9uIE1vbiwgMjAxNi0wNS0zMCBhdCAxNToxNSArMDIwMCwgQXJuZCBCZXJnbWFubiB3
cm90ZToNCj4gPiA+ID4gPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9zb2MvZnNsL2d1dHMuYyBiL2Ry
aXZlcnMvc29jL2ZzbC9ndXRzLmMgbmV3DQo+ID4gPiA+ID4gZmlsZSBtb2RlIDEwMDY0NCBpbmRl
eCAwMDAwMDAwMDAwMDAuLjJmMzA2OThmNWJjZg0KPiA+ID4gPiA+IC0tLSAvZGV2L251bGwNCj4g
PiA+ID4gPiArKysgYi9kcml2ZXJzL3NvYy9mc2wvZ3V0cy5jDQo+ID4gPiA+ID4gQEAgLTAsMCAr
MSwxMzAgQEANCj4gPiA+ID4gPiArLyoNCj4gPiA+ID4gPiArICogRnJlZXNjYWxlIFFvcklRIFBs
YXRmb3JtcyBHVVRTIERyaXZlcg0KPiA+ID4gPiA+ICsgKg0KPiA+ID4gPiA+ICsgKiBDb3B5cmln
aHQgKEMpIDIwMTYgRnJlZXNjYWxlIFNlbWljb25kdWN0b3IsIEluYy4NCj4gPiA+ID4gPiArICoN
Cj4gPiA+ID4gPiArICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVk
aXN0cmlidXRlIGl0DQo+ID4gPiA+ID4gK2FuZC9vciBtb2RpZnkNCj4gPiA+ID4gPiArICogaXQg
dW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcw0KPiA+
ID4gPiA+ICtwdWJsaXNoZWQgYnkNCj4gPiA+ID4gPiArICogdGhlIEZyZWUgU29mdHdhcmUgRm91
bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMiBvZiB0aGUNCj4gPiA+ID4gPiArTGljZW5zZSwgb3IN
Cj4gPiA+ID4gPiArICogKGF0IHlvdXIgb3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4NCj4gPiA+
ID4gPiArICovDQo+ID4gPiA+ID4gKw0KPiA+ID4gPiA+ICsjaW5jbHVkZSA8bGludXgvaW8uaD4N
Cj4gPiA+ID4gPiArI2luY2x1ZGUgPGxpbnV4L3BsYXRmb3JtX2RldmljZS5oPiAjaW5jbHVkZSA8
bGludXgvbW9kdWxlLmg+DQo+ID4gPiA+ID4gKyNpbmNsdWRlIDxsaW51eC9zbGFiLmg+ICNpbmNs
dWRlIDxsaW51eC9vZl9hZGRyZXNzLmg+ICNpbmNsdWRlDQo+ID4gPiA+ID4gKzxsaW51eC9vZl9w
bGF0Zm9ybS5oPiAjaW5jbHVkZSA8bGludXgvc3lzX3NvYy5oPg0KPiA+ID4gPiA+ICsNCj4gPiA+
ID4gPiArI2RlZmluZSBHVVRTX1BWUgkweDBhMA0KPiA+ID4gPiA+ICsjZGVmaW5lIEdVVFNfU1ZS
CTB4MGE0DQo+ID4gPiA+ID4gKw0KPiA+ID4gPiA+ICtzdHJ1Y3QgZ3V0cyB7DQo+ID4gPiA+ID4g
Kwl2b2lkIF9faW9tZW0gKnJlZ3M7DQo+ID4gPiA+DQo+ID4gPiA+IFdlIGFscmVhZHkgaGF2ZSBh
IHN0cnVjdCB0byBkZWZpbmUgZ3V0cy4gIFdoeSBhcmUgeW91IG5vdCB1c2luZyBpdD8NCj4gPiA+
ID4gV2h5IGRvIHlvdSBjb25zaWRlciB1c2luZyBpdCB0byBiZSAiYWJ1c2UiPyAgV2hhdCBpZiB3
ZSB3YW50IHRvDQo+ID4gPiA+IG1vdmUgbW9yZSBndXRzIGZ1bmN0aW9uYWxpdHkgaW50byB0aGlz
IGRyaXZlcj8NCj4gPiA+DQo+ID4gPiBUaGlzIHN0cnVjdHVyZSB3YXMgaW4gdGhlIG9yaWdpbmFs
IHBhdGNoLCBJIGxlZnQgaXQgaW4gdGhlcmUsIG9ubHkNCj4gPiA+IHJlbW92ZWQgdGhlIGluY2x1
c2lvbiBvZiB0aGUgcG93ZXJwYyBoZWFkZXIgZmlsZSwgd2hpY2ggc2VlbWVkIHRvIGJlDQo+ID4g
PiBtaXNwbGFjZWQuDQo+ID4NCj4gPiBJJ20gbm90IHJlZmVyaW5nICJzdHJ1Y3QgZ3V0cyIuICBJ
J20gcmVmZXJyaW5nIHRvIGNoYW5naW5nICJzdHJ1Y3QNCj4gPiBjY3NyX2d1dHMgX19pb21lbSAq
cmVncyIgaW50byAidm9pZCBfX2lvbWVtICpyZWdzIi4NCj4gPg0KPiA+IEFuZCBpdCdzIG5vdCBh
IHBvd2VycGMgaGVhZGVyIGZpbGUuDQo+ID4NCj4gPiA+ID4gPiArLyoNCj4gPiA+ID4gPiArICog
VGFibGUgZm9yIG1hdGNoaW5nIGNvbXBhdGlibGUgc3RyaW5ncywgZm9yIGRldmljZSB0cmVlDQo+
ID4gPiA+ID4gKyAqIGd1dHMgbm9kZSwgZm9yIEZyZWVzY2FsZSBRb3JJUSBTT0NzLg0KPiA+ID4g
PiA+ICsgKi8NCj4gPiA+ID4gPiArc3RhdGljIGNvbnN0IHN0cnVjdCBvZl9kZXZpY2VfaWQgZnNs
X2d1dHNfb2ZfbWF0Y2hbXSA9IHsNCj4gPiA+ID4gPiArCS8qIEZvciBUNCAmIEI0IFNlcmllcyBT
T0NzICovDQo+ID4gPiA+ID4gKwl7IC5jb21wYXRpYmxlID0gImZzbCxxb3JpcS1kZXZpY2UtY29u
ZmlnLTEuMCIsIC5kYXRhID0gIlQ0L0I0DQo+ID4gPiA+ID4gc2VyaWVzIiB9LA0KPiA+ID4gPiBb
c25pcF0NCj4gPiA+ID4gPiArCXsgLmNvbXBhdGlibGUgPSAiZnNsLHFvcmlxLWRldmljZS1jb25m
aWctMi4wIiwgLmRhdGEgPSAiUA0KPiA+ID4gPiA+IHNlcmllcyINCj4gPiA+ID4NCj4gPiA+ID4g
QXMgbm90ZWQgaW4gbXkgY29tbWVudCBvbiBwYXRjaCAzLzQsIHRoZXNlIGRlc2NyaXB0aW9ucyBh
cmUNCj4gcmV2ZXJzZWQuDQo+ID4gPiA+DQo+ID4gPiA+IFRoZXkncmUgYWxzbyBpbmNvbXBsZXRl
LiAgdDIwODAgaGFzIGRldmljZSBjb25maWcgMi4wLiAgdDEwNDAgaXMNCj4gPiA+ID4gZGVzY3Jp
YmVkIGFzDQo+ID4gPiA+IDIuMCB0aG91Z2ggaXQgc2hvdWxkIHByb2JhYmx5IGJlIDIuMSAob3Ig
YmV0dGVyLCBkcm9wIHRoZSBnZW5lcmljDQo+ID4gPiA+IGNvbXBhdGlibGUgYWx0b2dldGhlciku
DQo+ID4gPg0KPiA+ID4gT2suIElkZWFsbHkgSSB0aGluayB3ZSdkIGV2ZW4gbG9vayB1cCB0aGUg
c3BlY2lmaWMgU29DIG5hbWVzIGZyb20NCj4gPiA+IHRoZSBTVkMgcmF0aGVyIHRoYW4gdGhlIGNv
bXBhdGlibGUgc3RyaW5nLiBJIGp1c3QgZGlkbid0IGhhdmUgYSBnb29kDQo+ID4gPiBsaXN0IGZv
ciB0aG9zZSB0byBwdXQgaW4gdGhlIGRyaXZlci4NCj4gPg0KPiA+IFRoZSBsaXN0IGlzIGluIGFy
Y2gvcG93ZXJwYy9pbmNsdWRlL2FzbS9tcGM4NXh4LmggYnV0IEkgZG9uJ3Qga25vdyB3aHkNCj4g
PiB3ZSBuZWVkIHRvIGNvbnZlcnQgaXQgdG8gYSBzdHJpbmcgaW4gdGhlIGZpcnN0IHBsYWNlLg0K
PiA+DQo+ID4gPg0KPiA+ID4gPiA+ICsJLyoNCj4gPiA+ID4gPiArCSAqIHN5c2NvbiBkZXZpY2Vz
IGRlZmF1bHQgdG8gbGl0dGxlLWVuZGlhbiwgYnV0IG9uIHBvd2VycGMgd2UNCj4gPiA+ID4gPiBo
YXZlDQo+ID4gPiA+ID4gKwkgKiBleGlzdGluZyBkZXZpY2UgdHJlZXMgd2l0aCBiaWctZW5kaWFu
IG1hcHMgYW5kIGFuIGFic2VudA0KPiA+ID4gPiA+IGVuZGlhbmVzcw0KPiA+ID4gPiA+ICsJICog
ImJpZy1wcm9wZXJ0eSINCj4gPiA+ID4gPiArCSAqLw0KPiA+ID4gPiA+ICsJaWYgKCFJU19FTkFC
TEVEKENPTkZJR19QT1dFUlBDKSAmJg0KPiA+ID4gPiA+ICsJICAgICFvZl9wcm9wZXJ0eV9yZWFk
X2Jvb2woZGV2LT5vZl9ub2RlLCAiYmlnLWVuZGlhbiIpKQ0KPiA+ID4gPiA+ICsJCWd1dHMtPmxp
dHRsZV9lbmRpYW4gPSB0cnVlOw0KPiA+ID4gPg0KPiA+ID4gPiBUaGlzIGlzIG5vdCBhIHN5c2Nv
biBkZXZpY2UgKFlhbmdibydzIHBhdGNoIHRvIGFkZCBhIGd1dHMgbm9kZSBvbg0KPiA+ID4gPiBs
czIwODAgaXMgdGhlIG9ubHkgZ3V0cyBub2RlIHRoYXQgc2F5cyAic3lzY29uIiwgYW5kIHRoYXQg
d2FzIGENCj4gPiA+ID4gbGVmdG92ZXIgZnJvbSBlYXJsaWVyIHJldmlzaW9ucyBhbmQgc2hvdWxk
IHByb2JhYmx5IGJlIHJlbW92ZWQpLg0KPiA+ID4gPiBFdmVuIGlmIGl0IHdlcmUsIHdoZXJlIGlz
IGl0IGRvY3VtZW50ZWQgdGhhdCBzeXNjb24gZGVmYXVsdHMgdG8NCj4gPiA+ID4gbGl0dGxlLWVu
ZGlhbj8NCj4gPiA+DQo+ID4gPiBEb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvcmVn
bWFwL3JlZ21hcC50eHQNCj4gPiA+DQo+ID4gPiBXZSBoYWQgYSBsaXR0bGUgc2NyZXd1cCBoZXJl
LCBiYXNpY2FsbHkgcmVnbWFwIChhbmQgYnkgY29uc2VxdWVuY2UsDQo+ID4gPiBzeXNjb24pIGFs
d2F5cyBkZWZhdWx0ZWQgdG8gbGl0dGxlLWVuZGlhbiB3YXkgYmVmb3JlIHRoYXQgd2FzDQo+ID4g
PiBkb2N1bWVudGVkLCBzbyBpdCdzIHRvbyBsYXRlIHRvIGNoYW5nZSBpdCwNCj4gPg0KPiA+IFdo
YXQgY2F1c2VzIGEgZGV2aWNlIG5vZGUgdG8gZmFsbCB1bmRlciB0aGUganVyaXNkaWN0aW9uIG9m
IHJlZ21hcC50eHQ/DQo+ID4gIEFnYWluLCB0aGVzZSBub2RlcyBkbyBub3QgY2xhaW0gInN5c2Nv
biIgY29tcGF0aWJpbGl0eS4NCj4gPg0KPiA+ID4gYWx0aG91Z2ggSSBhZ3JlZSBpdCB3b3VsZCBo
YXZlIG1hZGUgc2Vuc2UgdG8gZG9jdW1lbnQgcmVnbWFwIHRvDQo+ID4gPiBkZWZhdWx0IHRvIGJp
Zy1lbmRpYW4gb24gcG93ZXJwYy4NCj4gPg0KPiA+IFBsZWFzZSBkb24ndC4gIEl0J3MgZW5vdWdo
IG9mIGEgbWVzcyBhcyBpczsgbm8gbmVlZCB0byBzdGFydCB0aHJvd2luZw0KPiA+IGluIGFyY2hp
dGVjdHVyZSBpZmRlZnMuDQo+ID4NCj4gPiA+ID4gRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2Jp
bmRpbmdzL2NvbW1vbi1wcm9wZXJ0aWVzLnR4dCBzYXlzIHRoYXQNCj4gPiA+ID4gdGhlIGluZGl2
aWR1YWwgYmluZGluZyBzcGVjaWZpZXMgdGhlIGRlZmF1bHQuICBUaGUgZGVmYXVsdCBmb3INCj4g
PiA+ID4gdGhpcyBub2RlIHNob3VsZCBiZSBiaWctZW5kaWFuIGJlY2F1c2UgdGhhdCdzIHdoYXQg
ZXhpc3RlZCBiZWZvcmUNCj4gPiA+ID4gdGhlcmUgd2FzIGEgbmVlZCB0byBkZXNjcmliZSB0aGUg
ZW5kaWFubmVzcy4gIEFuZCB3ZSBuZWVkIGFuDQo+ID4gPiA+IHVwZGF0ZSB0byB0aGUgZ3V0cyBi
aW5kaW5nIHRvIHNwZWNpZnkgdGhhdC4NCj4gPiA+DQo+ID4gPiBHb29kIHBvaW50LiBUaGlzIHBy
b2FibHkgbWVhbnMgdGhhdCBzcGVjaWZ5aW5nIGJvdGggdGhlICJndXRzIiBhbmQNCj4gPiAic3lz
Y29uIg0KPiA+ID4gY29tcGF0aWJsZSBzdHJpbmdzIGltcGxpZXMgaGF2aW5nIHRvIGFsc28gc3Bl
Y2lmeSB0aGUgZW5kaWFuZXNzDQo+ID4gPiBleHBsaWNpdGx5IGJvdGggd2F5cywgYmVjYXVzZSBv
dGhlcndpc2Ugd2UgYnJlYWsgb25lIG9mIHRoZSB0d28NCj4gPiBiaW5kaW5ncy4NCj4gPg0KPiA+
IFllcywgYnV0IHRoZSBub2RlIHNob3VsZCBvbmx5IHNwZWNpZnkgImd1dHMiLg0KPiA+DQo+ID4g
Pg0KPiA+ID4gPiA+ICsNCj4gPiA+ID4gPiArCWd1dHMtPnJlZ3MgPSBkZXZtX2lvcmVtYXBfcmVz
b3VyY2UoZGV2LCAwKTsNCj4gPiA+ID4gPiArCWlmICghZ3V0cy0+cmVncykgew0KPiA+ID4gPiA+
ICsJCXJldCA9IC1FTk9NRU07DQo+ID4gPiA+ID4gKwkJa2ZyZWUoZ3V0cyk7DQo+ID4gPiA+ID4g
KwkJZ290byBvdXQ7DQo+ID4gPiA+ID4gKwl9DQo+ID4gPiA+ID4gKw0KPiA+ID4gPiA+ICsJZnNs
X2d1dHNfaW5pdChkZXYsIGd1dHMpOw0KPiA+ID4gPiA+ICsJcmV0ID0gMDsNCj4gPiA+ID4gPiAr
b3V0Og0KPiA+ID4gPiA+ICsJcmV0dXJuIHJldDsNCj4gPiA+ID4gPiArfQ0KPiA+ID4gPiA+ICsN
Cj4gPiA+ID4gPiArc3RhdGljIHN0cnVjdCBwbGF0Zm9ybV9kcml2ZXIgZnNsX3NvY19ndXRzID0g
ew0KPiA+ID4gPiA+ICsJLnByb2JlID0gZnNsX2d1dHNfcHJvYmUsDQo+ID4gPiA+ID4gKwkuZHJp
dmVyLm9mX21hdGNoX3RhYmxlID0gZnNsX2d1dHNfb2ZfbWF0Y2gsIH07DQo+ID4gPiA+ID4gKw0K
PiA+ID4gPiA+ICttb2R1bGVfcGxhdGZvcm1fZHJpdmVyKGZzbF9zb2NfZ3V0cyk7DQo+ID4gPiA+
DQo+ID4gPiA+IEFnYWluLCB0aGlzIG1lYW5zIHRoYXQgdGhlIGluZm9ybWF0aW9uIGlzIG5vdCBh
dmFpbGFibGUgZHVyaW5nDQo+ID4gPiA+IGVhcmx5IGJvb3QsIHN1Y2ggYXMgaW4gdGhlIGNsb2Nr
IGRyaXZlci4gIFRodXMgd2Ugd291bGQgbm90IGJlDQo+ID4gPiA+IGFibGUgdG8gY29udmVydCBj
bGsgLXFvcmlxJ3MgZGlyZWN0IG1mc3ByKFNQUk5fU1ZSKSBpbnRvIGFuDQo+ID4gPiA+IHNvY19k
ZXZpY2VfbWF0Y2goKSAob3IgYW55dGhpbmcgZWxzZSB0aGF0IG1ha2VzIHVzZSBvZiB0aGlzIGZp
bGUpLA0KPiA+ID4gPiBub3Igd291bGQgd2UgYmUgYWJsZSB0byBtb3ZlIGl0cyBhY2Nlc3Mgb2Yg
dGhlIGd1dHMgUkNXIHJlZ2lzdGVycw0KPiA+ID4gPiBpbnRvIHRoaXMgZHJpdmVyLg0KPiA+ID4N
Cj4gPiA+IENvcnJlY3QuIERvIHdlIGhhdmUgYSByZWFzb24gdG8gY29udmVydCB0aGUgbWZzcHIo
KSB0aG91Z2g/IEkgZG9uJ3QNCj4gPiA+IHJlYWxseSBzZWUgYW4gaW1wcm92ZW1lbnQgb3ZlciB0
aGUgY3VycmVudCBzdGF0ZSBpZiB3ZSBkbyB0aGF0LA0KPiA+DQo+ID4gVGhlbiBzaG91bGQgd2Ug
ZHJvcCB0aGlzIHBhdGNoc2V0IGFuZCBwdXQgYSBzaW1pbGFyIFBQQyBpZmRlZiBpbg0KPiA+IGRy
aXZlcnMvbW1jL2hvc3Qvc2RoY2ktb2YtZXNkaGMuYz8NCj4gPg0KPiA+IFRoZXJlJ3MgYWxzbyB0
aGUgUkNXIGFjY2Vzcy4gIFlvdSBzYWlkIGluIHRoZSBwYXRjaCA0LzQgZGlzY3Vzc2lvbg0KPiA+
IHRoYXQgeW91IGRpIGRuJ3QgbGlrZSBhbnkgcmFuZG9tIGRyaXZlciBpb3JlbWFwcGluZyB0aGUg
cmVnaXN0ZXJzLi4uDQo+ID4NCj4gPiA+IGFuZCBmb3IgbmV3IGRldmljZXMNCj4gPiA+IHRoYXQg
bWlnaHQgbmVlZCB0aGUgZXJyYXR1bSB3b3JrYXJvdW5kLCB3ZSBjb3VsZCBhZGQgYSBEVCBwcm9w
ZXJ0eQ0KPiA+ID4gdGhhdCB3b3VsZCBiZSBwcmVmZXJyZWQgdG8gYm90aC4NCj4gPg0KPiA+IEl0
J3MgdW5saWtlbHkgdGhhdCB3ZSB3b3VsZCBrbm93IHRoZSBlcnJhdHVtIGV4aXN0cyBhdCB0aGUg
dGltZSB0aGUNCj4gPiBkZXZpY2UgdHJlZSBpcyBjcmVhdGVkLiAgV2UgYWxzbyBnZW5lcmFsbHkg
ZG9uJ3QgaGF2ZSBzZXBhcmF0ZSBkZXZpY2UNCj4gPiB0cmVlcyBmb3IgZWFjaCByZXZpc2lvbiBv
ZiBhIGNoaXAgKGFuZCBpZiB3ZSBkaWQsIHdlJ2QgaGF2ZSB1c2VycyB0aGF0DQo+ID4gdXNlIHRo
ZSB3cm9uZyBvbmUpLg0KPiA+DQo+ID4gLVNjb3R0DQoNCg==
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-07-07 2:35 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-07-07 2:35 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
Could you reply when you see the email?
If your method doesn?t resolve the problem, we still want to use our old patchset.
This guts driver had been discussed about one year and blocked many workaround upstream.
So please help to review and comment soon.
Thanks a lot.
Best regards,
Yangbo Lu
> -----Original Message-----
> From: Yangbo Lu
> Sent: Thursday, June 23, 2016 10:46 AM
> To: 'Scott Wood'; Arnd Bergmann; linuxppc-dev at lists.ozlabs.org
> Cc: Mark Rutland; Ulf Hansson; linux-kernel at vger.kernel.org; linux-
> i2c at vger.kernel.org; linux-clk at vger.kernel.org; Qiang Zhao; Russell King;
> Bhupesh Sharma; Joerg Roedel; Claudiu Manoil; devicetree at vger.kernel.org;
> Kumar Gala; Rob Herring; Santosh Shilimkar; linux-arm-
> kernel at lists.infradead.org; netdev at vger.kernel.org; linux-
> mmc at vger.kernel.org; Xiaobo Xie; Yang-Leo Li; iommu at lists.linux-
> foundation.org
> Subject: RE: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
>
> Hi Arnd,
>
> Could you comment on these?
> Thanks.
>
>
> Best regards,
> Yangbo Lu
>
>
> > -----Original Message-----
> > From: Scott Wood [mailto:oss at buserror.net]
> > Sent: Saturday, June 11, 2016 9:51 AM
> > To: Arnd Bergmann; linuxppc-dev at lists.ozlabs.org
> > Cc: Mark Rutland; Ulf Hansson; linux-kernel at vger.kernel.org; linux-
> > i2c at vger.kernel.org; linux-clk at vger.kernel.org; Qiang Zhao; Russell
> > King; Bhupesh Sharma; Joerg Roedel; Claudiu Manoil;
> > devicetree at vger.kernel.org; Kumar Gala; Rob Herring; Santosh
> > Shilimkar; linux-arm- kernel at lists.infradead.org;
> > netdev at vger.kernel.org; linux- mmc at vger.kernel.org; Xiaobo Xie;
> > Yang-Leo Li; iommu at lists.linux- foundation.org; Yangbo Lu
> > Subject: Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
> >
> > On Thu, 2016-06-02 at 10:43 +0200, Arnd Bergmann wrote:
> > > On Wednesday, June 1, 2016 8:47:22 PM CEST Scott Wood wrote:
> > > > On Mon, 2016-05-30 at 15:15 +0200, Arnd Bergmann wrote:
> > > > > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c new
> > > > > file mode 100644 index 000000000000..2f30698f5bcf
> > > > > --- /dev/null
> > > > > +++ b/drivers/soc/fsl/guts.c
> > > > > @@ -0,0 +1,130 @@
> > > > > +/*
> > > > > + * Freescale QorIQ Platforms GUTS Driver
> > > > > + *
> > > > > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > > > > + *
> > > > > + * This program is free software; you can redistribute it
> > > > > +and/or modify
> > > > > + * it under the terms of the GNU General Public License as
> > > > > +published by
> > > > > + * the Free Software Foundation; either version 2 of the
> > > > > +License, or
> > > > > + * (at your option) any later version.
> > > > > + */
> > > > > +
> > > > > +#include <linux/io.h>
> > > > > +#include <linux/platform_device.h> #include <linux/module.h>
> > > > > +#include <linux/slab.h> #include <linux/of_address.h> #include
> > > > > +<linux/of_platform.h> #include <linux/sys_soc.h>
> > > > > +
> > > > > +#define GUTS_PVR 0x0a0
> > > > > +#define GUTS_SVR 0x0a4
> > > > > +
> > > > > +struct guts {
> > > > > + void __iomem *regs;
> > > >
> > > > We already have a struct to define guts. Why are you not using it?
> > > > Why do you consider using it to be "abuse"? What if we want to
> > > > move more guts functionality into this driver?
> > >
> > > This structure was in the original patch, I left it in there, only
> > > removed the inclusion of the powerpc header file, which seemed to be
> > > misplaced.
> >
> > I'm not refering "struct guts". I'm referring to changing "struct
> > ccsr_guts __iomem *regs" into "void __iomem *regs".
> >
> > And it's not a powerpc header file.
> >
> > > > > +/*
> > > > > + * Table for matching compatible strings, for device tree
> > > > > + * guts node, for Freescale QorIQ SOCs.
> > > > > + */
> > > > > +static const struct of_device_id fsl_guts_of_match[] = {
> > > > > + /* For T4 & B4 Series SOCs */
> > > > > + { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4
> > > > > series" },
> > > > [snip]
> > > > > + { .compatible = "fsl,qoriq-device-config-2.0", .data = "P
> > > > > series"
> > > >
> > > > As noted in my comment on patch 3/4, these descriptions are
> reversed.
> > > >
> > > > They're also incomplete. t2080 has device config 2.0. t1040 is
> > > > described as
> > > > 2.0 though it should probably be 2.1 (or better, drop the generic
> > > > compatible altogether).
> > >
> > > Ok. Ideally I think we'd even look up the specific SoC names from
> > > the SVC rather than the compatible string. I just didn't have a good
> > > list for those to put in the driver.
> >
> > The list is in arch/powerpc/include/asm/mpc85xx.h but I don't know why
> > we need to convert it to a string in the first place.
> >
> > >
> > > > > + /*
> > > > > + * syscon devices default to little-endian, but on powerpc we
> > > > > have
> > > > > + * existing device trees with big-endian maps and an absent
> > > > > endianess
> > > > > + * "big-property"
> > > > > + */
> > > > > + if (!IS_ENABLED(CONFIG_POWERPC) &&
> > > > > + !of_property_read_bool(dev->of_node, "big-endian"))
> > > > > + guts->little_endian = true;
> > > >
> > > > This is not a syscon device (Yangbo's patch to add a guts node on
> > > > ls2080 is the only guts node that says "syscon", and that was a
> > > > leftover from earlier revisions and should probably be removed).
> > > > Even if it were, where is it documented that syscon defaults to
> > > > little-endian?
> > >
> > > Documentation/devicetree/bindings/regmap/regmap.txt
> > >
> > > We had a little screwup here, basically regmap (and by consequence,
> > > syscon) always defaulted to little-endian way before that was
> > > documented, so it's too late to change it,
> >
> > What causes a device node to fall under the jurisdiction of regmap.txt?
> > Again, these nodes do not claim "syscon" compatibility.
> >
> > > although I agree it would have made sense to document regmap to
> > > default to big-endian on powerpc.
> >
> > Please don't. It's enough of a mess as is; no need to start throwing
> > in architecture ifdefs.
> >
> > > > Documentation/devicetree/bindings/common-properties.txt says that
> > > > the individual binding specifies the default. The default for
> > > > this node should be big-endian because that's what existed before
> > > > there was a need to describe the endianness. And we need an
> > > > update to the guts binding to specify that.
> > >
> > > Good point. This proably means that specifying both the "guts" and
> > "syscon"
> > > compatible strings implies having to also specify the endianess
> > > explicitly both ways, because otherwise we break one of the two
> > bindings.
> >
> > Yes, but the node should only specify "guts".
> >
> > >
> > > > > +
> > > > > + guts->regs = devm_ioremap_resource(dev, 0);
> > > > > + if (!guts->regs) {
> > > > > + ret = -ENOMEM;
> > > > > + kfree(guts);
> > > > > + goto out;
> > > > > + }
> > > > > +
> > > > > + fsl_guts_init(dev, guts);
> > > > > + ret = 0;
> > > > > +out:
> > > > > + return ret;
> > > > > +}
> > > > > +
> > > > > +static struct platform_driver fsl_soc_guts = {
> > > > > + .probe = fsl_guts_probe,
> > > > > + .driver.of_match_table = fsl_guts_of_match, };
> > > > > +
> > > > > +module_platform_driver(fsl_soc_guts);
> > > >
> > > > Again, this means that the information is not available during
> > > > early boot, such as in the clock driver. Thus we would not be
> > > > able to convert clk -qoriq's direct mfspr(SPRN_SVR) into an
> > > > soc_device_match() (or anything else that makes use of this file),
> > > > nor would we be able to move its access of the guts RCW registers
> > > > into this driver.
> > >
> > > Correct. Do we have a reason to convert the mfspr() though? I don't
> > > really see an improvement over the current state if we do that,
> >
> > Then should we drop this patchset and put a similar PPC ifdef in
> > drivers/mmc/host/sdhci-of-esdhc.c?
> >
> > There's also the RCW access. You said in the patch 4/4 discussion
> > that you di dn't like any random driver ioremapping the registers...
> >
> > > and for new devices
> > > that might need the erratum workaround, we could add a DT property
> > > that would be preferred to both.
> >
> > It's unlikely that we would know the erratum exists at the time the
> > device tree is created. We also generally don't have separate device
> > trees for each revision of a chip (and if we did, we'd have users that
> > use the wrong one).
> >
> > -Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-07-07 8:30 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-07-07 8:30 UTC (permalink / raw)
To: Yangbo Lu
Cc: Scott Wood, linuxppc-dev, Mark Rutland, Ulf Hansson,
linux-kernel, linux-i2c, linux-clk, Qiang Zhao, Russell King,
Bhupesh Sharma, Joerg Roedel, Claudiu Manoil, devicetree,
Kumar Gala, Rob Herring, Santosh Shilimkar, linux-arm-kernel,
netdev, linux-mmc, Xiaobo Xie, Yang-Leo Li, iommu
On Thursday, July 7, 2016 2:35:33 AM CEST Yangbo Lu wrote:
> Hi Arnd,
>
> Could you reply when you see the email?
> If your method doesn’t resolve the problem, we still want to use our old patchset.
>
> This guts driver had been discussed about one year and blocked many workaround upstream.
> So please help to review and comment soon.
>
I don't really see how more discussion is going to help us here. I think
I've made it pretty clear that I don't want to see another platform
specific way to read an SoC revision and I've even sent a proof-of-concept
patch to show how the interface can work, now it's up to you to fit the
guts hardware into that and send a new patch series.
Arnd
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-07-07 8:30 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-07-07 8:30 UTC (permalink / raw)
To: Yangbo Lu
Cc: Mark Rutland, Ulf Hansson, Xiaobo Xie,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Qiang Zhao, Russell King,
Bhupesh Sharma, Claudiu Manoil,
devicetree-u79uwXL29TY76Z2rM5mHXA, Scott Wood, Rob Herring,
Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Yang-Leo Li,
iommu-cunTk1MwBs+mg8Ev75riOw@public.gmane.org x-foundation.org
On Thursday, July 7, 2016 2:35:33 AM CEST Yangbo Lu wrote:
> Hi Arnd,
>
> Could you reply when you see the email?
> If your method doesn’t resolve the problem, we still want to use our old patchset.
>
> This guts driver had been discussed about one year and blocked many workaround upstream.
> So please help to review and comment soon.
>
I don't really see how more discussion is going to help us here. I think
I've made it pretty clear that I don't want to see another platform
specific way to read an SoC revision and I've even sent a proof-of-concept
patch to show how the interface can work, now it's up to you to fit the
guts hardware into that and send a new patch series.
Arnd
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-07-07 8:30 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-07-07 8:30 UTC (permalink / raw)
To: Yangbo Lu
Cc: Mark Rutland, Ulf Hansson, Xiaobo Xie,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Qiang Zhao, Russell King,
Bhupesh Sharma, Claudiu Manoil,
devicetree-u79uwXL29TY76Z2rM5mHXA, Scott Wood, Rob Herring,
Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Yang-Leo Li,
iommu-cunTk1MwBs+mg8Ev75riOw@public.gmane.org x-foundation.org
On Thursday, July 7, 2016 2:35:33 AM CEST Yangbo Lu wrote:
> Hi Arnd,
>
> Could you reply when you see the email?
> If your method doesn’t resolve the problem, we still want to use our old patchset.
>
> This guts driver had been discussed about one year and blocked many workaround upstream.
> So please help to review and comment soon.
>
I don't really see how more discussion is going to help us here. I think
I've made it pretty clear that I don't want to see another platform
specific way to read an SoC revision and I've even sent a proof-of-concept
patch to show how the interface can work, now it's up to you to fit the
guts hardware into that and send a new patch series.
Arnd
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-07-07 8:30 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-07-07 8:30 UTC (permalink / raw)
To: Yangbo Lu
Cc: Mark Rutland, Ulf Hansson, Xiaobo Xie, linux-i2c, linux-clk,
Qiang Zhao, Russell King, Bhupesh Sharma, Joerg Roedel,
Claudiu Manoil, devicetree, Scott Wood, Rob Herring,
Santosh Shilimkar, linux-arm-kernel, netdev, linux-mmc,
linux-kernel, Yang-Leo Li, iommu, Kumar Gala, linuxppc-dev
T24gVGh1cnNkYXksIEp1bHkgNywgMjAxNiAyOjM1OjMzIEFNIENFU1QgWWFuZ2JvIEx1IHdyb3Rl
Ogo+IEhpIEFybmQsCj4gCj4gQ291bGQgeW91IHJlcGx5IHdoZW4geW91IHNlZSB0aGUgZW1haWw/
Cj4gSWYgeW91ciBtZXRob2QgZG9lc27igJl0IHJlc29sdmUgdGhlIHByb2JsZW0sIHdlIHN0aWxs
IHdhbnQgdG8gdXNlIG91ciBvbGQgcGF0Y2hzZXQuCj4gCj4gVGhpcyBndXRzIGRyaXZlciBoYWQg
YmVlbiBkaXNjdXNzZWQgYWJvdXQgb25lIHllYXIgYW5kIGJsb2NrZWQgbWFueSB3b3JrYXJvdW5k
IHVwc3RyZWFtLgo+IFNvIHBsZWFzZSBoZWxwIHRvIHJldmlldyBhbmQgY29tbWVudCBzb29uLgo+
IAoKSSBkb24ndCByZWFsbHkgc2VlIGhvdyBtb3JlIGRpc2N1c3Npb24gaXMgZ29pbmcgdG8gaGVs
cCB1cyBoZXJlLiBJIHRoaW5rCkkndmUgbWFkZSBpdCBwcmV0dHkgY2xlYXIgdGhhdCBJIGRvbid0
IHdhbnQgdG8gc2VlIGFub3RoZXIgcGxhdGZvcm0Kc3BlY2lmaWMgd2F5IHRvIHJlYWQgYW4gU29D
IHJldmlzaW9uIGFuZCBJJ3ZlIGV2ZW4gc2VudCBhIHByb29mLW9mLWNvbmNlcHQKcGF0Y2ggdG8g
c2hvdyBob3cgdGhlIGludGVyZmFjZSBjYW4gd29yaywgbm93IGl0J3MgdXAgdG8geW91IHRvIGZp
dCB0aGUKZ3V0cyBoYXJkd2FyZSBpbnRvIHRoYXQgYW5kIHNlbmQgYSBuZXcgcGF0Y2ggc2VyaWVz
LgoKCUFybmQKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpsaW51eC1hcm0ta2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmlu
ZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9s
aW51eC1hcm0ta2VybmVsCg==
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-07-07 8:30 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-07-07 8:30 UTC (permalink / raw)
To: Yangbo Lu
Cc: Scott Wood, linuxppc-dev, Mark Rutland, Ulf Hansson,
linux-kernel, linux-i2c, linux-clk, Qiang Zhao, Russell King,
Bhupesh Sharma, Joerg Roedel, Claudiu Manoil, devicetree,
Kumar Gala, Rob Herring, Santosh Shilimkar, linux-arm-kernel,
netdev, linux-mmc, Xiaobo Xie, Yang-Leo Li, iommu
On Thursday, July 7, 2016 2:35:33 AM CEST Yangbo Lu wrote:
> Hi Arnd,
>=20
> Could you reply when you see the email?
> If your method doesn=E2=80=99t resolve the problem, we still want to use =
our old patchset.
>=20
> This guts driver had been discussed about one year and blocked many worka=
round upstream.
> So please help to review and comment soon.
>=20
I don't really see how more discussion is going to help us here. I think
I've made it pretty clear that I don't want to see another platform
specific way to read an SoC revision and I've even sent a proof-of-concept
patch to show how the interface can work, now it's up to you to fit the
guts hardware into that and send a new patch series.
Arnd
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-07-07 8:30 ` Arnd Bergmann
0 siblings, 0 replies; 185+ messages in thread
From: Arnd Bergmann @ 2016-07-07 8:30 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday, July 7, 2016 2:35:33 AM CEST Yangbo Lu wrote:
> Hi Arnd,
>
> Could you reply when you see the email?
> If your method doesn?t resolve the problem, we still want to use our old patchset.
>
> This guts driver had been discussed about one year and blocked many workaround upstream.
> So please help to review and comment soon.
>
I don't really see how more discussion is going to help us here. I think
I've made it pretty clear that I don't want to see another platform
specific way to read an SoC revision and I've even sent a proof-of-concept
patch to show how the interface can work, now it's up to you to fit the
guts hardware into that and send a new patch series.
Arnd
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
2016-07-07 8:30 ` Arnd Bergmann
` (2 preceding siblings ...)
(?)
@ 2016-07-07 20:42 ` Scott Wood
-1 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-07-07 20:42 UTC (permalink / raw)
To: Arnd Bergmann, Yangbo Lu
Cc: linuxppc-dev, Mark Rutland, Ulf Hansson, linux-kernel, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Kumar Gala,
Rob Herring, Santosh Shilimkar, linux-arm-kernel, netdev,
linux-mmc, Xiaobo Xie, Yang-Leo Li, iommu
On Thu, 2016-07-07 at 10:30 +0200, Arnd Bergmann wrote:
> On Thursday, July 7, 2016 2:35:33 AM CEST Yangbo Lu wrote:
> >
> > Hi Arnd,
> >
> > Could you reply when you see the email?
> > If your method doesn’t resolve the problem, we still want to use our old
> > patchset.
> >
> > This guts driver had been discussed about one year and blocked many
> > workaround upstream.
> > So please help to review and comment soon.
> >
> I don't really see how more discussion is going to help us here. I think
> I've made it pretty clear that I don't want to see another platform
> specific way to read an SoC revision and I've even sent a proof-of-concept
> patch to show how the interface can work, now it's up to you to fit the
> guts hardware into that and send a new patch series.
In which relevant maintainership capacity are you NACKing it?
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-07-07 20:42 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-07-07 20:42 UTC (permalink / raw)
To: Arnd Bergmann, Yangbo Lu
Cc: linuxppc-dev, Mark Rutland, Ulf Hansson, linux-kernel, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Kumar Gala,
Rob Herring, Santosh Shilimkar, linux-arm-kernel, netdev,
linux-mmc, Xiaob
On Thu, 2016-07-07 at 10:30 +0200, Arnd Bergmann wrote:
> On Thursday, July 7, 2016 2:35:33 AM CEST Yangbo Lu wrote:
> >
> > Hi Arnd,
> >
> > Could you reply when you see the email?
> > If your method doesn’t resolve the problem, we still want to use our old
> > patchset.
> >
> > This guts driver had been discussed about one year and blocked many
> > workaround upstream.
> > So please help to review and comment soon.
> >
> I don't really see how more discussion is going to help us here. I think
> I've made it pretty clear that I don't want to see another platform
> specific way to read an SoC revision and I've even sent a proof-of-concept
> patch to show how the interface can work, now it's up to you to fit the
> guts hardware into that and send a new patch series.
In which relevant maintainership capacity are you NACKing it?
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-07-07 20:42 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-07-07 20:42 UTC (permalink / raw)
To: Arnd Bergmann, Yangbo Lu
Cc: linuxppc-dev, Mark Rutland, Ulf Hansson, linux-kernel, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Kumar Gala,
Rob Herring, Santosh Shilimkar, linux-arm-kernel, netdev,
linux-mmc, Xiaobo Xie, Yang-Leo Li, iommu
On Thu, 2016-07-07 at 10:30 +0200, Arnd Bergmann wrote:
> On Thursday, July 7, 2016 2:35:33 AM CEST Yangbo Lu wrote:
> >
> > Hi Arnd,
> >
> > Could you reply when you see the email?
> > If your method doesn’t resolve the problem, we still want to use our old
> > patchset.
> >
> > This guts driver had been discussed about one year and blocked many
> > workaround upstream.
> > So please help to review and comment soon.
> >
> I don't really see how more discussion is going to help us here. I think
> I've made it pretty clear that I don't want to see another platform
> specific way to read an SoC revision and I've even sent a proof-of-concept
> patch to show how the interface can work, now it's up to you to fit the
> guts hardware into that and send a new patch series.
In which relevant maintainership capacity are you NACKing it?
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-07-07 20:42 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-07-07 20:42 UTC (permalink / raw)
To: Arnd Bergmann, Yangbo Lu
Cc: linuxppc-dev, Mark Rutland, Ulf Hansson, linux-kernel, linux-i2c,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Kumar Gala,
Rob Herring, Santosh Shilimkar, linux-arm-kernel, netdev,
linux-mmc, Xiaobo Xie, Yang-Leo Li, iommu
On Thu, 2016-07-07 at 10:30 +0200, Arnd Bergmann wrote:
> On Thursday, July 7, 2016 2:35:33 AM CEST Yangbo Lu wrote:
> >
> > Hi Arnd,
> >
> > Could you reply when you see the email?
> > If your method doesn’t resolve the problem, we still want to use our old
> > patchset.
> >
> > This guts driver had been discussed about one year and blocked many
> > workaround upstream.
> > So please help to review and comment soon.
> >
> I don't really see how more discussion is going to help us here. I think
> I've made it pretty clear that I don't want to see another platform
> specific way to read an SoC revision and I've even sent a proof-of-concept
> patch to show how the interface can work, now it's up to you to fit the
> guts hardware into that and send a new patch series.
In which relevant maintainership capacity are you NACKing it?
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-07-07 20:42 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-07-07 20:42 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 2016-07-07 at 10:30 +0200, Arnd Bergmann wrote:
> On Thursday, July 7, 2016 2:35:33 AM CEST Yangbo Lu wrote:
> >
> > Hi Arnd,
> >
> > Could you reply when you see the email?
> > If your method doesn?t resolve the problem, we still want to use our old
> > patchset.
> >
> > This guts driver had been discussed about one year and blocked many
> > workaround upstream.
> > So please help to review and comment soon.
> >
> I don't really see how more discussion is going to help us here. I think
> I've made it pretty clear that I don't want to see another platform
> specific way to read an SoC revision and I've even sent a proof-of-concept
> patch to show how the interface can work, now it's up to you to fit the
> guts hardware into that and send a new patch series.
In which relevant maintainership capacity are you NACKing it?
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
2016-07-07 8:30 ` Arnd Bergmann
` (3 preceding siblings ...)
(?)
@ 2016-07-08 3:05 ` Yangbo Lu
-1 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-07-08 3:05 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Scott Wood, linuxppc-dev, Mark Rutland, Ulf Hansson,
linux-kernel, linux-i2c, linux-clk, Qiang Zhao, Russell King,
Bhupesh Sharma, Joerg Roedel, Claudiu Manoil, devicetree,
Kumar Gala, Rob Herring, Santosh Shilimkar, linux-arm-kernel,
netdev, linux-mmc, Xiaobo Xie, Yang-Leo Li, iommu
Hi Arnd,
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@arndb.de]
> Sent: Thursday, July 07, 2016 4:30 PM
> To: Yangbo Lu
> Cc: Scott Wood; linuxppc-dev@lists.ozlabs.org; Mark Rutland; Ulf Hansson;
> linux-kernel@vger.kernel.org; linux-i2c@vger.kernel.org; linux-
> clk@vger.kernel.org; Qiang Zhao; Russell King; Bhupesh Sharma; Joerg
> Roedel; Claudiu Manoil; devicetree@vger.kernel.org; Kumar Gala; Rob
> Herring; Santosh Shilimkar; linux-arm-kernel@lists.infradead.org;
> netdev@vger.kernel.org; linux-mmc@vger.kernel.org; Xiaobo Xie; Yang-Leo
> Li; iommu@lists.linux-foundation.org
> Subject: Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
>
> On Thursday, July 7, 2016 2:35:33 AM CEST Yangbo Lu wrote:
> > Hi Arnd,
> >
> > Could you reply when you see the email?
> > If your method doesn’t resolve the problem, we still want to use our
> old patchset.
> >
> > This guts driver had been discussed about one year and blocked many
> workaround upstream.
> > So please help to review and comment soon.
> >
>
> I don't really see how more discussion is going to help us here. I think
> I've made it pretty clear that I don't want to see another platform
> specific way to read an SoC revision and I've even sent a proof-of-
> concept patch to show how the interface can work, now it's up to you to
> fit the guts hardware into that and send a new patch series.
>
> Arnd
I think your proof-of-concept patch is still in discussion. Some answers are needed from you to
address Scott's comments on your patchset. Have you reached an agreement?
Thanks.
- Yangbo Lu
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-07-08 3:05 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-07-08 3:05 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, Ulf Hansson, Xiaobo Xie,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Qiang Zhao, Russell King,
Bhupesh Sharma, Claudiu Manoil,
devicetree-u79uwXL29TY76Z2rM5mHXA, Scott Wood, Rob Herring,
Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Yang-Leo Li,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Hi Arnd,
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@arndb.de]
> Sent: Thursday, July 07, 2016 4:30 PM
> To: Yangbo Lu
> Cc: Scott Wood; linuxppc-dev@lists.ozlabs.org; Mark Rutland; Ulf Hansson;
> linux-kernel@vger.kernel.org; linux-i2c@vger.kernel.org; linux-
> clk@vger.kernel.org; Qiang Zhao; Russell King; Bhupesh Sharma; Joerg
> Roedel; Claudiu Manoil; devicetree@vger.kernel.org; Kumar Gala; Rob
> Herring; Santosh Shilimkar; linux-arm-kernel@lists.infradead.org;
> netdev@vger.kernel.org; linux-mmc@vger.kernel.org; Xiaobo Xie; Yang-Leo
> Li; iommu@lists.linux-foundation.org
> Subject: Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
>
> On Thursday, July 7, 2016 2:35:33 AM CEST Yangbo Lu wrote:
> > Hi Arnd,
> >
> > Could you reply when you see the email?
> > If your method doesn’t resolve the problem, we still want to use our
> old patchset.
> >
> > This guts driver had been discussed about one year and blocked many
> workaround upstream.
> > So please help to review and comment soon.
> >
>
> I don't really see how more discussion is going to help us here. I think
> I've made it pretty clear that I don't want to see another platform
> specific way to read an SoC revision and I've even sent a proof-of-
> concept patch to show how the interface can work, now it's up to you to
> fit the guts hardware into that and send a new patch series.
>
> Arnd
I think your proof-of-concept patch is still in discussion. Some answers are needed from you to
address Scott's comments on your patchset. Have you reached an agreement?
Thanks.
- Yangbo Lu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-07-08 3:05 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-07-08 3:05 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, Ulf Hansson, Xiaobo Xie,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Qiang Zhao, Russell King,
Bhupesh Sharma, Claudiu Manoil,
devicetree-u79uwXL29TY76Z2rM5mHXA, Scott Wood, Rob Herring,
Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Yang-Leo Li,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Hi Arnd,
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@arndb.de]
> Sent: Thursday, July 07, 2016 4:30 PM
> To: Yangbo Lu
> Cc: Scott Wood; linuxppc-dev@lists.ozlabs.org; Mark Rutland; Ulf Hansson;
> linux-kernel@vger.kernel.org; linux-i2c@vger.kernel.org; linux-
> clk@vger.kernel.org; Qiang Zhao; Russell King; Bhupesh Sharma; Joerg
> Roedel; Claudiu Manoil; devicetree@vger.kernel.org; Kumar Gala; Rob
> Herring; Santosh Shilimkar; linux-arm-kernel@lists.infradead.org;
> netdev@vger.kernel.org; linux-mmc@vger.kernel.org; Xiaobo Xie; Yang-Leo
> Li; iommu@lists.linux-foundation.org
> Subject: Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
>
> On Thursday, July 7, 2016 2:35:33 AM CEST Yangbo Lu wrote:
> > Hi Arnd,
> >
> > Could you reply when you see the email?
> > If your method doesn’t resolve the problem, we still want to use our
> old patchset.
> >
> > This guts driver had been discussed about one year and blocked many
> workaround upstream.
> > So please help to review and comment soon.
> >
>
> I don't really see how more discussion is going to help us here. I think
> I've made it pretty clear that I don't want to see another platform
> specific way to read an SoC revision and I've even sent a proof-of-
> concept patch to show how the interface can work, now it's up to you to
> fit the guts hardware into that and send a new patch series.
>
> Arnd
I think your proof-of-concept patch is still in discussion. Some answers are needed from you to
address Scott's comments on your patchset. Have you reached an agreement?
Thanks.
- Yangbo Lu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-07-08 3:05 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-07-08 3:05 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, Ulf Hansson, Xiaobo Xie, linux-i2c, linux-clk,
Qiang Zhao, Russell King, Bhupesh Sharma, Joerg Roedel,
Claudiu Manoil, devicetree, Scott Wood, Rob Herring,
Santosh Shilimkar, linux-arm-kernel, netdev, linux-mmc,
linux-kernel, Yang-Leo Li, iommu, Kumar Gala, linuxppc-dev
SGkgQXJuZCwNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFybmQg
QmVyZ21hbm4gW21haWx0bzphcm5kQGFybmRiLmRlXQ0KPiBTZW50OiBUaHVyc2RheSwgSnVseSAw
NywgMjAxNiA0OjMwIFBNDQo+IFRvOiBZYW5nYm8gTHUNCj4gQ2M6IFNjb3R0IFdvb2Q7IGxpbnV4
cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOyBNYXJrIFJ1dGxhbmQ7IFVsZiBIYW5zc29uOw0KPiBs
aW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnOyBsaW51eC1pMmNAdmdlci5rZXJuZWwub3JnOyBs
aW51eC0NCj4gY2xrQHZnZXIua2VybmVsLm9yZzsgUWlhbmcgWmhhbzsgUnVzc2VsbCBLaW5nOyBC
aHVwZXNoIFNoYXJtYTsgSm9lcmcNCj4gUm9lZGVsOyBDbGF1ZGl1IE1hbm9pbDsgZGV2aWNldHJl
ZUB2Z2VyLmtlcm5lbC5vcmc7IEt1bWFyIEdhbGE7IFJvYg0KPiBIZXJyaW5nOyBTYW50b3NoIFNo
aWxpbWthcjsgbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnOw0KPiBuZXRkZXZA
dmdlci5rZXJuZWwub3JnOyBsaW51eC1tbWNAdmdlci5rZXJuZWwub3JnOyBYaWFvYm8gWGllOyBZ
YW5nLUxlbw0KPiBMaTsgaW9tbXVAbGlzdHMubGludXgtZm91bmRhdGlvbi5vcmcNCj4gU3ViamVj
dDogUmU6IFtQQVRDSCAyLzRdIHNvYzogZnNsOiBhZGQgR1VUUyBkcml2ZXIgZm9yIFFvcklRIHBs
YXRmb3Jtcw0KPiANCj4gT24gVGh1cnNkYXksIEp1bHkgNywgMjAxNiAyOjM1OjMzIEFNIENFU1Qg
WWFuZ2JvIEx1IHdyb3RlOg0KPiA+IEhpIEFybmQsDQo+ID4NCj4gPiBDb3VsZCB5b3UgcmVwbHkg
d2hlbiB5b3Ugc2VlIHRoZSBlbWFpbD8NCj4gPiBJZiB5b3VyIG1ldGhvZCBkb2VzbuKAmXQgcmVz
b2x2ZSB0aGUgcHJvYmxlbSwgd2Ugc3RpbGwgd2FudCB0byB1c2Ugb3VyDQo+IG9sZCBwYXRjaHNl
dC4NCj4gPg0KPiA+IFRoaXMgZ3V0cyBkcml2ZXIgaGFkIGJlZW4gZGlzY3Vzc2VkIGFib3V0IG9u
ZSB5ZWFyIGFuZCBibG9ja2VkIG1hbnkNCj4gd29ya2Fyb3VuZCB1cHN0cmVhbS4NCj4gPiBTbyBw
bGVhc2UgaGVscCB0byByZXZpZXcgYW5kIGNvbW1lbnQgc29vbi4NCj4gPg0KPiANCj4gSSBkb24n
dCByZWFsbHkgc2VlIGhvdyBtb3JlIGRpc2N1c3Npb24gaXMgZ29pbmcgdG8gaGVscCB1cyBoZXJl
LiBJIHRoaW5rDQo+IEkndmUgbWFkZSBpdCBwcmV0dHkgY2xlYXIgdGhhdCBJIGRvbid0IHdhbnQg
dG8gc2VlIGFub3RoZXIgcGxhdGZvcm0NCj4gc3BlY2lmaWMgd2F5IHRvIHJlYWQgYW4gU29DIHJl
dmlzaW9uIGFuZCBJJ3ZlIGV2ZW4gc2VudCBhIHByb29mLW9mLQ0KPiBjb25jZXB0IHBhdGNoIHRv
IHNob3cgaG93IHRoZSBpbnRlcmZhY2UgY2FuIHdvcmssIG5vdyBpdCdzIHVwIHRvIHlvdSB0bw0K
PiBmaXQgdGhlIGd1dHMgaGFyZHdhcmUgaW50byB0aGF0IGFuZCBzZW5kIGEgbmV3IHBhdGNoIHNl
cmllcy4NCj4gDQo+IAlBcm5kDQoNCkkgdGhpbmsgeW91ciBwcm9vZi1vZi1jb25jZXB0IHBhdGNo
IGlzIHN0aWxsIGluIGRpc2N1c3Npb24uIFNvbWUgYW5zd2VycyBhcmUgbmVlZGVkIGZyb20geW91
IHRvDQphZGRyZXNzIFNjb3R0J3MgY29tbWVudHMgb24geW91ciBwYXRjaHNldC4gSGF2ZSB5b3Ug
cmVhY2hlZCBhbiBhZ3JlZW1lbnQ/DQoNClRoYW5rcy4NCg0KLSBZYW5nYm8gTHUNCg0KDQoNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFybS1r
ZXJuZWwgbWFpbGluZyBsaXN0CmxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpo
dHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJu
ZWwK
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-07-08 3:05 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-07-08 3:05 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Scott Wood, linuxppc-dev, Mark Rutland, Ulf Hansson,
linux-kernel, linux-i2c, linux-clk, Qiang Zhao, Russell King,
Bhupesh Sharma, Joerg Roedel, Claudiu Manoil, devicetree,
Kumar Gala, Rob Herring, Santosh Shilimkar, linux-arm-kernel,
netdev, linux-mmc, Xiaobo Xie, Yang-Leo Li, iommu
SGkgQXJuZCwNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFybmQg
QmVyZ21hbm4gW21haWx0bzphcm5kQGFybmRiLmRlXQ0KPiBTZW50OiBUaHVyc2RheSwgSnVseSAw
NywgMjAxNiA0OjMwIFBNDQo+IFRvOiBZYW5nYm8gTHUNCj4gQ2M6IFNjb3R0IFdvb2Q7IGxpbnV4
cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOyBNYXJrIFJ1dGxhbmQ7IFVsZiBIYW5zc29uOw0KPiBs
aW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnOyBsaW51eC1pMmNAdmdlci5rZXJuZWwub3JnOyBs
aW51eC0NCj4gY2xrQHZnZXIua2VybmVsLm9yZzsgUWlhbmcgWmhhbzsgUnVzc2VsbCBLaW5nOyBC
aHVwZXNoIFNoYXJtYTsgSm9lcmcNCj4gUm9lZGVsOyBDbGF1ZGl1IE1hbm9pbDsgZGV2aWNldHJl
ZUB2Z2VyLmtlcm5lbC5vcmc7IEt1bWFyIEdhbGE7IFJvYg0KPiBIZXJyaW5nOyBTYW50b3NoIFNo
aWxpbWthcjsgbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnOw0KPiBuZXRkZXZA
dmdlci5rZXJuZWwub3JnOyBsaW51eC1tbWNAdmdlci5rZXJuZWwub3JnOyBYaWFvYm8gWGllOyBZ
YW5nLUxlbw0KPiBMaTsgaW9tbXVAbGlzdHMubGludXgtZm91bmRhdGlvbi5vcmcNCj4gU3ViamVj
dDogUmU6IFtQQVRDSCAyLzRdIHNvYzogZnNsOiBhZGQgR1VUUyBkcml2ZXIgZm9yIFFvcklRIHBs
YXRmb3Jtcw0KPiANCj4gT24gVGh1cnNkYXksIEp1bHkgNywgMjAxNiAyOjM1OjMzIEFNIENFU1Qg
WWFuZ2JvIEx1IHdyb3RlOg0KPiA+IEhpIEFybmQsDQo+ID4NCj4gPiBDb3VsZCB5b3UgcmVwbHkg
d2hlbiB5b3Ugc2VlIHRoZSBlbWFpbD8NCj4gPiBJZiB5b3VyIG1ldGhvZCBkb2VzbuKAmXQgcmVz
b2x2ZSB0aGUgcHJvYmxlbSwgd2Ugc3RpbGwgd2FudCB0byB1c2Ugb3VyDQo+IG9sZCBwYXRjaHNl
dC4NCj4gPg0KPiA+IFRoaXMgZ3V0cyBkcml2ZXIgaGFkIGJlZW4gZGlzY3Vzc2VkIGFib3V0IG9u
ZSB5ZWFyIGFuZCBibG9ja2VkIG1hbnkNCj4gd29ya2Fyb3VuZCB1cHN0cmVhbS4NCj4gPiBTbyBw
bGVhc2UgaGVscCB0byByZXZpZXcgYW5kIGNvbW1lbnQgc29vbi4NCj4gPg0KPiANCj4gSSBkb24n
dCByZWFsbHkgc2VlIGhvdyBtb3JlIGRpc2N1c3Npb24gaXMgZ29pbmcgdG8gaGVscCB1cyBoZXJl
LiBJIHRoaW5rDQo+IEkndmUgbWFkZSBpdCBwcmV0dHkgY2xlYXIgdGhhdCBJIGRvbid0IHdhbnQg
dG8gc2VlIGFub3RoZXIgcGxhdGZvcm0NCj4gc3BlY2lmaWMgd2F5IHRvIHJlYWQgYW4gU29DIHJl
dmlzaW9uIGFuZCBJJ3ZlIGV2ZW4gc2VudCBhIHByb29mLW9mLQ0KPiBjb25jZXB0IHBhdGNoIHRv
IHNob3cgaG93IHRoZSBpbnRlcmZhY2UgY2FuIHdvcmssIG5vdyBpdCdzIHVwIHRvIHlvdSB0bw0K
PiBmaXQgdGhlIGd1dHMgaGFyZHdhcmUgaW50byB0aGF0IGFuZCBzZW5kIGEgbmV3IHBhdGNoIHNl
cmllcy4NCj4gDQo+IAlBcm5kDQoNCkkgdGhpbmsgeW91ciBwcm9vZi1vZi1jb25jZXB0IHBhdGNo
IGlzIHN0aWxsIGluIGRpc2N1c3Npb24uIFNvbWUgYW5zd2VycyBhcmUgbmVlZGVkIGZyb20geW91
IHRvDQphZGRyZXNzIFNjb3R0J3MgY29tbWVudHMgb24geW91ciBwYXRjaHNldC4gSGF2ZSB5b3Ug
cmVhY2hlZCBhbiBhZ3JlZW1lbnQ/DQoNClRoYW5rcy4NCg0KLSBZYW5nYm8gTHUNCg0KDQoNCg==
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-07-08 3:05 ` Yangbo Lu
0 siblings, 0 replies; 185+ messages in thread
From: Yangbo Lu @ 2016-07-08 3:05 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Thursday, July 07, 2016 4:30 PM
> To: Yangbo Lu
> Cc: Scott Wood; linuxppc-dev at lists.ozlabs.org; Mark Rutland; Ulf Hansson;
> linux-kernel at vger.kernel.org; linux-i2c at vger.kernel.org; linux-
> clk at vger.kernel.org; Qiang Zhao; Russell King; Bhupesh Sharma; Joerg
> Roedel; Claudiu Manoil; devicetree at vger.kernel.org; Kumar Gala; Rob
> Herring; Santosh Shilimkar; linux-arm-kernel at lists.infradead.org;
> netdev at vger.kernel.org; linux-mmc at vger.kernel.org; Xiaobo Xie; Yang-Leo
> Li; iommu at lists.linux-foundation.org
> Subject: Re: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms
>
> On Thursday, July 7, 2016 2:35:33 AM CEST Yangbo Lu wrote:
> > Hi Arnd,
> >
> > Could you reply when you see the email?
> > If your method doesn?t resolve the problem, we still want to use our
> old patchset.
> >
> > This guts driver had been discussed about one year and blocked many
> workaround upstream.
> > So please help to review and comment soon.
> >
>
> I don't really see how more discussion is going to help us here. I think
> I've made it pretty clear that I don't want to see another platform
> specific way to read an SoC revision and I've even sent a proof-of-
> concept patch to show how the interface can work, now it's up to you to
> fit the guts hardware into that and send a new patch series.
>
> Arnd
I think your proof-of-concept patch is still in discussion. Some answers are needed from you to
address Scott's comments on your patchset. Have you reached an agreement?
Thanks.
- Yangbo Lu
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [v10, 3/7] soc: fsl: add GUTS driver for QorIQ platforms
2016-05-05 3:12 ` Yangbo Lu
(?)
(?)
@ 2016-07-15 16:43 ` Paul Gortmaker
-1 siblings, 0 replies; 185+ messages in thread
From: Paul Gortmaker @ 2016-07-15 16:43 UTC (permalink / raw)
To: Yangbo Lu
Cc: linux-mmc, linuxppc-dev, devicetree, linux-arm-kernel, LKML,
linux-clk, linux-i2c, iommu, netdev, ulf.hansson, Scott Wood,
Mark Rutland, Rob Herring, Russell King, Jochen Friedrich,
Joerg Roedel, Claudiu Manoil, Bhupesh Sharma, Qiang Zhao,
Kumar Gala, Santosh Shilimkar, leoyang.li, xiaobo.xie
On Wed, May 4, 2016 at 11:12 PM, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> The global utilities block controls power management, I/O device
> enabling, power-onreset(POR) configuration monitoring, alternate
> function selection for multiplexed signals,and clock control.
>
> This patch adds GUTS driver to manage and access global utilities
> block.
>
> Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> Acked-by: Scott Wood <oss@buserror.net>
> ---
> Changes for v4:
> - Added this patch
> Changes for v5:
> - Modified copyright info
> - Changed MODULE_LICENSE to GPL
> - Changed EXPORT_SYMBOL_GPL to EXPORT_SYMBOL
> - Made FSL_GUTS user-invisible
> - Added a complete compatible list for GUTS
> - Stored guts info in file-scope variable
> - Added mfspr() getting SVR
> - Redefined GUTS APIs
> - Called fsl_guts_init rather than using platform driver
> - Removed useless parentheses
> - Removed useless 'extern' key words
> Changes for v6:
> - Made guts thread safe in fsl_guts_init
> Changes for v7:
> - Removed 'ifdef' for function declaration in guts.h
> Changes for v8:
> - Fixes lines longer than 80 characters checkpatch issue
> - Added 'Acked-by: Scott Wood'
> Changes for v9:
> - None
> Changes for v10:
> - None
> ---
> drivers/soc/Kconfig | 2 +-
> drivers/soc/fsl/Kconfig | 8 +++
> drivers/soc/fsl/Makefile | 1 +
> drivers/soc/fsl/guts.c | 119 ++++++++++++++++++++++++++++++++++++++++++++
> include/linux/fsl/guts.h | 126 +++++++++++++++++++++++++++++------------------
> 5 files changed, 207 insertions(+), 49 deletions(-)
> create mode 100644 drivers/soc/fsl/Kconfig
> create mode 100644 drivers/soc/fsl/guts.c
>
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index cb58ef0..7106463 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -2,7 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
>
> source "drivers/soc/bcm/Kconfig"
> source "drivers/soc/brcmstb/Kconfig"
> -source "drivers/soc/fsl/qe/Kconfig"
> +source "drivers/soc/fsl/Kconfig"
> source "drivers/soc/mediatek/Kconfig"
> source "drivers/soc/qcom/Kconfig"
> source "drivers/soc/rockchip/Kconfig"
> diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
> new file mode 100644
> index 0000000..b313759
> --- /dev/null
> +++ b/drivers/soc/fsl/Kconfig
> @@ -0,0 +1,8 @@
> +#
> +# Freescale SOC drivers
> +#
> +
> +source "drivers/soc/fsl/qe/Kconfig"
> +
> +config FSL_GUTS
> + bool
> diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
> index 203307f..02afb7f 100644
> --- a/drivers/soc/fsl/Makefile
> +++ b/drivers/soc/fsl/Makefile
> @@ -4,3 +4,4 @@
>
> obj-$(CONFIG_QUICC_ENGINE) += qe/
> obj-$(CONFIG_CPM) += qe/
> +obj-$(CONFIG_FSL_GUTS) += guts.o
> diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> new file mode 100644
> index 0000000..fa155e6
> --- /dev/null
> +++ b/drivers/soc/fsl/guts.c
> @@ -0,0 +1,119 @@
> +/*
> + * Freescale QorIQ Platforms GUTS Driver
> + *
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <linux/io.h>
> +#include <linux/module.h>
Seems there was lots of discussion on this. If it does end up being
resent, it would be nice to get the module.h and other modular stuff
gone since it is a bool Kconfig.
Thanks,
Paul.
--
> +#include <linux/slab.h>
> +#include <linux/mutex.h>
> +#include <linux/of_address.h>
> +#include <linux/of_platform.h>
> +#include <linux/fsl/guts.h>
> +
>
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [v10, 3/7] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-07-15 16:43 ` Paul Gortmaker
0 siblings, 0 replies; 185+ messages in thread
From: Paul Gortmaker @ 2016-07-15 16:43 UTC (permalink / raw)
To: Yangbo Lu
Cc: linux-mmc, linuxppc-dev, devicetree, linux-arm-kernel, LKML,
linux-clk, linux-i2c, iommu, netdev, ulf.hansson, Scott Wood,
Mark Rutland, Rob Herring, Russell King, Jochen Friedrich,
Joerg Roedel, Claudiu Manoil, Bhupesh Sharma, Qiang Zhao,
Kumar Gala, Santosh Shilimkar, leoyang.li, xiaobo.xie
On Wed, May 4, 2016 at 11:12 PM, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> The global utilities block controls power management, I/O device
> enabling, power-onreset(POR) configuration monitoring, alternate
> function selection for multiplexed signals,and clock control.
>
> This patch adds GUTS driver to manage and access global utilities
> block.
>
> Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> Acked-by: Scott Wood <oss@buserror.net>
> ---
> Changes for v4:
> - Added this patch
> Changes for v5:
> - Modified copyright info
> - Changed MODULE_LICENSE to GPL
> - Changed EXPORT_SYMBOL_GPL to EXPORT_SYMBOL
> - Made FSL_GUTS user-invisible
> - Added a complete compatible list for GUTS
> - Stored guts info in file-scope variable
> - Added mfspr() getting SVR
> - Redefined GUTS APIs
> - Called fsl_guts_init rather than using platform driver
> - Removed useless parentheses
> - Removed useless 'extern' key words
> Changes for v6:
> - Made guts thread safe in fsl_guts_init
> Changes for v7:
> - Removed 'ifdef' for function declaration in guts.h
> Changes for v8:
> - Fixes lines longer than 80 characters checkpatch issue
> - Added 'Acked-by: Scott Wood'
> Changes for v9:
> - None
> Changes for v10:
> - None
> ---
> drivers/soc/Kconfig | 2 +-
> drivers/soc/fsl/Kconfig | 8 +++
> drivers/soc/fsl/Makefile | 1 +
> drivers/soc/fsl/guts.c | 119 ++++++++++++++++++++++++++++++++++++++++++++
> include/linux/fsl/guts.h | 126 +++++++++++++++++++++++++++++------------------
> 5 files changed, 207 insertions(+), 49 deletions(-)
> create mode 100644 drivers/soc/fsl/Kconfig
> create mode 100644 drivers/soc/fsl/guts.c
>
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index cb58ef0..7106463 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -2,7 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
>
> source "drivers/soc/bcm/Kconfig"
> source "drivers/soc/brcmstb/Kconfig"
> -source "drivers/soc/fsl/qe/Kconfig"
> +source "drivers/soc/fsl/Kconfig"
> source "drivers/soc/mediatek/Kconfig"
> source "drivers/soc/qcom/Kconfig"
> source "drivers/soc/rockchip/Kconfig"
> diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
> new file mode 100644
> index 0000000..b313759
> --- /dev/null
> +++ b/drivers/soc/fsl/Kconfig
> @@ -0,0 +1,8 @@
> +#
> +# Freescale SOC drivers
> +#
> +
> +source "drivers/soc/fsl/qe/Kconfig"
> +
> +config FSL_GUTS
> + bool
> diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
> index 203307f..02afb7f 100644
> --- a/drivers/soc/fsl/Makefile
> +++ b/drivers/soc/fsl/Makefile
> @@ -4,3 +4,4 @@
>
> obj-$(CONFIG_QUICC_ENGINE) += qe/
> obj-$(CONFIG_CPM) += qe/
> +obj-$(CONFIG_FSL_GUTS) += guts.o
> diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> new file mode 100644
> index 0000000..fa155e6
> --- /dev/null
> +++ b/drivers/soc/fsl/guts.c
> @@ -0,0 +1,119 @@
> +/*
> + * Freescale QorIQ Platforms GUTS Driver
> + *
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <linux/io.h>
> +#include <linux/module.h>
Seems there was lots of discussion on this. If it does end up being
resent, it would be nice to get the module.h and other modular stuff
gone since it is a bool Kconfig.
Thanks,
Paul.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [v10, 3/7] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-07-15 16:43 ` Paul Gortmaker
0 siblings, 0 replies; 185+ messages in thread
From: Paul Gortmaker @ 2016-07-15 16:43 UTC (permalink / raw)
To: Yangbo Lu
Cc: linux-mmc, linuxppc-dev, devicetree, linux-arm-kernel, LKML,
linux-clk, linux-i2c, iommu, netdev, ulf.hansson, Scott Wood,
Mark Rutland, Rob Herring, Russell King, Jochen Friedrich,
Joerg Roedel, Claudiu Manoil, Bhupesh Sharma, Qiang Zhao,
Kumar Gala, Santosh Shilimkar, leoyang.li, xiaobo.xie
On Wed, May 4, 2016 at 11:12 PM, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> The global utilities block controls power management, I/O device
> enabling, power-onreset(POR) configuration monitoring, alternate
> function selection for multiplexed signals,and clock control.
>
> This patch adds GUTS driver to manage and access global utilities
> block.
>
> Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> Acked-by: Scott Wood <oss@buserror.net>
> ---
> Changes for v4:
> - Added this patch
> Changes for v5:
> - Modified copyright info
> - Changed MODULE_LICENSE to GPL
> - Changed EXPORT_SYMBOL_GPL to EXPORT_SYMBOL
> - Made FSL_GUTS user-invisible
> - Added a complete compatible list for GUTS
> - Stored guts info in file-scope variable
> - Added mfspr() getting SVR
> - Redefined GUTS APIs
> - Called fsl_guts_init rather than using platform driver
> - Removed useless parentheses
> - Removed useless 'extern' key words
> Changes for v6:
> - Made guts thread safe in fsl_guts_init
> Changes for v7:
> - Removed 'ifdef' for function declaration in guts.h
> Changes for v8:
> - Fixes lines longer than 80 characters checkpatch issue
> - Added 'Acked-by: Scott Wood'
> Changes for v9:
> - None
> Changes for v10:
> - None
> ---
> drivers/soc/Kconfig | 2 +-
> drivers/soc/fsl/Kconfig | 8 +++
> drivers/soc/fsl/Makefile | 1 +
> drivers/soc/fsl/guts.c | 119 ++++++++++++++++++++++++++++++++++++++++++++
> include/linux/fsl/guts.h | 126 +++++++++++++++++++++++++++++------------------
> 5 files changed, 207 insertions(+), 49 deletions(-)
> create mode 100644 drivers/soc/fsl/Kconfig
> create mode 100644 drivers/soc/fsl/guts.c
>
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index cb58ef0..7106463 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -2,7 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
>
> source "drivers/soc/bcm/Kconfig"
> source "drivers/soc/brcmstb/Kconfig"
> -source "drivers/soc/fsl/qe/Kconfig"
> +source "drivers/soc/fsl/Kconfig"
> source "drivers/soc/mediatek/Kconfig"
> source "drivers/soc/qcom/Kconfig"
> source "drivers/soc/rockchip/Kconfig"
> diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
> new file mode 100644
> index 0000000..b313759
> --- /dev/null
> +++ b/drivers/soc/fsl/Kconfig
> @@ -0,0 +1,8 @@
> +#
> +# Freescale SOC drivers
> +#
> +
> +source "drivers/soc/fsl/qe/Kconfig"
> +
> +config FSL_GUTS
> + bool
> diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
> index 203307f..02afb7f 100644
> --- a/drivers/soc/fsl/Makefile
> +++ b/drivers/soc/fsl/Makefile
> @@ -4,3 +4,4 @@
>
> obj-$(CONFIG_QUICC_ENGINE) += qe/
> obj-$(CONFIG_CPM) += qe/
> +obj-$(CONFIG_FSL_GUTS) += guts.o
> diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> new file mode 100644
> index 0000000..fa155e6
> --- /dev/null
> +++ b/drivers/soc/fsl/guts.c
> @@ -0,0 +1,119 @@
> +/*
> + * Freescale QorIQ Platforms GUTS Driver
> + *
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <linux/io.h>
> +#include <linux/module.h>
Seems there was lots of discussion on this. If it does end up being
resent, it would be nice to get the module.h and other modular stuff
gone since it is a bool Kconfig.
Thanks,
Paul.
--
> +#include <linux/slab.h>
> +#include <linux/mutex.h>
> +#include <linux/of_address.h>
> +#include <linux/of_platform.h>
> +#include <linux/fsl/guts.h>
> +
>
^ permalink raw reply [flat|nested] 185+ messages in thread
* [v10, 3/7] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-07-15 16:43 ` Paul Gortmaker
0 siblings, 0 replies; 185+ messages in thread
From: Paul Gortmaker @ 2016-07-15 16:43 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, May 4, 2016 at 11:12 PM, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> The global utilities block controls power management, I/O device
> enabling, power-onreset(POR) configuration monitoring, alternate
> function selection for multiplexed signals,and clock control.
>
> This patch adds GUTS driver to manage and access global utilities
> block.
>
> Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> Acked-by: Scott Wood <oss@buserror.net>
> ---
> Changes for v4:
> - Added this patch
> Changes for v5:
> - Modified copyright info
> - Changed MODULE_LICENSE to GPL
> - Changed EXPORT_SYMBOL_GPL to EXPORT_SYMBOL
> - Made FSL_GUTS user-invisible
> - Added a complete compatible list for GUTS
> - Stored guts info in file-scope variable
> - Added mfspr() getting SVR
> - Redefined GUTS APIs
> - Called fsl_guts_init rather than using platform driver
> - Removed useless parentheses
> - Removed useless 'extern' key words
> Changes for v6:
> - Made guts thread safe in fsl_guts_init
> Changes for v7:
> - Removed 'ifdef' for function declaration in guts.h
> Changes for v8:
> - Fixes lines longer than 80 characters checkpatch issue
> - Added 'Acked-by: Scott Wood'
> Changes for v9:
> - None
> Changes for v10:
> - None
> ---
> drivers/soc/Kconfig | 2 +-
> drivers/soc/fsl/Kconfig | 8 +++
> drivers/soc/fsl/Makefile | 1 +
> drivers/soc/fsl/guts.c | 119 ++++++++++++++++++++++++++++++++++++++++++++
> include/linux/fsl/guts.h | 126 +++++++++++++++++++++++++++++------------------
> 5 files changed, 207 insertions(+), 49 deletions(-)
> create mode 100644 drivers/soc/fsl/Kconfig
> create mode 100644 drivers/soc/fsl/guts.c
>
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index cb58ef0..7106463 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -2,7 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
>
> source "drivers/soc/bcm/Kconfig"
> source "drivers/soc/brcmstb/Kconfig"
> -source "drivers/soc/fsl/qe/Kconfig"
> +source "drivers/soc/fsl/Kconfig"
> source "drivers/soc/mediatek/Kconfig"
> source "drivers/soc/qcom/Kconfig"
> source "drivers/soc/rockchip/Kconfig"
> diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
> new file mode 100644
> index 0000000..b313759
> --- /dev/null
> +++ b/drivers/soc/fsl/Kconfig
> @@ -0,0 +1,8 @@
> +#
> +# Freescale SOC drivers
> +#
> +
> +source "drivers/soc/fsl/qe/Kconfig"
> +
> +config FSL_GUTS
> + bool
> diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
> index 203307f..02afb7f 100644
> --- a/drivers/soc/fsl/Makefile
> +++ b/drivers/soc/fsl/Makefile
> @@ -4,3 +4,4 @@
>
> obj-$(CONFIG_QUICC_ENGINE) += qe/
> obj-$(CONFIG_CPM) += qe/
> +obj-$(CONFIG_FSL_GUTS) += guts.o
> diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> new file mode 100644
> index 0000000..fa155e6
> --- /dev/null
> +++ b/drivers/soc/fsl/guts.c
> @@ -0,0 +1,119 @@
> +/*
> + * Freescale QorIQ Platforms GUTS Driver
> + *
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <linux/io.h>
> +#include <linux/module.h>
Seems there was lots of discussion on this. If it does end up being
resent, it would be nice to get the module.h and other modular stuff
gone since it is a bool Kconfig.
Thanks,
Paul.
--
> +#include <linux/slab.h>
> +#include <linux/mutex.h>
> +#include <linux/of_address.h>
> +#include <linux/of_platform.h>
> +#include <linux/fsl/guts.h>
> +
>
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [v10, 3/7] soc: fsl: add GUTS driver for QorIQ platforms
2016-07-15 16:43 ` Paul Gortmaker
(?)
(?)
@ 2016-07-15 19:12 ` Scott Wood
-1 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-07-15 19:12 UTC (permalink / raw)
To: Paul Gortmaker, Yangbo Lu
Cc: linux-mmc, linuxppc-dev, devicetree, linux-arm-kernel, LKML,
linux-clk, linux-i2c, iommu, netdev, ulf.hansson, Mark Rutland,
Rob Herring, Russell King, Jochen Friedrich, Joerg Roedel,
Claudiu Manoil, Bhupesh Sharma, Qiang Zhao, Kumar Gala,
Santosh Shilimkar, leoyang.li, xiaobo.xie
On Fri, 2016-07-15 at 12:43 -0400, Paul Gortmaker wrote:
> On Wed, May 4, 2016 at 11:12 PM, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> >
> > The global utilities block controls power management, I/O device
> > enabling, power-onreset(POR) configuration monitoring, alternate
> > function selection for multiplexed signals,and clock control.
> >
> > This patch adds GUTS driver to manage and access global utilities
> > block.
> >
> > Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> > Acked-by: Scott Wood <oss@buserror.net>
> > ---
> > Changes for v4:
> > - Added this patch
> > Changes for v5:
> > - Modified copyright info
> > - Changed MODULE_LICENSE to GPL
> > - Changed EXPORT_SYMBOL_GPL to EXPORT_SYMBOL
> > - Made FSL_GUTS user-invisible
> > - Added a complete compatible list for GUTS
> > - Stored guts info in file-scope variable
> > - Added mfspr() getting SVR
> > - Redefined GUTS APIs
> > - Called fsl_guts_init rather than using platform driver
> > - Removed useless parentheses
> > - Removed useless 'extern' key words
> > Changes for v6:
> > - Made guts thread safe in fsl_guts_init
> > Changes for v7:
> > - Removed 'ifdef' for function declaration in guts.h
> > Changes for v8:
> > - Fixes lines longer than 80 characters checkpatch issue
> > - Added 'Acked-by: Scott Wood'
> > Changes for v9:
> > - None
> > Changes for v10:
> > - None
> > ---
> > drivers/soc/Kconfig | 2 +-
> > drivers/soc/fsl/Kconfig | 8 +++
> > drivers/soc/fsl/Makefile | 1 +
> > drivers/soc/fsl/guts.c | 119
> > ++++++++++++++++++++++++++++++++++++++++++++
> > include/linux/fsl/guts.h | 126 +++++++++++++++++++++++++++++-------------
> > -----
> > 5 files changed, 207 insertions(+), 49 deletions(-)
> > create mode 100644 drivers/soc/fsl/Kconfig
> > create mode 100644 drivers/soc/fsl/guts.c
> >
> > diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> > index cb58ef0..7106463 100644
> > --- a/drivers/soc/Kconfig
> > +++ b/drivers/soc/Kconfig
> > @@ -2,7 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
> >
> > source "drivers/soc/bcm/Kconfig"
> > source "drivers/soc/brcmstb/Kconfig"
> > -source "drivers/soc/fsl/qe/Kconfig"
> > +source "drivers/soc/fsl/Kconfig"
> > source "drivers/soc/mediatek/Kconfig"
> > source "drivers/soc/qcom/Kconfig"
> > source "drivers/soc/rockchip/Kconfig"
> > diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
> > new file mode 100644
> > index 0000000..b313759
> > --- /dev/null
> > +++ b/drivers/soc/fsl/Kconfig
> > @@ -0,0 +1,8 @@
> > +#
> > +# Freescale SOC drivers
> > +#
> > +
> > +source "drivers/soc/fsl/qe/Kconfig"
> > +
> > +config FSL_GUTS
> > + bool
> > diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
> > index 203307f..02afb7f 100644
> > --- a/drivers/soc/fsl/Makefile
> > +++ b/drivers/soc/fsl/Makefile
> > @@ -4,3 +4,4 @@
> >
> > obj-$(CONFIG_QUICC_ENGINE) += qe/
> > obj-$(CONFIG_CPM) += qe/
> > +obj-$(CONFIG_FSL_GUTS) += guts.o
> > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> > new file mode 100644
> > index 0000000..fa155e6
> > --- /dev/null
> > +++ b/drivers/soc/fsl/guts.c
> > @@ -0,0 +1,119 @@
> > +/*
> > + * Freescale QorIQ Platforms GUTS Driver
> > + *
> > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +
> > +#include <linux/io.h>
> > +#include <linux/module.h>
> Seems there was lots of discussion on this. If it does end up being
> resent, it would be nice to get the module.h and other modular stuff
> gone since it is a bool Kconfig.
I plan to resend just the GUTS driver portion and send it through the PPC
tree.
I don't see any modular stuff in there besides the linux/module.h include.
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [v10, 3/7] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-07-15 19:12 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-07-15 19:12 UTC (permalink / raw)
To: Paul Gortmaker, Yangbo Lu
Cc: linux-mmc, linuxppc-dev, devicetree, linux-arm-kernel, LKML,
linux-clk, linux-i2c, iommu, netdev, ulf.hansson, Mark Rutland,
Rob Herring, Russell King, Jochen Friedrich, Joerg Roedel,
Claudiu Manoil, Bhupesh Sharma, Qiang Zhao, Kumar Gala,
Santosh Shilimkar, leoyang.li, xiaobo.xie
On Fri, 2016-07-15 at 12:43 -0400, Paul Gortmaker wrote:
> On Wed, May 4, 2016 at 11:12 PM, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> >
> > The global utilities block controls power management, I/O device
> > enabling, power-onreset(POR) configuration monitoring, alternate
> > function selection for multiplexed signals,and clock control.
> >
> > This patch adds GUTS driver to manage and access global utilities
> > block.
> >
> > Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> > Acked-by: Scott Wood <oss@buserror.net>
> > ---
> > Changes for v4:
> > - Added this patch
> > Changes for v5:
> > - Modified copyright info
> > - Changed MODULE_LICENSE to GPL
> > - Changed EXPORT_SYMBOL_GPL to EXPORT_SYMBOL
> > - Made FSL_GUTS user-invisible
> > - Added a complete compatible list for GUTS
> > - Stored guts info in file-scope variable
> > - Added mfspr() getting SVR
> > - Redefined GUTS APIs
> > - Called fsl_guts_init rather than using platform driver
> > - Removed useless parentheses
> > - Removed useless 'extern' key words
> > Changes for v6:
> > - Made guts thread safe in fsl_guts_init
> > Changes for v7:
> > - Removed 'ifdef' for function declaration in guts.h
> > Changes for v8:
> > - Fixes lines longer than 80 characters checkpatch issue
> > - Added 'Acked-by: Scott Wood'
> > Changes for v9:
> > - None
> > Changes for v10:
> > - None
> > ---
> > drivers/soc/Kconfig | 2 +-
> > drivers/soc/fsl/Kconfig | 8 +++
> > drivers/soc/fsl/Makefile | 1 +
> > drivers/soc/fsl/guts.c | 119
> > ++++++++++++++++++++++++++++++++++++++++++++
> > include/linux/fsl/guts.h | 126 +++++++++++++++++++++++++++++-------------
> > -----
> > 5 files changed, 207 insertions(+), 49 deletions(-)
> > create mode 100644 drivers/soc/fsl/Kconfig
> > create mode 100644 drivers/soc/fsl/guts.c
> >
> > diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> > index cb58ef0..7106463 100644
> > --- a/drivers/soc/Kconfig
> > +++ b/drivers/soc/Kconfig
> > @@ -2,7 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
> >
> > source "drivers/soc/bcm/Kconfig"
> > source "drivers/soc/brcmstb/Kconfig"
> > -source "drivers/soc/fsl/qe/Kconfig"
> > +source "drivers/soc/fsl/Kconfig"
> > source "drivers/soc/mediatek/Kconfig"
> > source "drivers/soc/qcom/Kconfig"
> > source "drivers/soc/rockchip/Kconfig"
> > diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
> > new file mode 100644
> > index 0000000..b313759
> > --- /dev/null
> > +++ b/drivers/soc/fsl/Kconfig
> > @@ -0,0 +1,8 @@
> > +#
> > +# Freescale SOC drivers
> > +#
> > +
> > +source "drivers/soc/fsl/qe/Kconfig"
> > +
> > +config FSL_GUTS
> > + bool
> > diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
> > index 203307f..02afb7f 100644
> > --- a/drivers/soc/fsl/Makefile
> > +++ b/drivers/soc/fsl/Makefile
> > @@ -4,3 +4,4 @@
> >
> > obj-$(CONFIG_QUICC_ENGINE) += qe/
> > obj-$(CONFIG_CPM) += qe/
> > +obj-$(CONFIG_FSL_GUTS) += guts.o
> > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> > new file mode 100644
> > index 0000000..fa155e6
> > --- /dev/null
> > +++ b/drivers/soc/fsl/guts.c
> > @@ -0,0 +1,119 @@
> > +/*
> > + * Freescale QorIQ Platforms GUTS Driver
> > + *
> > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +
> > +#include <linux/io.h>
> > +#include <linux/module.h>
> Seems there was lots of discussion on this. If it does end up being
> resent, it would be nice to get the module.h and other modular stuff
> gone since it is a bool Kconfig.
I plan to resend just the GUTS driver portion and send it through the PPC
tree.
I don't see any modular stuff in there besides the linux/module.h include.
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [v10, 3/7] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-07-15 19:12 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-07-15 19:12 UTC (permalink / raw)
To: Paul Gortmaker, Yangbo Lu
Cc: linux-mmc, linuxppc-dev, devicetree, linux-arm-kernel, LKML,
linux-clk, linux-i2c, iommu, netdev, ulf.hansson, Mark Rutland,
Rob Herring, Russell King, Jochen Friedrich, Joerg Roedel,
Claudiu Manoil, Bhupesh Sharma, Qiang Zhao, Kumar Gala,
Santosh Shilimkar, leoyang.li, xiaobo.xie
On Fri, 2016-07-15 at 12:43 -0400, Paul Gortmaker wrote:
> On Wed, May 4, 2016 at 11:12 PM, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> >
> > The global utilities block controls power management, I/O device
> > enabling, power-onreset(POR) configuration monitoring, alternate
> > function selection for multiplexed signals,and clock control.
> >
> > This patch adds GUTS driver to manage and access global utilities
> > block.
> >
> > Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> > Acked-by: Scott Wood <oss@buserror.net>
> > ---
> > Changes for v4:
> > - Added this patch
> > Changes for v5:
> > - Modified copyright info
> > - Changed MODULE_LICENSE to GPL
> > - Changed EXPORT_SYMBOL_GPL to EXPORT_SYMBOL
> > - Made FSL_GUTS user-invisible
> > - Added a complete compatible list for GUTS
> > - Stored guts info in file-scope variable
> > - Added mfspr() getting SVR
> > - Redefined GUTS APIs
> > - Called fsl_guts_init rather than using platform driver
> > - Removed useless parentheses
> > - Removed useless 'extern' key words
> > Changes for v6:
> > - Made guts thread safe in fsl_guts_init
> > Changes for v7:
> > - Removed 'ifdef' for function declaration in guts.h
> > Changes for v8:
> > - Fixes lines longer than 80 characters checkpatch issue
> > - Added 'Acked-by: Scott Wood'
> > Changes for v9:
> > - None
> > Changes for v10:
> > - None
> > ---
> > drivers/soc/Kconfig | 2 +-
> > drivers/soc/fsl/Kconfig | 8 +++
> > drivers/soc/fsl/Makefile | 1 +
> > drivers/soc/fsl/guts.c | 119
> > ++++++++++++++++++++++++++++++++++++++++++++
> > include/linux/fsl/guts.h | 126 +++++++++++++++++++++++++++++-------------
> > -----
> > 5 files changed, 207 insertions(+), 49 deletions(-)
> > create mode 100644 drivers/soc/fsl/Kconfig
> > create mode 100644 drivers/soc/fsl/guts.c
> >
> > diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> > index cb58ef0..7106463 100644
> > --- a/drivers/soc/Kconfig
> > +++ b/drivers/soc/Kconfig
> > @@ -2,7 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
> >
> > source "drivers/soc/bcm/Kconfig"
> > source "drivers/soc/brcmstb/Kconfig"
> > -source "drivers/soc/fsl/qe/Kconfig"
> > +source "drivers/soc/fsl/Kconfig"
> > source "drivers/soc/mediatek/Kconfig"
> > source "drivers/soc/qcom/Kconfig"
> > source "drivers/soc/rockchip/Kconfig"
> > diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
> > new file mode 100644
> > index 0000000..b313759
> > --- /dev/null
> > +++ b/drivers/soc/fsl/Kconfig
> > @@ -0,0 +1,8 @@
> > +#
> > +# Freescale SOC drivers
> > +#
> > +
> > +source "drivers/soc/fsl/qe/Kconfig"
> > +
> > +config FSL_GUTS
> > + bool
> > diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
> > index 203307f..02afb7f 100644
> > --- a/drivers/soc/fsl/Makefile
> > +++ b/drivers/soc/fsl/Makefile
> > @@ -4,3 +4,4 @@
> >
> > obj-$(CONFIG_QUICC_ENGINE) += qe/
> > obj-$(CONFIG_CPM) += qe/
> > +obj-$(CONFIG_FSL_GUTS) += guts.o
> > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> > new file mode 100644
> > index 0000000..fa155e6
> > --- /dev/null
> > +++ b/drivers/soc/fsl/guts.c
> > @@ -0,0 +1,119 @@
> > +/*
> > + * Freescale QorIQ Platforms GUTS Driver
> > + *
> > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +
> > +#include <linux/io.h>
> > +#include <linux/module.h>
> Seems there was lots of discussion on this. If it does end up being
> resent, it would be nice to get the module.h and other modular stuff
> gone since it is a bool Kconfig.
I plan to resend just the GUTS driver portion and send it through the PPC
tree.
I don't see any modular stuff in there besides the linux/module.h include.
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* [v10, 3/7] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-07-15 19:12 ` Scott Wood
0 siblings, 0 replies; 185+ messages in thread
From: Scott Wood @ 2016-07-15 19:12 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 2016-07-15 at 12:43 -0400, Paul Gortmaker wrote:
> On Wed, May 4, 2016 at 11:12 PM, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> >
> > The global utilities block controls power management, I/O device
> > enabling, power-onreset(POR) configuration monitoring, alternate
> > function selection for multiplexed signals,and clock control.
> >
> > This patch adds GUTS driver to manage and access global utilities
> > block.
> >
> > Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> > Acked-by: Scott Wood <oss@buserror.net>
> > ---
> > Changes for v4:
> > ????????- Added this patch
> > Changes for v5:
> > ????????- Modified copyright info
> > ????????- Changed MODULE_LICENSE to GPL
> > ????????- Changed EXPORT_SYMBOL_GPL to EXPORT_SYMBOL
> > ????????- Made FSL_GUTS user-invisible
> > ????????- Added a complete compatible list for GUTS
> > ????????- Stored guts info in file-scope variable
> > ????????- Added mfspr() getting SVR
> > ????????- Redefined GUTS APIs
> > ????????- Called fsl_guts_init rather than using platform driver
> > ????????- Removed useless parentheses
> > ????????- Removed useless 'extern' key words
> > Changes for v6:
> > ????????- Made guts thread safe in fsl_guts_init
> > Changes for v7:
> > ????????- Removed 'ifdef' for function declaration in guts.h
> > Changes for v8:
> > ????????- Fixes lines longer than 80 characters checkpatch issue
> > ????????- Added 'Acked-by: Scott Wood'
> > Changes for v9:
> > ????????- None
> > Changes for v10:
> > ????????- None
> > ---
> > ?drivers/soc/Kconfig??????|???2 +-
> > ?drivers/soc/fsl/Kconfig??|???8 +++
> > ?drivers/soc/fsl/Makefile |???1 +
> > ?drivers/soc/fsl/guts.c???| 119
> > ++++++++++++++++++++++++++++++++++++++++++++
> > ?include/linux/fsl/guts.h | 126 +++++++++++++++++++++++++++++-------------
> > -----
> > ?5 files changed, 207 insertions(+), 49 deletions(-)
> > ?create mode 100644 drivers/soc/fsl/Kconfig
> > ?create mode 100644 drivers/soc/fsl/guts.c
> >
> > diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> > index cb58ef0..7106463 100644
> > --- a/drivers/soc/Kconfig
> > +++ b/drivers/soc/Kconfig
> > @@ -2,7 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
> >
> > ?source "drivers/soc/bcm/Kconfig"
> > ?source "drivers/soc/brcmstb/Kconfig"
> > -source "drivers/soc/fsl/qe/Kconfig"
> > +source "drivers/soc/fsl/Kconfig"
> > ?source "drivers/soc/mediatek/Kconfig"
> > ?source "drivers/soc/qcom/Kconfig"
> > ?source "drivers/soc/rockchip/Kconfig"
> > diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
> > new file mode 100644
> > index 0000000..b313759
> > --- /dev/null
> > +++ b/drivers/soc/fsl/Kconfig
> > @@ -0,0 +1,8 @@
> > +#
> > +# Freescale SOC drivers
> > +#
> > +
> > +source "drivers/soc/fsl/qe/Kconfig"
> > +
> > +config FSL_GUTS
> > +???????bool
> > diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
> > index 203307f..02afb7f 100644
> > --- a/drivers/soc/fsl/Makefile
> > +++ b/drivers/soc/fsl/Makefile
> > @@ -4,3 +4,4 @@
> >
> > ?obj-$(CONFIG_QUICC_ENGINE)?????????????+= qe/
> > ?obj-$(CONFIG_CPM)??????????????????????+= qe/
> > +obj-$(CONFIG_FSL_GUTS)?????????????????+= guts.o
> > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> > new file mode 100644
> > index 0000000..fa155e6
> > --- /dev/null
> > +++ b/drivers/soc/fsl/guts.c
> > @@ -0,0 +1,119 @@
> > +/*
> > + * Freescale QorIQ Platforms GUTS Driver
> > + *
> > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +
> > +#include <linux/io.h>
> > +#include <linux/module.h>
> Seems there was lots of discussion on this.??If it does end up being
> resent, it would be nice to get the module.h and other modular stuff
> gone since it is a bool Kconfig.
I plan to resend just the GUTS driver portion and send it through the PPC
tree.
I don't see any modular stuff in there besides the linux/module.h include.
-Scott
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [v10, 3/7] soc: fsl: add GUTS driver for QorIQ platforms
2016-07-15 19:12 ` Scott Wood
(?)
(?)
@ 2016-07-15 22:39 ` Paul Gortmaker
-1 siblings, 0 replies; 185+ messages in thread
From: Paul Gortmaker @ 2016-07-15 22:39 UTC (permalink / raw)
To: Scott Wood
Cc: Yangbo Lu, linux-mmc, linuxppc-dev, devicetree, linux-arm-kernel,
LKML, linux-clk, linux-i2c, iommu, netdev, ulf.hansson,
Mark Rutland, Rob Herring, Russell King, Jochen Friedrich,
Joerg Roedel, Claudiu Manoil, Bhupesh Sharma, Qiang Zhao,
Kumar Gala, Santosh Shilimkar, leoyang.li, xiaobo.xie
[Re: [v10, 3/7] soc: fsl: add GUTS driver for QorIQ platforms] On 15/07/2016 (Fri 14:12) Scott Wood wrote:
> On Fri, 2016-07-15 at 12:43 -0400, Paul Gortmaker wrote:
> > > +source "drivers/soc/fsl/qe/Kconfig"
[...]
> > > +
> > > +config FSL_GUTS
> > > + bool
> > > diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
> > > index 203307f..02afb7f 100644
> > > --- a/drivers/soc/fsl/Makefile
> > > +++ b/drivers/soc/fsl/Makefile
> > > @@ -4,3 +4,4 @@
> > >
> > > obj-$(CONFIG_QUICC_ENGINE) += qe/
> > > obj-$(CONFIG_CPM) += qe/
> > > +obj-$(CONFIG_FSL_GUTS) += guts.o
> > > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> > > new file mode 100644
> > > index 0000000..fa155e6
> > > --- /dev/null
> > > +++ b/drivers/soc/fsl/guts.c
> > > @@ -0,0 +1,119 @@
> > > +/*
> > > + * Freescale QorIQ Platforms GUTS Driver
> > > + *
> > > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License as published by
> > > + * the Free Software Foundation; either version 2 of the License, or
> > > + * (at your option) any later version.
> > > + */
> > > +
> > > +#include <linux/io.h>
> > > +#include <linux/module.h>
> > Seems there was lots of discussion on this. If it does end up being
> > resent, it would be nice to get the module.h and other modular stuff
> > gone since it is a bool Kconfig.
>
> I plan to resend just the GUTS driver portion and send it through the PPC
> tree.
>
> I don't see any modular stuff in there besides the linux/module.h include.
Great. Normally I'm seeing the MODULE_DEVICE_TABLE and MODULE_AUTHOR
and MODULE_LICENSE etc, so it has (unfortunately) become a knee jerk
reaction to assume the latter follows a module.h presence... thanks for
removing the extraneous include.
Paul.
--
>
> -Scott
>
>
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [v10, 3/7] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-07-15 22:39 ` Paul Gortmaker
0 siblings, 0 replies; 185+ messages in thread
From: Paul Gortmaker @ 2016-07-15 22:39 UTC (permalink / raw)
To: Scott Wood
Cc: Yangbo Lu, linux-mmc, linuxppc-dev, devicetree, linux-arm-kernel,
LKML, linux-clk, linux-i2c, iommu, netdev, ulf.hansson,
Mark Rutland, Rob Herring, Russell King, Jochen Friedrich,
Joerg Roedel, Claudiu Manoil, Bhupesh Sharma, Qiang Zhao,
Kumar Gala, Santosh Shilimkar, leoyang.li, xiaobo.xie
[Re: [v10, 3/7] soc: fsl: add GUTS driver for QorIQ platforms] On 15/07/2016 (Fri 14:12) Scott Wood wrote:
> On Fri, 2016-07-15 at 12:43 -0400, Paul Gortmaker wrote:
> > > +source "drivers/soc/fsl/qe/Kconfig"
[...]
> > > +
> > > +config FSL_GUTS
> > > + bool
> > > diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
> > > index 203307f..02afb7f 100644
> > > --- a/drivers/soc/fsl/Makefile
> > > +++ b/drivers/soc/fsl/Makefile
> > > @@ -4,3 +4,4 @@
> > >
> > > obj-$(CONFIG_QUICC_ENGINE) += qe/
> > > obj-$(CONFIG_CPM) += qe/
> > > +obj-$(CONFIG_FSL_GUTS) += guts.o
> > > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> > > new file mode 100644
> > > index 0000000..fa155e6
> > > --- /dev/null
> > > +++ b/drivers/soc/fsl/guts.c
> > > @@ -0,0 +1,119 @@
> > > +/*
> > > + * Freescale QorIQ Platforms GUTS Driver
> > > + *
> > > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License as published by
> > > + * the Free Software Foundation; either version 2 of the License, or
> > > + * (at your option) any later version.
> > > + */
> > > +
> > > +#include <linux/io.h>
> > > +#include <linux/module.h>
> > Seems there was lots of discussion on this. If it does end up being
> > resent, it would be nice to get the module.h and other modular stuff
> > gone since it is a bool Kconfig.
>
> I plan to resend just the GUTS driver portion and send it through the PPC
> tree.
>
> I don't see any modular stuff in there besides the linux/module.h include.
Great. Normally I'm seeing the MODULE_DEVICE_TABLE and MODULE_AUTHOR
and MODULE_LICENSE etc, so it has (unfortunately) become a knee jerk
reaction to assume the latter follows a module.h presence... thanks for
removing the extraneous include.
Paul.
--
>
> -Scott
>
>
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [v10, 3/7] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-07-15 22:39 ` Paul Gortmaker
0 siblings, 0 replies; 185+ messages in thread
From: Paul Gortmaker @ 2016-07-15 22:39 UTC (permalink / raw)
To: Scott Wood
Cc: Yangbo Lu, linux-mmc, linuxppc-dev, devicetree, linux-arm-kernel,
LKML, linux-clk, linux-i2c, iommu, netdev, ulf.hansson,
Mark Rutland, Rob Herring, Russell King, Jochen Friedrich,
Joerg Roedel, Claudiu Manoil, Bhupesh Sharma, Qiang Zhao,
Kumar Gala, Santosh Shilimkar, leoyang.li, xiaobo.xie
[Re: [v10, 3/7] soc: fsl: add GUTS driver for QorIQ platforms] On 15/07/2016 (Fri 14:12) Scott Wood wrote:
> On Fri, 2016-07-15 at 12:43 -0400, Paul Gortmaker wrote:
> > > +source "drivers/soc/fsl/qe/Kconfig"
[...]
> > > +
> > > +config FSL_GUTS
> > > + bool
> > > diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
> > > index 203307f..02afb7f 100644
> > > --- a/drivers/soc/fsl/Makefile
> > > +++ b/drivers/soc/fsl/Makefile
> > > @@ -4,3 +4,4 @@
> > >
> > > obj-$(CONFIG_QUICC_ENGINE) += qe/
> > > obj-$(CONFIG_CPM) += qe/
> > > +obj-$(CONFIG_FSL_GUTS) += guts.o
> > > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> > > new file mode 100644
> > > index 0000000..fa155e6
> > > --- /dev/null
> > > +++ b/drivers/soc/fsl/guts.c
> > > @@ -0,0 +1,119 @@
> > > +/*
> > > + * Freescale QorIQ Platforms GUTS Driver
> > > + *
> > > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License as published by
> > > + * the Free Software Foundation; either version 2 of the License, or
> > > + * (at your option) any later version.
> > > + */
> > > +
> > > +#include <linux/io.h>
> > > +#include <linux/module.h>
> > Seems there was lots of discussion on this. If it does end up being
> > resent, it would be nice to get the module.h and other modular stuff
> > gone since it is a bool Kconfig.
>
> I plan to resend just the GUTS driver portion and send it through the PPC
> tree.
>
> I don't see any modular stuff in there besides the linux/module.h include.
Great. Normally I'm seeing the MODULE_DEVICE_TABLE and MODULE_AUTHOR
and MODULE_LICENSE etc, so it has (unfortunately) become a knee jerk
reaction to assume the latter follows a module.h presence... thanks for
removing the extraneous include.
Paul.
--
>
> -Scott
>
>
^ permalink raw reply [flat|nested] 185+ messages in thread
* [v10, 3/7] soc: fsl: add GUTS driver for QorIQ platforms
@ 2016-07-15 22:39 ` Paul Gortmaker
0 siblings, 0 replies; 185+ messages in thread
From: Paul Gortmaker @ 2016-07-15 22:39 UTC (permalink / raw)
To: linux-arm-kernel
[Re: [v10, 3/7] soc: fsl: add GUTS driver for QorIQ platforms] On 15/07/2016 (Fri 14:12) Scott Wood wrote:
> On Fri, 2016-07-15 at 12:43 -0400, Paul Gortmaker wrote:
> > > +source "drivers/soc/fsl/qe/Kconfig"
[...]
> > > +
> > > +config FSL_GUTS
> > > +???????bool
> > > diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
> > > index 203307f..02afb7f 100644
> > > --- a/drivers/soc/fsl/Makefile
> > > +++ b/drivers/soc/fsl/Makefile
> > > @@ -4,3 +4,4 @@
> > >
> > > ?obj-$(CONFIG_QUICC_ENGINE)?????????????+= qe/
> > > ?obj-$(CONFIG_CPM)??????????????????????+= qe/
> > > +obj-$(CONFIG_FSL_GUTS)?????????????????+= guts.o
> > > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> > > new file mode 100644
> > > index 0000000..fa155e6
> > > --- /dev/null
> > > +++ b/drivers/soc/fsl/guts.c
> > > @@ -0,0 +1,119 @@
> > > +/*
> > > + * Freescale QorIQ Platforms GUTS Driver
> > > + *
> > > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License as published by
> > > + * the Free Software Foundation; either version 2 of the License, or
> > > + * (at your option) any later version.
> > > + */
> > > +
> > > +#include <linux/io.h>
> > > +#include <linux/module.h>
> > Seems there was lots of discussion on this.??If it does end up being
> > resent, it would be nice to get the module.h and other modular stuff
> > gone since it is a bool Kconfig.
>
> I plan to resend just the GUTS driver portion and send it through the PPC
> tree.
>
> I don't see any modular stuff in there besides the linux/module.h include.
Great. Normally I'm seeing the MODULE_DEVICE_TABLE and MODULE_AUTHOR
and MODULE_LICENSE etc, so it has (unfortunately) become a knee jerk
reaction to assume the latter follows a module.h presence... thanks for
removing the extraneous include.
Paul.
--
>
> -Scott
>
>
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
2016-05-05 11:10 ` Arnd Bergmann
(?)
@ 2017-04-03 14:16 ` Kiran Kumar
-1 siblings, 0 replies; 185+ messages in thread
From: Kiran Kumar @ 2017-04-03 14:16 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Qiang Zhao, Russell King,
Bhupesh Sharma, Claudiu Manoil,
devicetree-u79uwXL29TY76Z2rM5mHXA, Kumar Gala, Scott Wood,
Rob Herring, Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
Xiaobo Xie, Yang-Leo Li,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
[-- Attachment #1.1: Type: text/plain, Size: 8813 bytes --]
Sorry to post in this huge email bunch.
I have most probably hit an errata in Freescale T4240 for
PPC_DISABLE_THREADS. I'm using Rev2 - T4240. Is this Errata required to be
taken care or not? Any quick help is appreciated!
My issue: I'm running line rate of Traffic to T4240 [10G of traffic on each
port of capacity of 10G]; After few hours of running of traffic, My CPU/LMP
gets stuck and goes in for Hard reset. When I searched through the code and
some open forums, I saw the errata listed above. I'm not sure if that
errata works for me or not. I have pasted a snapshot of issue occuring in
my system
============================================
During hang, with Softlock up enabled, I get prints from smp_many ->
showing ‘every processor is waiting for processor 22’ ; I need to know what
happened to processor 22. The processor number keep changing every time
when I run the traffic.
Processor 22 goes into a deadlock state with interrupts disabled or it went
into a deep idle sleep state is the issue i feel.
If its deep idle state -> a NMI should have recovered it.
But if it’s a deadlock issue with interrupt disabled then I need to know
the root cause for the deadlock.
*root@A@0-1-1:~# [ 1602.261011] Current::17 waiting::22 flag::4353 [
1602.720488] Current::14 waiting::22 flag::3585 [ 1602.756404] Current::15
waiting::22 flag::3841 [ 1604.903248] Current::16 waiting::22 flag::4097 [
1619.400917] Current::14 waiting::22 flag::3585 [ 1619.517870] Current::17
waiting::22 flag::4353 [ 1619.749893] Current::15 waiting::22 flag::3841 [
1619.798453] Current::4 waiting::22 flag::1025 [ 1622.177171] Current::16
waiting::22 flag::4097 [ 1622.449412] INFO: rcu_preempt detected stalls on
CPUs/tasks: { 22} (detected by 4, t=21008 jiffies, g=101651, c=101650,
q=4713) [ 1622.460951] Task dump for CPU 22:*
*[ 1622.464275] swapper/22 R running task 0 0 1
0x00000800*
*[ 1622.471355] Call Trace:*
*[ 1622.473820] [c0000001f92b78d0] [000000000000009e] 0x9e (unreliable) [
1622.480119] [c0000001f92b7960] [c0000001f92b7aa0] 0xc0000001f92b7aa0 [
1622.486497] [c0000001f92b79e0] [c000000000a90275] 0xc000000000a90275 [
1622.492878] [c0000001f92b7a60] [c000000000006f64] .do_IRQ+0x184/0x370 [
1622.499344] [c0000001f92b7b10] [c00000000001b93c]
exc_0x500_common+0xfc/0x100 [ 1622.506539] --- Exception: 501 at
0xc000000000a3e200*
*[ 1622.506539] LR = .__check_irq_replay+0x68/0x110*
*[ 1622.516388] [c0000001f92b7e00] [c0000000000bc590]
.cpu_startup_entry+0x1d0/0x350 (unreliable) [ 1622.524950]
[c0000001f92b7ed0] [c000000000a00460] .start_secondary+0x3ec/0x3f4 [
1622.532197] [c0000001f92b7f90] [c00000000000036c]
.start_secondary_prolog+0x10/0x14 [ 1635.237829] Current::3 waiting::5
flag::769 [ 1636.587746] Current::14 waiting::22 flag::3585 [ 1637.082117]
Current::17 waiting::22 flag::4353 [ 1637.224920] Current::4 waiting::22
flag::1025 [ 1637.268789] Current::15 waiting::22 flag::3841 [ 1640.085792]
Current::16 waiting::22 flag::4097 [ 1651.093367] Current::4 waiting::22
flag::1025*
*=============================================================*
Regards,
Kiran
On Thu, May 5, 2016 at 4:40 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Thursday 05 May 2016 09:41:32 Yangbo Lu wrote:
> > > -----Original Message-----
> > > From: Arnd Bergmann [mailto:arnd-r2nGTMty4D4@public.gmane.org]
> > > Sent: Thursday, May 05, 2016 4:32 PM
> > > To: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> > > Cc: Yangbo Lu; linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > > linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > > linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> iommu-cunTk1MwBs/ROKNJybVBZg@public.gmane.org
> > > foundation.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Mark Rutland;
> > > ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org; Russell King; Bhupesh Sharma; Joerg Roedel;
> > > Santosh Shilimkar; Yang-Leo Li; Scott Wood; Rob Herring; Claudiu
> Manoil;
> > > Kumar Gala; Xiaobo Xie; Qiang Zhao
> > > Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for
> T4240-
> > > R1.0-R2.0
> > >
> > > On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
> > > >
> > > > + fsl_guts_init();
> > > > + svr = fsl_guts_get_svr();
> > > > + if (svr) {
> > > > + esdhc->soc_ver = SVR_SOC_VER(svr);
> > > > + esdhc->soc_rev = SVR_REV(svr);
> > > > + } else {
> > > > + dev_err(&pdev->dev, "Failed to get SVR value!\n");
> > > > + }
> > > > +
> > > >
> > >
> > >
> > > Sorry for jumping in again after not participating in the discussion
> for
> > > the past few versions.
> > >
> > > What happened to my suggestion of making this a platform-independent
> > > interface to avoid the link time dependency?
> > >
> > > Specifically, why not add an exported function to drivers/base/soc.c
> that
> > > uses glob_match() for comparing a string in the device driver to the ID
> > > of the SoC that is set by whatever SoC identifying driver the platform
> > > has?
> >
> > [Lu Yangbo-B47093] I think this has been discussed in v6.
> > You can find Scott's comments about this in below link.
> > https://patchwork.kernel.org/patch/8544501/
>
> Ah, thanks for bearing with me and digging this out again. Let me follow
> up on Scott's older replies here then:
>
> > >> IIRC, it is the same IP block as i.MX and Arnd's point is this won't
> > >> even compile on !PPC. It is things like this that prevent sharing the
> > >> driver.
> >
> > The whole point of using the MMIO SVR instead of the PPC SPR is so that
> > it will work on ARM... The guts driver should build on any platform as
> > long as OF is enabled, and if it doesn't find a node to bind to it will
> > return 0 for SVR, and the eSDHC driver will continue (after printing an
> > error that should be removed) without the ability to test for errata
> > based on SVR.
>
> It feels like a bad design to have to come up with a different
> method for each SoC type here when they all do the same thing
> and want to identify some variant of the chip to do device
> specific quirks.
>
> As far as I'm concerned, every driver in drivers/soc that needs to
> export a symbol to be used by a device driver is an indication that
> we don't have the right set of abstractions yet. There are cases
> that are not worth abstracting because the functionality is rather
> obscure and only a couple of drivers for one particular chip
> ever need it.
>
> Finding out the version of the SoC does not look like this case.
>
> > > I think the first four patches take care of building for ARM,
> > > but the problem remains if you want to enable COMPILE_TEST as
> > > we need for certain automated checking.
> >
> > What specific problem is there with COMPILE_TEST?
>
> COMPILE_TEST is solvable here and the way it is implemented in this
> case (selecting FSL_GUTS from the driver) indeed looks like it works
> correctly, but it's still awkward that this means building the
> SoC specific ID stuff into the vmlinux binary for any driver that
> uses something like that for a particular SoC.
>
> > >> Dealing with Si revs is a common problem. We should have a
> > >> common solution. There is soc_device for this purpose.
> > >
> > > Exactly. The last time this came up, I think we agreed to implement a
> > > helper using glob_match() on the soc_device strings. Unfortunately
> > > this hasn't happened then, but I'd still prefer that over yet another
> > > vendor-specific way of dealing with the generic issue.
> >
> > soc_device would require encoding the SVR as a string and then decoding
> > the string, which is more complicated and error prone than having
> > platform-specific code test a platform-specific number.
>
> You already need to encode it as a string to register the soc_device,
> and the driver just needs to pass a glob string, so the only part that
> is missing is the generic function that takes the string from the
> driver and passes that to glob_match for the soc_device.
>
> > And when would it get registered on arm64, which doesn't have
> > platform code?
>
> Whenever the soc driver is loaded, as is the case now. The match
> function can return -EPROBE_DEFER if no SoC device is registered
> yet.
>
> Arnd
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
[-- Attachment #1.2: Type: text/html, Size: 12997 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2017-04-03 14:16 ` Kiran Kumar
0 siblings, 0 replies; 185+ messages in thread
From: Kiran Kumar @ 2017-04-03 14:16 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Qiang Zhao, Russell King,
Bhupesh Sharma, Claudiu Manoil,
devicetree-u79uwXL29TY76Z2rM5mHXA, Kumar Gala, Scott Wood,
Rob Herring, Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
Xiaobo Xie, Yang-Leo Li
[-- Attachment #1.1: Type: text/plain, Size: 8813 bytes --]
Sorry to post in this huge email bunch.
I have most probably hit an errata in Freescale T4240 for
PPC_DISABLE_THREADS. I'm using Rev2 - T4240. Is this Errata required to be
taken care or not? Any quick help is appreciated!
My issue: I'm running line rate of Traffic to T4240 [10G of traffic on each
port of capacity of 10G]; After few hours of running of traffic, My CPU/LMP
gets stuck and goes in for Hard reset. When I searched through the code and
some open forums, I saw the errata listed above. I'm not sure if that
errata works for me or not. I have pasted a snapshot of issue occuring in
my system
============================================
During hang, with Softlock up enabled, I get prints from smp_many ->
showing ‘every processor is waiting for processor 22’ ; I need to know what
happened to processor 22. The processor number keep changing every time
when I run the traffic.
Processor 22 goes into a deadlock state with interrupts disabled or it went
into a deep idle sleep state is the issue i feel.
If its deep idle state -> a NMI should have recovered it.
But if it’s a deadlock issue with interrupt disabled then I need to know
the root cause for the deadlock.
*root@A@0-1-1:~# [ 1602.261011] Current::17 waiting::22 flag::4353 [
1602.720488] Current::14 waiting::22 flag::3585 [ 1602.756404] Current::15
waiting::22 flag::3841 [ 1604.903248] Current::16 waiting::22 flag::4097 [
1619.400917] Current::14 waiting::22 flag::3585 [ 1619.517870] Current::17
waiting::22 flag::4353 [ 1619.749893] Current::15 waiting::22 flag::3841 [
1619.798453] Current::4 waiting::22 flag::1025 [ 1622.177171] Current::16
waiting::22 flag::4097 [ 1622.449412] INFO: rcu_preempt detected stalls on
CPUs/tasks: { 22} (detected by 4, t=21008 jiffies, g=101651, c=101650,
q=4713) [ 1622.460951] Task dump for CPU 22:*
*[ 1622.464275] swapper/22 R running task 0 0 1
0x00000800*
*[ 1622.471355] Call Trace:*
*[ 1622.473820] [c0000001f92b78d0] [000000000000009e] 0x9e (unreliable) [
1622.480119] [c0000001f92b7960] [c0000001f92b7aa0] 0xc0000001f92b7aa0 [
1622.486497] [c0000001f92b79e0] [c000000000a90275] 0xc000000000a90275 [
1622.492878] [c0000001f92b7a60] [c000000000006f64] .do_IRQ+0x184/0x370 [
1622.499344] [c0000001f92b7b10] [c00000000001b93c]
exc_0x500_common+0xfc/0x100 [ 1622.506539] --- Exception: 501 at
0xc000000000a3e200*
*[ 1622.506539] LR = .__check_irq_replay+0x68/0x110*
*[ 1622.516388] [c0000001f92b7e00] [c0000000000bc590]
.cpu_startup_entry+0x1d0/0x350 (unreliable) [ 1622.524950]
[c0000001f92b7ed0] [c000000000a00460] .start_secondary+0x3ec/0x3f4 [
1622.532197] [c0000001f92b7f90] [c00000000000036c]
.start_secondary_prolog+0x10/0x14 [ 1635.237829] Current::3 waiting::5
flag::769 [ 1636.587746] Current::14 waiting::22 flag::3585 [ 1637.082117]
Current::17 waiting::22 flag::4353 [ 1637.224920] Current::4 waiting::22
flag::1025 [ 1637.268789] Current::15 waiting::22 flag::3841 [ 1640.085792]
Current::16 waiting::22 flag::4097 [ 1651.093367] Current::4 waiting::22
flag::1025*
*=============================================================*
Regards,
Kiran
On Thu, May 5, 2016 at 4:40 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Thursday 05 May 2016 09:41:32 Yangbo Lu wrote:
> > > -----Original Message-----
> > > From: Arnd Bergmann [mailto:arnd-r2nGTMty4D4@public.gmane.org]
> > > Sent: Thursday, May 05, 2016 4:32 PM
> > > To: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> > > Cc: Yangbo Lu; linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > > linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > > linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> iommu-cunTk1MwBs/ROKNJybVBZg@public.gmane.org
> > > foundation.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Mark Rutland;
> > > ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org; Russell King; Bhupesh Sharma; Joerg Roedel;
> > > Santosh Shilimkar; Yang-Leo Li; Scott Wood; Rob Herring; Claudiu
> Manoil;
> > > Kumar Gala; Xiaobo Xie; Qiang Zhao
> > > Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for
> T4240-
> > > R1.0-R2.0
> > >
> > > On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
> > > >
> > > > + fsl_guts_init();
> > > > + svr = fsl_guts_get_svr();
> > > > + if (svr) {
> > > > + esdhc->soc_ver = SVR_SOC_VER(svr);
> > > > + esdhc->soc_rev = SVR_REV(svr);
> > > > + } else {
> > > > + dev_err(&pdev->dev, "Failed to get SVR value!\n");
> > > > + }
> > > > +
> > > >
> > >
> > >
> > > Sorry for jumping in again after not participating in the discussion
> for
> > > the past few versions.
> > >
> > > What happened to my suggestion of making this a platform-independent
> > > interface to avoid the link time dependency?
> > >
> > > Specifically, why not add an exported function to drivers/base/soc.c
> that
> > > uses glob_match() for comparing a string in the device driver to the ID
> > > of the SoC that is set by whatever SoC identifying driver the platform
> > > has?
> >
> > [Lu Yangbo-B47093] I think this has been discussed in v6.
> > You can find Scott's comments about this in below link.
> > https://patchwork.kernel.org/patch/8544501/
>
> Ah, thanks for bearing with me and digging this out again. Let me follow
> up on Scott's older replies here then:
>
> > >> IIRC, it is the same IP block as i.MX and Arnd's point is this won't
> > >> even compile on !PPC. It is things like this that prevent sharing the
> > >> driver.
> >
> > The whole point of using the MMIO SVR instead of the PPC SPR is so that
> > it will work on ARM... The guts driver should build on any platform as
> > long as OF is enabled, and if it doesn't find a node to bind to it will
> > return 0 for SVR, and the eSDHC driver will continue (after printing an
> > error that should be removed) without the ability to test for errata
> > based on SVR.
>
> It feels like a bad design to have to come up with a different
> method for each SoC type here when they all do the same thing
> and want to identify some variant of the chip to do device
> specific quirks.
>
> As far as I'm concerned, every driver in drivers/soc that needs to
> export a symbol to be used by a device driver is an indication that
> we don't have the right set of abstractions yet. There are cases
> that are not worth abstracting because the functionality is rather
> obscure and only a couple of drivers for one particular chip
> ever need it.
>
> Finding out the version of the SoC does not look like this case.
>
> > > I think the first four patches take care of building for ARM,
> > > but the problem remains if you want to enable COMPILE_TEST as
> > > we need for certain automated checking.
> >
> > What specific problem is there with COMPILE_TEST?
>
> COMPILE_TEST is solvable here and the way it is implemented in this
> case (selecting FSL_GUTS from the driver) indeed looks like it works
> correctly, but it's still awkward that this means building the
> SoC specific ID stuff into the vmlinux binary for any driver that
> uses something like that for a particular SoC.
>
> > >> Dealing with Si revs is a common problem. We should have a
> > >> common solution. There is soc_device for this purpose.
> > >
> > > Exactly. The last time this came up, I think we agreed to implement a
> > > helper using glob_match() on the soc_device strings. Unfortunately
> > > this hasn't happened then, but I'd still prefer that over yet another
> > > vendor-specific way of dealing with the generic issue.
> >
> > soc_device would require encoding the SVR as a string and then decoding
> > the string, which is more complicated and error prone than having
> > platform-specific code test a platform-specific number.
>
> You already need to encode it as a string to register the soc_device,
> and the driver just needs to pass a glob string, so the only part that
> is missing is the generic function that takes the string from the
> driver and passes that to glob_match for the soc_device.
>
> > And when would it get registered on arm64, which doesn't have
> > platform code?
>
> Whenever the soc driver is loaded, as is the case now. The match
> function can return -EPROBE_DEFER if no SoC device is registered
> yet.
>
> Arnd
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
[-- Attachment #1.2: Type: text/html, Size: 12997 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
@ 2017-04-03 14:16 ` Kiran Kumar
0 siblings, 0 replies; 185+ messages in thread
From: Kiran Kumar @ 2017-04-03 14:16 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Mark Rutland, ulf.hansson, Xiaobo Xie,
linux-i2c, linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Joerg Roedel, Claudiu Manoil, devicetree, Yangbo Lu, Scott Wood,
Rob Herring, Santosh Shilimkar, netdev, linux-mmc, linux-kernel,
Yang-Leo Li, iommu, Kumar Gala, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 8497 bytes --]
Sorry to post in this huge email bunch.
I have most probably hit an errata in Freescale T4240 for
PPC_DISABLE_THREADS. I'm using Rev2 - T4240. Is this Errata required to be
taken care or not? Any quick help is appreciated!
My issue: I'm running line rate of Traffic to T4240 [10G of traffic on each
port of capacity of 10G]; After few hours of running of traffic, My CPU/LMP
gets stuck and goes in for Hard reset. When I searched through the code and
some open forums, I saw the errata listed above. I'm not sure if that
errata works for me or not. I have pasted a snapshot of issue occuring in
my system
============================================
During hang, with Softlock up enabled, I get prints from smp_many ->
showing ‘every processor is waiting for processor 22’ ; I need to know what
happened to processor 22. The processor number keep changing every time
when I run the traffic.
Processor 22 goes into a deadlock state with interrupts disabled or it went
into a deep idle sleep state is the issue i feel.
If its deep idle state -> a NMI should have recovered it.
But if it’s a deadlock issue with interrupt disabled then I need to know
the root cause for the deadlock.
*root@A@0-1-1:~# [ 1602.261011] Current::17 waiting::22 flag::4353 [
1602.720488] Current::14 waiting::22 flag::3585 [ 1602.756404] Current::15
waiting::22 flag::3841 [ 1604.903248] Current::16 waiting::22 flag::4097 [
1619.400917] Current::14 waiting::22 flag::3585 [ 1619.517870] Current::17
waiting::22 flag::4353 [ 1619.749893] Current::15 waiting::22 flag::3841 [
1619.798453] Current::4 waiting::22 flag::1025 [ 1622.177171] Current::16
waiting::22 flag::4097 [ 1622.449412] INFO: rcu_preempt detected stalls on
CPUs/tasks: { 22} (detected by 4, t=21008 jiffies, g=101651, c=101650,
q=4713) [ 1622.460951] Task dump for CPU 22:*
*[ 1622.464275] swapper/22 R running task 0 0 1
0x00000800*
*[ 1622.471355] Call Trace:*
*[ 1622.473820] [c0000001f92b78d0] [000000000000009e] 0x9e (unreliable) [
1622.480119] [c0000001f92b7960] [c0000001f92b7aa0] 0xc0000001f92b7aa0 [
1622.486497] [c0000001f92b79e0] [c000000000a90275] 0xc000000000a90275 [
1622.492878] [c0000001f92b7a60] [c000000000006f64] .do_IRQ+0x184/0x370 [
1622.499344] [c0000001f92b7b10] [c00000000001b93c]
exc_0x500_common+0xfc/0x100 [ 1622.506539] --- Exception: 501 at
0xc000000000a3e200*
*[ 1622.506539] LR = .__check_irq_replay+0x68/0x110*
*[ 1622.516388] [c0000001f92b7e00] [c0000000000bc590]
.cpu_startup_entry+0x1d0/0x350 (unreliable) [ 1622.524950]
[c0000001f92b7ed0] [c000000000a00460] .start_secondary+0x3ec/0x3f4 [
1622.532197] [c0000001f92b7f90] [c00000000000036c]
.start_secondary_prolog+0x10/0x14 [ 1635.237829] Current::3 waiting::5
flag::769 [ 1636.587746] Current::14 waiting::22 flag::3585 [ 1637.082117]
Current::17 waiting::22 flag::4353 [ 1637.224920] Current::4 waiting::22
flag::1025 [ 1637.268789] Current::15 waiting::22 flag::3841 [ 1640.085792]
Current::16 waiting::22 flag::4097 [ 1651.093367] Current::4 waiting::22
flag::1025*
*=============================================================*
Regards,
Kiran
On Thu, May 5, 2016 at 4:40 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 05 May 2016 09:41:32 Yangbo Lu wrote:
> > > -----Original Message-----
> > > From: Arnd Bergmann [mailto:arnd@arndb.de]
> > > Sent: Thursday, May 05, 2016 4:32 PM
> > > To: linuxppc-dev@lists.ozlabs.org
> > > Cc: Yangbo Lu; linux-mmc@vger.kernel.org; devicetree@vger.kernel.org;
> > > linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> > > linux-clk@vger.kernel.org; linux-i2c@vger.kernel.org;
> iommu@lists.linux-
> > > foundation.org; netdev@vger.kernel.org; Mark Rutland;
> > > ulf.hansson@linaro.org; Russell King; Bhupesh Sharma; Joerg Roedel;
> > > Santosh Shilimkar; Yang-Leo Li; Scott Wood; Rob Herring; Claudiu
> Manoil;
> > > Kumar Gala; Xiaobo Xie; Qiang Zhao
> > > Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for
> T4240-
> > > R1.0-R2.0
> > >
> > > On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
> > > >
> > > > + fsl_guts_init();
> > > > + svr = fsl_guts_get_svr();
> > > > + if (svr) {
> > > > + esdhc->soc_ver = SVR_SOC_VER(svr);
> > > > + esdhc->soc_rev = SVR_REV(svr);
> > > > + } else {
> > > > + dev_err(&pdev->dev, "Failed to get SVR value!\n");
> > > > + }
> > > > +
> > > >
> > >
> > >
> > > Sorry for jumping in again after not participating in the discussion
> for
> > > the past few versions.
> > >
> > > What happened to my suggestion of making this a platform-independent
> > > interface to avoid the link time dependency?
> > >
> > > Specifically, why not add an exported function to drivers/base/soc.c
> that
> > > uses glob_match() for comparing a string in the device driver to the ID
> > > of the SoC that is set by whatever SoC identifying driver the platform
> > > has?
> >
> > [Lu Yangbo-B47093] I think this has been discussed in v6.
> > You can find Scott's comments about this in below link.
> > https://patchwork.kernel.org/patch/8544501/
>
> Ah, thanks for bearing with me and digging this out again. Let me follow
> up on Scott's older replies here then:
>
> > >> IIRC, it is the same IP block as i.MX and Arnd's point is this won't
> > >> even compile on !PPC. It is things like this that prevent sharing the
> > >> driver.
> >
> > The whole point of using the MMIO SVR instead of the PPC SPR is so that
> > it will work on ARM... The guts driver should build on any platform as
> > long as OF is enabled, and if it doesn't find a node to bind to it will
> > return 0 for SVR, and the eSDHC driver will continue (after printing an
> > error that should be removed) without the ability to test for errata
> > based on SVR.
>
> It feels like a bad design to have to come up with a different
> method for each SoC type here when they all do the same thing
> and want to identify some variant of the chip to do device
> specific quirks.
>
> As far as I'm concerned, every driver in drivers/soc that needs to
> export a symbol to be used by a device driver is an indication that
> we don't have the right set of abstractions yet. There are cases
> that are not worth abstracting because the functionality is rather
> obscure and only a couple of drivers for one particular chip
> ever need it.
>
> Finding out the version of the SoC does not look like this case.
>
> > > I think the first four patches take care of building for ARM,
> > > but the problem remains if you want to enable COMPILE_TEST as
> > > we need for certain automated checking.
> >
> > What specific problem is there with COMPILE_TEST?
>
> COMPILE_TEST is solvable here and the way it is implemented in this
> case (selecting FSL_GUTS from the driver) indeed looks like it works
> correctly, but it's still awkward that this means building the
> SoC specific ID stuff into the vmlinux binary for any driver that
> uses something like that for a particular SoC.
>
> > >> Dealing with Si revs is a common problem. We should have a
> > >> common solution. There is soc_device for this purpose.
> > >
> > > Exactly. The last time this came up, I think we agreed to implement a
> > > helper using glob_match() on the soc_device strings. Unfortunately
> > > this hasn't happened then, but I'd still prefer that over yet another
> > > vendor-specific way of dealing with the generic issue.
> >
> > soc_device would require encoding the SVR as a string and then decoding
> > the string, which is more complicated and error prone than having
> > platform-specific code test a platform-specific number.
>
> You already need to encode it as a string to register the soc_device,
> and the driver just needs to pass a glob string, so the only part that
> is missing is the generic function that takes the string from the
> driver and passes that to glob_match for the soc_device.
>
> > And when would it get registered on arm64, which doesn't have
> > platform code?
>
> Whenever the soc driver is loaded, as is the case now. The match
> function can return -EPROBE_DEFER if no SoC device is registered
> yet.
>
> Arnd
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
[-- Attachment #2: Type: text/html, Size: 12499 bytes --]
^ permalink raw reply [flat|nested] 185+ messages in thread
end of thread, other threads:[~2017-04-03 14:16 UTC | newest]
Thread overview: 185+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-05-05 3:12 [v10, 0/7] Fix eSDHC host version register bug Yangbo Lu
2016-05-05 3:12 ` Yangbo Lu
2016-05-05 3:12 ` Yangbo Lu
2016-05-05 3:12 ` Yangbo Lu
2016-05-05 3:12 ` Yangbo Lu
2016-05-05 3:12 ` [v10, 1/7] Documentation: DT: update Freescale DCFG compatible Yangbo Lu
2016-05-05 3:12 ` Yangbo Lu
2016-05-05 3:12 ` Yangbo Lu
2016-05-05 3:12 ` Yangbo Lu
2016-05-05 3:12 ` Yangbo Lu
2016-05-05 22:25 ` Rob Herring
2016-05-05 22:25 ` Rob Herring
2016-05-05 3:12 ` [v10, 2/7] ARM64: dts: ls2080a: add device configuration node Yangbo Lu
2016-05-05 3:12 ` Yangbo Lu
2016-05-05 3:12 ` Yangbo Lu
2016-05-05 3:12 ` Yangbo Lu
2016-05-05 3:12 ` Yangbo Lu
2016-05-05 3:12 ` [v10, 3/7] soc: fsl: add GUTS driver for QorIQ platforms Yangbo Lu
2016-05-05 3:12 ` Yangbo Lu
2016-05-05 3:12 ` Yangbo Lu
2016-05-05 3:12 ` Yangbo Lu
2016-07-15 16:43 ` Paul Gortmaker
2016-07-15 16:43 ` Paul Gortmaker
2016-07-15 16:43 ` Paul Gortmaker
2016-07-15 16:43 ` Paul Gortmaker
2016-07-15 19:12 ` Scott Wood
2016-07-15 19:12 ` Scott Wood
2016-07-15 19:12 ` Scott Wood
2016-07-15 19:12 ` Scott Wood
2016-07-15 22:39 ` Paul Gortmaker
2016-07-15 22:39 ` Paul Gortmaker
2016-07-15 22:39 ` Paul Gortmaker
2016-07-15 22:39 ` Paul Gortmaker
2016-05-05 3:12 ` [v10, 4/7] dt: move guts devicetree doc out of powerpc directory Yangbo Lu
2016-05-05 3:12 ` Yangbo Lu
2016-05-05 3:12 ` Yangbo Lu
2016-05-05 3:12 ` Yangbo Lu
2016-05-05 3:12 ` Yangbo Lu
2016-05-05 3:12 ` [v10, 5/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl Yangbo Lu
2016-05-05 3:12 ` Yangbo Lu
2016-05-05 3:12 ` Yangbo Lu
2016-05-05 3:12 ` Yangbo Lu
2016-05-05 3:12 ` Yangbo Lu
2016-05-05 3:12 ` [v10, 6/7] MAINTAINERS: add entry for Freescale SoC drivers Yangbo Lu
2016-05-05 3:12 ` Yangbo Lu
2016-05-05 3:12 ` Yangbo Lu
2016-05-05 3:12 ` Yangbo Lu
2016-05-05 3:12 ` [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0 Yangbo Lu
2016-05-05 3:12 ` Yangbo Lu
2016-05-05 3:12 ` Yangbo Lu
2016-05-05 3:12 ` Yangbo Lu
2016-05-05 8:31 ` Arnd Bergmann
2016-05-05 8:31 ` Arnd Bergmann
2016-05-05 8:31 ` Arnd Bergmann
2016-05-05 9:41 ` Yangbo Lu
2016-05-05 9:41 ` Yangbo Lu
2016-05-05 9:41 ` Yangbo Lu
2016-05-05 9:41 ` Yangbo Lu
2016-05-05 9:41 ` Yangbo Lu
2016-05-05 9:41 ` Yangbo Lu
2016-05-05 11:10 ` Arnd Bergmann
2016-05-05 11:10 ` Arnd Bergmann
2016-05-05 11:10 ` Arnd Bergmann
2016-05-05 11:10 ` Arnd Bergmann
2016-05-11 3:26 ` Scott Wood
2016-05-11 3:26 ` Scott Wood
2016-05-11 3:26 ` Scott Wood
2016-05-11 3:26 ` Scott Wood
2016-05-20 6:05 ` Yangbo Lu
2016-05-20 6:05 ` Yangbo Lu
2016-05-20 6:05 ` Yangbo Lu
2016-05-20 6:05 ` Yangbo Lu
2016-05-20 6:05 ` Yangbo Lu
2016-05-20 6:05 ` Yangbo Lu
2016-05-26 4:05 ` Yangbo Lu
2016-05-26 4:05 ` Yangbo Lu
2016-05-26 4:05 ` Yangbo Lu
2016-05-26 4:05 ` Yangbo Lu
2016-05-26 4:05 ` Yangbo Lu
2016-05-26 7:44 ` Ulf Hansson
2016-05-26 7:44 ` Ulf Hansson
2016-05-26 7:44 ` Ulf Hansson
2016-05-26 7:44 ` Ulf Hansson
2016-05-30 13:13 ` Arnd Bergmann
2016-05-30 13:13 ` Arnd Bergmann
2016-05-30 13:13 ` Arnd Bergmann
2016-05-30 13:13 ` Arnd Bergmann
2016-05-30 13:14 ` [PATCH 1/4] base: soc: introduce soc_device_match() interface Arnd Bergmann
2016-05-30 13:14 ` Arnd Bergmann
2016-05-30 13:14 ` Arnd Bergmann
2016-05-30 13:14 ` Arnd Bergmann
2016-05-30 14:57 ` Arnd Bergmann
2016-05-30 14:57 ` Arnd Bergmann
2016-05-30 14:57 ` Arnd Bergmann
2016-05-30 14:57 ` Arnd Bergmann
2016-05-30 13:15 ` [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms Arnd Bergmann
2016-05-30 13:15 ` Arnd Bergmann
2016-05-30 13:15 ` Arnd Bergmann
2016-05-30 13:15 ` Arnd Bergmann
2016-06-02 1:47 ` Scott Wood
2016-06-02 1:47 ` Scott Wood
2016-06-02 1:47 ` Scott Wood
2016-06-02 1:47 ` Scott Wood
2016-06-02 1:47 ` Scott Wood
2016-06-02 1:47 ` Scott Wood
2016-06-02 8:43 ` Arnd Bergmann
2016-06-02 8:43 ` Arnd Bergmann
2016-06-02 8:43 ` Arnd Bergmann
2016-06-02 8:43 ` Arnd Bergmann
2016-06-11 1:50 ` Scott Wood
2016-06-11 1:50 ` Scott Wood
2016-06-11 1:50 ` Scott Wood
2016-06-11 1:50 ` Scott Wood
2016-06-11 1:50 ` Scott Wood
2016-06-11 1:50 ` Scott Wood
2016-06-23 2:46 ` Yangbo Lu
2016-06-23 2:46 ` Yangbo Lu
2016-06-23 2:46 ` Yangbo Lu
2016-06-23 2:46 ` Yangbo Lu
2016-06-23 2:46 ` Yangbo Lu
2016-07-07 2:35 ` Yangbo Lu
2016-07-07 2:35 ` Yangbo Lu
2016-07-07 2:35 ` Yangbo Lu
2016-07-07 2:35 ` Yangbo Lu
2016-07-07 2:35 ` Yangbo Lu
2016-07-07 2:35 ` Yangbo Lu
2016-07-07 8:30 ` Arnd Bergmann
2016-07-07 8:30 ` Arnd Bergmann
2016-07-07 8:30 ` Arnd Bergmann
2016-07-07 8:30 ` Arnd Bergmann
2016-07-07 8:30 ` Arnd Bergmann
2016-07-07 8:30 ` Arnd Bergmann
2016-07-07 20:42 ` Scott Wood
2016-07-07 20:42 ` Scott Wood
2016-07-07 20:42 ` Scott Wood
2016-07-07 20:42 ` Scott Wood
2016-07-07 20:42 ` Scott Wood
2016-07-08 3:05 ` Yangbo Lu
2016-07-08 3:05 ` Yangbo Lu
2016-07-08 3:05 ` Yangbo Lu
2016-07-08 3:05 ` Yangbo Lu
2016-07-08 3:05 ` Yangbo Lu
2016-07-08 3:05 ` Yangbo Lu
2016-05-30 13:16 ` [PATCH 3/4] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0 Arnd Bergmann
2016-05-30 13:16 ` Arnd Bergmann
2016-05-30 13:16 ` Arnd Bergmann
2016-05-30 13:16 ` Arnd Bergmann
2016-06-02 1:11 ` Scott Wood
2016-06-02 1:11 ` Scott Wood
2016-06-02 1:11 ` Scott Wood
2016-06-02 1:11 ` Scott Wood
2016-06-02 1:11 ` Scott Wood
2016-06-02 8:52 ` Arnd Bergmann
2016-06-02 8:52 ` Arnd Bergmann
2016-06-02 8:52 ` Arnd Bergmann
2016-06-02 8:52 ` Arnd Bergmann
2016-06-02 8:52 ` Arnd Bergmann
2016-06-11 2:00 ` Scott Wood
2016-06-11 2:00 ` Scott Wood
2016-06-11 2:00 ` Scott Wood
2016-06-11 2:00 ` Scott Wood
2016-06-11 2:00 ` Scott Wood
2016-06-11 2:00 ` Scott Wood
2016-05-30 13:18 ` [PATCH 4/4] Revert "powerpc/fsl: Move fsl_guts.h out of arch/powerpc" Arnd Bergmann
2016-05-30 13:18 ` Arnd Bergmann
2016-05-30 13:18 ` Arnd Bergmann
2016-05-30 13:18 ` Arnd Bergmann
2016-06-02 1:24 ` Scott Wood
2016-06-02 1:24 ` Scott Wood
2016-06-02 1:24 ` Scott Wood
2016-06-02 1:24 ` Scott Wood
2016-06-02 1:24 ` Scott Wood
2016-06-02 9:01 ` Arnd Bergmann
2016-06-02 9:01 ` Arnd Bergmann
2016-06-02 9:01 ` Arnd Bergmann
2016-06-02 9:01 ` Arnd Bergmann
2016-06-02 9:01 ` Arnd Bergmann
2016-06-11 2:13 ` Scott Wood
2016-06-11 2:13 ` Scott Wood
2016-06-11 2:13 ` Scott Wood
2016-06-11 2:13 ` Scott Wood
2016-06-11 2:13 ` Scott Wood
2017-04-03 14:16 ` [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0 Kiran Kumar
2017-04-03 14:16 ` Kiran Kumar
2017-04-03 14:16 ` Kiran Kumar
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.