RE: [PATCH 3/4 v2] powerpc/fsl-booke: Add T1024 RDB board support
--- v2: Integrated scott's comments. My comment was to add a binding for the QE TDM stuff, not to remove it. -Scott QE TDM has not been upstream on any fsl-board, it needs QE TDM owner finish it uniformly for those boards(p1021, p1025, t1040, t1024, etc) with binding. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/4 v2] powerpc/fsl-booke: Add device tree support for T1024/T1023 SoC
+soc {
+/include/ qoriq-tdm1.0.dtsi
Where is this file? Is there some dependency you've forgotten to mention?
If this is meant to apply after
http://patchwork.ozlabs.org/patch/457605/
is that really QUICC engine TDM as described in the comment above?
-Scott
Yes, it depends on http://patchwork.ozlabs.org/patch/457605/
right that's really QUICC engine TDM.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [1/4] powerpc/fsl-booke: Add device tree support for T1024/T1023 SoC
-Original Message-
From: Wood Scott-B07421
Sent: Friday, January 30, 2015 9:20 AM
To: Liu Shengzhou-B36685
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [1/4] powerpc/fsl-booke: Add device tree support for
T1024/T1023 SoC
On Thu, Jan 29, 2015 at 03:52:24PM +0800, Shengzhou Liu wrote:
+ corenet-cf@18000 {
+ compatible = fsl,corenet2-cf;
While the damage has already been done by the t1040 device tree, this is
not 100% compatible with what's on t4240. I'm not sure if it's worth
doing anything about it at this point, given that you can tell the
difference by the version register even though that register is reserved
on t4240 and simliar chips, which is what I do in
http://patchwork.ozlabs.org/patch/419911/
Now here fsl,corenet2-cf is suitable for t1024 after your t1040 patch was
merged.
T1024 and t1040 have the same version of ccf.
+ reg = 0x18000 0x1000;
+ interrupts = 16 2 1 31;
+ fsl,ccf-num-csdids = 32;
+ fsl,ccf-num-snoopids = 32;
The t1040/t1024 CCM does not have CSD/Snoop IDs.
Removed.
+/include/ qoriq-i2c-0.dtsi
+/include/ qoriq-i2c-1.dtsi
t1023 has only three i2c controllers -- where do you disable the fourth?
u-boot will disable the fourth i2c controller.
+/include/ t1023si-post.dtsi
+soc {
+ display:display@18 {
+ compatible = fsl,t1024-diu, fsl,diu;
+ reg = 0x18 1000;
+ interrupts = 74 2 0 0;
+ };
+};
There are other differences between t1023 an t1024. Where do you
describe t1024's QE? Where do you describe the DDR and IFC differences?
can they be detected at runtime? t1024 supports deep sleep, but t1023
doesn't -- yet you label both chips as having t1024 rcpm.
As QE IP block has not been upstream yet, so have to removed QE info in dts
currently(same on t1040),
DDR and IFC differences are in u-boot, not in dts.
Both t1023 and t1024 support sleep, so label both chips as having t1024 rcpm.
Only t1024 has deep sleep, the difference is identified in *.c not in dts
(confirmed with deep sleep owner).
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [1/4] powerpc/fsl-booke: Add device tree support for T1024/T1023 SoC
There are other differences between t1023 an t1024. Where do you
describe t1024's QE? Where do you describe the DDR and IFC differences?
can they be detected at runtime? t1024 supports deep sleep, but
t1023 doesn't -- yet you label both chips as having t1024 rcpm.
As QE IP block has not been upstream yet,
Huh?
arch/powerpc/sysdev/qe_lib/
arch/powerpc/boot/dts/fsl/qoriq-tdm1.0.dtsi has not been upstream by TDM owner.
Ok, I will first send qoriq-tdm1.0.dtsi upstream in order to include QE in
t1024 dts.
DDR and IFC differences are in u-boot, not in dts.
The differences are in hardware, which is what the dts is supposed to
describe.
Theoretically I think so, but not all hardware details must be described in dts
as current IP driver doesn't take care of it from dts.
If so, IP owners will have to update drivers, for now let's keep as it's.
Both t1023 and t1024 support sleep, so label both chips as having t1024
rcpm.
That's not how it works.
Only t1024 has deep sleep, the difference is identified in *.c not in dts
(confirmed with deep sleep owner).
Even if the C code chooses to use SVR to identify the difference (why?),
that doesn't mean it's OK for the device tree to contain wrong information.
Where is the wrong information?
rcpm: global-utilities@e2000 {
compatible = fsl,t1024-rcpm, fsl,qoriq-rcpm-2.0;
reg = 0xe2000 0x1000;
};
sdhc@114000 {
compatible = fsl,t1024-esdhc, fsl,esdhc;
fsl,iommu-parent = pamu0;
fsl,liodn-reg = guts 0x530; /* eSDHCLIODNR */
sdhci,auto-cmd12;
no-1-8-v;
sleep = rcpm 0x0080;
};
t1023 also supports sleep(not deep sleep), it needs the info above.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] of: Add vendor prefix for EON Corporation
-Original Message- From: Wood Scott-B07421 Sent: Tuesday, July 08, 2014 2:55 AM To: Liu Shengzhou-B36685 Cc: linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH] of: Add vendor prefix for EON Corporation On Mon, 2014-07-07 at 17:29 +0800, Shengzhou Liu wrote: Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) Again, please CC all relevant mailing lists. Where is the devicetree list? And mention why this patch is relevant to PPC. -Scott [Shengzhou] I didn't find any relevant list for devicetree in the MAINTAINERS, so sent it here to wait for someone point to the proper list. diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 1a6793b..3c10a21 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -42,6 +42,7 @@ ebv EBV Elektronik edtEmerging Display Technologies emmicroEM Microelectronic epfl Ecole Polytechnique Fédérale de Lausanne +eonEon Silicon Solution, Inc. epson Seiko Epson Corp. estESTeem Wireless Modems eukrea Eukréa Electromatique ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] of: Add vendor prefix for EON Corporation
-Original Message- From: Liu Shengzhou-B36685 Sent: Tuesday, July 08, 2014 3:05 PM To: Wood Scott-B07421 Cc: linuxppc-dev@lists.ozlabs.org Subject: RE: [PATCH] of: Add vendor prefix for EON Corporation -Original Message- From: Wood Scott-B07421 Sent: Tuesday, July 08, 2014 2:55 AM To: Liu Shengzhou-B36685 Cc: linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH] of: Add vendor prefix for EON Corporation On Mon, 2014-07-07 at 17:29 +0800, Shengzhou Liu wrote: Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) Again, please CC all relevant mailing lists. Where is the devicetree list? And mention why this patch is relevant to PPC. -Scott [Shengzhou] I didn't find any relevant list for device tree in the MAINTAINERS, so sent it here to wait for someone point to the proper list. [Shengzhou] found it, will send to devicet...@vger.kernel.org ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [3/3,v4] powerpc/t2080rdb: Add T2080RDB board support
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, June 26, 2014 7:35 AM
To: Liu Shengzhou-B36685
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [3/3,v4] powerpc/t2080rdb: Add T2080RDB board support
On Wed, Jun 11, 2014 at 06:10:06PM +0800, Shengzhou Liu wrote:
+ i2c@0 {
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x0;
+
+ sfp@50 {
+ compatible = optics,sfp;
+ reg = 0x50;
+ };
+ };
What is sfp? Please use generic node names when possible.
I'm not able to easily find what chip this is referring to by googling
optics sfp. I suspect this compatible is too vague -- what is the
actual part number? Could you provide a URL to a description of the chip?
If optics is the correct vendor name, it needs to go into
vendor-prefixes.txt.
-Scott
[Shengzhou] SFP is Small Form-factor Pluggable transceiver for 10Gpbs optics
module. Actually, there is no a specific vendor for this case, it is a general
sfp cage to which we can plug in different optics module from different
vendors. And there is no need to configure it by SW.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [linuxppc-release] [PATCH][v10] powerpc/mpc85xx:Add initial device tree support of T104x
-Original Message-
From: linuxppc-release-boun...@linux.freescale.net [mailto:linuxppc-
release-boun...@linux.freescale.net] On Behalf Of Prabhakar Kushwaha
Sent: Monday, April 21, 2014 7:34 PM
To: linuxppc-dev@lists.ozlabs.org
Cc: Wood Scott-B07421; Jain Priyanka-B32167; Aggrwal Poonam-B10812;
Kushwaha Prabhakar-B32579
Subject: [linuxppc-release] [PATCH][v10] powerpc/mpc85xx:Add initial
device tree support of T104x
The QorIQ T1040/T1042 processor support four integrated 64-bit e5500 PA
processor cores with high-performance data path acceleration architecture
and network peripheral interfaces required for networking
telecommunications.
+
+ iommu@2 {
+ compatible = fsl,pamu-v1.0, fsl,pamu;
+ reg = 0x2 0x1000;
+ ranges = 0 0x2 0x1000;
+ #address-cells = 1;
+ #size-cells = 1;
+ interrupts =
+ 24 2 0 0
+ 16 2 1 30;
+ pamu0: pamu@0 {
+ reg = 0 0x1000;
+ fsl,primary-cache-geometry = 128 1;
+ fsl,secondary-cache-geometry = 16 2;
+ };
[Shengzhou] T1040 RM says:
Hardware coherent PAMU Look-aside caches to improve performance
* A 32-entry, direct-mapped primary PAACT cache
* A 128-entry, 2-way, set-associative secondary PAACT cache
It appears it should be:
fsl,primary-cache-geometry = 32 1;
fsl,secondary-cache-geometry = 128 2;
is there any reason that it was 128 1, 16 2 ?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [2/2] powerpc/corenet64_smp_defconfig: enable RTC support
-Original Message- From: Wood Scott-B07421 Sent: Wednesday, May 28, 2014 12:21 AM To: Kumar Gala Cc: Liu Shengzhou-B36685; linuxppc-dev@lists.ozlabs.org Subject: Re: [2/2] powerpc/corenet64_smp_defconfig: enable RTC support On Tue, 2014-05-27 at 10:33 -0500, Kumar Gala wrote: On May 25, 2014, at 10:08 PM, shengzhou@freescale.com wrote: -Original Message- From: Wood Scott-B07421 Sent: Saturday, May 24, 2014 1:06 AM To: Liu Shengzhou-B36685 Cc: linuxppc-dev@lists.ozlabs.org Subject: Re: [2/2] powerpc/corenet64_smp_defconfig: enable RTC support On Fri, 2014-05-23 at 03:03 -0500, Liu Shengzhou-B36685 wrote: -Original Message- From: Wood Scott-B07421 Sent: Friday, May 23, 2014 6:52 AM To: Liu Shengzhou-B36685 Cc: linuxppc-dev@lists.ozlabs.org Subject: Re: [2/2] powerpc/corenet64_smp_defconfig: enable RTC support +++ b/arch/powerpc/configs/corenet64_smp_defconfig @@ -125,6 +125,11 @@ CONFIG_USB_EHCI_FSL=y CONFIG_USB_STORAGE=y CONFIG_MMC=y CONFIG_MMC_SDHCI=y +CONFIG_RTC_CLASS=y +CONFIG_RTC_DRV_CMOS=y +CONFIG_RTC_DRV_DS1307=y +CONFIG_RTC_DRV_DS1374=y +CONFIG_RTC_DRV_DS3232=y CONFIG_EDAC=y CONFIG_EDAC_MM_EDAC=y CONFIG_DMADEVICES=y Why only corenet64 and not corenet32? -Scott [Shengzhou] There is already RTC support in corenet32, only missing in corenet64. Only DS3232, not DS1307 or DS1374. Which boards use the latter two? Why do we need CONFIG_RTC_DRV_CMOS? -Scott [Shengzhou] so far DS1307 and DS1374 occur only on those boards with corenet64. Which boards? I don't see them in any corenet dts files. [Shengzhou] CONFIG_RTC_DRV_DS1307 is needed for ds1339 on t2080rdb. I do see some instances of ds1374 in the dts files of boards non-corenet mpc85xx boards (mpc8568mds, mpc8569mds, and p1021mds), yet it's not in the mpc85xx_defconfig or mpc85xx_smp_defconfig. CONFIG_RTC_DRV_CMOS is enabled in mpc85xx_defconfig, mpc85xx_smp_defconfig, corenet32_smp_defconfig, etc, here keeps consistent in corenet64. It seems CONFIG_RTC_DRV_CMOS is not needed on 85xx platform, do we need to remove CONFIG_RTC_DRV_CMOS from all 85xx/corenet defconfig? If so, I will post a new patch to do it. The CDS board uses an RTC over ISA if I remember correctly, not sure what driver deals with that (if its CONFIG_RTC_DRV_CMOS) or something else. If it's just CDS then we don't need it in either corenet config. -Scott [Shengzhou] yes, mpc8548cds board uses CONFIG_RTC_DRV_CMOS to deal with rtc. I updated these changes with new patch v2: http://patchwork.ozlabs.org/patch/353243/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [2/2] powerpc/corenet64_smp_defconfig: enable RTC support
-Original Message- From: Wood Scott-B07421 Sent: Saturday, May 24, 2014 1:06 AM To: Liu Shengzhou-B36685 Cc: linuxppc-dev@lists.ozlabs.org Subject: Re: [2/2] powerpc/corenet64_smp_defconfig: enable RTC support On Fri, 2014-05-23 at 03:03 -0500, Liu Shengzhou-B36685 wrote: -Original Message- From: Wood Scott-B07421 Sent: Friday, May 23, 2014 6:52 AM To: Liu Shengzhou-B36685 Cc: linuxppc-dev@lists.ozlabs.org Subject: Re: [2/2] powerpc/corenet64_smp_defconfig: enable RTC support +++ b/arch/powerpc/configs/corenet64_smp_defconfig @@ -125,6 +125,11 @@ CONFIG_USB_EHCI_FSL=y CONFIG_USB_STORAGE=y CONFIG_MMC=y CONFIG_MMC_SDHCI=y +CONFIG_RTC_CLASS=y +CONFIG_RTC_DRV_CMOS=y +CONFIG_RTC_DRV_DS1307=y +CONFIG_RTC_DRV_DS1374=y +CONFIG_RTC_DRV_DS3232=y CONFIG_EDAC=y CONFIG_EDAC_MM_EDAC=y CONFIG_DMADEVICES=y Why only corenet64 and not corenet32? -Scott [Shengzhou] There is already RTC support in corenet32, only missing in corenet64. Only DS3232, not DS1307 or DS1374. Which boards use the latter two? Why do we need CONFIG_RTC_DRV_CMOS? -Scott [Shengzhou] so far DS1307 and DS1374 occur only on those boards with corenet64. CONFIG_RTC_DRV_CMOS is enabled in mpc85xx_defconfig, mpc85xx_smp_defconfig, corenet32_smp_defconfig, etc, here keeps consistent in corenet64. It seems CONFIG_RTC_DRV_CMOS is not needed on 85xx platform, do we need to remove CONFIG_RTC_DRV_CMOS from all 85xx/corenet defconfig? If so, I will post a new patch to do it. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [2/2] powerpc/corenet64_smp_defconfig: enable RTC support
-Original Message- From: Wood Scott-B07421 Sent: Friday, May 23, 2014 6:52 AM To: Liu Shengzhou-B36685 Cc: linuxppc-dev@lists.ozlabs.org Subject: Re: [2/2] powerpc/corenet64_smp_defconfig: enable RTC support +++ b/arch/powerpc/configs/corenet64_smp_defconfig @@ -125,6 +125,11 @@ CONFIG_USB_EHCI_FSL=y CONFIG_USB_STORAGE=y CONFIG_MMC=y CONFIG_MMC_SDHCI=y +CONFIG_RTC_CLASS=y +CONFIG_RTC_DRV_CMOS=y +CONFIG_RTC_DRV_DS1307=y +CONFIG_RTC_DRV_DS1374=y +CONFIG_RTC_DRV_DS3232=y CONFIG_EDAC=y CONFIG_EDAC_MM_EDAC=y CONFIG_DMADEVICES=y Why only corenet64 and not corenet32? -Scott [Shengzhou] There is already RTC support in corenet32, only missing in corenet64. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/2] mtd/spi: support en25s64 device
-Original Message-
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -745,6 +745,7 @@ static const struct spi_device_id m25p_ids[] = {
{ en25q32b, INFO(0x1c3016, 0, 64 * 1024, 64, 0) },
{ en25p64,INFO(0x1c2017, 0, 64 * 1024, 128, 0) },
{ en25q64,INFO(0x1c3017, 0, 64 * 1024, 128, SECT_4K) },
+ { en25s64,INFO(0x1c3817, 0, 64 * 1024, 128, 0) },
{ en25qh256, INFO(0x1c7019, 0, 64 * 1024, 512, 0) },
/* ESMT */
This needs to be sent to the mtd and/or spi maintainers, not here.
What does this have to do with patch 2/2? Don't put unrelated things in
the same patchset, especially when they're destined for different
maintainers.
-Scott
[Shengzhou] thanks, sent to linux-...@lists.infradead.org already.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] net/phy: tune get_phy_c45_ids to support more c45 phy
-Original Message- From: Wood Scott-B07421 Sent: Thursday, April 24, 2014 5:02 AM To: Liu Shengzhou-B36685 Cc: linuxppc-dev@lists.ozlabs.org; tr...@ti.com Subject: Re: [PATCH] net/phy: tune get_phy_c45_ids to support more c45 phy On Wed, 2014-04-23 at 17:55 +0800, Shengzhou Liu wrote: As some C45 10G PHYs(e.g. Cortina CS4315/CS4340 PHY) have zero Devices In package, current driver can't get correct devices_in_package value by non-zero Devices In package. so let's probe more with zero Devices In package to support more C45 PHYs which have zero Devices In package. Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- Tested with CS4315 on T2080RDB, this patch have no impact on previous XAUI phy with verification. drivers/net/phy/phy_device.c | 25 + 1 file changed, 21 insertions(+), 4 deletions(-) diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c index cfb5110..8fd777e 100644 --- a/drivers/net/phy/phy_device.c +++ b/drivers/net/phy/phy_device.c You need to send this to the netdev list and maintainer. -Scott [Shengzhou] Sent to netdev list, but it seems there is no maintainer of drivers/net/phy in MAINTAINERS list. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] net/phy: Add Cortina CS43xx PHY support
Sure, will too post to netdev list. Regards, Shengzhou -Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: Wednesday, March 05, 2014 5:30 PM To: Liu Shengzhou-B36685 Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Cao Yong Hua-B43619 Subject: Re: [PATCH] net/phy: Add Cortina CS43xx PHY support On Mar 5, 2014, at 2:16 AM, Shengzhou Liu shengzhou@freescale.com wrote: Add support for Cortina CS4315/CS4340 10G PHY. (Tested with CS4315 on T2080RDB and CS4340 on T4240RDB). Signed-off-by: YongHua Cao b43...@freescale.com Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- drivers/net/phy/Kconfig | 5 +++ drivers/net/phy/Makefile | 1 + drivers/net/phy/cortina.c | 92 +++ 3 files changed, 98 insertions(+) create mode 100644 drivers/net/phy/cortina.c This patch really needs to be posted to the netdev list - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] net/phy: Add Cortina CS43xx PHY support
Abandon this patch, in Kernel gen10g_driver can support Cortina PHY, we need specific PHY driver just in u-boot. -Shengzhou ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 4/5] powerpc/fsl-booke: Add initial T208x QDS board support
-Original Message-
From: Wood Scott-B07421
Sent: Wednesday, December 18, 2013 3:57 AM
To: Liu Shengzhou-B36685
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 4/5] powerpc/fsl-booke: Add initial T208x QDS board
support
On Wed, 2013-12-11 at 19:19 +0800, Shengzhou Liu wrote:
+ boardctrl: board-control@3,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,fpga-qixis;
+ reg = 3 0 0x300;
+ ranges = 0 3 0 0x300;
+ };
Why do you have ranges and #address-cells/#size-cells here? When would
there ever be a child node?
[Shengzhou] There are multiple child nodes for this(in a separate DPAA-related
patch, but whole DPAA module has not been upstreamed yet so far)
+ };
+
+ memory {
+ device_type = memory;
+ };
+
+ dcsr: dcsr@f {
+ ranges = 0x 0xf 0x 0x01072000;
+ };
+
+ soc: soc@ffe00 {
+ ranges = 0x 0xf 0xfe00 0x100;
+ reg = 0xf 0xfe00 0 0x1000;
+ spi@11 {
+ flash@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = spansion,s25sl12801;
+ reg = 0;
+ spi-max-frequency = 4000; /* input clock
*/
+ partition@u-boot {
+ label = SPI U-Boot;
+ reg = 0x 0x0010;
+ read-only;
+ };
+ partition@kernel {
+ label = SPI Kernel;
+ reg = 0x0010 0x0050;
+ read-only;
+ };
+ partition@dtb {
+ label = SPI DTB;
+ reg = 0x0060 0x0010;
+ read-only;
+ };
+ partition@fs {
+ label = SPI File System;
+ reg = 0x0070 0x0090;
+ };
These are not valid unit addresses -- and the kernel/dtb should not be
read-only.
Do you really want to dedicate a whole mebibyte to the dtb, given that
the flash is only 16 MiB total?
Actually, let's please just stop putting partitions in the dts. Either
use mtdparts on the command line, or have U-Boot fill in the partition
info (there is code in U-Boot to do this based on the mtdparts env
variable).
[Shengzhou] okay, will use mtdparts instead of this way.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/5] powerpc/85xx/dts: add third elo3 dma component
-Original Message- From: Hongbo Zhang [mailto:hongbo.zh...@freescale.com] Sent: Thursday, December 12, 2013 5:57 PM To: Liu Shengzhou-B36685; linuxppc-dev@lists.ozlabs.org; Wood Scott- B07421 Subject: Re: [PATCH 1/5] powerpc/85xx/dts: add third elo3 dma component Shengzhou, I canceled my patch http://patchwork.ozlabs.org/patch/295157/ because the original wrong elo3-dma-2.dtsi hadn't been merged. But please pay attention to comments from Scott about my changes of adding 208 for some interrupts, and take some actions if needed, or further discussions. Below comments form Scott: The FSL MPIC binding should be updated to point out how this works. Technically it's not a change to the binding itself, since it's defined in terms of register offset, but the explanatory text says So interrupt 0 is at offset 0x0, interrupt 1 is at offset 0x20, and so on. which is not accurate for these new high interrupt numbers. Hongbo, Could you update FSL MPIC binding as Scott pointed out? thanks, Shengzhou ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
