From: Scott Wood <oss@buserror.net> Date: 2016-07-17 02:51:00
This patchset adds the beginnings of a driver to consolidate accesses to
the Freescale/NXP "global utilities" block. Initially only access to SVR
(the system version register) is provided. This register is needed by
various drivers, mainly for errata detection. Access to SVR via
mfspr(SPRN_SVR) is now discouraged, especially in drivers that are
not PPC-specific.
I plan to send this via the PPC tree for this merge window, to provide a
base for using/extending the guts driver in various drivers in the next
cycle.
Scott Wood (1):
powerpc/fsl-pci: Use fsl_guts_get_svr()
Yangbo Lu (2):
dt: bindings: move guts devicetree doc out of powerpc directory
soc: fsl: add GUTS driver for QorIQ platforms
yangbo lu (2):
dt: bindings: update Freescale DCFG compatible
powerpc/fsl: move mpc85xx.h to include/linux/fsl
Documentation/devicetree/bindings/arm/fsl.txt | 6 +-
.../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
arch/powerpc/Kconfig | 1 +
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
arch/powerpc/platforms/85xx/common.c | 2 -
arch/powerpc/sysdev/fsl_pci.c | 8 +-
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 +-
drivers/soc/Kconfig | 2 +-
drivers/soc/fsl/Kconfig | 8 ++
drivers/soc/fsl/Makefile | 1 +
drivers/soc/fsl/guts.c | 113 ++++++++++++++++++
include/linux/fsl/guts.h | 126 +++++++++++++--------
.../asm/mpc85xx.h => include/linux/fsl/svr.h | 4 +-
16 files changed, 223 insertions(+), 63 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.7.4
From: Scott Wood <oss@buserror.net> Date: 2016-07-17 02:50:36
From: yangbo lu <yangbo.lu@nxp.com>
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>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Scott Wood <oss@buserror.net>
---
Documentation/devicetree/bindings/arm/fsl.txt | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
@@ -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:
From: Scott Wood <oss@buserror.net> Date: 2016-07-17 02:50:54
From: Yangbo Lu <yangbo.lu@nxp.com>
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: Rob Herring <robh@kernel.org>
Signed-off-by: Scott Wood <oss@buserror.net>
---
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.txtsimilarity index 91%rename from Documentation/devicetree/bindings/powerpc/fsl/guts.txtrename to Documentation/devicetree/bindings/soc/fsl/guts.txtindex 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";
From: Scott Wood <oss@buserror.net> Date: 2016-07-17 02:50:58
Establish an initial user of fsl_guts_get_svr(), so that the code gets
some test coverage until users outside arch/powerpc can get converted.
Signed-off-by: Scott Wood <oss@buserror.net>
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/sysdev/fsl_pci.c | 6 +++++-
2 files changed, 6 insertions(+), 1 deletion(-)
@@ -529,7 +530,10 @@ int fsl_add_bridge(struct platform_device *pdev, int is_primary)structdevice_node*dev;structccsr_pci__iomem*pci;u16temp;-u32svr=mfspr(SPRN_SVR);+u32svr;++fsl_guts_init();+svr=fsl_guts_get_svr();dev=pdev->dev.of_node;
From: Scott Wood <oss@buserror.net> Date: 2016-07-17 02:51:04
From: yangbo lu <yangbo.lu@nxp.com>
Move mpc85xx.h to include/linux/fsl and rename it to svr.h as a common
header file. This SVR numberspace is used on some ARM chips as well as
PPC, and even to check for a PPC SVR multi-arch drivers would otherwise
need to ifdef the header inclusion and all references to the SVR symbols.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Wolfram Sang <redacted>
Acked-by: Stephen Boyd <redacted>
Acked-by: Joerg Roedel <redacted>
[scottwood: update description]
Signed-off-by: Scott Wood <oss@buserror.net>
---
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
arch/powerpc/sysdev/fsl_pci.c | 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 ++--
7 files changed, 8 insertions(+), 10 deletions(-)
rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)
diff --git a/arch/powerpc/include/asm/mpc85xx.h b/include/linux/fsl/svr.hsimilarity index 97%rename from arch/powerpc/include/asm/mpc85xx.hrename to include/linux/fsl/svr.hindex 213f3a8..8d13836 100644--- a/arch/powerpc/include/asm/mpc85xx.h+++ b/include/linux/fsl/svr.h
From: Scott Wood <oss@buserror.net> Date: 2016-07-17 02:51:06
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 a driver to manage and access global utilities block.
Initially only reading SVR is supported. Other guts accesses, such as
reading RCW, should eventually be moved into this driver as well.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
[scottwood: minor cleanup]
Signed-off-by: Scott Wood <oss@buserror.net>
---
arch/powerpc/platforms/85xx/common.c | 2 -
drivers/soc/Kconfig | 2 +-
drivers/soc/fsl/Kconfig | 8 +++
drivers/soc/fsl/Makefile | 1 +
drivers/soc/fsl/guts.c | 113 +++++++++++++++++++++++++++++++
include/linux/fsl/guts.h | 126 ++++++++++++++++++++++-------------
6 files changed, 201 insertions(+), 51 deletions(-)
create mode 100644 drivers/soc/fsl/Kconfig
create mode 100644 drivers/soc/fsl/guts.c
@@ -29,8 +29,6 @@ static const struct of_device_id mpc85xx_common_ids[] __initconst = {{.compatible="fsl,srio",},/* So that the DMA channel nodes can be probed individually: */{.compatible="fsl,eloplus-dma",},-/* For the PMC driver */-{.compatible="fsl,mpc8548-guts",},/* Probably unnecessary? */{.compatible="gpio-leds",},/* For all PCI controllers */
@@ -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"
@@ -0,0 +1,113 @@+/*+*FreescaleQorIQPlatformsGUTSDriver+*+*Copyright(C)2016FreescaleSemiconductor,Inc.+*+*Thisprogramisfreesoftware;youcanredistributeitand/ormodify+*itunderthetermsoftheGNUGeneralPublicLicenseaspublishedby+*theFreeSoftwareFoundation;eitherversion2oftheLicense,or+*(atyouroption)anylaterversion.+*/++#include<linux/io.h>+#include<linux/slab.h>+#include<linux/mutex.h>+#include<linux/of_address.h>+#include<linux/of_platform.h>+#include<linux/fsl/guts.h>++structguts{+structccsr_guts__iomem*regs;+boollittle_endian;+};++staticstructguts*guts;+staticDEFINE_MUTEX(guts_lock);++u32fsl_guts_get_svr(void)+{+u32svr=0;++if(!guts||!guts->regs){+#ifdef CONFIG_PPC+svr=mfspr(SPRN_SVR);+#endif+returnsvr;+}++if(guts->little_endian)+svr=ioread32(&guts->regs->svr);+else+svr=ioread32be(&guts->regs->svr);++returnsvr;+}+EXPORT_SYMBOL(fsl_guts_get_svr);++/*+*Tableformatchingcompatiblestrings,fordevicetree+*gutsnode,forFreescaleQorIQSOCs.+*/+staticconststructof_device_idguts_of_match[]={+{.compatible="fsl,qoriq-device-config-1.0",},+{.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",},+{.compatible="fsl,bsc9131-guts",},+{.compatible="fsl,bsc9132-guts",},+{.compatible="fsl,mpc8536-guts",},+{.compatible="fsl,mpc8544-guts",},+{.compatible="fsl,mpc8548-guts",},+{.compatible="fsl,mpc8568-guts",},+{.compatible="fsl,mpc8569-guts",},+{.compatible="fsl,mpc8572-guts",},+{.compatible="fsl,ls1021a-dcfg",},+{.compatible="fsl,ls1043a-dcfg",},+{.compatible="fsl,ls2080a-dcfg",},+{}+};++intfsl_guts_init(void)+{+structdevice_node*np;+intret;++mutex_lock(&guts_lock);+/* Initialize guts only once */+if(guts){+ret=guts->regs?0:-ENOMEM;+gotoout;+}++np=of_find_matching_node(NULL,guts_of_match);+if(!np){+ret=-ENODEV;+gotoout;+}++guts=kzalloc(sizeof(*guts),GFP_KERNEL);+if(!guts){+ret=-ENOMEM;+gotoout_np;+}++guts->little_endian=of_property_read_bool(np,"little-endian");++guts->regs=of_iomap(np,0);+if(!guts->regs){+ret=-ENOMEM;+gotoout_np;+}++ret=0;+out_np:+of_node_put(np);+out:+mutex_unlock(&guts_lock);+returnret;+}+EXPORT_SYMBOL(fsl_guts_init);
On Saturday, July 16, 2016 9:50:21 PM CEST Scott Wood wrote:
From: yangbo lu <yangbo.lu@nxp.com>
Move mpc85xx.h to include/linux/fsl and rename it to svr.h as a common
header file. This SVR numberspace is used on some ARM chips as well as
PPC, and even to check for a PPC SVR multi-arch drivers would otherwise
need to ifdef the header inclusion and all references to the SVR symbols.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Wolfram Sang <redacted>
Acked-by: Stephen Boyd <redacted>
Acked-by: Joerg Roedel <redacted>
[scottwood: update description]
Signed-off-by: Scott Wood <oss@buserror.net>
As discussed before, please don't introduce yet another vendor specific
way to match a SoC ID from a device driver.
I've posted a patch for an extension to the soc_device infrastructure
to allow comparing the running SoC to a table of devices, use that
instead.
Arnd
From: Scott Wood <oss@buserror.net> Date: 2016-07-20 18:32:01
On Wed, 2016-07-20 at 13:24 +0200, Arnd Bergmann wrote:
On Saturday, July 16, 2016 9:50:21 PM CEST Scott Wood wrote:
quoted
From: yangbo lu <yangbo.lu@nxp.com>
Move mpc85xx.h to include/linux/fsl and rename it to svr.h as a common
header file. This SVR numberspace is used on some ARM chips as well as
PPC, and even to check for a PPC SVR multi-arch drivers would otherwise
need to ifdef the header inclusion and all references to the SVR symbols.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Wolfram Sang <redacted>
Acked-by: Stephen Boyd <redacted>
Acked-by: Joerg Roedel <redacted>
[scottwood: update description]
Signed-off-by: Scott Wood <oss@buserror.net>
As discussed before, please don't introduce yet another vendor specific
way to match a SoC ID from a device driver.
I've posted a patch for an extension to the soc_device infrastructure
to allow comparing the running SoC to a table of devices, use that
instead.
As I asked before, in which relevant maintainership capacity are you NACKing
this?
-Scott
On Wednesday, July 20, 2016 1:31:48 PM CEST Scott Wood wrote:
On Wed, 2016-07-20 at 13:24 +0200, Arnd Bergmann wrote:
quoted
On Saturday, July 16, 2016 9:50:21 PM CEST Scott Wood wrote:
quoted
From: yangbo lu <yangbo.lu@nxp.com>
Move mpc85xx.h to include/linux/fsl and rename it to svr.h as a common
header file. This SVR numberspace is used on some ARM chips as well as
PPC, and even to check for a PPC SVR multi-arch drivers would otherwise
need to ifdef the header inclusion and all references to the SVR symbols.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Wolfram Sang <redacted>
Acked-by: Stephen Boyd <redacted>
Acked-by: Joerg Roedel <redacted>
[scottwood: update description]
Signed-off-by: Scott Wood <oss@buserror.net>
As discussed before, please don't introduce yet another vendor specific
way to match a SoC ID from a device driver.
I've posted a patch for an extension to the soc_device infrastructure
to allow comparing the running SoC to a table of devices, use that
instead.
As I asked before, in which relevant maintainership capacity are you NACKing
this?
I don't know why that's important, but I suggested the creation of
drivers/soc/ as a place to have a more general place for platform
specific drivers as part of being maintainer for arm-soc, and
almost all changes to drivers/soc go through our tree.
Olof does about half the merges, but I do the majority of the reviews
for drivers/soc patches. See also
git log --graph --format="%an %s" --merges drivers/soc/
Arnd
From: Scott Wood <oss@buserror.net> Date: 2016-07-21 16:45:40
On Thu, 2016-07-21 at 20:26 +1000, Michael Ellerman wrote:
Quoting Scott Wood (2016-07-21 04:31:48)
quoted
On Wed, 2016-07-20 at 13:24 +0200, Arnd Bergmann wrote:
quoted
On Saturday, July 16, 2016 9:50:21 PM CEST Scott Wood wrote:
quoted
From: yangbo lu <yangbo.lu@nxp.com>
Move mpc85xx.h to include/linux/fsl and rename it to svr.h as a common
header file. This SVR numberspace is used on some ARM chips as well
as
PPC, and even to check for a PPC SVR multi-arch drivers would
otherwise
need to ifdef the header inclusion and all references to the SVR
symbols.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Wolfram Sang <redacted>
Acked-by: Stephen Boyd <redacted>
Acked-by: Joerg Roedel <redacted>
[scottwood: update description]
Signed-off-by: Scott Wood <oss@buserror.net>
As discussed before, please don't introduce yet another vendor specific
way to match a SoC ID from a device driver.
I've posted a patch for an extension to the soc_device infrastructure
to allow comparing the running SoC to a table of devices, use that
instead.
As I asked before, in which relevant maintainership capacity are you
NACKing
this?
I'll nack the powerpc part until you guys can agree.
OK, I've pulled these patches out.
For the MMC issue I suggest using ifdef CONFIG_PPC and mfspr(SPRN_SVR) like
the clock driver does[1] and we can revisit the issue if/when we need to do
something similar on an ARM chip.
-Scott
[1] One of the issues with Arnd's approach is that it wouldn't have worked for
early things like the clock driver, and he didn't seem to mind using ifdef and
mfspr() there.
On Thursday, July 21, 2016 11:45:26 AM CEST Scott Wood wrote:
For the MMC issue I suggest using ifdef CONFIG_PPC and mfspr(SPRN_SVR) like
the clock driver does[1] and we can revisit the issue if/when we need to do
something similar on an ARM chip.
That sounds ok to me. having an mfspr check isn't nice but does the
job to work around existing bindings. For future chips, we can hopefully
find a way to identify most quirks early enough that the DT binding
can describe them using distinct compatible strings or other properties,
if necessary with the help of the boot loader.
Some other folks on MIPS were interested in having the soc_device
matching infrastructure and contacted me off-list, but they can of
course take the patch I sent and work from that.
Arnd
From: Scott Wood <oss@buserror.net> Date: 2016-07-27 00:38:26
On Mon, 2016-07-25 at 06:12 +0000, Yangbo Lu wrote:
Hi Scott,
quoted
-----Original Message-----
From: Scott Wood [mailto:oss@buserror.net]
Sent: Friday, July 22, 2016 12:45 AM
To: Michael Ellerman; Arnd Bergmann
Cc: linux-mmc@vger.kernel.org; devicetree@vger.kernel.org; linuxppc-
dev@lists.ozlabs.org; linux-kernel@vger.kernel.org; Yangbo Lu
Subject: Re: [PATCH v11 4/5] powerpc/fsl: move mpc85xx.h to
include/linux/fsl
On Thu, 2016-07-21 at 20:26 +1000, Michael Ellerman wrote:
quoted
Quoting Scott Wood (2016-07-21 04:31:48)
quoted
On Wed, 2016-07-20 at 13:24 +0200, Arnd Bergmann wrote:
quoted
On Saturday, July 16, 2016 9:50:21 PM CEST Scott Wood wrote:
quoted
From: yangbo lu <yangbo.lu@nxp.com>
Move mpc85xx.h to include/linux/fsl and rename it to svr.h as a
common header file. This SVR numberspace is used on some ARM
chips as well as PPC, and even to check for a PPC SVR multi-arch
drivers would otherwise need to ifdef the header inclusion and
all references to the SVR symbols.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Wolfram Sang <redacted>
Acked-by: Stephen Boyd <redacted>
Acked-by: Joerg Roedel <redacted>
[scottwood: update description]
Signed-off-by: Scott Wood <oss@buserror.net>
As discussed before, please don't introduce yet another vendor
specific way to match a SoC ID from a device driver.
I've posted a patch for an extension to the soc_device
infrastructure to allow comparing the running SoC to a table of
devices, use that instead.
As I asked before, in which relevant maintainership capacity are you
NACKing this?
I'll nack the powerpc part until you guys can agree.
OK, I've pulled these patches out.
For the MMC issue I suggest using ifdef CONFIG_PPC and mfspr(SPRN_SVR)
like the clock driver does[1] and we can revisit the issue if/when we
need to do something similar on an ARM chip.
[Lu Yangbo-B47093] I remembered that Uffe had opposed us to introduce non-
generic header files(like '#include <asm/mpc85xx.h>')
in mmc driver initially. So I think it will not be accepted to use ifdef
CONFIG_PPC and mfspr(SPRN_SVR)...
And this method still couldn’t get SVR of ARM chip now.
Right, as I said we'll have to revisit the issue if/when we have the same
problem on an ARM chip. That also applies if the PPC ifdef is still getting
NACKed from the MMC side.
Any other suggestion here?
The other option is to try to come up with something that fits into Arnd's
framework while addressing the concerns I raised. The soc_id string should be
well-structured to avoid mismatches and compatibility problems (especially
since it would get exposed to userspace). Maybe something like:
svr:<SVR minus E bit>,svre:<full SVR including E bit>,name:<soc name>,die:<soc
die name>,rev:X.Y,<tag1>,<tag2>,<...>,
with the final comma used so that globs can put a colon on either end to be
sure they're matching a full field. The SoC die name would be the primary
chip for a given die (e.g. p4040 would have a die name of p4080). The "name"
and "die" fields would never include the trailing "e" indicated by the E bit.
Extra tags could be used for common groupings, such as all chips from a
particular die before a certain revision. Once a tag is added it can't be
removed or reordered, to maintain userspace compatibility, but new tags could
be appended.
Some examples:
svr:0x82000020,svre:0x82000020,name:p4080,die:p4080,rev:2.0,
svr:0x82000020,svr
e:0x82080020,name:p4080,die:p4080,rev:2.0,
svr:0x82000030,svre:0x82000030,name:
p4080,die:p4080,rev:3.0,
svr:0x82000030,svre:0x82080030,name:p4080,die:p4080,re
v:3.0,
svr:0x82010020,svre:0x82010020,name:p4040,die:p4080,rev:2.0,
svr:0x820100
20,svre:0x82090020,name:p4040,die:p4080,rev:2.0,
svr:0x82010030,svre:0x82010030
,name:p4040,die:p4080,rev:3.0,
svr:0x82010030,svre:0x82090030,name:p4040,die:p4
080,rev:3.0,
Then if you want to apply a workaround on:
- all chips using the p4080 die, match with "*,die:p4080,*"
- all chips using the rev 2.0 p4080 die, match with "*,die:p4080,rev:2.0,*"
- Only p4040, but of any rev, match with "*,name:p4040,*"
Matching via open-coded hex number should be considered a last resort (it's
more error-prone, either for getting the number wrong or for forgetting
variants -- the latter is already a common problem), but preferable to adding
too many tags.
Using wildcards within a tag field would be discouraged.
-Scott
From: Scott Wood <oss@buserror.net> Date: 2016-08-02 22:04:35
On Tue, 2016-08-02 at 05:57 +0000, Yangbo Lu wrote:
Hi Scott,
quoted
-----Original Message-----
From: Scott Wood [mailto:oss@buserror.net]
Sent: Wednesday, July 27, 2016 8:38 AM
To: Yangbo Lu; Michael Ellerman; Arnd Bergmann; Ulf Hansson
Cc: linux-mmc@vger.kernel.org; devicetree@vger.kernel.org; linuxppc-
dev@lists.ozlabs.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v11 4/5] powerpc/fsl: move mpc85xx.h to
include/linux/fsl
On Mon, 2016-07-25 at 06:12 +0000, Yangbo Lu wrote:
quoted
Hi Scott,
quoted
-----Original Message-----
From: Scott Wood [mailto:oss@buserror.net]
Sent: Friday, July 22, 2016 12:45 AM
To: Michael Ellerman; Arnd Bergmann
Cc: linux-mmc@vger.kernel.org; devicetree@vger.kernel.org; linuxppc-
dev@lists.ozlabs.org; linux-kernel@vger.kernel.org; Yangbo Lu
Subject: Re: [PATCH v11 4/5] powerpc/fsl: move mpc85xx.h to
include/linux/fsl
On Thu, 2016-07-21 at 20:26 +1000, Michael Ellerman wrote:
quoted
Quoting Scott Wood (2016-07-21 04:31:48)
quoted
On Wed, 2016-07-20 at 13:24 +0200, Arnd Bergmann wrote:
quoted
On Saturday, July 16, 2016 9:50:21 PM CEST Scott Wood wrote:
quoted
From: yangbo lu <yangbo.lu@nxp.com>
Move mpc85xx.h to include/linux/fsl and rename it to svr.h
as a common header file. This SVR numberspace is used on
some ARM chips as well as PPC, and even to check for a PPC
SVR multi-arch drivers would otherwise need to ifdef the
header inclusion and all references to the SVR symbols.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Wolfram Sang <redacted>
Acked-by: Stephen Boyd <redacted>
Acked-by: Joerg Roedel <redacted>
[scottwood: update description]
Signed-off-by: Scott Wood <oss@buserror.net>
As discussed before, please don't introduce yet another vendor
specific way to match a SoC ID from a device driver.
I've posted a patch for an extension to the soc_device
infrastructure to allow comparing the running SoC to a table
of devices, use that instead.
As I asked before, in which relevant maintainership capacity are
you NACKing this?
I'll nack the powerpc part until you guys can agree.
OK, I've pulled these patches out.
For the MMC issue I suggest using ifdef CONFIG_PPC and
mfspr(SPRN_SVR) like the clock driver does[1] and we can revisit the
issue if/when we need to do something similar on an ARM chip.
[Lu Yangbo-B47093] I remembered that Uffe had opposed us to introduce
non- generic header files(like '#include <asm/mpc85xx.h>') in mmc
driver initially. So I think it will not be accepted to use ifdef
CONFIG_PPC and mfspr(SPRN_SVR)...
And this method still couldn’t get SVR of ARM chip now.
Right, as I said we'll have to revisit the issue if/when we have the same
problem on an ARM chip. That also applies if the PPC ifdef is still
getting NACKed from the MMC side.
[Lu Yangbo-B47093] It's not clear for me about your idea :(
Do you mean we can still use this method, or not ?
I think Uffe had opposed to use ifdef CONFIG_PPC and mfspr(SPRN_SVR).
Is there any solution to resolve ?
:)
As I said, I'm OK with using the SPR. It's up to you to find out whether it's
still unacceptable with the MMC maintainers given all the discussion (it would
be the quickest way to get the workaround enabled), or just go with the method
below.
quoted
quoted
Any other suggestion here?
The other option is to try to come up with something that fits into
Arnd's framework while addressing the concerns I raised. The soc_id
string should be well-structured to avoid mismatches and compatibility
problems (especially since it would get exposed to userspace). Maybe
something like:
svr:<SVR minus E bit>,svre:<full SVR including E bit>,name:<soc
name>,die:<soc die name>,rev:X.Y,<tag1>,<tag2>,<...>,
[Lu Yangbo-B47093] The soc_device_attribut struct is defined as below.
struct soc_device_attribute {
const char *machine;
const char *family;
const char *revision;
const char *soc_id;
};
We can put the 'model' in root node of dts as machine, put 'Freescale QorIQ'
as family,
I'd just put "QorIQ" to avoid the question of whether to use "Freescale" or
"NXP".
and put x.x as revision. Is it ok?
As you suggested, you like to use below string as soc_id. It's easy to get
svr, but how does the software know the name and die,
and put them into this string ? It's a large code to define them.
Yes, there would need to be a table in the guts driver for each SVR. If the
SVR isn't found in the table then the soc_id would only contain the svr: and
svre: fields.
quoted
svr:<SVR minus E bit>,svre:<full SVR including E bit>,name:<soc
name>,die:<soc die name>,rev:X.Y,<tag1>,<tag2>,<...>,
Should we remove rev here since there is also a revision member?
Yes, I forgot there was a revision field -- it should go there obviously.
Regarding the guts_init, we still call guts_init and then match the soc, or
we change to use platform driver?
Or do you know any better place to call guts_init to initialize only once?
Use a platform driver for now. If we ever need to check an ARM SVR in the
clock driver or similar place, then Arnd can explain what he wants us to do
then :-)
-Scott