Re: [RESEND PATCH v7 00/22] MBus DT binding: The return of PCIe
Hi Grant, Arnd, Jason: On Mon, Jul 15, 2013 at 11:57:29AM -0300, Ezequiel Garcia wrote: Here's the new MBus DT binding, implementing the changes proposed by Thomas when we discussed the previous patchset: http://www.spinics.net/lists/arm-kernel/msg257170.html As far as I know, this round fixes *all* the concerns raised in the past and therefore I'd like to get Acked-by's from all the parties involved on the respective patches, and particularly for the DT binding. If there's anything left to review, we'll be glad to fix it quickly, so don't hesitate in providing your feedback! Can you comment on this DT binding? Notice this is the outcome of a lengthy discussion and has been already agreed by Arnd and Jason Gunthorpe. If it looks OK, I'd like to have formal Acked-by's so Jason Cooper can merge it. On the other side, given we've decided to mark some bindings as 'unstable' or 'staging' maybe Jason can merge it so it can be in linux-next. This way developers can actually start using this, and complaining if there's anything to complain. If we leave it as a patchset floating in mailing-lists it's hardly going to get tested. Does this approach make sense? Thanks a lot! -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RESEND PATCH v7 00/22] MBus DT binding: The return of PCIe
Andrew, On Sat, Jul 20, 2013 at 07:38:47PM +0200, Andrew Lunn wrote: On Sat, Jul 20, 2013 at 06:58:55PM +0200, Andrew Lunn wrote: On Mon, Jul 15, 2013 at 11:57:29AM -0300, Ezequiel Garcia wrote: Here's the new MBus DT binding, implementing the changes proposed by Thomas when we discussed the previous patchset: http://www.spinics.net/lists/arm-kernel/msg257170.html As far as I know, this round fixes *all* the concerns raised in the past and therefore I'd like to get Acked-by's from all the parties involved on the respective patches, and particularly for the DT binding. If there's anything left to review, we'll be glad to fix it quickly, so don't hesitate in providing your feedback! I'm sure many of you are dying to test this new MBus thing, so to make it easier for those courageous enough, I've pushed a public branch: https://github.com/MISL-EBU-System-SW/mainline-public/tree/marvell-mvebu-mbus-v7 Hi Ezequiel I just tried this in my Kirkwood QNAP. Uncompressing Linux... done, booting the kernel. Booting Linux on physical CPU 0x0 Linux version 3.11.0-rc1-00022-g44e8c39 (l...@londo.lunn.ch) (gcc version 4.3.43 CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977 CPU: VIVT data cache, VIVT instruction cache Machine: Marvell Kirkwood (Flattened Device Tree), model: QNAP TS219 family bootconsole [earlycon0] enabled Memory policy: ECC disabled, Data cache writeback Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 Kernel command line: root=/dev/sda2 console=ttyS0,115200 earlyprintk PID hash table entries: 2048 (order: 1, 8192 bytes) Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 513268K/524288K available (4247K kernel code, 241K rwdata, 1148K rodata) Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) vmalloc : 0xe080 - 0xff00 ( 488 MB) lowmem : 0xc000 - 0xe000 ( 512 MB) modules : 0xbf00 - 0xc000 ( 16 MB) .text : 0xc0008000 - 0xc054d050 (5397 kB) .init : 0xc054e000 - 0xc0576520 ( 162 kB) .data : 0xc0578000 - 0xc05b4420 ( 242 kB) .bss : 0xc05b4420 - 0xc064e104 ( 616 kB) SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Preemptible hierarchical RCU implementation. NR_IRQS:114 sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 21474ms Console: colour dummy device 80x30 Calibrating delay loop... 1587.60 BogoMIPS (lpj=7938048) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok Setting up static identity map for 0xc040e888 - 0xc040e8c4 pinctrl core: initialized pinctrl subsystem regulator-dummy: no parameters NET: Registered protocol family 16 DMA: preallocated 256 KiB pool for atomic coherent allocations Kirkwood: MV88F6282-Rev-A0, TCLK=2. Feroceon L2: Enabling L2 Feroceon L2: Cache support initialised. bio: create slab bio-0 at 0 mvebu-pcie pcie-controller.1: PCIe0.0: cannot get tgt/attr for mem window mvebu-pcie pcie-controller.1: PCIe1.0: cannot get tgt/attr for mem window Hi Ezequiel I just put some debug into mvebu_get_tgt_attr(): slot 0, PCI_SLOT(devfn) 1 type 512, rtype 512 slot 0, PCI_SLOT(devfn) 1 type 512, rtype 512 slot 0, PCI_SLOT(devfn) 1 type 512, rtype 512 slot 0, PCI_SLOT(devfn) 1 type 512, rtype 256 mvebu-pcie pcie-controller.1: PCIe0.0: cannot get tgt/attr for mem window -2 slot 0, PCI_SLOT(devfn) 2 type 512, rtype 512 slot 0, PCI_SLOT(devfn) 2 type 512, rtype 512 slot 0, PCI_SLOT(devfn) 2 type 512, rtype 512 slot 0, PCI_SLOT(devfn) 2 type 512, rtype 256 Any ideas? Thanks a lot for testing this! I'll take a look and let you know... -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: Kirkwood: Fix the internal register ranges translation
Hi Gerlando,
On Wed, Jul 17, 2013 at 08:35:38AM +0200, Gerlando Falauto wrote:
On 07/16/2013 02:56 PM, Ezequiel Garcia wrote:
[...]
Also, speaking of device bus this nand node should be behind a devicebus
node.
ranges = MBUS_ID(0xf0, 0x01) 0 0 0xf100 0x10 /*
internal-regs */
MBUS_ID(0x01, 0x2f) 0 0 0xf400 0x400;
devbus {
status = okay;
ranges = 0 MBUS_ID(0x01, 0x2f) 0 0x400;
/* nand */
nand {
compatible = marvell,orion-nand;
reg = 0 0x400;
};
};
(notice this will allow you to relocate the base address of the NAND windows
easily if it conflicts with your PCIe needs).
I am MAYBE slowly starting to understand this whole mbus rework.
Just one remark though: don't you think it would make sense to add
something like:
#define MBUS_ID_INTERNAL_REGS MBUS_ID(0xf0, 0x01)
#define MBUS_ID_NAND MBUS_ID(0x01, 0x2f)
Yeah, maybe it would make sense. This has been discussed in the past
and others were against, so that's the reason it's not included in
the series I submitted.
But feel free to send a patch proposing it once the MBus is merged!
Thanks,
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: Kirkwood: Fix the internal register ranges translation
Gerlando,
On Tue, Jul 16, 2013 at 08:51:37PM +0200, Gerlando Falauto wrote:
[...]
Also, speaking of device bus this nand node should be behind a devicebus
node.
ranges = MBUS_ID(0xf0, 0x01) 0 0 0xf100 0x10 /*
internal-regs */
MBUS_ID(0x01, 0x2f) 0 0 0xf400 0x400;
devbus {
status = okay;
ranges = 0 MBUS_ID(0x01, 0x2f) 0 0x400;
/* nand */
nand {
compatible = marvell,orion-nand;
reg = 0 0x400;
};
};
I believe that makes a lot more sense this way... I guess this feature
(device bus) requires your latest set of patches, right? (either v7 as
you posted yesterday or your tree at
git://github.com/MISL-EBU-System-SW/mainline-public.git/marvell-mvebu-mbus-v7)
No, not really. The device-bus driver is already merged, so we only need
to use it, and maybe extend it a bit to support kirkwood (in case it's
needed). You can see in:
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
for an example.
I would prefer that to be done *after* the MBus is accepted...
but that's just a personal preference.
(notice this will allow you to relocate the base address of the NAND windows
easily if it conflicts with your PCIe needs).
I sort of had the impression I could do already do that somehow, though
I am not quite sure anymore...
Well, you can do it by patching and re-building the kernel as the
MBus windows are created from C-files.
With the MBus DT binding, all you need is to change the DT.
avoid a later incosistency between the unit-address and the first
reg address:
#address-cells = 1;
#size-cells = 1;
@@ -171,7 +172,7 @@
nand@300 {
^^^
Oh, this should be fixed. I just missed it, and nobody noticed either.
So, in the end, you think it's OK to have a set of nodes with relative
addresses (gpio@10140, serial@12000 etc...) and some with absolute
addresses (nand@0xf400, where the ranges property does a 0-offset
translation)?
Even though I understand this is just some transitional state, and it
will all be fixed like your example above, once we get the rest of the
rework merged (mbus/devbus).
Mmm.. I see your point. In the end, it's just as you say, the current state
is only transitional. There's no way to have a proper DT without the MBus DT
binding.
The reason for this mess is that the current layout mixes the actual
address space. Feel free to take a look at the latest MBus series and
try to add MBus DT binding for Kirkwood.
If you do, don't hesitate in asking as many questions as you need and/or
posting RFCs for us to look at.
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 00/10] Orion Watchdog fixes
Hi Thomas, Andrew: Thanks for looking at this! On Tue, Jul 16, 2013 at 09:31:01AM +0200, Andrew Lunn wrote: On Tue, Jul 16, 2013 at 09:20:59AM +0200, Thomas Petazzoni wrote: On Tue, 16 Jul 2013 08:59:52 +0200, Andrew Lunn wrote: Maybe i'm missing something here. You are making use of orion_timer_ctrl_clrset() from time-orion.c. How will this work on 370/XP which has a different clocksource driver? I *think* the idea is that the Armada 370/XP driver will expose the same function, so from the point of view of the watchdog driver, it will just work. Indeed that was one of the ideas. As Thomas said, this was just preparation work. That was what i was thinking would happen. And then i started to wonder how well the kernel linker deals with multiple definitions of the same symbol. Dove and 370/XP can end up in the same kernel. So we need to have both orion-timer and the 370/XP timer in the same kernel, so we end up with the same symbol in the kernel twice... Yeah, well... I wasn't sure about using the same name, so another approach would be adding a new compatible to the driver and then make it use the appropriate function in the 370/XP clocksource driver (with a different name). And, yet another approach, is what Sebastian just said, although I'm not sure I understood it :). In any case, we have already several solutions, which is why I'm not too worried about this particular issue. On the other side, I'm much interested in knowing if you are OK with breaking the watchdog DT compatibility. If you NACK this, then I'll start preparing a different watchdog driver for 370/XP, since I don't want to extend a driver that is a bit dirty. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 00/10] Orion Watchdog fixes
Hi Sebastian, On Tue, Jul 16, 2013 at 09:48:56AM +0200, Sebastian Hesselbarth wrote: In the discussion about orion clocksource Russell was proposing a generic thread-safe write. That puts a single lock around all those writes. Of course, it will also blocked by totally unrelated thread-safe register accesses but should prevent us from having dozens of locks and solves the symbol issue. Thanks for the insight! I'll try to dig this suggestion in the clocksource discussion. Do you have any plans for posting the clocksource soon? This way I can base this series on something that's in Jason's trees... Thanks! -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: Kirkwood: Fix the internal register ranges translation
Hi Gerlando,
On Tue, Jul 16, 2013 at 11:37:30AM +0200, Gerlando Falauto wrote:
apologies in advance for commenting on an already-merged patch.
Sure, no problem.
On 06/18/2013 05:31 PM, Ezequiel Garcia wrote:
Although the internal register window size is 1 MiB, the previous
ranges translation for the internal register space had a size of
0x400. This was done to allow the crypto and nand node to access
the corresponding 'sram' and 'nand' decoding windows.
In order to describe the hardware more accurately, we declare the
real 1 MiB internal register space in the ranges, and add a translation
entry for the nand node to access the 'nand' window.
This commit will make future improvements on the MBus DT binding easier.
Signed-off-by: Ezequiel Garcia
ezequiel.garcia-wi1+55ScJUtKEb57/3fjtnbpr1lh4...@public.gmane.org
---
Tested on Plathome Openblocks A6 board.
arch/arm/boot/dts/kirkwood.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood.dtsi
b/arch/arm/boot/dts/kirkwood.dtsi
index 8a1e3bb..910fabc 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -38,7 +38,8 @@
ocp@f100 {
compatible = simple-bus;
- ranges = 0x 0xf100 0x400
+ ranges = 0x 0xf100 0x010
+ 0xf400 0xf400 0x400
0xf500 0xf500 0x400;
Apart from consistency with the following range (0xf500) used by
the crypto node, is there any reason why you did not do something like
this instead (which Valentin suggested, but I will take the blame for):
I'm not sure the reason is consistency with the crypto node.
There's an MBus window at 0xf400 for NAND, and that is what is described
in the snippet above; and this is a better reason.
That said, technically speaking, you can have any translation scheme you want,
as long as it ends up in 0xf400.
- ranges = 0x 0xf100 0x400
+ ranges = 0x 0xf100 0x010
+ 0x0300 0xf400 0x400
0xf500 0xf500 0x400;
This would keep a consistent addressing within the child device bus, and
Could you explain how this keeps a consistent addressing?
Frankly, I don't understand why you choose 0x300 ... am I missing something?
Also, speaking of device bus this nand node should be behind a devicebus node.
ranges = MBUS_ID(0xf0, 0x01) 0 0 0xf100 0x10 /*
internal-regs */
MBUS_ID(0x01, 0x2f) 0 0 0xf400 0x400;
devbus {
status = okay;
ranges = 0 MBUS_ID(0x01, 0x2f) 0 0x400;
/* nand */
nand {
compatible = marvell,orion-nand;
reg = 0 0x400;
};
};
(notice this will allow you to relocate the base address of the NAND windows
easily if it conflicts with your PCIe needs).
avoid a later incosistency between the unit-address and the first
reg address:
#address-cells = 1;
#size-cells = 1;
@@ -171,7 +172,7 @@
nand@300 {
^^^
Oh, this should be fixed. I just missed it, and nobody noticed either.
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 00/10] Orion Watchdog fixes
On Tue, Jul 16, 2013 at 09:44:22AM -0400, Jason Cooper wrote: On Tue, Jul 16, 2013 at 09:14:33AM -0300, Ezequiel Garcia wrote: On the other side, I'm much interested in knowing if you are OK with breaking the watchdog DT compatibility. If you NACK this, then I'll start preparing a different watchdog driver for 370/XP, since I don't want to extend a driver that is a bit dirty. Apparently there is some agreement that the bindings are still in flux and that they need to be for a bit longer in order to hammer out problems such as this. Arnd and Olof both mentioned that something (a doc, and email?) is forthcoming about marking some bindings as stable. Whatever form that takes, this one wouldn't get the stable marking yet. ;-) Yup, that's my understanding as well. But on the other side, I don't want to break possible users out there. So, just to check, you say it's early enough to safely do such change? In that case, I'll extend this patchset to include Armada 370/XP support and post it as soon as Sebastian's clocksource stuff gets in. Oh, and one more nit. The work 'fix' triggers a whole bunch of get on this right away, does it need to go to stable? Has anyone confirmed it? Which commit caused the regression? etc. Although I hate the word, I think 'refactoring' is much more appropriate description for this series. Oh, good observation. I wrote the cover letter at 8 PM, after ten long hours (*) of hacking and smashing this into something easy to review, and that's the best title I could come up with. I'll change it on v2. Thanks, (*) yes, I have another pair of eyes, in case these wear out. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 05/10] watchdog: orion: Add a memory resource for RSTOUT register
Andrew, On Tue, Jul 16, 2013 at 04:04:15PM +0200, Andrew Lunn wrote: On Mon, Jul 15, 2013 at 08:32:38PM -0300, Ezequiel Garcia wrote: Instead of accessing the RSTOUT register directly, this commit adds a platform memory resource to map this register into the driver. Have you looked at: arch/arm/mach-mvebu/system-controller.c Mmm... I saw the use of the RSTOUT register in kirkwood_restart() but wasn't sure who should be the real 'owner' of this register. It is also using this register. Are we going to have a similar problem as the TIMER_CTRL register, which you refactered in an earlier patch? Probably. marvell,orion-system-controller is not actually used yet, but once kirkwood moves into mach-mvebu, it will start using it. I guess so. We should take that into account *now*. Let me think about it and see if I can have something sane for v2. Thanks! -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RESEND PATCH v7 03/22] ARM: kirkwood: Move to ID based MBus window creation
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.
This will allow to deprecate the name based API, once every
user is removed.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/mach-kirkwood/common.c | 18 ++
arch/arm/mach-kirkwood/pcie.c | 40
2 files changed, 38 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-kirkwood/common.c
index e9238b5..165e751 100644
--- a/arch/arm/mach-kirkwood/common.c
+++ b/arch/arm/mach-kirkwood/common.c
@@ -37,6 +37,12 @@
#include linux/platform_data/dma-mv_xor.h
#include common.h
+/* These can go away once Kirkwood uses the mvebu-mbus DT binding */
+#define KIRKWOOD_MBUS_NAND_TARGET 0x01
+#define KIRKWOOD_MBUS_NAND_ATTR 0x2f
+#define KIRKWOOD_MBUS_SRAM_TARGET 0x03
+#define KIRKWOOD_MBUS_SRAM_ATTR 0x01
+
/*
* I/O Address Mapping
/
@@ -672,10 +678,14 @@ char * __init kirkwood_id(void)
void __init kirkwood_setup_wins(void)
{
- mvebu_mbus_add_window(nand, KIRKWOOD_NAND_MEM_PHYS_BASE,
- KIRKWOOD_NAND_MEM_SIZE);
- mvebu_mbus_add_window(sram, KIRKWOOD_SRAM_PHYS_BASE,
- KIRKWOOD_SRAM_SIZE);
+ mvebu_mbus_add_window_by_id(KIRKWOOD_MBUS_NAND_TARGET,
+ KIRKWOOD_MBUS_NAND_ATTR,
+ KIRKWOOD_NAND_MEM_PHYS_BASE,
+ KIRKWOOD_NAND_MEM_SIZE);
+ mvebu_mbus_add_window_by_id(KIRKWOOD_MBUS_SRAM_TARGET,
+ KIRKWOOD_MBUS_SRAM_ATTR,
+ KIRKWOOD_SRAM_PHYS_BASE,
+ KIRKWOOD_SRAM_SIZE);
}
void __init kirkwood_l2_init(void)
diff --git a/arch/arm/mach-kirkwood/pcie.c b/arch/arm/mach-kirkwood/pcie.c
index ddcb09f..12d86f3 100644
--- a/arch/arm/mach-kirkwood/pcie.c
+++ b/arch/arm/mach-kirkwood/pcie.c
@@ -20,6 +20,16 @@
#include mach/bridge-regs.h
#include common.h
+/* These can go away once Kirkwood uses the mvebu-mbus DT binding */
+#define KIRKWOOD_MBUS_PCIE0_MEM_TARGET0x4
+#define KIRKWOOD_MBUS_PCIE0_MEM_ATTR 0xe8
+#define KIRKWOOD_MBUS_PCIE0_IO_TARGET 0x4
+#define KIRKWOOD_MBUS_PCIE0_IO_ATTR 0xe0
+#define KIRKWOOD_MBUS_PCIE1_MEM_TARGET0x4
+#define KIRKWOOD_MBUS_PCIE1_MEM_ATTR 0xd8
+#define KIRKWOOD_MBUS_PCIE1_IO_TARGET 0x4
+#define KIRKWOOD_MBUS_PCIE1_IO_ATTR 0xd0
+
static void kirkwood_enable_pcie_clk(const char *port)
{
struct clk *clk;
@@ -254,26 +264,24 @@ static void __init add_pcie_port(int index, void __iomem
*base)
void __init kirkwood_pcie_init(unsigned int portmask)
{
- mvebu_mbus_add_window_remap_flags(pcie0.0,
+ mvebu_mbus_add_window_remap_by_id(KIRKWOOD_MBUS_PCIE0_IO_TARGET,
+ KIRKWOOD_MBUS_PCIE0_IO_ATTR,
KIRKWOOD_PCIE_IO_PHYS_BASE,
KIRKWOOD_PCIE_IO_SIZE,
- KIRKWOOD_PCIE_IO_BUS_BASE,
- MVEBU_MBUS_PCI_IO);
- mvebu_mbus_add_window_remap_flags(pcie0.0,
- KIRKWOOD_PCIE_MEM_PHYS_BASE,
- KIRKWOOD_PCIE_MEM_SIZE,
- MVEBU_MBUS_NO_REMAP,
- MVEBU_MBUS_PCI_MEM);
- mvebu_mbus_add_window_remap_flags(pcie1.0,
+ KIRKWOOD_PCIE_IO_BUS_BASE);
+ mvebu_mbus_add_window_by_id(KIRKWOOD_MBUS_PCIE0_MEM_TARGET,
+ KIRKWOOD_MBUS_PCIE0_MEM_ATTR,
+ KIRKWOOD_PCIE_MEM_PHYS_BASE,
+ KIRKWOOD_PCIE_MEM_SIZE);
+ mvebu_mbus_add_window_remap_by_id(KIRKWOOD_MBUS_PCIE1_IO_TARGET,
+ KIRKWOOD_MBUS_PCIE1_IO_ATTR,
KIRKWOOD_PCIE1_IO_PHYS_BASE,
KIRKWOOD_PCIE1_IO_SIZE,
- KIRKWOOD_PCIE1_IO_BUS_BASE,
- MVEBU_MBUS_PCI_IO);
- mvebu_mbus_add_window_remap_flags(pcie1.0,
- KIRKWOOD_PCIE1_MEM_PHYS_BASE,
- KIRKWOOD_PCIE1_MEM_SIZE,
- MVEBU_MBUS_NO_REMAP,
- MVEBU_MBUS_PCI_MEM);
+ KIRKWOOD_PCIE1_IO_BUS_BASE);
+
[RESEND PATCH v7 00/22] MBus DT binding: The return of PCIe
) 0x4 0
0x2000 /* Port 0.0 registers */
0x8200 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0
0x2000 /* Port 2.0 registers */
0x8200 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0
0x2000 /* Port 0.1 registers */
0x8200 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0
0x2000 /* Port 0.2 registers */
0x8200 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0
0x2000 /* Port 0.3 registers */
0x8200 0x1 0 MBUS_ID(0x04, 0xe8) 0 1 0 /*
Port 0.0 MEM */
0x8100 0x1 0 MBUS_ID(0x04, 0xe0) 0 1 0 /*
Port 0.0 IO */
0x8200 0x2 0 MBUS_ID(0x08, 0xe8) 0 1 0 /*
Port 1.0 MEM */
0x8100 0x2 0 MBUS_ID(0x08, 0xe0) 0 1 0 /*
Port 1.0 IO */;
pcie@1,0 {
device_type = pci;
assigned-addresses = 0x82000800 0 0x4 0 0x2000;
reg = 0x0800 0 0 0 0;
#address-cells = 3;
#size-cells = 2;
#interrupt-cells = 1;
ranges = 0x8200 0 0 0x8200 0x1 0 1 0
0x8100 0 0 0x8100 0x1 0 1 0;
interrupt-map-mask = 0 0 0 0;
interrupt-map = 0 0 0 0 mpic 58;
marvell,pcie-port = 0;
marvell,pcie-lane = 0;
clocks = gateclk 5;
status = disabled;
};
pcie@2,0 {
device_type = pci;
assigned-addresses = 0x82002800 0 0x8 0 0x2000;
reg = 0x1000 0 0 0 0;
#address-cells = 3;
#size-cells = 2;
#interrupt-cells = 1;
ranges = 0x8200 0 0 0x8200 0x2 0 1 0
0x8100 0 0 0x8100 0x2 0 1 0;
interrupt-map-mask = 0 0 0 0;
interrupt-map = 0 0 0 0 mpic 62;
marvell,pcie-port = 1;
marvell,pcie-lane = 0;
clocks = gateclk 9;
status = disabled;
};
};
internal-regs {
compatible = simple-bus;
#address-cells = 1;
#size-cells = 1;
ranges = 0 MBUS_ID(0xf0, 0x01) 0 0x10;
mbusc: mbus-controller@2 {
reg = 0x2 0x100, 0x20180 0x20;
};
interrupt-controller@2 {
reg = 0x20a00 0x2d0, 0x21070 0x58;
};
};
};
Ezequiel Garcia (12):
memory: mvebu-devbus: Remove address decoding window workaround
bus: mvebu-mbus: Factor out initialization details
bus: mvebu-mbus: Introduce device tree binding
bus: mvebu-mbus: Add static window allocation to the DT binding
bus: mvebu-mbus: Add new API for the PCIe memory and IO aperture
ARM: mvebu: Remove the harcoded BootROM window allocation
ARM: mvebu: Initialize MBus using the DT binding
ARM: mvebu: Use the preprocessor on Armada 370/XP device tree files
ARM: mvebu: Add MBus to Armada 370/XP device tree
ARM: mvebu: Add BootROM to Armada 370/XP device tree
ARM: mvebu: Relocate Armada 370/XP DeviceBus device tree nodes
ARM: mvebu: Relocate Armada 370/XP PCIe device tree nodes
Thomas Petazzoni (10):
bus: mvebu-mbus: Add new API for window creation
ARM: kirkwood: Move to ID based MBus window creation
ARM: mv78xx0: Move to ID based window creation
ARM: orion5x: Move to ID based window creation
ARM: dove: Move to ID based window creation
PCI: mvebu: Adapt to the new device tree layout
bus: mvebu-mbus: Remove the no longer used name-based API
bus: mvebu-mbus: Remove name - target, attribute mapping tables
bus: mvebu-mbus: Update main description
bus: mvebu-mbus: Factorize Armada 370/XP data structures
.../devicetree/bindings/bus/mvebu-mbus.txt | 267 +
.../devicetree/bindings/pci/mvebu-pci.txt | 145 +--
arch/arm/boot/dts/armada-370-db.dts| 5 +-
arch/arm/boot/dts/armada-370-mirabox.dts | 37 +-
arch/arm/boot/dts/armada-370-rd.dts| 5 +-
arch/arm/boot/dts/armada-370-xp.dtsi | 111 +++---
arch/arm/boot/dts/armada-370.dtsi | 112 +++---
arch/arm/boot/dts/armada-xp-db.dts | 131 +++
arch/arm/boot/dts/armada-xp-gp.dts | 107 +++--
arch/arm/boot/dts/armada-xp-mv78230.dtsi | 222 ++-
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 263 +++--
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 411 ++-
arch/arm
[RESEND PATCH v7 04/22] ARM: mv78xx0: Move to ID based window creation
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.
This will allow to deprecate the name based API, once every
user is removed.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/mach-mv78xx0/pcie.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-mv78xx0/pcie.c b/arch/arm/mach-mv78xx0/pcie.c
index dc26a65..397afde 100644
--- a/arch/arm/mach-mv78xx0/pcie.c
+++ b/arch/arm/mach-mv78xx0/pcie.c
@@ -18,6 +18,11 @@
#include mach/mv78xx0.h
#include common.h
+#define MV78XX0_MBUS_PCIE_MEM_TARGET(port,lane) ((port) ? 8 : 4)
+#define MV78XX0_MBUS_PCIE_MEM_ATTR(port,lane) (0xf8 ~(0x10 (lane)))
+#define MV78XX0_MBUS_PCIE_IO_TARGET(port,lane) ((port) ? 8 : 4)
+#define MV78XX0_MBUS_PCIE_IO_ATTR(port,lane)(0xf0 ~(0x10 (lane)))
+
struct pcie_port {
u8 maj;
u8 min;
@@ -71,7 +76,6 @@ static void __init mv78xx0_pcie_preinit(void)
start = MV78XX0_PCIE_MEM_PHYS_BASE;
for (i = 0; i num_pcie_ports; i++) {
struct pcie_port *pp = pcie_port + i;
- char winname[MVEBU_MBUS_MAX_WINNAME_SZ];
snprintf(pp-mem_space_name, sizeof(pp-mem_space_name),
PCIe %d.%d MEM, pp-maj, pp-min);
@@ -85,17 +89,12 @@ static void __init mv78xx0_pcie_preinit(void)
if (request_resource(iomem_resource, pp-res))
panic(can't allocate PCIe MEM sub-space);
- snprintf(winname, sizeof(winname), pcie%d.%d,
-pp-maj, pp-min);
-
- mvebu_mbus_add_window_remap_flags(winname,
- pp-res.start,
- resource_size(pp-res),
- MVEBU_MBUS_NO_REMAP,
- MVEBU_MBUS_PCI_MEM);
- mvebu_mbus_add_window_remap_flags(winname,
- i * SZ_64K, SZ_64K,
- 0, MVEBU_MBUS_PCI_IO);
+
mvebu_mbus_add_window_by_id(MV78XX0_MBUS_PCIE_MEM_TARGET(pp-maj, pp-min),
+ MV78XX0_MBUS_PCIE_MEM_ATTR(pp-maj,
pp-min),
+ pp-res.start,
resource_size(pp-res));
+
mvebu_mbus_add_window_remap_by_id(MV78XX0_MBUS_PCIE_IO_TARGET(pp-maj, pp-min),
+
MV78XX0_MBUS_PCIE_IO_ATTR(pp-maj, pp-min),
+ i * SZ_64K, SZ_64K, 0);
}
}
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RESEND PATCH v7 01/22] memory: mvebu-devbus: Remove address decoding window workaround
Now that mbus device tree binding has been introduced, remove the address
decoding window management from this driver.
A suitable 'ranges' entry should be added to the devbus-compatible node in
the device tree, as described by the mbus binding documentation.
Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/memory/mvebu-devbus.c | 64 ++-
1 file changed, 2 insertions(+), 62 deletions(-)
diff --git a/drivers/memory/mvebu-devbus.c b/drivers/memory/mvebu-devbus.c
index 978e8e3..94c9248 100644
--- a/drivers/memory/mvebu-devbus.c
+++ b/drivers/memory/mvebu-devbus.c
@@ -208,16 +208,11 @@ static int mvebu_devbus_probe(struct platform_device
*pdev)
{
struct device *dev = pdev-dev;
struct device_node *node = pdev-dev.of_node;
- struct device_node *parent;
struct devbus *devbus;
struct resource *res;
struct clk *clk;
unsigned long rate;
- const __be32 *ranges;
- int err, cs;
- int addr_cells, p_addr_cells, size_cells;
- int ranges_len, tuple_len;
- u32 base, size;
+ int err;
devbus = devm_kzalloc(pdev-dev, sizeof(struct devbus), GFP_KERNEL);
if (!devbus)
@@ -248,68 +243,13 @@ static int mvebu_devbus_probe(struct platform_device
*pdev)
return err;
/*
-* Allocate an address window for this device.
-* If the device probing fails, then we won't be able to
-* remove the allocated address decoding window.
-*
-* FIXME: This is only a temporary hack! We need to do this here
-* because we still don't have device tree bindings for mbus.
-* Once that support is added, we will declare these address windows
-* statically in the device tree, and remove the window configuration
-* from here.
-*/
-
- /*
-* Get the CS to choose the window string.
-* This is a bit hacky, but it will be removed once the
-* address windows are declared in the device tree.
-*/
- cs = (((unsigned long)devbus-base) % 0x400) / 8;
-
- /*
-* Parse 'ranges' property to obtain a (base,size) window tuple.
-* This will be removed once the address windows
-* are declared in the device tree.
-*/
- parent = of_get_parent(node);
- if (!parent)
- return -EINVAL;
-
- p_addr_cells = of_n_addr_cells(parent);
- of_node_put(parent);
-
- addr_cells = of_n_addr_cells(node);
- size_cells = of_n_size_cells(node);
- tuple_len = (p_addr_cells + addr_cells + size_cells) * sizeof(__be32);
-
- ranges = of_get_property(node, ranges, ranges_len);
- if (ranges == NULL || ranges_len != tuple_len)
- return -EINVAL;
-
- base = of_translate_address(node, ranges + addr_cells);
- if (base == OF_BAD_ADDR)
- return -EINVAL;
- size = of_read_number(ranges + addr_cells + p_addr_cells, size_cells);
-
- /*
-* Create an mbus address windows.
-* FIXME: Remove this, together with the above code, once the
-* address windows are declared in the device tree.
-*/
- err = mvebu_mbus_add_window(devbus_wins[cs], base, size);
- if (err 0)
- return err;
-
- /*
* We need to create a child device explicitly from here to
* guarantee that the child will be probed after the timing
* parameters for the bus are written.
*/
err = of_platform_populate(node, NULL, NULL, dev);
- if (err 0) {
- mvebu_mbus_del_window(base, size);
+ if (err 0)
return err;
- }
return 0;
}
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RESEND PATCH v7 07/22] bus: mvebu-mbus: Factor out initialization details
We introduce a common initialization function mvebu_mbus_common_init()
that will be used by both legacy and device-tree initialization code.
This patch is an intermediate step, which will allow to introduce the
DT binding for this driver in a less intrusive way.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/bus/mvebu-mbus.c | 47 ++-
1 file changed, 30 insertions(+), 17 deletions(-)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 827468a..1b17954 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -847,26 +847,14 @@ static __init int mvebu_mbus_debugfs_init(void)
}
fs_initcall(mvebu_mbus_debugfs_init);
-int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
- size_t mbuswins_size,
- phys_addr_t sdramwins_phys_base,
- size_t sdramwins_size)
+static int __init mvebu_mbus_common_init(struct mvebu_mbus_state *mbus,
+phys_addr_t mbuswins_phys_base,
+size_t mbuswins_size,
+phys_addr_t sdramwins_phys_base,
+size_t sdramwins_size)
{
- struct mvebu_mbus_state *mbus = mbus_state;
- const struct of_device_id *of_id;
int win;
- for (of_id = of_mvebu_mbus_ids; of_id-compatible; of_id++)
- if (!strcmp(of_id-compatible, soc))
- break;
-
- if (!of_id-compatible) {
- pr_err(could not find a matching SoC family\n);
- return -ENODEV;
- }
-
- mbus-soc = of_id-data;
-
mbus-mbuswins_base = ioremap(mbuswins_phys_base, mbuswins_size);
if (!mbus-mbuswins_base)
return -ENOMEM;
@@ -887,3 +875,28 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t
mbuswins_phys_base,
return 0;
}
+
+int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
+ size_t mbuswins_size,
+ phys_addr_t sdramwins_phys_base,
+ size_t sdramwins_size)
+{
+ const struct of_device_id *of_id;
+
+ for (of_id = of_mvebu_mbus_ids; of_id-compatible; of_id++)
+ if (!strcmp(of_id-compatible, soc))
+ break;
+
+ if (!of_id-compatible) {
+ pr_err(could not find a matching SoC family\n);
+ return -ENODEV;
+ }
+
+ mbus_state.soc = of_id-data;
+
+ return mvebu_mbus_common_init(mbus_state,
+ mbuswins_phys_base,
+ mbuswins_size,
+ sdramwins_phys_base,
+ sdramwins_size);
+}
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RESEND PATCH v7 08/22] bus: mvebu-mbus: Introduce device tree binding
This patch adds the most fundamental device-tree initialization.
We only introduce what's required to be able to probe the mvebu-mbus
driver from the DT. Follow-up patches will extend the device tree binding,
allowing to describe static address decoding windows.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/bus/mvebu-mbus.c | 49
include/linux/mbus.h | 1 +
2 files changed, 50 insertions(+)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 1b17954..44a07c4 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -900,3 +900,52 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t
mbuswins_phys_base,
sdramwins_phys_base,
sdramwins_size);
}
+
+#ifdef CONFIG_OF
+int __init mvebu_mbus_dt_init(void)
+{
+ struct resource mbuswins_res, sdramwins_res;
+ struct device_node *np, *controller;
+ const struct of_device_id *of_id;
+ const __be32 *prop;
+ int ret;
+
+ np = of_find_matching_node(NULL, of_mvebu_mbus_ids);
+ if (!np) {
+ pr_err(could not find a matching SoC family\n);
+ return -ENODEV;
+ }
+
+ of_id = of_match_node(of_mvebu_mbus_ids, np);
+ mbus_state.soc = of_id-data;
+
+ prop = of_get_property(np, controller, NULL);
+ if (!prop) {
+ pr_err(required 'controller' property missing\n);
+ return -EINVAL;
+ }
+
+ controller = of_find_node_by_phandle(be32_to_cpup(prop));
+ if (!controller) {
+ pr_err(could not find an 'mbus-controller' node\n);
+ return -ENODEV;
+ }
+
+ if (of_address_to_resource(controller, 0, mbuswins_res)) {
+ pr_err(cannot get MBUS register address\n);
+ return -EINVAL;
+ }
+
+ if (of_address_to_resource(controller, 1, sdramwins_res)) {
+ pr_err(cannot get SDRAM register address\n);
+ return -EINVAL;
+ }
+
+ ret = mvebu_mbus_common_init(mbus_state,
+mbuswins_res.start,
+resource_size(mbuswins_res),
+sdramwins_res.start,
+resource_size(sdramwins_res));
+ return ret;
+}
+#endif
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index 9245b66..eadefd6 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -74,5 +74,6 @@ int mvebu_mbus_del_window(phys_addr_t base, size_t size);
int mvebu_mbus_init(const char *soc, phys_addr_t mbus_phys_base,
size_t mbus_size, phys_addr_t sdram_phys_base,
size_t sdram_size);
+int mvebu_mbus_dt_init(void);
#endif /* __LINUX_MBUS_H */
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RESEND PATCH v7 06/22] ARM: dove: Move to ID based window creation
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.
This will allow to deprecate the name based API, once every
user is removed.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/mach-dove/common.c | 68 ++---
1 file changed, 45 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-dove/common.c b/arch/arm/mach-dove/common.c
index 00247c7..bc22056 100644
--- a/arch/arm/mach-dove/common.c
+++ b/arch/arm/mach-dove/common.c
@@ -27,6 +27,22 @@
#include plat/time.h
#include common.h
+/* These can go away once Dove uses the mvebu-mbus DT binding */
+#define DOVE_MBUS_PCIE0_MEM_TARGET0x4
+#define DOVE_MBUS_PCIE0_MEM_ATTR 0xe8
+#define DOVE_MBUS_PCIE0_IO_TARGET 0x4
+#define DOVE_MBUS_PCIE0_IO_ATTR 0xe0
+#define DOVE_MBUS_PCIE1_MEM_TARGET0x8
+#define DOVE_MBUS_PCIE1_MEM_ATTR 0xe8
+#define DOVE_MBUS_PCIE1_IO_TARGET 0x8
+#define DOVE_MBUS_PCIE1_IO_ATTR 0xe0
+#define DOVE_MBUS_CESA_TARGET 0x3
+#define DOVE_MBUS_CESA_ATTR 0x1
+#define DOVE_MBUS_BOOTROM_TARGET 0x1
+#define DOVE_MBUS_BOOTROM_ATTR0xfd
+#define DOVE_MBUS_SCRATCHPAD_TARGET 0xd
+#define DOVE_MBUS_SCRATCHPAD_ATTR 0x0
+
/*
* I/O Address Mapping
/
@@ -332,34 +348,40 @@ void __init dove_setup_cpu_wins(void)
{
/*
* The PCIe windows will no longer be statically allocated
-* here once Dove is migrated to the pci-mvebu driver.
+* here once Dove is migrated to the pci-mvebu driver. The
+* non-PCIe windows will no longer be created here once Dove
+* fully moves to DT.
*/
- mvebu_mbus_add_window_remap_flags(pcie0.0,
+ mvebu_mbus_add_window_remap_by_id(DOVE_MBUS_PCIE0_IO_TARGET,
+ DOVE_MBUS_PCIE0_IO_ATTR,
DOVE_PCIE0_IO_PHYS_BASE,
DOVE_PCIE0_IO_SIZE,
- DOVE_PCIE0_IO_BUS_BASE,
- MVEBU_MBUS_PCI_IO);
- mvebu_mbus_add_window_remap_flags(pcie1.0,
+ DOVE_PCIE0_IO_BUS_BASE);
+ mvebu_mbus_add_window_remap_by_id(DOVE_MBUS_PCIE1_IO_TARGET,
+ DOVE_MBUS_PCIE1_IO_ATTR,
DOVE_PCIE1_IO_PHYS_BASE,
DOVE_PCIE1_IO_SIZE,
- DOVE_PCIE1_IO_BUS_BASE,
- MVEBU_MBUS_PCI_IO);
- mvebu_mbus_add_window_remap_flags(pcie0.0,
- DOVE_PCIE0_MEM_PHYS_BASE,
- DOVE_PCIE0_MEM_SIZE,
- MVEBU_MBUS_NO_REMAP,
- MVEBU_MBUS_PCI_MEM);
- mvebu_mbus_add_window_remap_flags(pcie1.0,
- DOVE_PCIE1_MEM_PHYS_BASE,
- DOVE_PCIE1_MEM_SIZE,
- MVEBU_MBUS_NO_REMAP,
- MVEBU_MBUS_PCI_MEM);
- mvebu_mbus_add_window(cesa, DOVE_CESA_PHYS_BASE,
- DOVE_CESA_SIZE);
- mvebu_mbus_add_window(bootrom, DOVE_BOOTROM_PHYS_BASE,
- DOVE_BOOTROM_SIZE);
- mvebu_mbus_add_window(scratchpad, DOVE_SCRATCHPAD_PHYS_BASE,
- DOVE_SCRATCHPAD_SIZE);
+ DOVE_PCIE1_IO_BUS_BASE);
+ mvebu_mbus_add_window_by_id(DOVE_MBUS_PCIE0_MEM_TARGET,
+ DOVE_MBUS_PCIE0_MEM_ATTR,
+ DOVE_PCIE0_MEM_PHYS_BASE,
+ DOVE_PCIE0_MEM_SIZE);
+ mvebu_mbus_add_window_by_id(DOVE_MBUS_PCIE1_MEM_TARGET,
+ DOVE_MBUS_PCIE1_MEM_ATTR,
+ DOVE_PCIE1_MEM_PHYS_BASE,
+ DOVE_PCIE1_MEM_SIZE);
+ mvebu_mbus_add_window_by_id(DOVE_MBUS_CESA_TARGET,
+ DOVE_MBUS_CESA_ATTR,
+ DOVE_CESA_PHYS_BASE,
+ DOVE_CESA_SIZE);
+ mvebu_mbus_add_window_by_id(DOVE_MBUS_BOOTROM_TARGET,
+ DOVE_MBUS_BOOTROM_ATTR,
+ DOVE_BOOTROM_PHYS_BASE,
+ DOVE_BOOTROM_SIZE);
+ mvebu_mbus_add_window_by_id(DOVE_MBUS_SCRATCHPAD_TARGET,
+ DOVE_MBUS_SCRATCHPAD_ATTR,
[RESEND PATCH v7 05/22] ARM: orion5x: Move to ID based window creation
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.
This will allow to deprecate the name based API, once every
user is removed.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/mach-orion5x/common.c | 36 ++
arch/arm/mach-orion5x/common.h | 17
arch/arm/mach-orion5x/d2net-setup.c| 6 +++--
arch/arm/mach-orion5x/db88f5281-setup.c| 24 +++--
arch/arm/mach-orion5x/dns323-setup.c | 6 +++--
arch/arm/mach-orion5x/edmini_v2-setup.c| 6 +++--
arch/arm/mach-orion5x/kurobox_pro-setup.c | 12 ++---
arch/arm/mach-orion5x/ls-chl-setup.c | 6 +++--
arch/arm/mach-orion5x/ls_hgl-setup.c | 6 +++--
arch/arm/mach-orion5x/lsmini-setup.c | 6 +++--
arch/arm/mach-orion5x/mss2-setup.c | 6 +++--
arch/arm/mach-orion5x/mv2120-setup.c | 6 +++--
arch/arm/mach-orion5x/net2big-setup.c | 6 +++--
arch/arm/mach-orion5x/pci.c| 9 +++
arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c | 6 +++--
arch/arm/mach-orion5x/rd88f5181l-ge-setup.c| 6 +++--
arch/arm/mach-orion5x/rd88f5182-setup.c| 13 ++
arch/arm/mach-orion5x/terastation_pro2-setup.c | 6 +++--
arch/arm/mach-orion5x/ts209-setup.c| 6 +++--
arch/arm/mach-orion5x/ts409-setup.c| 6 +++--
arch/arm/mach-orion5x/wnr854t-setup.c | 6 +++--
arch/arm/mach-orion5x/wrt350n-v2-setup.c | 6 +++--
22 files changed, 137 insertions(+), 70 deletions(-)
diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
index b41599f..91a5852 100644
--- a/arch/arm/mach-orion5x/common.c
+++ b/arch/arm/mach-orion5x/common.c
@@ -174,8 +174,10 @@ void __init orion5x_xor_init(void)
/
static void __init orion5x_crypto_init(void)
{
- mvebu_mbus_add_window(sram, ORION5X_SRAM_PHYS_BASE,
- ORION5X_SRAM_SIZE);
+ mvebu_mbus_add_window_by_id(ORION_MBUS_SRAM_TARGET,
+ ORION_MBUS_SRAM_ATTR,
+ ORION5X_SRAM_PHYS_BASE,
+ ORION5X_SRAM_SIZE);
orion_crypto_init(ORION5X_CRYPTO_PHYS_BASE, ORION5X_SRAM_PHYS_BASE,
SZ_8K, IRQ_ORION5X_CESA);
}
@@ -222,22 +224,24 @@ void orion5x_setup_wins(void)
* The PCIe windows will no longer be statically allocated
* here once Orion5x is migrated to the pci-mvebu driver.
*/
- mvebu_mbus_add_window_remap_flags(pcie0.0, ORION5X_PCIE_IO_PHYS_BASE,
+ mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
+ ORION_MBUS_PCIE_IO_ATTR,
+ ORION5X_PCIE_IO_PHYS_BASE,
ORION5X_PCIE_IO_SIZE,
- ORION5X_PCIE_IO_BUS_BASE,
- MVEBU_MBUS_PCI_IO);
- mvebu_mbus_add_window_remap_flags(pcie0.0, ORION5X_PCIE_MEM_PHYS_BASE,
- ORION5X_PCIE_MEM_SIZE,
- MVEBU_MBUS_NO_REMAP,
- MVEBU_MBUS_PCI_MEM);
- mvebu_mbus_add_window_remap_flags(pci0.0, ORION5X_PCI_IO_PHYS_BASE,
+ ORION5X_PCIE_IO_BUS_BASE);
+ mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
+ ORION_MBUS_PCIE_MEM_ATTR,
+ ORION5X_PCIE_MEM_PHYS_BASE,
+ ORION5X_PCIE_MEM_SIZE);
+ mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
+ ORION_MBUS_PCI_IO_ATTR,
+ ORION5X_PCI_IO_PHYS_BASE,
ORION5X_PCI_IO_SIZE,
- ORION5X_PCI_IO_BUS_BASE,
- MVEBU_MBUS_PCI_IO);
- mvebu_mbus_add_window_remap_flags(pci0.0, ORION5X_PCI_MEM_PHYS_BASE,
- ORION5X_PCI_MEM_SIZE,
- MVEBU_MBUS_NO_REMAP,
- MVEBU_MBUS_PCI_MEM);
+ ORION5X_PCI_IO_BUS_BASE);
+ mvebu_mbus_add_window_by_id(ORION_MBUS_PCI_MEM_TARGET,
+ ORION_MBUS_PCI_MEM_ATTR,
+ ORION5X_PCI_MEM_PHYS_BASE,
+ ORION5X_PCI_MEM_SIZE);
}
int orion5x_tclk;
diff --git a/arch/arm/mach-orion5x/common.h b/arch/arm/mach-orion5x/common.h
index
[RESEND PATCH v7 09/22] bus: mvebu-mbus: Add static window allocation to the DT binding
This patch adds static window allocation to the device tree binding.
Each first-child of the mbus-compatible node, with a suitable 'ranges'
property, declaring an address translation, will trigger an address
decoding window allocation.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
.../devicetree/bindings/bus/mvebu-mbus.txt | 253 +
drivers/bus/mvebu-mbus.c | 121 +-
2 files changed, 373 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/bus/mvebu-mbus.txt
diff --git a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
new file mode 100644
index 000..cce863f
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
@@ -0,0 +1,253 @@
+
+* Marvell MBus
+
+Required properties:
+
+- compatible: Should be set to one of the following:
+marvell,armada370-mbus
+marvell,armadaxp-mbus
+
+- address-cells: Must be '2'. The first cell for the MBus ID encoding,
+ the second cell for the address offset within the window.
+
+- size-cells:Must be '1'.
+
+- ranges:Must be set up to provide a proper translation for each child.
+See the examples below.
+
+- controller:Contains a single phandle referring to the MBus controller
+ node. This allows to specify the node that contains the
+registers that control the MBus, which is typically contained
+within the internal register window (see below).
+
+* Marvell MBus controller
+
+Required properties:
+
+- compatible: Should be set to marvell,mbus-controller.
+
+- reg: Device's register space.
+ Two entries are expected (see the examples below):
+ the first one controls the devices decoding window and
+ the second one controls the SDRAM decoding window.
+
+Example:
+
+ soc {
+ compatible = marvell,armada370-mbus, simple-bus;
+ #address-cells = 2;
+ #size-cells = 1;
+ controller = mbusc;
+
+ internal-regs {
+ compatible = simple-bus;
+
+ mbusc: mbus-controller@2 {
+ compatible = marvell,mbus-controller;
+ reg = 0x2 0x100, 0x20180 0x20;
+ };
+
+ /* more children ...*/
+ };
+ };
+
+** MBus address decoding window specification
+
+The MBus children address space is comprised of two cells: the first one for
+the window ID and the second one for the offset within the window.
+In order to allow to describe valid and non-valid window entries, the
+following encoding is used:
+
+ 0xSIAA 0x00oo
+
+Where:
+
+ S = 0x0 for a MBus valid window
+ S = 0xf for a non-valid window (see below)
+
+If S = 0x0, then:
+
+ I = 4-bit window target ID
+ AA = windpw attribute
+
+If S = 0xf, then:
+
+ I = don't care
+ AA = 1 for internal register
+
+Following the above encoding, for each ranges entry for a MBus valid window
+(S = 0x0), an address decoding window is allocated. On the other side,
+entries for translation that do not correspond to valid windows (S = 0xf)
+are skipped.
+
+ soc {
+ compatible = marvell,armada370-mbus, simple-bus;
+ #address-cells = 2;
+ #size-cells = 1;
+ controller = mbusc;
+
+ ranges = 0xf001 0 0 0xd000 0x10
+ 0x01e0 0 0 0xfff0 0x10;
+
+ bootrom {
+ compatible = marvell,bootrom;
+ reg = 0x01e0 0 0x10;
+ };
+
+ /* other children */
+ ...
+
+ internal-regs {
+ compatible = simple-bus;
+ ranges = 0 0xf001 0 0x10;
+
+ mbusc: mbus-controller@2 {
+ compatible = marvell,mbus-controller;
+ reg = 0x2 0x100, 0x20180 0x20;
+ };
+
+ /* more children ...*/
+ };
+ };
+
+In the shown example, the translation entry in the 'ranges' property is what
+makes the MBus driver create a static decoding window for the corresponding
+given child device. Note that the binding does not require child nodes to be
+present. Of course, child nodes are needed to probe the devices.
+
+Since each window is identified by its target ID and attribute ID there's
+a special macro that can be use to simplify the translation entries:
+
+#define MBUS_ID(target,attributes) (((target) 24) | ((attributes) 16))
+
+Using this macro, the above example would be:
+
+ soc {
+ compatible = marvell,armada370-mbus, simple-bus
[RESEND PATCH v7 13/22] bus: mvebu-mbus: Remove name - target, attribute mapping tables
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
This tables were used together with the name-based MBus window
creation API. Since that's has been removed, we can also remove
the tables.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
drivers/bus/mvebu-mbus.c | 150 +++
1 file changed, 7 insertions(+), 143 deletions(-)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 9aee344..e13d475 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -97,33 +97,6 @@
#define DOVE_DDR_BASE_CS_OFF(n) ((n) 4)
-struct mvebu_mbus_mapping {
- const char *name;
- u8 target;
- u8 attr;
- u8 attrmask;
-};
-
-/*
- * Masks used for the 'attrmask' field of mvebu_mbus_mapping. They
- * allow to get the real attribute value, discarding the special bits
- * used to select a PCI MEM region or a PCI WA region. This allows the
- * debugfs code to reverse-match the name of a device from its
- * target/attr values.
- *
- * For all devices except PCI, all bits of 'attr' must be
- * considered. For most SoCs, only bit 3 should be ignored (it allows
- * to select between PCI MEM and PCI I/O). On Orion5x however, there
- * is the special bit 5 to select a PCI WA region.
- */
-#define MAPDEF_NOMASK 0xff
-#define MAPDEF_PCIMASK 0xf7
-#define MAPDEF_ORIONPCIMASK 0xd7
-
-/* Macro used to define one mvebu_mbus_mapping entry */
-#define MAPDEF(__n, __t, __a, __m) \
- { .name = __n, .target = __t, .attr = __a, .attrmask = __m }
-
struct mvebu_mbus_state;
struct mvebu_mbus_soc_data {
@@ -133,7 +106,6 @@ struct mvebu_mbus_soc_data {
void (*setup_cpu_target)(struct mvebu_mbus_state *s);
int (*show_cpu_target)(struct mvebu_mbus_state *s,
struct seq_file *seq, void *v);
- const struct mvebu_mbus_mapping *map;
};
struct mvebu_mbus_state {
@@ -430,8 +402,7 @@ static int mvebu_devs_debug_show(struct seq_file *seq, void
*v)
u64 wbase, wremap;
u32 wsize;
u8 wtarget, wattr;
- int enabled, i;
- const char *name;
+ int enabled;
mvebu_mbus_read_window(mbus, win,
enabled, wbase, wsize,
@@ -442,18 +413,9 @@ static int mvebu_devs_debug_show(struct seq_file *seq,
void *v)
continue;
}
-
- for (i = 0; mbus-soc-map[i].name; i++)
- if (mbus-soc-map[i].target == wtarget
- mbus-soc-map[i].attr ==
- (wattr mbus-soc-map[i].attrmask))
- break;
-
- name = mbus-soc-map[i].name ?: unknown;
-
- seq_printf(seq, [%02d] %016llx - %016llx : %s,
+ seq_printf(seq, [%02d] %016llx - %016llx : %04x:%04x,
win, (unsigned long long)wbase,
- (unsigned long long)(wbase + wsize), name);
+ (unsigned long long)(wbase + wsize), wtarget, wattr);
if (win mbus-soc-num_remappable_wins) {
seq_printf(seq, (remap %016llx)\n,
@@ -578,45 +540,12 @@ mvebu_mbus_dove_setup_cpu_target(struct mvebu_mbus_state
*mbus)
mvebu_mbus_dram_info.num_cs = cs;
}
-static const struct mvebu_mbus_mapping armada_370_map[] = {
- MAPDEF(bootrom, 1, 0xe0, MAPDEF_NOMASK),
- MAPDEF(devbus-boot, 1, 0x2f, MAPDEF_NOMASK),
- MAPDEF(devbus-cs0, 1, 0x3e, MAPDEF_NOMASK),
- MAPDEF(devbus-cs1, 1, 0x3d, MAPDEF_NOMASK),
- MAPDEF(devbus-cs2, 1, 0x3b, MAPDEF_NOMASK),
- MAPDEF(devbus-cs3, 1, 0x37, MAPDEF_NOMASK),
- MAPDEF(pcie0.0, 4, 0xe0, MAPDEF_PCIMASK),
- MAPDEF(pcie1.0, 8, 0xe0, MAPDEF_PCIMASK),
- {},
-};
-
static const struct mvebu_mbus_soc_data armada_370_mbus_data = {
.num_wins= 20,
.num_remappable_wins = 8,
.win_cfg_offset = armada_370_xp_mbus_win_offset,
.setup_cpu_target= mvebu_mbus_default_setup_cpu_target,
.show_cpu_target = mvebu_sdram_debug_show_orion,
- .map = armada_370_map,
-};
-
-static const struct mvebu_mbus_mapping armada_xp_map[] = {
- MAPDEF(bootrom, 1, 0x1d, MAPDEF_NOMASK),
- MAPDEF(devbus-boot, 1, 0x2f, MAPDEF_NOMASK),
- MAPDEF(devbus-cs0, 1, 0x3e, MAPDEF_NOMASK),
- MAPDEF(devbus-cs1, 1, 0x3d, MAPDEF_NOMASK),
- MAPDEF(devbus-cs2, 1, 0x3b, MAPDEF_NOMASK),
- MAPDEF(devbus-cs3, 1, 0x37, MAPDEF_NOMASK),
- MAPDEF(pcie0.0, 4, 0xe0, MAPDEF_PCIMASK),
- MAPDEF(pcie0.1, 4, 0xd0, MAPDEF_PCIMASK),
- MAPDEF(pcie0.2, 4, 0xb0, MAPDEF_PCIMASK),
- MAPDEF(pcie0.3, 4, 0x70, MAPDEF_PCIMASK),
- MAPDEF(pcie1.0, 8, 0xe0, MAPDEF_PCIMASK),
- MAPDEF(pcie1.1, 8, 0xd0, MAPDEF_PCIMASK),
-
[RESEND PATCH v7 12/22] bus: mvebu-mbus: Remove the no longer used name-based API
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
Now that every user of the deprecated name-based API has been
converted to using the ID-based API, let's remove the former one.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
drivers/bus/mvebu-mbus.c | 38 --
include/linux/mbus.h | 5 -
2 files changed, 43 deletions(-)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 5f0bfa3..9aee344 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -766,44 +766,6 @@ int mvebu_mbus_add_window_remap_by_id(unsigned int target,
return mvebu_mbus_alloc_window(s, base, size, remap, target, attribute);
}
-int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
- size_t size, phys_addr_t remap,
- unsigned int flags)
-{
- struct mvebu_mbus_state *s = mbus_state;
- u8 target, attr;
- int i;
-
- if (!s-soc-map)
- return -ENODEV;
-
- for (i = 0; s-soc-map[i].name; i++)
- if (!strcmp(s-soc-map[i].name, devname))
- break;
-
- if (!s-soc-map[i].name) {
- pr_err(unknown device '%s'\n, devname);
- return -ENODEV;
- }
-
- target = s-soc-map[i].target;
- attr = s-soc-map[i].attr;
-
- if (flags == MVEBU_MBUS_PCI_MEM)
- attr |= 0x8;
- else if (flags == MVEBU_MBUS_PCI_WA)
- attr |= 0x28;
-
- return mvebu_mbus_add_window_remap_by_id(target, attr, base,
-size, remap);
-}
-
-int mvebu_mbus_add_window(const char *devname, phys_addr_t base, size_t size)
-{
- return mvebu_mbus_add_window_remap_flags(devname, base, size,
-MVEBU_MBUS_NO_REMAP, 0);
-}
-
int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
phys_addr_t base, size_t size)
{
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index 650bc15..345b8c5 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -63,15 +63,10 @@ static inline const struct mbus_dram_target_info
*mv_mbus_dram_info(void)
void mvebu_mbus_get_pcie_mem_aperture(struct resource *res);
void mvebu_mbus_get_pcie_io_aperture(struct resource *res);
-int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
- size_t size, phys_addr_t remap,
- unsigned int flags);
int mvebu_mbus_add_window_remap_by_id(unsigned int target,
unsigned int attribute,
phys_addr_t base, size_t size,
phys_addr_t remap);
-int mvebu_mbus_add_window(const char *devname, phys_addr_t base,
- size_t size);
int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
phys_addr_t base, size_t size);
int mvebu_mbus_del_window(phys_addr_t base, size_t size);
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RESEND PATCH v7 11/22] PCI: mvebu: Adapt to the new device tree layout
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
The new device tree layout encodes the window's target ID and attribute
in the PCIe controller node's ranges property. This allows to parse
such entries to obtain such information and use the recently introduced
MBus API to create the windows, instead of using the current name based
scheme.
Acked-by: Bjorn Helgaas bhelg...@google.com
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
.../devicetree/bindings/pci/mvebu-pci.txt | 145 -
drivers/pci/host/pci-mvebu.c | 113 +++-
2 files changed, 193 insertions(+), 65 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index f8d4058..9556e2f 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -1,6 +1,7 @@
* Marvell EBU PCIe interfaces
Mandatory properties:
+
- compatible: one of the following values:
marvell,armada-370-pcie
marvell,armada-xp-pcie
@@ -10,11 +11,49 @@ Mandatory properties:
- #interrupt-cells, set to 1
- bus-range: PCI bus numbers covered
- device_type, set to pci
-- ranges: ranges for the PCI memory and I/O regions, as well as the
- MMIO registers to control the PCIe interfaces.
+- ranges: ranges describing the MMIO registers to control the PCIe
+ interfaces, and ranges describing the MBus windows needed to access
+ the memory and I/O regions of each PCIe interface.
+
+The ranges describing the MMIO registers have the following layout:
+
+0x8200 0 r MBUS_ID(0xf0, 0x01) r 0 s
+
+where:
+
+ * r is a 32-bits value that gives the offset of the MMIO
+ registers of this PCIe interface, from the base of the internal
+ registers.
+
+ * s is a 32-bits value that give the size of this MMIO
+ registers area. This range entry translates the '0x8200 0 r' PCI
+ address into the 'MBUS_ID(0xf0, 0x01) r' CPU address, which is part
+ of the internal register window (as identified by MBUS_ID(0xf0,
+ 0x01)).
+
+The ranges describing the MBus windows have the following layout:
+
+0x8t00 s 0 MBUS_ID(w, a) 0 1 0
+
+where:
+
+ * t is the type of the MBus window (as defined by the standard PCI DT
+ bindings), 1 for I/O and 2 for memory.
-In addition, the Device Tree node must have sub-nodes describing each
+ * s is the PCI slot that corresponds to this PCIe interface
+
+ * w is the 'target ID' value for the MBus window
+
+ * a the 'attribute' value for the MBus window.
+
+Since the location and size of the different MBus windows is not fixed in
+hardware, and only determined in runtime, those ranges cover the full first
+4 GB of the physical address space, and do not translate into a valid CPU
+address.
+
+In addition, the device tree node must have sub-nodes describing each
PCIe interface, having the following mandatory properties:
+
- reg: used only for interrupt mapping, so only the first four bytes
are used to refer to the correct bus number and device number.
- assigned-addresses: reference to the MMIO registers used to control
@@ -26,7 +65,8 @@ PCIe interface, having the following mandatory properties:
- #address-cells, set to 3
- #size-cells, set to 2
- #interrupt-cells, set to 1
-- ranges, empty property.
+- ranges, translating the MBus windows ranges of the parent node into
+ standard PCI addresses.
- interrupt-map-mask and interrupt-map, standard PCI properties to
define the mapping of the PCIe interface to interrupt numbers.
@@ -47,27 +87,50 @@ pcie-controller {
bus-range = 0x00 0xff;
- ranges = 0x8200 0 0xd004 0xd004 0 0x2000 /* Port 0.0
registers */
- 0x8200 0 0xd0042000 0xd0042000 0 0x2000 /* Port 2.0
registers */
- 0x8200 0 0xd0044000 0xd0044000 0 0x2000 /* Port 0.1
registers */
- 0x8200 0 0xd0048000 0xd0048000 0 0x2000 /* Port 0.2
registers */
- 0x8200 0 0xd004c000 0xd004c000 0 0x2000 /* Port 0.3
registers */
- 0x8200 0 0xd008 0xd008 0 0x2000 /* Port 1.0
registers */
- 0x8200 0 0xd0082000 0xd0082000 0 0x2000 /* Port 3.0
registers */
- 0x8200 0 0xd0084000 0xd0084000 0 0x2000 /* Port 1.1
registers */
- 0x8200 0 0xd0088000 0xd0088000 0 0x2000 /* Port 1.2
registers */
- 0x8200 0 0xd008c000 0xd008c000 0 0x2000 /* Port 1.3
registers */
- 0x8200 0 0xe000 0xe000 0 0x0800 /*
non-prefetchable memory */
- 0x8100 0 0 0xe800 0 0x0010; /*
downstream I/O */
+ ranges =
+ 0x8200 0 0x4 MBUS_ID(0xf0, 0x01) 0x4 0 0x2000
/* Port 0.0 registers */
+ 0x8200 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000
[RESEND PATCH v7 19/22] ARM: mvebu: Add MBus to Armada 370/XP device tree
The Armada 370/XP SoC family has a completely configurable address
space handled by the MBus controller.
This patch introduces the device tree layout of MBus, making the
'soc' node as mbus-compatible.
Since every peripheral/controller is a child of this 'soc' node,
this makes all of them sit behind the mbus, thus describing the
hardware accurately.
A translation entry has been added for the internal-regs mapping.
This can't be done in the common armada-370-xp.dtsi because A370
and AXP have different addressing width.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-db.dts | 2 ++
arch/arm/boot/dts/armada-370-mirabox.dts | 2 ++
arch/arm/boot/dts/armada-370-rd.dts | 2 ++
arch/arm/boot/dts/armada-370-xp.dtsi | 15 ++-
arch/arm/boot/dts/armada-370.dtsi| 4 ++--
arch/arm/boot/dts/armada-xp-db.dts | 4 +---
arch/arm/boot/dts/armada-xp-gp.dts | 4 +---
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 4 +---
arch/arm/boot/dts/armada-xp.dtsi | 2 ++
9 files changed, 23 insertions(+), 16 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index 55b986c..5920b4e 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,6 +30,8 @@
};
soc {
+ ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10;
+
internal-regs {
serial@12000 {
clock-frequency = 2;
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index 37530af..a4202b6 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,6 +25,8 @@
};
soc {
+ ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10;
+
internal-regs {
serial@12000 {
clock-frequency = 2;
diff --git a/arch/arm/boot/dts/armada-370-rd.dts
b/arch/arm/boot/dts/armada-370-rd.dts
index 7aa2171..dd0ba01 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,6 +28,8 @@
};
soc {
+ ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10;
+
internal-regs {
serial@12000 {
clock-frequency = 2;
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 90b1176..62639b4 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -18,6 +18,8 @@
/include/ skeleton64.dtsi
+#define MBUS_ID(target,attributes) (((target) 24) | ((attributes) 16))
+
/ {
model = Marvell Armada 370 and XP SoC;
compatible = marvell,armada-370-xp;
@@ -38,18 +40,21 @@
};
soc {
- #address-cells = 1;
+ #address-cells = 2;
#size-cells = 1;
- compatible = simple-bus;
+ controller = mbusc;
interrupt-parent = mpic;
- ranges = 0 0 0xd000 0x010 /* internal
registers */
- 0xe000 0 0xe000 0x810 /* PCIe */;
internal-regs {
compatible = simple-bus;
#address-cells = 1;
#size-cells = 1;
- ranges;
+ ranges = 0 MBUS_ID(0xf0, 0x01) 0 0x10;
+
+ mbusc: mbus-controller@2 {
+ compatible = marvell,mbus-controller;
+ reg = 0x2 0x100, 0x20180 0x20;
+ };
mpic: interrupt-controller@2 {
compatible = marvell,mpic;
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index 08ec6e3..4b54e51 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -29,8 +29,8 @@
};
soc {
- ranges = 0 0xd000 0x010 /* internal registers
*/
- 0xe000 0xe000 0x810 /* PCIe */;
+ compatible = marvell,armada370-mbus, simple-bus;
+
internal-regs {
system-controller@18200 {
compatible =
marvell,armada-370-xp-system-controller;
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index a9bd766..0d4ce54 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -30,9 +30,7 @@
};
soc {
- ranges = 0 0 0xd000 0x10 /* Internal
registers 1MiB
[RESEND PATCH v7 18/22] ARM: mvebu: Use the preprocessor on Armada 370/XP device tree files
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-db.dts | 2 +-
arch/arm/boot/dts/armada-370-mirabox.dts | 2 +-
arch/arm/boot/dts/armada-370-rd.dts | 2 +-
arch/arm/boot/dts/armada-370.dtsi| 2 +-
arch/arm/boot/dts/armada-xp-db.dts | 2 +-
arch/arm/boot/dts/armada-xp-gp.dts | 2 +-
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 2 +-
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 2 +-
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 2 +-
arch/arm/boot/dts/armada-xp.dtsi | 2 +-
10 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index beee169..55b986c 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -14,7 +14,7 @@
*/
/dts-v1/;
-/include/ armada-370.dtsi
+#include armada-370.dtsi
/ {
model = Marvell Armada 370 Evaluation Board;
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index 45b1077..37530af 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -9,7 +9,7 @@
*/
/dts-v1/;
-/include/ armada-370.dtsi
+#include armada-370.dtsi
/ {
model = Globalscale Mirabox;
diff --git a/arch/arm/boot/dts/armada-370-rd.dts
b/arch/arm/boot/dts/armada-370-rd.dts
index a3a2fed..7aa2171 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -12,7 +12,7 @@
*/
/dts-v1/;
-/include/ armada-370.dtsi
+#include armada-370.dtsi
/ {
model = Marvell Armada 370 Reference Design;
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index fa3dfc6..08ec6e3 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -15,7 +15,7 @@
* common to all Armada SoCs.
*/
-/include/ armada-370-xp.dtsi
+#include armada-370-xp.dtsi
/include/ skeleton.dtsi
/ {
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index e28e68f..a9bd766 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -14,7 +14,7 @@
*/
/dts-v1/;
-/include/ armada-xp-mv78460.dtsi
+#include armada-xp-mv78460.dtsi
/ {
model = Marvell Armada XP Evaluation Board;
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts
b/arch/arm/boot/dts/armada-xp-gp.dts
index c87b2de..54843e5 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -14,7 +14,7 @@
*/
/dts-v1/;
-/include/ armada-xp-mv78460.dtsi
+#include armada-xp-mv78460.dtsi
/ {
model = Marvell Armada XP Development Board DB-MV784MP-GP;
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 2d9335d..985373a 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -13,7 +13,7 @@
* common to all Armada XP SoCs.
*/
-/include/ armada-xp.dtsi
+#include armada-xp.dtsi
/ {
model = Marvell Armada XP MV78260 SoC;
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index c7b1f4d..f8bf25a 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -13,7 +13,7 @@
* common to all Armada XP SoCs.
*/
-/include/ armada-xp.dtsi
+#include armada-xp.dtsi
/ {
model = Marvell Armada XP MV78460 SoC;
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 8f51045..d090264 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -11,7 +11,7 @@
*/
/dts-v1/;
-/include/ armada-xp-mv78260.dtsi
+#include armada-xp-mv78260.dtsi
/ {
model = PlatHome OpenBlocks AX3-4 board;
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 416eb94..8c07bfe 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -16,7 +16,7 @@
* common to all Armada SoCs.
*/
-/include/ armada-370-xp.dtsi
+#include armada-370-xp.dtsi
/ {
model = Marvell Armada XP family SoC;
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RESEND PATCH v7 22/22] ARM: mvebu: Relocate Armada 370/XP PCIe device tree nodes
Now that mbus has been added to the device tree, it's possible to
move the PCIe nodes out of internal registers, placing it directly
below the mbus. This is a more accurate representation of the
hardware.
Moving the PCIe nodes, we now need to introduce an extra cell to
encode the window target ID and attribute. Since this depends on
the PCIe port, we split the ranges translation entries, to correspond
to each MBus window.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-mirabox.dts | 32 +-
arch/arm/boot/dts/armada-370-xp.dtsi | 2 +
arch/arm/boot/dts/armada-370.dtsi| 101 +++---
arch/arm/boot/dts/armada-xp-db.dts | 67 ++--
arch/arm/boot/dts/armada-xp-gp.dts | 42 +--
arch/arm/boot/dts/armada-xp-mv78230.dtsi | 222 ++--
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 261 ---
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 409 ---
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 18 +-
9 files changed, 612 insertions(+), 542 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index 19341d2..2471d9d 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -28,6 +28,22 @@
ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10
MBUS_ID(0x01, 0xe0) 0 0xfff0 0x10;
+ pcie-controller {
+ status = okay;
+
+ /* Internal mini-PCIe connector */
+ pcie@1,0 {
+ /* Port 0, Lane 0 */
+ status = okay;
+ };
+
+ /* Connected on the PCB to a USB 3.0 XHCI controller */
+ pcie@2,0 {
+ /* Port 1, Lane 0 */
+ status = okay;
+ };
+ };
+
internal-regs {
serial@12000 {
clock-frequency = 2;
@@ -123,22 +139,6 @@
reg = 0x25;
};
};
-
- pcie-controller {
- status = okay;
-
- /* Internal mini-PCIe connector */
- pcie@1,0 {
- /* Port 0, Lane 0 */
- status = okay;
- };
-
- /* Connected on the PCB to a USB 3.0 XHCI
controller */
- pcie@2,0 {
- /* Port 1, Lane 0 */
- status = okay;
- };
- };
};
};
};
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 073dd20..e984ce6 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -44,6 +44,8 @@
#size-cells = 1;
controller = mbusc;
interrupt-parent = mpic;
+ pcie-mem-aperture = 0xe000 0x800;
+ pcie-io-aperture = 0xe800 0x10;
devbus-bootcs {
compatible = marvell,mvebu-devbus;
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index bd21d49..648e530 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -36,6 +36,59 @@
reg = MBUS_ID(0x01, 0xe0) 0 0x10;
};
+ pcie-controller {
+ compatible = marvell,armada-370-pcie;
+ status = disabled;
+ device_type = pci;
+
+ #address-cells = 3;
+ #size-cells = 2;
+
+ bus-range = 0x00 0xff;
+
+ ranges =
+ 0x8200 0 0x4 MBUS_ID(0xf0, 0x01)
0x4 0 0x2000
+ 0x8200 0 0x8 MBUS_ID(0xf0, 0x01)
0x8 0 0x2000
+ 0x8200 0x1 0 MBUS_ID(0x04, 0xe8) 0
1 0 /* Port 0.0 MEM */
+ 0x8100 0x1 0 MBUS_ID(0x04, 0xe0) 0
1 0 /* Port 0.0 IO */
+ 0x8200 0x2 0 MBUS_ID(0x08, 0xe8) 0
1 0 /* Port 1.0 MEM */
+ 0x8100 0x2 0 MBUS_ID(0x08, 0xe0) 0
1 0 /* Port 1.0 IO */;
+
+ pcie@1,0 {
+ device_type = pci
[RESEND PATCH v7 15/22] bus: mvebu-mbus: Factorize Armada 370/XP data structures
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
These structures were only different in the mapping tables.
Now that those tables have been removed, it doesn't make any sense
to keep different structures.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
drivers/bus/mvebu-mbus.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index f6e9192..d0a61ce 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -536,15 +536,7 @@ mvebu_mbus_dove_setup_cpu_target(struct mvebu_mbus_state
*mbus)
mvebu_mbus_dram_info.num_cs = cs;
}
-static const struct mvebu_mbus_soc_data armada_370_mbus_data = {
- .num_wins= 20,
- .num_remappable_wins = 8,
- .win_cfg_offset = armada_370_xp_mbus_win_offset,
- .setup_cpu_target= mvebu_mbus_default_setup_cpu_target,
- .show_cpu_target = mvebu_sdram_debug_show_orion,
-};
-
-static const struct mvebu_mbus_soc_data armada_xp_mbus_data = {
+static const struct mvebu_mbus_soc_data armada_370_xp_mbus_data = {
.num_wins= 20,
.num_remappable_wins = 8,
.win_cfg_offset = armada_370_xp_mbus_win_offset,
@@ -604,9 +596,9 @@ static const struct mvebu_mbus_soc_data mv78xx0_mbus_data =
{
*/
static const struct of_device_id of_mvebu_mbus_ids[] = {
{ .compatible = marvell,armada370-mbus,
- .data = armada_370_mbus_data, },
+ .data = armada_370_xp_mbus_data, },
{ .compatible = marvell,armadaxp-mbus,
- .data = armada_xp_mbus_data, },
+ .data = armada_370_xp_mbus_data, },
{ .compatible = marvell,kirkwood-mbus,
.data = kirkwood_mbus_data, },
{ .compatible = marvell,dove-mbus,
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RESEND PATCH v7 20/22] ARM: mvebu: Add BootROM to Armada 370/XP device tree
In order to access the SoC BootROM, we need to declare a mapping
(through a ranges property). The mbus driver will use this property
to allocate a suitable address decoding window.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-db.dts | 3 ++-
arch/arm/boot/dts/armada-370-mirabox.dts | 3 ++-
arch/arm/boot/dts/armada-370-rd.dts | 3 ++-
arch/arm/boot/dts/armada-370.dtsi| 5 +
arch/arm/boot/dts/armada-xp-db.dts | 3 ++-
arch/arm/boot/dts/armada-xp-gp.dts | 3 ++-
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 3 ++-
arch/arm/boot/dts/armada-xp.dtsi | 5 +
8 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index 5920b4e..90ce29d 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,7 +30,8 @@
};
soc {
- ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10;
+ ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10
+ MBUS_ID(0x01, 0xe0) 0 0xfff0 0x10;
internal-regs {
serial@12000 {
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index a4202b6..19341d2 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,7 +25,8 @@
};
soc {
- ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10;
+ ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10
+ MBUS_ID(0x01, 0xe0) 0 0xfff0 0x10;
internal-regs {
serial@12000 {
diff --git a/arch/arm/boot/dts/armada-370-rd.dts
b/arch/arm/boot/dts/armada-370-rd.dts
index dd0ba01..0b3acf3 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,7 +28,8 @@
};
soc {
- ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10;
+ ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10
+ MBUS_ID(0x01, 0xe0) 0 0xfff0 0x10;
internal-regs {
serial@12000 {
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index 4b54e51..bd21d49 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -31,6 +31,11 @@
soc {
compatible = marvell,armada370-mbus, simple-bus;
+ bootrom {
+ compatible = marvell,bootrom;
+ reg = MBUS_ID(0x01, 0xe0) 0 0x10;
+ };
+
internal-regs {
system-controller@18200 {
compatible =
marvell,armada-370-xp-system-controller;
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index 0d4ce54..857f272 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -30,7 +30,8 @@
};
soc {
- ranges = MBUS_ID(0xf0, 0x01) 0 0 0xd000 0x10;
+ ranges = MBUS_ID(0xf0, 0x01) 0 0 0xd000 0x10
+ MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10;
internal-regs {
serial@12000 {
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts
b/arch/arm/boot/dts/armada-xp-gp.dts
index 2fa9209..934dc46 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -39,7 +39,8 @@
};
soc {
- ranges = MBUS_ID(0xf0, 0x01) 0 0 0xd000 0x10;
+ ranges = MBUS_ID(0xf0, 0x01) 0 0 0xd000 0x10
+ MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10;
internal-regs {
serial@12000 {
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index a3e3a12..1700f6f 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -27,7 +27,8 @@
};
soc {
- ranges = MBUS_ID(0xf0, 0x01) 0 0 0xd000 0x10;
+ ranges = MBUS_ID(0xf0, 0x01) 0 0 0xd000 0x10
+ MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10;
internal-regs {
serial@12000 {
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 8033824..7ba99ce 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -29,6 +29,11 @@
soc {
compatible = marvell,armadaxp-mbus, simple-bus;
+ bootrom {
+ compatible = marvell,bootrom
[RESEND PATCH v7 17/22] ARM: mvebu: Initialize MBus using the DT binding
Now that the mbus device tree binding has been introduced, we can
switch over to it.
Also, and since the initialization of the mbus driver is quite
fundamental for the system to work properly, this patch adds a BUG()
in case mbus fails to initialize.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-mvebu/armada-370-xp.c | 34 +-
1 file changed, 1 insertion(+), 33 deletions(-)
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c
b/arch/arm/mach-mvebu/armada-370-xp.c
index 97cbb80..829b573 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -34,44 +34,12 @@ static void __init armada_370_xp_map_io(void)
debug_ll_io_init();
}
-/*
- * This initialization will be replaced by a DT-based
- * initialization once the mvebu-mbus driver gains DT support.
- */
-
-#define ARMADA_370_XP_MBUS_WINS_OFFS 0x2
-#define ARMADA_370_XP_MBUS_WINS_SIZE 0x100
-#define ARMADA_370_XP_SDRAM_WINS_OFFS 0x20180
-#define ARMADA_370_XP_SDRAM_WINS_SIZE 0x20
-
-static void __init armada_370_xp_mbus_init(void)
-{
- char *mbus_soc_name;
- struct device_node *dn;
- const __be32 mbus_wins_offs = cpu_to_be32(ARMADA_370_XP_MBUS_WINS_OFFS);
- const __be32 sdram_wins_offs =
cpu_to_be32(ARMADA_370_XP_SDRAM_WINS_OFFS);
-
- if (of_machine_is_compatible(marvell,armada370))
- mbus_soc_name = marvell,armada370-mbus;
- else
- mbus_soc_name = marvell,armadaxp-mbus;
-
- dn = of_find_node_by_name(NULL, internal-regs);
- BUG_ON(!dn);
-
- mvebu_mbus_init(mbus_soc_name,
- of_translate_address(dn, mbus_wins_offs),
- ARMADA_370_XP_MBUS_WINS_SIZE,
- of_translate_address(dn, sdram_wins_offs),
- ARMADA_370_XP_SDRAM_WINS_SIZE);
-}
-
static void __init armada_370_xp_timer_and_clk_init(void)
{
of_clk_init(NULL);
armada_370_xp_timer_init();
coherency_init();
- armada_370_xp_mbus_init();
+ BUG_ON(mvebu_mbus_dt_init());
#ifdef CONFIG_CACHE_L2X0
l2x0_of_init(0, ~0UL);
#endif
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RESEND PATCH v7 16/22] ARM: mvebu: Remove the harcoded BootROM window allocation
The address decoding window to access the BootROM should not be
allocated programatically, but instead declared in the device tree.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-mvebu/platsmp.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
index 93f2f3a..a952f8d 100644
--- a/arch/arm/mach-mvebu/platsmp.c
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -21,6 +21,7 @@
#include linux/smp.h
#include linux/clk.h
#include linux/of.h
+#include linux/of_address.h
#include linux/mbus.h
#include asm/cacheflush.h
#include asm/smp_plat.h
@@ -29,6 +30,9 @@
#include pmsu.h
#include coherency.h
+#define AXP_BOOTROM_BASE 0xfff0
+#define AXP_BOOTROM_SIZE 0x10
+
void __init set_secondary_cpus_clock(void)
{
int thiscpu;
@@ -115,10 +119,29 @@ static void __init armada_xp_smp_init_cpus(void)
void __init armada_xp_smp_prepare_cpus(unsigned int max_cpus)
{
+ struct device_node *node;
+ struct resource res;
+ int err;
+
set_secondary_cpus_clock();
flush_cache_all();
set_cpu_coherent(cpu_logical_map(smp_processor_id()), 0);
- mvebu_mbus_add_window(bootrom, 0xfff0, SZ_1M);
+
+ /*
+* In order to boot the secondary CPUs we need to ensure
+* the bootROM is mapped at the correct address.
+*/
+ node = of_find_compatible_node(NULL, NULL, marvell,bootrom);
+ if (!node)
+ panic(Cannot find 'marvell,bootrom' compatible node);
+
+ err = of_address_to_resource(node, 0, res);
+ if (err 0)
+ panic(Cannot get 'bootrom' node address);
+
+ if (res.start != AXP_BOOTROM_BASE||
+ resource_size(res) != AXP_BOOTROM_SIZE)
+ panic(The address for the BootROM is incorrect);
}
struct smp_operations armada_xp_smp_ops __initdata = {
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RESEND PATCH v7 21/22] ARM: mvebu: Relocate Armada 370/XP DeviceBus device tree nodes
Now that mbus has been added to the device tree, it's possible to
move the DeviceBus out of internal registers, placing it directly
below the mbus. This is a more accurate representation of the hardware.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-xp.dtsi | 94 +---
arch/arm/boot/dts/armada-xp-db.dts | 59 +++
arch/arm/boot/dts/armada-xp-gp.dts | 60 +++
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 65
4 files changed, 140 insertions(+), 138 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 62639b4..073dd20 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -45,6 +45,56 @@
controller = mbusc;
interrupt-parent = mpic;
+ devbus-bootcs {
+ compatible = marvell,mvebu-devbus;
+ reg = MBUS_ID(0xf0, 0x01) 0x10400 0x8;
+ ranges = 0 MBUS_ID(0x01, 0x2f) 0 0x;
+ #address-cells = 1;
+ #size-cells = 1;
+ clocks = coreclk 0;
+ status = disabled;
+ };
+
+ devbus-cs0 {
+ compatible = marvell,mvebu-devbus;
+ reg = MBUS_ID(0xf0, 0x01) 0x10408 0x8;
+ ranges = 0 MBUS_ID(0x01, 0x3e) 0 0x;
+ #address-cells = 1;
+ #size-cells = 1;
+ clocks = coreclk 0;
+ status = disabled;
+ };
+
+ devbus-cs1 {
+ compatible = marvell,mvebu-devbus;
+ reg = MBUS_ID(0xf0, 0x01) 0x10410 0x8;
+ ranges = 0 MBUS_ID(0x01, 0x3d) 0 0x;
+ #address-cells = 1;
+ #size-cells = 1;
+ clocks = coreclk 0;
+ status = disabled;
+ };
+
+ devbus-cs2 {
+ compatible = marvell,mvebu-devbus;
+ reg = MBUS_ID(0xf0, 0x01) 0x10418 0x8;
+ ranges = 0 MBUS_ID(0x01, 0x3b) 0 0x;
+ #address-cells = 1;
+ #size-cells = 1;
+ clocks = coreclk 0;
+ status = disabled;
+ };
+
+ devbus-cs3 {
+ compatible = marvell,mvebu-devbus;
+ reg = MBUS_ID(0xf0, 0x01) 0x10420 0x8;
+ ranges = 0 MBUS_ID(0x01, 0x37) 0 0x;
+ #address-cells = 1;
+ #size-cells = 1;
+ clocks = coreclk 0;
+ status = disabled;
+ };
+
internal-regs {
compatible = simple-bus;
#address-cells = 1;
@@ -200,50 +250,6 @@
status = disabled;
};
- devbus-bootcs@10400 {
- compatible = marvell,mvebu-devbus;
- reg = 0x10400 0x8;
- #address-cells = 1;
- #size-cells = 1;
- clocks = coreclk 0;
- status = disabled;
- };
-
- devbus-cs0@10408 {
- compatible = marvell,mvebu-devbus;
- reg = 0x10408 0x8;
- #address-cells = 1;
- #size-cells = 1;
- clocks = coreclk 0;
- status = disabled;
- };
-
- devbus-cs1@10410 {
- compatible = marvell,mvebu-devbus;
- reg = 0x10410 0x8;
- #address-cells = 1;
- #size-cells = 1;
- clocks = coreclk 0;
- status = disabled;
- };
-
- devbus-cs2@10418 {
- compatible = marvell,mvebu-devbus;
- reg = 0x10418 0x8;
- #address-cells = 1;
- #size-cells = 1;
- clocks = coreclk 0;
- status = disabled;
- };
-
- devbus-cs3@10420 {
- compatible = marvell,mvebu-devbus;
- reg = 0x10420 0x8
[RESEND PATCH v7 14/22] bus: mvebu-mbus: Update main description
From: Thomas Petazzoni thomas.petazz...@free-electrons.com After replacing the MBus name-based by the new ID-based API let's fix the general description of the driver at the beginning of the file. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com --- drivers/bus/mvebu-mbus.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c index e13d475..f6e9192 100644 --- a/drivers/bus/mvebu-mbus.c +++ b/drivers/bus/mvebu-mbus.c @@ -35,13 +35,9 @@ * * - Provides an API for platform code or device drivers to * dynamically add or remove address decoding windows for the CPU - - * device accesses. This API is mvebu_mbus_add_window(), - * mvebu_mbus_add_window_remap_flags() and - * mvebu_mbus_del_window(). Since the (target, attribute) values - * differ from one SoC family to another, the API uses a 'const char - * *' string to identify devices, and this driver is responsible for - * knowing the mapping between the name of a device and its - * corresponding (target, attribute) in the current SoC family. + * device accesses. This API is mvebu_mbus_add_window_by_id(), + * mvebu_mbus_add_window_remap_by_id() and + * mvebu_mbus_del_window(). * * - Provides a debugfs interface in /sys/kernel/debug/mvebu-mbus/ to * see the list of CPU - SDRAM windows and their configuration -- 1.8.1.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 01/10] clocksource: orion: Add thread-safe API header
Add a header declaration to allow drivers (such as watchdog) to access this exported API. Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com --- include/linux/time-orion.h | 7 +++ 1 file changed, 7 insertions(+) create mode 100644 include/linux/time-orion.h diff --git a/include/linux/time-orion.h b/include/linux/time-orion.h new file mode 100644 index 000..c7e6458 --- /dev/null +++ b/include/linux/time-orion.h @@ -0,0 +1,7 @@ + +#ifndef __TIME_ORION_H +#define __TIME_ORION_H + +void orion_timer_ctrl_clrset(u32 clr, u32 set); + +#endif -- 1.8.1.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 02/10] watchdog: orion: Use thread-safe clocksource API
The TIMER_CTRL register allows to control timer and watchdog counters, so it's a register shared between the clocksource and the watchdog drivers. In order to prevent race-conditions the clocksource driver exposed a thread-safe API. Use the API. Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com --- drivers/watchdog/orion_wdt.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c index da57798..c0597f4 100644 --- a/drivers/watchdog/orion_wdt.c +++ b/drivers/watchdog/orion_wdt.c @@ -25,12 +25,12 @@ #include linux/clk.h #include linux/err.h #include linux/of.h +#include linux/time-orion.h #include mach/bridge-regs.h /* * Watchdog timer block registers. */ -#define TIMER_CTRL 0x #define WDT_EN 0x0010 #define WDT_VAL0x0024 @@ -72,9 +72,7 @@ static int orion_wdt_start(struct watchdog_device *wdt_dev) writel(reg, BRIDGE_CAUSE); /* Enable watchdog timer */ - reg = readl(wdt_reg + TIMER_CTRL); - reg |= WDT_EN; - writel(reg, wdt_reg + TIMER_CTRL); + orion_timer_ctrl_clrset(0, WDT_EN); /* Enable reset on watchdog */ reg = readl(RSTOUTn_MASK); @@ -97,9 +95,7 @@ static int orion_wdt_stop(struct watchdog_device *wdt_dev) writel(reg, RSTOUTn_MASK); /* Disable watchdog timer */ - reg = readl(wdt_reg + TIMER_CTRL); - reg = ~WDT_EN; - writel(reg, wdt_reg + TIMER_CTRL); + orion_timer_ctrl_clrset(WDT_EN, 0); spin_unlock(wdt_lock); return 0; -- 1.8.1.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 04/10] watchdog: orion: Use the proper watchdog register
Until now the watchdog driver was using the timer control register
to access the watchdog counter register. This is not appropriate,
given the timer control register should be controlled by the clocksource
driver alone.
Fix this by passing the correct register address to the driver and making
direct use of it. Note that this breaks the current device-tree binding
compatibility since it changes the meaning of the 'reg' property.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-kirkwood/include/mach/bridge-regs.h | 1 +
arch/arm/mach-orion5x/include/mach/bridge-regs.h | 1 +
arch/arm/plat-orion/common.c | 2 +-
drivers/watchdog/orion_wdt.c | 7 +++
4 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
b/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
index d4cbe5e..c3f361d 100644
--- a/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
+++ b/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
@@ -40,6 +40,7 @@
#define TIMER_VIRT_BASE(BRIDGE_VIRT_BASE + 0x0300)
#define TIMER_PHYS_BASE(BRIDGE_PHYS_BASE + 0x0300)
+#define WDT_PHYS_BASE (BRIDGE_PHYS_BASE + 0x0324)
#define L2_CONFIG_REG (BRIDGE_VIRT_BASE + 0x0128)
#define L2_WRITETHROUGH0x0010
diff --git a/arch/arm/mach-orion5x/include/mach/bridge-regs.h
b/arch/arm/mach-orion5x/include/mach/bridge-regs.h
index 461fd69..aa35de3 100644
--- a/arch/arm/mach-orion5x/include/mach/bridge-regs.h
+++ b/arch/arm/mach-orion5x/include/mach/bridge-regs.h
@@ -36,4 +36,5 @@
#define TIMER_VIRT_BASE(ORION5X_BRIDGE_VIRT_BASE + 0x300)
#define TIMER_PHYS_BASE(ORION5X_BRIDGE_PHYS_BASE + 0x300)
+#define WDT_PHYS_BASE (ORION5X_BRIDGE_PHYS_BASE + 0x324)
#endif
diff --git a/arch/arm/plat-orion/common.c b/arch/arm/plat-orion/common.c
index c019b7a..77fac6c 100644
--- a/arch/arm/plat-orion/common.c
+++ b/arch/arm/plat-orion/common.c
@@ -595,7 +595,7 @@ void __init orion_spi_1_init(unsigned long mapbase)
* Watchdog
/
static struct resource orion_wdt_resource =
- DEFINE_RES_MEM(TIMER_PHYS_BASE, 0x28);
+ DEFINE_RES_MEM(WDT_PHYS_BASE, 0x04);
static struct platform_device orion_wdt_device = {
.name = orion_wdt,
diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
index c0597f4..01bcf53 100644
--- a/drivers/watchdog/orion_wdt.c
+++ b/drivers/watchdog/orion_wdt.c
@@ -32,7 +32,6 @@
* Watchdog timer block registers.
*/
#define WDT_EN 0x0010
-#define WDT_VAL0x0024
#define WDT_MAX_CYCLE_COUNT0x
#define WDT_IN_USE 0
@@ -51,7 +50,7 @@ static int orion_wdt_ping(struct watchdog_device *wdt_dev)
spin_lock(wdt_lock);
/* Reload watchdog duration */
- writel(wdt_tclk * wdt_dev-timeout, wdt_reg + WDT_VAL);
+ writel(wdt_tclk * wdt_dev-timeout, wdt_reg);
spin_unlock(wdt_lock);
return 0;
@@ -64,7 +63,7 @@ static int orion_wdt_start(struct watchdog_device *wdt_dev)
spin_lock(wdt_lock);
/* Set watchdog duration */
- writel(wdt_tclk * wdt_dev-timeout, wdt_reg + WDT_VAL);
+ writel(wdt_tclk * wdt_dev-timeout, wdt_reg);
/* Clear watchdog timer interrupt */
reg = readl(BRIDGE_CAUSE);
@@ -106,7 +105,7 @@ static unsigned int orion_wdt_get_timeleft(struct
watchdog_device *wdt_dev)
unsigned int time_left;
spin_lock(wdt_lock);
- time_left = readl(wdt_reg + WDT_VAL) / wdt_tclk;
+ time_left = readl(wdt_reg) / wdt_tclk;
spin_unlock(wdt_lock);
return time_left;
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 03/10] watchdog: orion: Rename device-tree binding documentation
Name this file to something a bit more judicious.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
Documentation/devicetree/bindings/watchdog/{marvel.txt = orion-wdt.txt} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/watchdog/{marvel.txt =
orion-wdt.txt} (100%)
diff --git a/Documentation/devicetree/bindings/watchdog/marvel.txt
b/Documentation/devicetree/bindings/watchdog/orion-wdt.txt
similarity index 100%
rename from Documentation/devicetree/bindings/watchdog/marvel.txt
rename to Documentation/devicetree/bindings/watchdog/orion-wdt.txt
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 10/10] ARM: kirkwood: Fix the device-tree watchdog's node reg property
The watchdog driver now needs two 'reg' property cells. The first one
is for the register containing the watchdog counter, while the second
one is for the RSTOUT register.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/kirkwood.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index ca296c3..0d74ee9 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -116,7 +116,8 @@
wdt: watchdog-timer@20300 {
compatible = marvell,orion-wdt;
- reg = 0x20300 0x28;
+ reg = 0x20324 0x04
+ 0x20108 0x04;
interrupt-parent = bridge_intc;
interrupts = 3;
clocks = gate_clk 7;
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 09/10] watchdog: orion: Use BIT()
This is a purely cosmetic commit: we replace hardcoded values that representing bits by BIT(), which is slightly more readable. Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com --- drivers/watchdog/orion_wdt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c index 4ed7a74..ae64cec 100644 --- a/drivers/watchdog/orion_wdt.c +++ b/drivers/watchdog/orion_wdt.c @@ -30,8 +30,8 @@ /* * Watchdog timer block registers. */ -#define WDT_EN 0x0010 -#define WDT_RESET_OUT_EN 0x0002 +#define WDT_EN BIT(4) +#define WDT_RESET_OUT_EN BIT(1) #define WDT_MAX_CYCLE_COUNT0x #define WDT_IN_USE 0 -- 1.8.1.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 06/10] watchdog: orion: Update device-tree binding documentation
Now that the 'reg' property meaning has been changed,
this commit updates the deivce-tree binding documentation.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
Documentation/devicetree/bindings/watchdog/orion-wdt.txt | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/watchdog/orion-wdt.txt
b/Documentation/devicetree/bindings/watchdog/orion-wdt.txt
index 5dc8d30..48a71fc 100644
--- a/Documentation/devicetree/bindings/watchdog/orion-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/orion-wdt.txt
@@ -3,7 +3,8 @@
Required Properties:
- Compatibility : marvell,orion-wdt
-- reg : Address of the timer registers
+- reg : First cell contains the register for the watchdog counter.
+ Second cell contains the register for the RSTOUT mask.
Optional properties:
@@ -11,9 +12,10 @@ Optional properties:
Example:
- wdt@20300 {
+ wdt@20324 {
compatible = marvell,orion-wdt;
- reg = 0x20300 0x28;
+ reg = 0x20324 0x4
+ 0x20108 0x4;
timeout-sec = 10;
status = okay;
};
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 08/10] watchdog: orion: Remove mach-specific unneeded header
The mach/bridge-regs.h header is not needed anymore, so we can remove it. This commit allows to use this driver on multiplatforms builds. Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com --- drivers/watchdog/orion_wdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c index 4a0ab47..4ed7a74 100644 --- a/drivers/watchdog/orion_wdt.c +++ b/drivers/watchdog/orion_wdt.c @@ -26,12 +26,12 @@ #include linux/err.h #include linux/of.h #include linux/time-orion.h -#include mach/bridge-regs.h /* * Watchdog timer block registers. */ #define WDT_EN 0x0010 +#define WDT_RESET_OUT_EN 0x0002 #define WDT_MAX_CYCLE_COUNT0x #define WDT_IN_USE 0 -- 1.8.1.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v7 03/22] ARM: kirkwood: Move to ID based MBus window creation
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.
This will allow to deprecate the name based API, once every
user is removed.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/mach-kirkwood/common.c | 18 ++
arch/arm/mach-kirkwood/pcie.c | 40
2 files changed, 38 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-kirkwood/common.c
index e9238b5..165e751 100644
--- a/arch/arm/mach-kirkwood/common.c
+++ b/arch/arm/mach-kirkwood/common.c
@@ -37,6 +37,12 @@
#include linux/platform_data/dma-mv_xor.h
#include common.h
+/* These can go away once Kirkwood uses the mvebu-mbus DT binding */
+#define KIRKWOOD_MBUS_NAND_TARGET 0x01
+#define KIRKWOOD_MBUS_NAND_ATTR 0x2f
+#define KIRKWOOD_MBUS_SRAM_TARGET 0x03
+#define KIRKWOOD_MBUS_SRAM_ATTR 0x01
+
/*
* I/O Address Mapping
/
@@ -672,10 +678,14 @@ char * __init kirkwood_id(void)
void __init kirkwood_setup_wins(void)
{
- mvebu_mbus_add_window(nand, KIRKWOOD_NAND_MEM_PHYS_BASE,
- KIRKWOOD_NAND_MEM_SIZE);
- mvebu_mbus_add_window(sram, KIRKWOOD_SRAM_PHYS_BASE,
- KIRKWOOD_SRAM_SIZE);
+ mvebu_mbus_add_window_by_id(KIRKWOOD_MBUS_NAND_TARGET,
+ KIRKWOOD_MBUS_NAND_ATTR,
+ KIRKWOOD_NAND_MEM_PHYS_BASE,
+ KIRKWOOD_NAND_MEM_SIZE);
+ mvebu_mbus_add_window_by_id(KIRKWOOD_MBUS_SRAM_TARGET,
+ KIRKWOOD_MBUS_SRAM_ATTR,
+ KIRKWOOD_SRAM_PHYS_BASE,
+ KIRKWOOD_SRAM_SIZE);
}
void __init kirkwood_l2_init(void)
diff --git a/arch/arm/mach-kirkwood/pcie.c b/arch/arm/mach-kirkwood/pcie.c
index ddcb09f..12d86f3 100644
--- a/arch/arm/mach-kirkwood/pcie.c
+++ b/arch/arm/mach-kirkwood/pcie.c
@@ -20,6 +20,16 @@
#include mach/bridge-regs.h
#include common.h
+/* These can go away once Kirkwood uses the mvebu-mbus DT binding */
+#define KIRKWOOD_MBUS_PCIE0_MEM_TARGET0x4
+#define KIRKWOOD_MBUS_PCIE0_MEM_ATTR 0xe8
+#define KIRKWOOD_MBUS_PCIE0_IO_TARGET 0x4
+#define KIRKWOOD_MBUS_PCIE0_IO_ATTR 0xe0
+#define KIRKWOOD_MBUS_PCIE1_MEM_TARGET0x4
+#define KIRKWOOD_MBUS_PCIE1_MEM_ATTR 0xd8
+#define KIRKWOOD_MBUS_PCIE1_IO_TARGET 0x4
+#define KIRKWOOD_MBUS_PCIE1_IO_ATTR 0xd0
+
static void kirkwood_enable_pcie_clk(const char *port)
{
struct clk *clk;
@@ -254,26 +264,24 @@ static void __init add_pcie_port(int index, void __iomem
*base)
void __init kirkwood_pcie_init(unsigned int portmask)
{
- mvebu_mbus_add_window_remap_flags(pcie0.0,
+ mvebu_mbus_add_window_remap_by_id(KIRKWOOD_MBUS_PCIE0_IO_TARGET,
+ KIRKWOOD_MBUS_PCIE0_IO_ATTR,
KIRKWOOD_PCIE_IO_PHYS_BASE,
KIRKWOOD_PCIE_IO_SIZE,
- KIRKWOOD_PCIE_IO_BUS_BASE,
- MVEBU_MBUS_PCI_IO);
- mvebu_mbus_add_window_remap_flags(pcie0.0,
- KIRKWOOD_PCIE_MEM_PHYS_BASE,
- KIRKWOOD_PCIE_MEM_SIZE,
- MVEBU_MBUS_NO_REMAP,
- MVEBU_MBUS_PCI_MEM);
- mvebu_mbus_add_window_remap_flags(pcie1.0,
+ KIRKWOOD_PCIE_IO_BUS_BASE);
+ mvebu_mbus_add_window_by_id(KIRKWOOD_MBUS_PCIE0_MEM_TARGET,
+ KIRKWOOD_MBUS_PCIE0_MEM_ATTR,
+ KIRKWOOD_PCIE_MEM_PHYS_BASE,
+ KIRKWOOD_PCIE_MEM_SIZE);
+ mvebu_mbus_add_window_remap_by_id(KIRKWOOD_MBUS_PCIE1_IO_TARGET,
+ KIRKWOOD_MBUS_PCIE1_IO_ATTR,
KIRKWOOD_PCIE1_IO_PHYS_BASE,
KIRKWOOD_PCIE1_IO_SIZE,
- KIRKWOOD_PCIE1_IO_BUS_BASE,
- MVEBU_MBUS_PCI_IO);
- mvebu_mbus_add_window_remap_flags(pcie1.0,
- KIRKWOOD_PCIE1_MEM_PHYS_BASE,
- KIRKWOOD_PCIE1_MEM_SIZE,
- MVEBU_MBUS_NO_REMAP,
- MVEBU_MBUS_PCI_MEM);
+ KIRKWOOD_PCIE1_IO_BUS_BASE);
+
[PATCH v7 01/22] memory: mvebu-devbus: Remove address decoding window workaround
Now that mbus device tree binding has been introduced, remove the address
decoding window management from this driver.
A suitable 'ranges' entry should be added to the devbus-compatible node in
the device tree, as described by the mbus binding documentation.
Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/memory/mvebu-devbus.c | 64 ++-
1 file changed, 2 insertions(+), 62 deletions(-)
diff --git a/drivers/memory/mvebu-devbus.c b/drivers/memory/mvebu-devbus.c
index 978e8e3..94c9248 100644
--- a/drivers/memory/mvebu-devbus.c
+++ b/drivers/memory/mvebu-devbus.c
@@ -208,16 +208,11 @@ static int mvebu_devbus_probe(struct platform_device
*pdev)
{
struct device *dev = pdev-dev;
struct device_node *node = pdev-dev.of_node;
- struct device_node *parent;
struct devbus *devbus;
struct resource *res;
struct clk *clk;
unsigned long rate;
- const __be32 *ranges;
- int err, cs;
- int addr_cells, p_addr_cells, size_cells;
- int ranges_len, tuple_len;
- u32 base, size;
+ int err;
devbus = devm_kzalloc(pdev-dev, sizeof(struct devbus), GFP_KERNEL);
if (!devbus)
@@ -248,68 +243,13 @@ static int mvebu_devbus_probe(struct platform_device
*pdev)
return err;
/*
-* Allocate an address window for this device.
-* If the device probing fails, then we won't be able to
-* remove the allocated address decoding window.
-*
-* FIXME: This is only a temporary hack! We need to do this here
-* because we still don't have device tree bindings for mbus.
-* Once that support is added, we will declare these address windows
-* statically in the device tree, and remove the window configuration
-* from here.
-*/
-
- /*
-* Get the CS to choose the window string.
-* This is a bit hacky, but it will be removed once the
-* address windows are declared in the device tree.
-*/
- cs = (((unsigned long)devbus-base) % 0x400) / 8;
-
- /*
-* Parse 'ranges' property to obtain a (base,size) window tuple.
-* This will be removed once the address windows
-* are declared in the device tree.
-*/
- parent = of_get_parent(node);
- if (!parent)
- return -EINVAL;
-
- p_addr_cells = of_n_addr_cells(parent);
- of_node_put(parent);
-
- addr_cells = of_n_addr_cells(node);
- size_cells = of_n_size_cells(node);
- tuple_len = (p_addr_cells + addr_cells + size_cells) * sizeof(__be32);
-
- ranges = of_get_property(node, ranges, ranges_len);
- if (ranges == NULL || ranges_len != tuple_len)
- return -EINVAL;
-
- base = of_translate_address(node, ranges + addr_cells);
- if (base == OF_BAD_ADDR)
- return -EINVAL;
- size = of_read_number(ranges + addr_cells + p_addr_cells, size_cells);
-
- /*
-* Create an mbus address windows.
-* FIXME: Remove this, together with the above code, once the
-* address windows are declared in the device tree.
-*/
- err = mvebu_mbus_add_window(devbus_wins[cs], base, size);
- if (err 0)
- return err;
-
- /*
* We need to create a child device explicitly from here to
* guarantee that the child will be probed after the timing
* parameters for the bus are written.
*/
err = of_platform_populate(node, NULL, NULL, dev);
- if (err 0) {
- mvebu_mbus_del_window(base, size);
+ if (err 0)
return err;
- }
return 0;
}
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v7 06/22] ARM: dove: Move to ID based window creation
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.
This will allow to deprecate the name based API, once every
user is removed.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/mach-dove/common.c | 68 ++---
1 file changed, 45 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-dove/common.c b/arch/arm/mach-dove/common.c
index 00247c7..bc22056 100644
--- a/arch/arm/mach-dove/common.c
+++ b/arch/arm/mach-dove/common.c
@@ -27,6 +27,22 @@
#include plat/time.h
#include common.h
+/* These can go away once Dove uses the mvebu-mbus DT binding */
+#define DOVE_MBUS_PCIE0_MEM_TARGET0x4
+#define DOVE_MBUS_PCIE0_MEM_ATTR 0xe8
+#define DOVE_MBUS_PCIE0_IO_TARGET 0x4
+#define DOVE_MBUS_PCIE0_IO_ATTR 0xe0
+#define DOVE_MBUS_PCIE1_MEM_TARGET0x8
+#define DOVE_MBUS_PCIE1_MEM_ATTR 0xe8
+#define DOVE_MBUS_PCIE1_IO_TARGET 0x8
+#define DOVE_MBUS_PCIE1_IO_ATTR 0xe0
+#define DOVE_MBUS_CESA_TARGET 0x3
+#define DOVE_MBUS_CESA_ATTR 0x1
+#define DOVE_MBUS_BOOTROM_TARGET 0x1
+#define DOVE_MBUS_BOOTROM_ATTR0xfd
+#define DOVE_MBUS_SCRATCHPAD_TARGET 0xd
+#define DOVE_MBUS_SCRATCHPAD_ATTR 0x0
+
/*
* I/O Address Mapping
/
@@ -332,34 +348,40 @@ void __init dove_setup_cpu_wins(void)
{
/*
* The PCIe windows will no longer be statically allocated
-* here once Dove is migrated to the pci-mvebu driver.
+* here once Dove is migrated to the pci-mvebu driver. The
+* non-PCIe windows will no longer be created here once Dove
+* fully moves to DT.
*/
- mvebu_mbus_add_window_remap_flags(pcie0.0,
+ mvebu_mbus_add_window_remap_by_id(DOVE_MBUS_PCIE0_IO_TARGET,
+ DOVE_MBUS_PCIE0_IO_ATTR,
DOVE_PCIE0_IO_PHYS_BASE,
DOVE_PCIE0_IO_SIZE,
- DOVE_PCIE0_IO_BUS_BASE,
- MVEBU_MBUS_PCI_IO);
- mvebu_mbus_add_window_remap_flags(pcie1.0,
+ DOVE_PCIE0_IO_BUS_BASE);
+ mvebu_mbus_add_window_remap_by_id(DOVE_MBUS_PCIE1_IO_TARGET,
+ DOVE_MBUS_PCIE1_IO_ATTR,
DOVE_PCIE1_IO_PHYS_BASE,
DOVE_PCIE1_IO_SIZE,
- DOVE_PCIE1_IO_BUS_BASE,
- MVEBU_MBUS_PCI_IO);
- mvebu_mbus_add_window_remap_flags(pcie0.0,
- DOVE_PCIE0_MEM_PHYS_BASE,
- DOVE_PCIE0_MEM_SIZE,
- MVEBU_MBUS_NO_REMAP,
- MVEBU_MBUS_PCI_MEM);
- mvebu_mbus_add_window_remap_flags(pcie1.0,
- DOVE_PCIE1_MEM_PHYS_BASE,
- DOVE_PCIE1_MEM_SIZE,
- MVEBU_MBUS_NO_REMAP,
- MVEBU_MBUS_PCI_MEM);
- mvebu_mbus_add_window(cesa, DOVE_CESA_PHYS_BASE,
- DOVE_CESA_SIZE);
- mvebu_mbus_add_window(bootrom, DOVE_BOOTROM_PHYS_BASE,
- DOVE_BOOTROM_SIZE);
- mvebu_mbus_add_window(scratchpad, DOVE_SCRATCHPAD_PHYS_BASE,
- DOVE_SCRATCHPAD_SIZE);
+ DOVE_PCIE1_IO_BUS_BASE);
+ mvebu_mbus_add_window_by_id(DOVE_MBUS_PCIE0_MEM_TARGET,
+ DOVE_MBUS_PCIE0_MEM_ATTR,
+ DOVE_PCIE0_MEM_PHYS_BASE,
+ DOVE_PCIE0_MEM_SIZE);
+ mvebu_mbus_add_window_by_id(DOVE_MBUS_PCIE1_MEM_TARGET,
+ DOVE_MBUS_PCIE1_MEM_ATTR,
+ DOVE_PCIE1_MEM_PHYS_BASE,
+ DOVE_PCIE1_MEM_SIZE);
+ mvebu_mbus_add_window_by_id(DOVE_MBUS_CESA_TARGET,
+ DOVE_MBUS_CESA_ATTR,
+ DOVE_CESA_PHYS_BASE,
+ DOVE_CESA_SIZE);
+ mvebu_mbus_add_window_by_id(DOVE_MBUS_BOOTROM_TARGET,
+ DOVE_MBUS_BOOTROM_ATTR,
+ DOVE_BOOTROM_PHYS_BASE,
+ DOVE_BOOTROM_SIZE);
+ mvebu_mbus_add_window_by_id(DOVE_MBUS_SCRATCHPAD_TARGET,
+ DOVE_MBUS_SCRATCHPAD_ATTR,
[PATCH v7 08/22] bus: mvebu-mbus: Introduce device tree binding
This patch adds the most fundamental device-tree initialization.
We only introduce what's required to be able to probe the mvebu-mbus
driver from the DT. Follow-up patches will extend the device tree binding,
allowing to describe static address decoding windows.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/bus/mvebu-mbus.c | 49
include/linux/mbus.h | 1 +
2 files changed, 50 insertions(+)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 1b17954..44a07c4 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -900,3 +900,52 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t
mbuswins_phys_base,
sdramwins_phys_base,
sdramwins_size);
}
+
+#ifdef CONFIG_OF
+int __init mvebu_mbus_dt_init(void)
+{
+ struct resource mbuswins_res, sdramwins_res;
+ struct device_node *np, *controller;
+ const struct of_device_id *of_id;
+ const __be32 *prop;
+ int ret;
+
+ np = of_find_matching_node(NULL, of_mvebu_mbus_ids);
+ if (!np) {
+ pr_err(could not find a matching SoC family\n);
+ return -ENODEV;
+ }
+
+ of_id = of_match_node(of_mvebu_mbus_ids, np);
+ mbus_state.soc = of_id-data;
+
+ prop = of_get_property(np, controller, NULL);
+ if (!prop) {
+ pr_err(required 'controller' property missing\n);
+ return -EINVAL;
+ }
+
+ controller = of_find_node_by_phandle(be32_to_cpup(prop));
+ if (!controller) {
+ pr_err(could not find an 'mbus-controller' node\n);
+ return -ENODEV;
+ }
+
+ if (of_address_to_resource(controller, 0, mbuswins_res)) {
+ pr_err(cannot get MBUS register address\n);
+ return -EINVAL;
+ }
+
+ if (of_address_to_resource(controller, 1, sdramwins_res)) {
+ pr_err(cannot get SDRAM register address\n);
+ return -EINVAL;
+ }
+
+ ret = mvebu_mbus_common_init(mbus_state,
+mbuswins_res.start,
+resource_size(mbuswins_res),
+sdramwins_res.start,
+resource_size(sdramwins_res));
+ return ret;
+}
+#endif
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index 9245b66..eadefd6 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -74,5 +74,6 @@ int mvebu_mbus_del_window(phys_addr_t base, size_t size);
int mvebu_mbus_init(const char *soc, phys_addr_t mbus_phys_base,
size_t mbus_size, phys_addr_t sdram_phys_base,
size_t sdram_size);
+int mvebu_mbus_dt_init(void);
#endif /* __LINUX_MBUS_H */
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v7 13/22] bus: mvebu-mbus: Remove name - target, attribute mapping tables
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
This tables were used together with the name-based MBus window
creation API. Since that's has been removed, we can also remove
the tables.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
drivers/bus/mvebu-mbus.c | 150 +++
1 file changed, 7 insertions(+), 143 deletions(-)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 9aee344..e13d475 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -97,33 +97,6 @@
#define DOVE_DDR_BASE_CS_OFF(n) ((n) 4)
-struct mvebu_mbus_mapping {
- const char *name;
- u8 target;
- u8 attr;
- u8 attrmask;
-};
-
-/*
- * Masks used for the 'attrmask' field of mvebu_mbus_mapping. They
- * allow to get the real attribute value, discarding the special bits
- * used to select a PCI MEM region or a PCI WA region. This allows the
- * debugfs code to reverse-match the name of a device from its
- * target/attr values.
- *
- * For all devices except PCI, all bits of 'attr' must be
- * considered. For most SoCs, only bit 3 should be ignored (it allows
- * to select between PCI MEM and PCI I/O). On Orion5x however, there
- * is the special bit 5 to select a PCI WA region.
- */
-#define MAPDEF_NOMASK 0xff
-#define MAPDEF_PCIMASK 0xf7
-#define MAPDEF_ORIONPCIMASK 0xd7
-
-/* Macro used to define one mvebu_mbus_mapping entry */
-#define MAPDEF(__n, __t, __a, __m) \
- { .name = __n, .target = __t, .attr = __a, .attrmask = __m }
-
struct mvebu_mbus_state;
struct mvebu_mbus_soc_data {
@@ -133,7 +106,6 @@ struct mvebu_mbus_soc_data {
void (*setup_cpu_target)(struct mvebu_mbus_state *s);
int (*show_cpu_target)(struct mvebu_mbus_state *s,
struct seq_file *seq, void *v);
- const struct mvebu_mbus_mapping *map;
};
struct mvebu_mbus_state {
@@ -430,8 +402,7 @@ static int mvebu_devs_debug_show(struct seq_file *seq, void
*v)
u64 wbase, wremap;
u32 wsize;
u8 wtarget, wattr;
- int enabled, i;
- const char *name;
+ int enabled;
mvebu_mbus_read_window(mbus, win,
enabled, wbase, wsize,
@@ -442,18 +413,9 @@ static int mvebu_devs_debug_show(struct seq_file *seq,
void *v)
continue;
}
-
- for (i = 0; mbus-soc-map[i].name; i++)
- if (mbus-soc-map[i].target == wtarget
- mbus-soc-map[i].attr ==
- (wattr mbus-soc-map[i].attrmask))
- break;
-
- name = mbus-soc-map[i].name ?: unknown;
-
- seq_printf(seq, [%02d] %016llx - %016llx : %s,
+ seq_printf(seq, [%02d] %016llx - %016llx : %04x:%04x,
win, (unsigned long long)wbase,
- (unsigned long long)(wbase + wsize), name);
+ (unsigned long long)(wbase + wsize), wtarget, wattr);
if (win mbus-soc-num_remappable_wins) {
seq_printf(seq, (remap %016llx)\n,
@@ -578,45 +540,12 @@ mvebu_mbus_dove_setup_cpu_target(struct mvebu_mbus_state
*mbus)
mvebu_mbus_dram_info.num_cs = cs;
}
-static const struct mvebu_mbus_mapping armada_370_map[] = {
- MAPDEF(bootrom, 1, 0xe0, MAPDEF_NOMASK),
- MAPDEF(devbus-boot, 1, 0x2f, MAPDEF_NOMASK),
- MAPDEF(devbus-cs0, 1, 0x3e, MAPDEF_NOMASK),
- MAPDEF(devbus-cs1, 1, 0x3d, MAPDEF_NOMASK),
- MAPDEF(devbus-cs2, 1, 0x3b, MAPDEF_NOMASK),
- MAPDEF(devbus-cs3, 1, 0x37, MAPDEF_NOMASK),
- MAPDEF(pcie0.0, 4, 0xe0, MAPDEF_PCIMASK),
- MAPDEF(pcie1.0, 8, 0xe0, MAPDEF_PCIMASK),
- {},
-};
-
static const struct mvebu_mbus_soc_data armada_370_mbus_data = {
.num_wins= 20,
.num_remappable_wins = 8,
.win_cfg_offset = armada_370_xp_mbus_win_offset,
.setup_cpu_target= mvebu_mbus_default_setup_cpu_target,
.show_cpu_target = mvebu_sdram_debug_show_orion,
- .map = armada_370_map,
-};
-
-static const struct mvebu_mbus_mapping armada_xp_map[] = {
- MAPDEF(bootrom, 1, 0x1d, MAPDEF_NOMASK),
- MAPDEF(devbus-boot, 1, 0x2f, MAPDEF_NOMASK),
- MAPDEF(devbus-cs0, 1, 0x3e, MAPDEF_NOMASK),
- MAPDEF(devbus-cs1, 1, 0x3d, MAPDEF_NOMASK),
- MAPDEF(devbus-cs2, 1, 0x3b, MAPDEF_NOMASK),
- MAPDEF(devbus-cs3, 1, 0x37, MAPDEF_NOMASK),
- MAPDEF(pcie0.0, 4, 0xe0, MAPDEF_PCIMASK),
- MAPDEF(pcie0.1, 4, 0xd0, MAPDEF_PCIMASK),
- MAPDEF(pcie0.2, 4, 0xb0, MAPDEF_PCIMASK),
- MAPDEF(pcie0.3, 4, 0x70, MAPDEF_PCIMASK),
- MAPDEF(pcie1.0, 8, 0xe0, MAPDEF_PCIMASK),
- MAPDEF(pcie1.1, 8, 0xd0, MAPDEF_PCIMASK),
-
[PATCH v7 11/22] PCI: mvebu: Adapt to the new device tree layout
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
The new device tree layout encodes the window's target ID and attribute
in the PCIe controller node's ranges property. This allows to parse
such entries to obtain such information and use the recently introduced
MBus API to create the windows, instead of using the current name based
scheme.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
.../devicetree/bindings/pci/mvebu-pci.txt | 145 -
drivers/pci/host/pci-mvebu.c | 113 +++-
2 files changed, 193 insertions(+), 65 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index f8d4058..9556e2f 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -1,6 +1,7 @@
* Marvell EBU PCIe interfaces
Mandatory properties:
+
- compatible: one of the following values:
marvell,armada-370-pcie
marvell,armada-xp-pcie
@@ -10,11 +11,49 @@ Mandatory properties:
- #interrupt-cells, set to 1
- bus-range: PCI bus numbers covered
- device_type, set to pci
-- ranges: ranges for the PCI memory and I/O regions, as well as the
- MMIO registers to control the PCIe interfaces.
+- ranges: ranges describing the MMIO registers to control the PCIe
+ interfaces, and ranges describing the MBus windows needed to access
+ the memory and I/O regions of each PCIe interface.
+
+The ranges describing the MMIO registers have the following layout:
+
+0x8200 0 r MBUS_ID(0xf0, 0x01) r 0 s
+
+where:
+
+ * r is a 32-bits value that gives the offset of the MMIO
+ registers of this PCIe interface, from the base of the internal
+ registers.
+
+ * s is a 32-bits value that give the size of this MMIO
+ registers area. This range entry translates the '0x8200 0 r' PCI
+ address into the 'MBUS_ID(0xf0, 0x01) r' CPU address, which is part
+ of the internal register window (as identified by MBUS_ID(0xf0,
+ 0x01)).
+
+The ranges describing the MBus windows have the following layout:
+
+0x8t00 s 0 MBUS_ID(w, a) 0 1 0
+
+where:
+
+ * t is the type of the MBus window (as defined by the standard PCI DT
+ bindings), 1 for I/O and 2 for memory.
-In addition, the Device Tree node must have sub-nodes describing each
+ * s is the PCI slot that corresponds to this PCIe interface
+
+ * w is the 'target ID' value for the MBus window
+
+ * a the 'attribute' value for the MBus window.
+
+Since the location and size of the different MBus windows is not fixed in
+hardware, and only determined in runtime, those ranges cover the full first
+4 GB of the physical address space, and do not translate into a valid CPU
+address.
+
+In addition, the device tree node must have sub-nodes describing each
PCIe interface, having the following mandatory properties:
+
- reg: used only for interrupt mapping, so only the first four bytes
are used to refer to the correct bus number and device number.
- assigned-addresses: reference to the MMIO registers used to control
@@ -26,7 +65,8 @@ PCIe interface, having the following mandatory properties:
- #address-cells, set to 3
- #size-cells, set to 2
- #interrupt-cells, set to 1
-- ranges, empty property.
+- ranges, translating the MBus windows ranges of the parent node into
+ standard PCI addresses.
- interrupt-map-mask and interrupt-map, standard PCI properties to
define the mapping of the PCIe interface to interrupt numbers.
@@ -47,27 +87,50 @@ pcie-controller {
bus-range = 0x00 0xff;
- ranges = 0x8200 0 0xd004 0xd004 0 0x2000 /* Port 0.0
registers */
- 0x8200 0 0xd0042000 0xd0042000 0 0x2000 /* Port 2.0
registers */
- 0x8200 0 0xd0044000 0xd0044000 0 0x2000 /* Port 0.1
registers */
- 0x8200 0 0xd0048000 0xd0048000 0 0x2000 /* Port 0.2
registers */
- 0x8200 0 0xd004c000 0xd004c000 0 0x2000 /* Port 0.3
registers */
- 0x8200 0 0xd008 0xd008 0 0x2000 /* Port 1.0
registers */
- 0x8200 0 0xd0082000 0xd0082000 0 0x2000 /* Port 3.0
registers */
- 0x8200 0 0xd0084000 0xd0084000 0 0x2000 /* Port 1.1
registers */
- 0x8200 0 0xd0088000 0xd0088000 0 0x2000 /* Port 1.2
registers */
- 0x8200 0 0xd008c000 0xd008c000 0 0x2000 /* Port 1.3
registers */
- 0x8200 0 0xe000 0xe000 0 0x0800 /*
non-prefetchable memory */
- 0x8100 0 0 0xe800 0 0x0010; /*
downstream I/O */
+ ranges =
+ 0x8200 0 0x4 MBUS_ID(0xf0, 0x01) 0x4 0 0x2000
/* Port 0.0 registers */
+ 0x8200 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x2000
/* Port 2.0 registers */
+
[PATCH v7 10/22] bus: mvebu-mbus: Add new API for the PCIe memory and IO aperture
We add two optional properties to the MBus DT binding, to encode
the PCIe memory and IO aperture. This allows such information to
be retrieved by -for instance- the pci driver to allocate the
MBus decoding windows.
Correspondingly, and in order to retrieve this information,
we add two new APIs.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
.../devicetree/bindings/bus/mvebu-mbus.txt | 14 +++
drivers/bus/mvebu-mbus.c | 49 ++
include/linux/mbus.h | 4 ++
3 files changed, 67 insertions(+)
diff --git a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
index cce863f..960186f 100644
--- a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
+++ b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
@@ -20,6 +20,18 @@ Required properties:
registers that control the MBus, which is typically contained
within the internal register window (see below).
+Optional properties:
+
+- pcie-mem-aperture: This optional property contains the aperture for
+ the memory region of the PCIe driver.
+ If it's defined, it must encode the base address and
+ size for the address decoding windows allocated for
+ the PCIe memory region.
+
+- pcie-io-aperture:Just as explained for the above property, this
+ optional property contains the aperture for the
+ I/O region of the PCIe driver.
+
* Marvell MBus controller
Required properties:
@@ -38,6 +50,8 @@ Example:
#address-cells = 2;
#size-cells = 1;
controller = mbusc;
+ pcie-mem-aperture = 0xe000 0x800;
+ pcie-io-aperture = 0xe800 0x10;
internal-regs {
compatible = simple-bus;
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 8aa3b45..5f0bfa3 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -142,6 +142,8 @@ struct mvebu_mbus_state {
struct dentry *debugfs_root;
struct dentry *debugfs_sdram;
struct dentry *debugfs_devs;
+ struct resource pcie_mem_aperture;
+ struct resource pcie_io_aperture;
const struct mvebu_mbus_soc_data *soc;
int hw_io_coherency;
};
@@ -821,6 +823,20 @@ int mvebu_mbus_del_window(phys_addr_t base, size_t size)
return 0;
}
+void mvebu_mbus_get_pcie_mem_aperture(struct resource *res)
+{
+ if (!res)
+ return;
+ *res = mbus_state.pcie_mem_aperture;
+}
+
+void mvebu_mbus_get_pcie_io_aperture(struct resource *res)
+{
+ if (!res)
+ return;
+ *res = mbus_state.pcie_io_aperture;
+}
+
static __init int mvebu_mbus_debugfs_init(void)
{
struct mvebu_mbus_state *s = mbus_state;
@@ -1017,6 +1033,35 @@ static int __init mbus_dt_setup(struct mvebu_mbus_state
*mbus,
return 0;
}
+static void __init mvebu_mbus_get_pcie_resources(struct device_node *np,
+struct resource *mem,
+struct resource *io)
+{
+ u32 reg[2];
+ int ret;
+
+ /*
+* These are optional, so we clear them and they'll
+* be zero if they are missing from the DT.
+*/
+ memset(mem, 0, sizeof(struct resource));
+ memset(io, 0, sizeof(struct resource));
+
+ ret = of_property_read_u32_array(np, pcie-mem-aperture, reg,
ARRAY_SIZE(reg));
+ if (!ret) {
+ mem-start = reg[0];
+ mem-end = mem-start + reg[1];
+ mem-flags = IORESOURCE_MEM;
+ }
+
+ ret = of_property_read_u32_array(np, pcie-io-aperture, reg,
ARRAY_SIZE(reg));
+ if (!ret) {
+ io-start = reg[0];
+ io-end = io-start + reg[1];
+ io-flags = IORESOURCE_IO;
+ }
+}
+
int __init mvebu_mbus_dt_init(void)
{
struct resource mbuswins_res, sdramwins_res;
@@ -1056,6 +1101,10 @@ int __init mvebu_mbus_dt_init(void)
return -EINVAL;
}
+ /* Get optional pcie-{mem,io}-aperture properties */
+ mvebu_mbus_get_pcie_resources(np, mbus_state.pcie_mem_aperture,
+ mbus_state.pcie_io_aperture);
+
ret = mvebu_mbus_common_init(mbus_state,
mbuswins_res.start,
resource_size(mbuswins_res),
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index eadefd6..650bc15 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -11,6 +11,8 @@
#ifndef __LINUX_MBUS_H
#define __LINUX_MBUS_H
+struct resource;
+
struct mbus_dram_target_info
{
/*
@@ -59,6 +61,8 @@ static inline const struct
[PATCH v7 16/22] ARM: mvebu: Remove the harcoded BootROM window allocation
The address decoding window to access the BootROM should not be
allocated programatically, but instead declared in the device tree.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-mvebu/platsmp.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
index ce81d30..7be1ec2 100644
--- a/arch/arm/mach-mvebu/platsmp.c
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -21,6 +21,7 @@
#include linux/smp.h
#include linux/clk.h
#include linux/of.h
+#include linux/of_address.h
#include linux/mbus.h
#include asm/cacheflush.h
#include asm/smp_plat.h
@@ -29,6 +30,9 @@
#include pmsu.h
#include coherency.h
+#define AXP_BOOTROM_BASE 0xfff0
+#define AXP_BOOTROM_SIZE 0x10
+
void __init set_secondary_cpus_clock(void)
{
int thiscpu;
@@ -114,10 +118,29 @@ static void __init armada_xp_smp_init_cpus(void)
void __init armada_xp_smp_prepare_cpus(unsigned int max_cpus)
{
+ struct device_node *node;
+ struct resource res;
+ int err;
+
set_secondary_cpus_clock();
flush_cache_all();
set_cpu_coherent(cpu_logical_map(smp_processor_id()), 0);
- mvebu_mbus_add_window(bootrom, 0xfff0, SZ_1M);
+
+ /*
+* In order to boot the secondary CPUs we need to ensure
+* the bootROM is mapped at the correct address.
+*/
+ node = of_find_compatible_node(NULL, NULL, marvell,bootrom);
+ if (!node)
+ panic(Cannot find 'marvell,bootrom' compatible node);
+
+ err = of_address_to_resource(node, 0, res);
+ if (err 0)
+ panic(Cannot get 'bootrom' node address);
+
+ if (res.start != AXP_BOOTROM_BASE||
+ resource_size(res) != AXP_BOOTROM_SIZE)
+ panic(The address for the BootROM is incorrect);
}
struct smp_operations armada_xp_smp_ops __initdata = {
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v7 14/22] bus: mvebu-mbus: Update main description
From: Thomas Petazzoni thomas.petazz...@free-electrons.com After replacing the MBus name-based by the new ID-based API let's fix the general description of the driver at the beginning of the file. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com --- drivers/bus/mvebu-mbus.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c index e13d475..f6e9192 100644 --- a/drivers/bus/mvebu-mbus.c +++ b/drivers/bus/mvebu-mbus.c @@ -35,13 +35,9 @@ * * - Provides an API for platform code or device drivers to * dynamically add or remove address decoding windows for the CPU - - * device accesses. This API is mvebu_mbus_add_window(), - * mvebu_mbus_add_window_remap_flags() and - * mvebu_mbus_del_window(). Since the (target, attribute) values - * differ from one SoC family to another, the API uses a 'const char - * *' string to identify devices, and this driver is responsible for - * knowing the mapping between the name of a device and its - * corresponding (target, attribute) in the current SoC family. + * device accesses. This API is mvebu_mbus_add_window_by_id(), + * mvebu_mbus_add_window_remap_by_id() and + * mvebu_mbus_del_window(). * * - Provides a debugfs interface in /sys/kernel/debug/mvebu-mbus/ to * see the list of CPU - SDRAM windows and their configuration -- 1.8.1.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v7 20/22] ARM: mvebu: Add BootROM to Armada 370/XP device tree
In order to access the SoC BootROM, we need to declare a mapping
(through a ranges property). The mbus driver will use this property
to allocate a suitable address decoding window.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-db.dts | 3 ++-
arch/arm/boot/dts/armada-370-mirabox.dts | 3 ++-
arch/arm/boot/dts/armada-370-rd.dts | 3 ++-
arch/arm/boot/dts/armada-370.dtsi| 5 +
arch/arm/boot/dts/armada-xp-db.dts | 3 ++-
arch/arm/boot/dts/armada-xp-gp.dts | 3 ++-
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 3 ++-
arch/arm/boot/dts/armada-xp.dtsi | 5 +
8 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index 5920b4e..90ce29d 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,7 +30,8 @@
};
soc {
- ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10;
+ ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10
+ MBUS_ID(0x01, 0xe0) 0 0xfff0 0x10;
internal-regs {
serial@12000 {
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index a4202b6..19341d2 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,7 +25,8 @@
};
soc {
- ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10;
+ ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10
+ MBUS_ID(0x01, 0xe0) 0 0xfff0 0x10;
internal-regs {
serial@12000 {
diff --git a/arch/arm/boot/dts/armada-370-rd.dts
b/arch/arm/boot/dts/armada-370-rd.dts
index dd0ba01..0b3acf3 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,7 +28,8 @@
};
soc {
- ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10;
+ ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10
+ MBUS_ID(0x01, 0xe0) 0 0xfff0 0x10;
internal-regs {
serial@12000 {
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index 4b54e51..bd21d49 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -31,6 +31,11 @@
soc {
compatible = marvell,armada370-mbus, simple-bus;
+ bootrom {
+ compatible = marvell,bootrom;
+ reg = MBUS_ID(0x01, 0xe0) 0 0x10;
+ };
+
internal-regs {
system-controller@18200 {
compatible =
marvell,armada-370-xp-system-controller;
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index 0d4ce54..857f272 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -30,7 +30,8 @@
};
soc {
- ranges = MBUS_ID(0xf0, 0x01) 0 0 0xd000 0x10;
+ ranges = MBUS_ID(0xf0, 0x01) 0 0 0xd000 0x10
+ MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10;
internal-regs {
serial@12000 {
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts
b/arch/arm/boot/dts/armada-xp-gp.dts
index 2fa9209..934dc46 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -39,7 +39,8 @@
};
soc {
- ranges = MBUS_ID(0xf0, 0x01) 0 0 0xd000 0x10;
+ ranges = MBUS_ID(0xf0, 0x01) 0 0 0xd000 0x10
+ MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10;
internal-regs {
serial@12000 {
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index a3e3a12..1700f6f 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -27,7 +27,8 @@
};
soc {
- ranges = MBUS_ID(0xf0, 0x01) 0 0 0xd000 0x10;
+ ranges = MBUS_ID(0xf0, 0x01) 0 0 0xd000 0x10
+ MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10;
internal-regs {
serial@12000 {
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 8033824..7ba99ce 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -29,6 +29,11 @@
soc {
compatible = marvell,armadaxp-mbus, simple-bus;
+ bootrom {
+ compatible = marvell,bootrom
[PATCH v7 19/22] ARM: mvebu: Add MBus to Armada 370/XP device tree
The Armada 370/XP SoC family has a completely configurable address
space handled by the MBus controller.
This patch introduces the device tree layout of MBus, making the
'soc' node as mbus-compatible.
Since every peripheral/controller is a child of this 'soc' node,
this makes all of them sit behind the mbus, thus describing the
hardware accurately.
A translation entry has been added for the internal-regs mapping.
This can't be done in the common armada-370-xp.dtsi because A370
and AXP have different addressing width.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-db.dts | 2 ++
arch/arm/boot/dts/armada-370-mirabox.dts | 2 ++
arch/arm/boot/dts/armada-370-rd.dts | 2 ++
arch/arm/boot/dts/armada-370-xp.dtsi | 15 ++-
arch/arm/boot/dts/armada-370.dtsi| 4 ++--
arch/arm/boot/dts/armada-xp-db.dts | 4 +---
arch/arm/boot/dts/armada-xp-gp.dts | 4 +---
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 4 +---
arch/arm/boot/dts/armada-xp.dtsi | 2 ++
9 files changed, 23 insertions(+), 16 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index 55b986c..5920b4e 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,6 +30,8 @@
};
soc {
+ ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10;
+
internal-regs {
serial@12000 {
clock-frequency = 2;
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index 37530af..a4202b6 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,6 +25,8 @@
};
soc {
+ ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10;
+
internal-regs {
serial@12000 {
clock-frequency = 2;
diff --git a/arch/arm/boot/dts/armada-370-rd.dts
b/arch/arm/boot/dts/armada-370-rd.dts
index 7aa2171..dd0ba01 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,6 +28,8 @@
};
soc {
+ ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10;
+
internal-regs {
serial@12000 {
clock-frequency = 2;
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 90b1176..62639b4 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -18,6 +18,8 @@
/include/ skeleton64.dtsi
+#define MBUS_ID(target,attributes) (((target) 24) | ((attributes) 16))
+
/ {
model = Marvell Armada 370 and XP SoC;
compatible = marvell,armada-370-xp;
@@ -38,18 +40,21 @@
};
soc {
- #address-cells = 1;
+ #address-cells = 2;
#size-cells = 1;
- compatible = simple-bus;
+ controller = mbusc;
interrupt-parent = mpic;
- ranges = 0 0 0xd000 0x010 /* internal
registers */
- 0xe000 0 0xe000 0x810 /* PCIe */;
internal-regs {
compatible = simple-bus;
#address-cells = 1;
#size-cells = 1;
- ranges;
+ ranges = 0 MBUS_ID(0xf0, 0x01) 0 0x10;
+
+ mbusc: mbus-controller@2 {
+ compatible = marvell,mbus-controller;
+ reg = 0x2 0x100, 0x20180 0x20;
+ };
mpic: interrupt-controller@2 {
compatible = marvell,mpic;
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index 08ec6e3..4b54e51 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -29,8 +29,8 @@
};
soc {
- ranges = 0 0xd000 0x010 /* internal registers
*/
- 0xe000 0xe000 0x810 /* PCIe */;
+ compatible = marvell,armada370-mbus, simple-bus;
+
internal-regs {
system-controller@18200 {
compatible =
marvell,armada-370-xp-system-controller;
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index a9bd766..0d4ce54 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -30,9 +30,7 @@
};
soc {
- ranges = 0 0 0xd000 0x10 /* Internal
registers 1MiB
[PATCH v7 22/22] ARM: mvebu: Relocate Armada 370/XP PCIe device tree nodes
Now that mbus has been added to the device tree, it's possible to
move the PCIe nodes out of internal registers, placing it directly
below the mbus. This is a more accurate representation of the
hardware.
Moving the PCIe nodes, we now need to introduce an extra cell to
encode the window target ID and attribute. Since this depends on
the PCIe port, we split the ranges translation entries, to correspond
to each MBus window.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-mirabox.dts | 32 +-
arch/arm/boot/dts/armada-370-xp.dtsi | 2 +
arch/arm/boot/dts/armada-370.dtsi| 101 +++---
arch/arm/boot/dts/armada-xp-db.dts | 67 ++--
arch/arm/boot/dts/armada-xp-gp.dts | 42 +--
arch/arm/boot/dts/armada-xp-mv78230.dtsi | 222 ++--
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 261 ---
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 409 ---
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 18 +-
9 files changed, 612 insertions(+), 542 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index 19341d2..2471d9d 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -28,6 +28,22 @@
ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10
MBUS_ID(0x01, 0xe0) 0 0xfff0 0x10;
+ pcie-controller {
+ status = okay;
+
+ /* Internal mini-PCIe connector */
+ pcie@1,0 {
+ /* Port 0, Lane 0 */
+ status = okay;
+ };
+
+ /* Connected on the PCB to a USB 3.0 XHCI controller */
+ pcie@2,0 {
+ /* Port 1, Lane 0 */
+ status = okay;
+ };
+ };
+
internal-regs {
serial@12000 {
clock-frequency = 2;
@@ -123,22 +139,6 @@
reg = 0x25;
};
};
-
- pcie-controller {
- status = okay;
-
- /* Internal mini-PCIe connector */
- pcie@1,0 {
- /* Port 0, Lane 0 */
- status = okay;
- };
-
- /* Connected on the PCB to a USB 3.0 XHCI
controller */
- pcie@2,0 {
- /* Port 1, Lane 0 */
- status = okay;
- };
- };
};
};
};
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 073dd20..e984ce6 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -44,6 +44,8 @@
#size-cells = 1;
controller = mbusc;
interrupt-parent = mpic;
+ pcie-mem-aperture = 0xe000 0x800;
+ pcie-io-aperture = 0xe800 0x10;
devbus-bootcs {
compatible = marvell,mvebu-devbus;
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index bd21d49..648e530 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -36,6 +36,59 @@
reg = MBUS_ID(0x01, 0xe0) 0 0x10;
};
+ pcie-controller {
+ compatible = marvell,armada-370-pcie;
+ status = disabled;
+ device_type = pci;
+
+ #address-cells = 3;
+ #size-cells = 2;
+
+ bus-range = 0x00 0xff;
+
+ ranges =
+ 0x8200 0 0x4 MBUS_ID(0xf0, 0x01)
0x4 0 0x2000
+ 0x8200 0 0x8 MBUS_ID(0xf0, 0x01)
0x8 0 0x2000
+ 0x8200 0x1 0 MBUS_ID(0x04, 0xe8) 0
1 0 /* Port 0.0 MEM */
+ 0x8100 0x1 0 MBUS_ID(0x04, 0xe0) 0
1 0 /* Port 0.0 IO */
+ 0x8200 0x2 0 MBUS_ID(0x08, 0xe8) 0
1 0 /* Port 1.0 MEM */
+ 0x8100 0x2 0 MBUS_ID(0x08, 0xe0) 0
1 0 /* Port 1.0 IO */;
+
+ pcie@1,0 {
+ device_type = pci
[PATCH v7 21/22] ARM: mvebu: Relocate Armada 370/XP DeviceBus device tree nodes
Now that mbus has been added to the device tree, it's possible to
move the DeviceBus out of internal registers, placing it directly
below the mbus. This is a more accurate representation of the hardware.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-xp.dtsi | 94 +---
arch/arm/boot/dts/armada-xp-db.dts | 59 +++
arch/arm/boot/dts/armada-xp-gp.dts | 60 +++
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 65
4 files changed, 140 insertions(+), 138 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 62639b4..073dd20 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -45,6 +45,56 @@
controller = mbusc;
interrupt-parent = mpic;
+ devbus-bootcs {
+ compatible = marvell,mvebu-devbus;
+ reg = MBUS_ID(0xf0, 0x01) 0x10400 0x8;
+ ranges = 0 MBUS_ID(0x01, 0x2f) 0 0x;
+ #address-cells = 1;
+ #size-cells = 1;
+ clocks = coreclk 0;
+ status = disabled;
+ };
+
+ devbus-cs0 {
+ compatible = marvell,mvebu-devbus;
+ reg = MBUS_ID(0xf0, 0x01) 0x10408 0x8;
+ ranges = 0 MBUS_ID(0x01, 0x3e) 0 0x;
+ #address-cells = 1;
+ #size-cells = 1;
+ clocks = coreclk 0;
+ status = disabled;
+ };
+
+ devbus-cs1 {
+ compatible = marvell,mvebu-devbus;
+ reg = MBUS_ID(0xf0, 0x01) 0x10410 0x8;
+ ranges = 0 MBUS_ID(0x01, 0x3d) 0 0x;
+ #address-cells = 1;
+ #size-cells = 1;
+ clocks = coreclk 0;
+ status = disabled;
+ };
+
+ devbus-cs2 {
+ compatible = marvell,mvebu-devbus;
+ reg = MBUS_ID(0xf0, 0x01) 0x10418 0x8;
+ ranges = 0 MBUS_ID(0x01, 0x3b) 0 0x;
+ #address-cells = 1;
+ #size-cells = 1;
+ clocks = coreclk 0;
+ status = disabled;
+ };
+
+ devbus-cs3 {
+ compatible = marvell,mvebu-devbus;
+ reg = MBUS_ID(0xf0, 0x01) 0x10420 0x8;
+ ranges = 0 MBUS_ID(0x01, 0x37) 0 0x;
+ #address-cells = 1;
+ #size-cells = 1;
+ clocks = coreclk 0;
+ status = disabled;
+ };
+
internal-regs {
compatible = simple-bus;
#address-cells = 1;
@@ -200,50 +250,6 @@
status = disabled;
};
- devbus-bootcs@10400 {
- compatible = marvell,mvebu-devbus;
- reg = 0x10400 0x8;
- #address-cells = 1;
- #size-cells = 1;
- clocks = coreclk 0;
- status = disabled;
- };
-
- devbus-cs0@10408 {
- compatible = marvell,mvebu-devbus;
- reg = 0x10408 0x8;
- #address-cells = 1;
- #size-cells = 1;
- clocks = coreclk 0;
- status = disabled;
- };
-
- devbus-cs1@10410 {
- compatible = marvell,mvebu-devbus;
- reg = 0x10410 0x8;
- #address-cells = 1;
- #size-cells = 1;
- clocks = coreclk 0;
- status = disabled;
- };
-
- devbus-cs2@10418 {
- compatible = marvell,mvebu-devbus;
- reg = 0x10418 0x8;
- #address-cells = 1;
- #size-cells = 1;
- clocks = coreclk 0;
- status = disabled;
- };
-
- devbus-cs3@10420 {
- compatible = marvell,mvebu-devbus;
- reg = 0x10420 0x8
[PATCH v7 00/22] MBus DT binding: The return of PCIe
;
#address-cells = 3;
#size-cells = 2;
ranges =
0x8200 0 0x4 MBUS_ID(0xf0, 0x01) 0x4 0
0x2000 /* Port 0.0 registers */
0x8200 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0
0x2000 /* Port 2.0 registers */
0x8200 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0
0x2000 /* Port 0.1 registers */
0x8200 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0
0x2000 /* Port 0.2 registers */
0x8200 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0
0x2000 /* Port 0.3 registers */
0x8200 0x1 0 MBUS_ID(0x04, 0xe8) 0 1 0 /*
Port 0.0 MEM */
0x8100 0x1 0 MBUS_ID(0x04, 0xe0) 0 1 0 /*
Port 0.0 IO */
0x8200 0x2 0 MBUS_ID(0x08, 0xe8) 0 1 0 /*
Port 1.0 MEM */
0x8100 0x2 0 MBUS_ID(0x08, 0xe0) 0 1 0 /*
Port 1.0 IO */;
pcie@1,0 {
device_type = pci;
assigned-addresses = 0x82000800 0 0x4 0 0x2000;
reg = 0x0800 0 0 0 0;
#address-cells = 3;
#size-cells = 2;
#interrupt-cells = 1;
ranges = 0x8200 0 0 0x8200 0x1 0 1 0
0x8100 0 0 0x8100 0x1 0 1 0;
interrupt-map-mask = 0 0 0 0;
interrupt-map = 0 0 0 0 mpic 58;
marvell,pcie-port = 0;
marvell,pcie-lane = 0;
clocks = gateclk 5;
status = disabled;
};
pcie@2,0 {
device_type = pci;
assigned-addresses = 0x82002800 0 0x8 0 0x2000;
reg = 0x1000 0 0 0 0;
#address-cells = 3;
#size-cells = 2;
#interrupt-cells = 1;
ranges = 0x8200 0 0 0x8200 0x2 0 1 0
0x8100 0 0 0x8100 0x2 0 1 0;
interrupt-map-mask = 0 0 0 0;
interrupt-map = 0 0 0 0 mpic 62;
marvell,pcie-port = 1;
marvell,pcie-lane = 0;
clocks = gateclk 9;
status = disabled;
};
};
internal-regs {
compatible = simple-bus;
#address-cells = 1;
#size-cells = 1;
ranges = 0 MBUS_ID(0xf0, 0x01) 0 0x10;
mbusc: mbus-controller@2 {
reg = 0x2 0x100, 0x20180 0x20;
};
interrupt-controller@2 {
reg = 0x20a00 0x2d0, 0x21070 0x58;
};
};
};
Ezequiel Garcia (12):
memory: mvebu-devbus: Remove address decoding window workaround
bus: mvebu-mbus: Factor out initialization details
bus: mvebu-mbus: Introduce device tree binding
bus: mvebu-mbus: Add static window allocation to the DT binding
bus: mvebu-mbus: Add new API for the PCIe memory and IO aperture
ARM: mvebu: Remove the harcoded BootROM window allocation
ARM: mvebu: Initialize MBus using the DT binding
ARM: mvebu: Use the preprocessor on Armada 370/XP device tree files
ARM: mvebu: Add MBus to Armada 370/XP device tree
ARM: mvebu: Add BootROM to Armada 370/XP device tree
ARM: mvebu: Relocate Armada 370/XP DeviceBus device tree nodes
ARM: mvebu: Relocate Armada 370/XP PCIe device tree nodes
Thomas Petazzoni (10):
bus: mvebu-mbus: Add new API for window creation
ARM: kirkwood: Move to ID based MBus window creation
ARM: mv78xx0: Move to ID based window creation
ARM: orion5x: Move to ID based window creation
ARM: dove: Move to ID based window creation
PCI: mvebu: Adapt to the new device tree layout
bus: mvebu-mbus: Remove the no longer used name-based API
bus: mvebu-mbus: Remove name - target, attribute mapping tables
bus: mvebu-mbus: Update main description
bus: mvebu-mbus: Factorize Armada 370/XP data structures
.../devicetree/bindings/bus/mvebu-mbus.txt | 267 +
.../devicetree/bindings/pci/mvebu-pci.txt | 145 +--
arch/arm/boot/dts/armada-370-db.dts| 5 +-
arch/arm/boot/dts/armada-370-mirabox.dts | 37 +-
arch/arm/boot/dts/armada-370-rd.dts| 5 +-
arch/arm/boot/dts/armada-370-xp.dtsi | 111 +++---
arch/arm/boot/dts/armada-370.dtsi | 112 +++---
arch/arm/boot/dts/armada-xp-db.dts | 131 +++
arch/arm/boot/dts/armada-xp-gp.dts | 107 +++--
arch/arm/boot/dts/armada-xp-mv78230.dtsi | 222
[PATCH v7 05/22] ARM: orion5x: Move to ID based window creation
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.
This will allow to deprecate the name based API, once every
user is removed.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/mach-orion5x/common.c | 36 ++
arch/arm/mach-orion5x/common.h | 17
arch/arm/mach-orion5x/d2net-setup.c| 6 +++--
arch/arm/mach-orion5x/db88f5281-setup.c| 24 +++--
arch/arm/mach-orion5x/dns323-setup.c | 6 +++--
arch/arm/mach-orion5x/edmini_v2-setup.c| 6 +++--
arch/arm/mach-orion5x/kurobox_pro-setup.c | 12 ++---
arch/arm/mach-orion5x/ls-chl-setup.c | 6 +++--
arch/arm/mach-orion5x/ls_hgl-setup.c | 6 +++--
arch/arm/mach-orion5x/lsmini-setup.c | 6 +++--
arch/arm/mach-orion5x/mss2-setup.c | 6 +++--
arch/arm/mach-orion5x/mv2120-setup.c | 6 +++--
arch/arm/mach-orion5x/net2big-setup.c | 6 +++--
arch/arm/mach-orion5x/pci.c| 9 +++
arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c | 6 +++--
arch/arm/mach-orion5x/rd88f5181l-ge-setup.c| 6 +++--
arch/arm/mach-orion5x/rd88f5182-setup.c| 13 ++
arch/arm/mach-orion5x/terastation_pro2-setup.c | 6 +++--
arch/arm/mach-orion5x/ts209-setup.c| 6 +++--
arch/arm/mach-orion5x/ts409-setup.c| 6 +++--
arch/arm/mach-orion5x/wnr854t-setup.c | 6 +++--
arch/arm/mach-orion5x/wrt350n-v2-setup.c | 6 +++--
22 files changed, 137 insertions(+), 70 deletions(-)
diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
index b41599f..91a5852 100644
--- a/arch/arm/mach-orion5x/common.c
+++ b/arch/arm/mach-orion5x/common.c
@@ -174,8 +174,10 @@ void __init orion5x_xor_init(void)
/
static void __init orion5x_crypto_init(void)
{
- mvebu_mbus_add_window(sram, ORION5X_SRAM_PHYS_BASE,
- ORION5X_SRAM_SIZE);
+ mvebu_mbus_add_window_by_id(ORION_MBUS_SRAM_TARGET,
+ ORION_MBUS_SRAM_ATTR,
+ ORION5X_SRAM_PHYS_BASE,
+ ORION5X_SRAM_SIZE);
orion_crypto_init(ORION5X_CRYPTO_PHYS_BASE, ORION5X_SRAM_PHYS_BASE,
SZ_8K, IRQ_ORION5X_CESA);
}
@@ -222,22 +224,24 @@ void orion5x_setup_wins(void)
* The PCIe windows will no longer be statically allocated
* here once Orion5x is migrated to the pci-mvebu driver.
*/
- mvebu_mbus_add_window_remap_flags(pcie0.0, ORION5X_PCIE_IO_PHYS_BASE,
+ mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
+ ORION_MBUS_PCIE_IO_ATTR,
+ ORION5X_PCIE_IO_PHYS_BASE,
ORION5X_PCIE_IO_SIZE,
- ORION5X_PCIE_IO_BUS_BASE,
- MVEBU_MBUS_PCI_IO);
- mvebu_mbus_add_window_remap_flags(pcie0.0, ORION5X_PCIE_MEM_PHYS_BASE,
- ORION5X_PCIE_MEM_SIZE,
- MVEBU_MBUS_NO_REMAP,
- MVEBU_MBUS_PCI_MEM);
- mvebu_mbus_add_window_remap_flags(pci0.0, ORION5X_PCI_IO_PHYS_BASE,
+ ORION5X_PCIE_IO_BUS_BASE);
+ mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
+ ORION_MBUS_PCIE_MEM_ATTR,
+ ORION5X_PCIE_MEM_PHYS_BASE,
+ ORION5X_PCIE_MEM_SIZE);
+ mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
+ ORION_MBUS_PCI_IO_ATTR,
+ ORION5X_PCI_IO_PHYS_BASE,
ORION5X_PCI_IO_SIZE,
- ORION5X_PCI_IO_BUS_BASE,
- MVEBU_MBUS_PCI_IO);
- mvebu_mbus_add_window_remap_flags(pci0.0, ORION5X_PCI_MEM_PHYS_BASE,
- ORION5X_PCI_MEM_SIZE,
- MVEBU_MBUS_NO_REMAP,
- MVEBU_MBUS_PCI_MEM);
+ ORION5X_PCI_IO_BUS_BASE);
+ mvebu_mbus_add_window_by_id(ORION_MBUS_PCI_MEM_TARGET,
+ ORION_MBUS_PCI_MEM_ATTR,
+ ORION5X_PCI_MEM_PHYS_BASE,
+ ORION5X_PCI_MEM_SIZE);
}
int orion5x_tclk;
diff --git a/arch/arm/mach-orion5x/common.h b/arch/arm/mach-orion5x/common.h
index
[PATCH v7 04/22] ARM: mv78xx0: Move to ID based window creation
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.
This will allow to deprecate the name based API, once every
user is removed.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/mach-mv78xx0/pcie.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-mv78xx0/pcie.c b/arch/arm/mach-mv78xx0/pcie.c
index dc26a65..397afde 100644
--- a/arch/arm/mach-mv78xx0/pcie.c
+++ b/arch/arm/mach-mv78xx0/pcie.c
@@ -18,6 +18,11 @@
#include mach/mv78xx0.h
#include common.h
+#define MV78XX0_MBUS_PCIE_MEM_TARGET(port,lane) ((port) ? 8 : 4)
+#define MV78XX0_MBUS_PCIE_MEM_ATTR(port,lane) (0xf8 ~(0x10 (lane)))
+#define MV78XX0_MBUS_PCIE_IO_TARGET(port,lane) ((port) ? 8 : 4)
+#define MV78XX0_MBUS_PCIE_IO_ATTR(port,lane)(0xf0 ~(0x10 (lane)))
+
struct pcie_port {
u8 maj;
u8 min;
@@ -71,7 +76,6 @@ static void __init mv78xx0_pcie_preinit(void)
start = MV78XX0_PCIE_MEM_PHYS_BASE;
for (i = 0; i num_pcie_ports; i++) {
struct pcie_port *pp = pcie_port + i;
- char winname[MVEBU_MBUS_MAX_WINNAME_SZ];
snprintf(pp-mem_space_name, sizeof(pp-mem_space_name),
PCIe %d.%d MEM, pp-maj, pp-min);
@@ -85,17 +89,12 @@ static void __init mv78xx0_pcie_preinit(void)
if (request_resource(iomem_resource, pp-res))
panic(can't allocate PCIe MEM sub-space);
- snprintf(winname, sizeof(winname), pcie%d.%d,
-pp-maj, pp-min);
-
- mvebu_mbus_add_window_remap_flags(winname,
- pp-res.start,
- resource_size(pp-res),
- MVEBU_MBUS_NO_REMAP,
- MVEBU_MBUS_PCI_MEM);
- mvebu_mbus_add_window_remap_flags(winname,
- i * SZ_64K, SZ_64K,
- 0, MVEBU_MBUS_PCI_IO);
+
mvebu_mbus_add_window_by_id(MV78XX0_MBUS_PCIE_MEM_TARGET(pp-maj, pp-min),
+ MV78XX0_MBUS_PCIE_MEM_ATTR(pp-maj,
pp-min),
+ pp-res.start,
resource_size(pp-res));
+
mvebu_mbus_add_window_remap_by_id(MV78XX0_MBUS_PCIE_IO_TARGET(pp-maj, pp-min),
+
MV78XX0_MBUS_PCIE_IO_ATTR(pp-maj, pp-min),
+ i * SZ_64K, SZ_64K, 0);
}
}
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v7 18/22] ARM: mvebu: Use the preprocessor on Armada 370/XP device tree files
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-db.dts | 2 +-
arch/arm/boot/dts/armada-370-mirabox.dts | 2 +-
arch/arm/boot/dts/armada-370-rd.dts | 2 +-
arch/arm/boot/dts/armada-370.dtsi| 2 +-
arch/arm/boot/dts/armada-xp-db.dts | 2 +-
arch/arm/boot/dts/armada-xp-gp.dts | 2 +-
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 2 +-
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 2 +-
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 2 +-
arch/arm/boot/dts/armada-xp.dtsi | 2 +-
10 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index beee169..55b986c 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -14,7 +14,7 @@
*/
/dts-v1/;
-/include/ armada-370.dtsi
+#include armada-370.dtsi
/ {
model = Marvell Armada 370 Evaluation Board;
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index 45b1077..37530af 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -9,7 +9,7 @@
*/
/dts-v1/;
-/include/ armada-370.dtsi
+#include armada-370.dtsi
/ {
model = Globalscale Mirabox;
diff --git a/arch/arm/boot/dts/armada-370-rd.dts
b/arch/arm/boot/dts/armada-370-rd.dts
index a3a2fed..7aa2171 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -12,7 +12,7 @@
*/
/dts-v1/;
-/include/ armada-370.dtsi
+#include armada-370.dtsi
/ {
model = Marvell Armada 370 Reference Design;
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index fa3dfc6..08ec6e3 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -15,7 +15,7 @@
* common to all Armada SoCs.
*/
-/include/ armada-370-xp.dtsi
+#include armada-370-xp.dtsi
/include/ skeleton.dtsi
/ {
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index e28e68f..a9bd766 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -14,7 +14,7 @@
*/
/dts-v1/;
-/include/ armada-xp-mv78460.dtsi
+#include armada-xp-mv78460.dtsi
/ {
model = Marvell Armada XP Evaluation Board;
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts
b/arch/arm/boot/dts/armada-xp-gp.dts
index c87b2de..54843e5 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -14,7 +14,7 @@
*/
/dts-v1/;
-/include/ armada-xp-mv78460.dtsi
+#include armada-xp-mv78460.dtsi
/ {
model = Marvell Armada XP Development Board DB-MV784MP-GP;
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 2d9335d..985373a 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -13,7 +13,7 @@
* common to all Armada XP SoCs.
*/
-/include/ armada-xp.dtsi
+#include armada-xp.dtsi
/ {
model = Marvell Armada XP MV78260 SoC;
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index c7b1f4d..f8bf25a 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -13,7 +13,7 @@
* common to all Armada XP SoCs.
*/
-/include/ armada-xp.dtsi
+#include armada-xp.dtsi
/ {
model = Marvell Armada XP MV78460 SoC;
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 8f51045..d090264 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -11,7 +11,7 @@
*/
/dts-v1/;
-/include/ armada-xp-mv78260.dtsi
+#include armada-xp-mv78260.dtsi
/ {
model = PlatHome OpenBlocks AX3-4 board;
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 416eb94..8c07bfe 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -16,7 +16,7 @@
* common to all Armada SoCs.
*/
-/include/ armada-370-xp.dtsi
+#include armada-370-xp.dtsi
/ {
model = Marvell Armada XP family SoC;
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v7 09/22] bus: mvebu-mbus: Add static window allocation to the DT binding
This patch adds static window allocation to the device tree binding.
Each first-child of the mbus-compatible node, with a suitable 'ranges'
property, declaring an address translation, will trigger an address
decoding window allocation.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
.../devicetree/bindings/bus/mvebu-mbus.txt | 253 +
drivers/bus/mvebu-mbus.c | 121 +-
2 files changed, 373 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/bus/mvebu-mbus.txt
diff --git a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
new file mode 100644
index 000..cce863f
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
@@ -0,0 +1,253 @@
+
+* Marvell MBus
+
+Required properties:
+
+- compatible: Should be set to one of the following:
+marvell,armada370-mbus
+marvell,armadaxp-mbus
+
+- address-cells: Must be '2'. The first cell for the MBus ID encoding,
+ the second cell for the address offset within the window.
+
+- size-cells:Must be '1'.
+
+- ranges:Must be set up to provide a proper translation for each child.
+See the examples below.
+
+- controller:Contains a single phandle referring to the MBus controller
+ node. This allows to specify the node that contains the
+registers that control the MBus, which is typically contained
+within the internal register window (see below).
+
+* Marvell MBus controller
+
+Required properties:
+
+- compatible: Should be set to marvell,mbus-controller.
+
+- reg: Device's register space.
+ Two entries are expected (see the examples below):
+ the first one controls the devices decoding window and
+ the second one controls the SDRAM decoding window.
+
+Example:
+
+ soc {
+ compatible = marvell,armada370-mbus, simple-bus;
+ #address-cells = 2;
+ #size-cells = 1;
+ controller = mbusc;
+
+ internal-regs {
+ compatible = simple-bus;
+
+ mbusc: mbus-controller@2 {
+ compatible = marvell,mbus-controller;
+ reg = 0x2 0x100, 0x20180 0x20;
+ };
+
+ /* more children ...*/
+ };
+ };
+
+** MBus address decoding window specification
+
+The MBus children address space is comprised of two cells: the first one for
+the window ID and the second one for the offset within the window.
+In order to allow to describe valid and non-valid window entries, the
+following encoding is used:
+
+ 0xSIAA 0x00oo
+
+Where:
+
+ S = 0x0 for a MBus valid window
+ S = 0xf for a non-valid window (see below)
+
+If S = 0x0, then:
+
+ I = 4-bit window target ID
+ AA = windpw attribute
+
+If S = 0xf, then:
+
+ I = don't care
+ AA = 1 for internal register
+
+Following the above encoding, for each ranges entry for a MBus valid window
+(S = 0x0), an address decoding window is allocated. On the other side,
+entries for translation that do not correspond to valid windows (S = 0xf)
+are skipped.
+
+ soc {
+ compatible = marvell,armada370-mbus, simple-bus;
+ #address-cells = 2;
+ #size-cells = 1;
+ controller = mbusc;
+
+ ranges = 0xf001 0 0 0xd000 0x10
+ 0x01e0 0 0 0xfff0 0x10;
+
+ bootrom {
+ compatible = marvell,bootrom;
+ reg = 0x01e0 0 0x10;
+ };
+
+ /* other children */
+ ...
+
+ internal-regs {
+ compatible = simple-bus;
+ ranges = 0 0xf001 0 0x10;
+
+ mbusc: mbus-controller@2 {
+ compatible = marvell,mbus-controller;
+ reg = 0x2 0x100, 0x20180 0x20;
+ };
+
+ /* more children ...*/
+ };
+ };
+
+In the shown example, the translation entry in the 'ranges' property is what
+makes the MBus driver create a static decoding window for the corresponding
+given child device. Note that the binding does not require child nodes to be
+present. Of course, child nodes are needed to probe the devices.
+
+Since each window is identified by its target ID and attribute ID there's
+a special macro that can be use to simplify the translation entries:
+
+#define MBUS_ID(target,attributes) (((target) 24) | ((attributes) 16))
+
+Using this macro, the above example would be:
+
+ soc {
+ compatible = marvell,armada370-mbus, simple-bus
[PATCH v7 12/22] bus: mvebu-mbus: Remove the no longer used name-based API
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
Now that every user of the deprecated name-based API has been
converted to using the ID-based API, let's remove the former one.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
drivers/bus/mvebu-mbus.c | 38 --
include/linux/mbus.h | 5 -
2 files changed, 43 deletions(-)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 5f0bfa3..9aee344 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -766,44 +766,6 @@ int mvebu_mbus_add_window_remap_by_id(unsigned int target,
return mvebu_mbus_alloc_window(s, base, size, remap, target, attribute);
}
-int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
- size_t size, phys_addr_t remap,
- unsigned int flags)
-{
- struct mvebu_mbus_state *s = mbus_state;
- u8 target, attr;
- int i;
-
- if (!s-soc-map)
- return -ENODEV;
-
- for (i = 0; s-soc-map[i].name; i++)
- if (!strcmp(s-soc-map[i].name, devname))
- break;
-
- if (!s-soc-map[i].name) {
- pr_err(unknown device '%s'\n, devname);
- return -ENODEV;
- }
-
- target = s-soc-map[i].target;
- attr = s-soc-map[i].attr;
-
- if (flags == MVEBU_MBUS_PCI_MEM)
- attr |= 0x8;
- else if (flags == MVEBU_MBUS_PCI_WA)
- attr |= 0x28;
-
- return mvebu_mbus_add_window_remap_by_id(target, attr, base,
-size, remap);
-}
-
-int mvebu_mbus_add_window(const char *devname, phys_addr_t base, size_t size)
-{
- return mvebu_mbus_add_window_remap_flags(devname, base, size,
-MVEBU_MBUS_NO_REMAP, 0);
-}
-
int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
phys_addr_t base, size_t size)
{
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index 650bc15..345b8c5 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -63,15 +63,10 @@ static inline const struct mbus_dram_target_info
*mv_mbus_dram_info(void)
void mvebu_mbus_get_pcie_mem_aperture(struct resource *res);
void mvebu_mbus_get_pcie_io_aperture(struct resource *res);
-int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
- size_t size, phys_addr_t remap,
- unsigned int flags);
int mvebu_mbus_add_window_remap_by_id(unsigned int target,
unsigned int attribute,
phys_addr_t base, size_t size,
phys_addr_t remap);
-int mvebu_mbus_add_window(const char *devname, phys_addr_t base,
- size_t size);
int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
phys_addr_t base, size_t size);
int mvebu_mbus_del_window(phys_addr_t base, size_t size);
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v7 07/22] bus: mvebu-mbus: Factor out initialization details
We introduce a common initialization function mvebu_mbus_common_init()
that will be used by both legacy and device-tree initialization code.
This patch is an intermediate step, which will allow to introduce the
DT binding for this driver in a less intrusive way.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/bus/mvebu-mbus.c | 47 ++-
1 file changed, 30 insertions(+), 17 deletions(-)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 827468a..1b17954 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -847,26 +847,14 @@ static __init int mvebu_mbus_debugfs_init(void)
}
fs_initcall(mvebu_mbus_debugfs_init);
-int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
- size_t mbuswins_size,
- phys_addr_t sdramwins_phys_base,
- size_t sdramwins_size)
+static int __init mvebu_mbus_common_init(struct mvebu_mbus_state *mbus,
+phys_addr_t mbuswins_phys_base,
+size_t mbuswins_size,
+phys_addr_t sdramwins_phys_base,
+size_t sdramwins_size)
{
- struct mvebu_mbus_state *mbus = mbus_state;
- const struct of_device_id *of_id;
int win;
- for (of_id = of_mvebu_mbus_ids; of_id-compatible; of_id++)
- if (!strcmp(of_id-compatible, soc))
- break;
-
- if (!of_id-compatible) {
- pr_err(could not find a matching SoC family\n);
- return -ENODEV;
- }
-
- mbus-soc = of_id-data;
-
mbus-mbuswins_base = ioremap(mbuswins_phys_base, mbuswins_size);
if (!mbus-mbuswins_base)
return -ENOMEM;
@@ -887,3 +875,28 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t
mbuswins_phys_base,
return 0;
}
+
+int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
+ size_t mbuswins_size,
+ phys_addr_t sdramwins_phys_base,
+ size_t sdramwins_size)
+{
+ const struct of_device_id *of_id;
+
+ for (of_id = of_mvebu_mbus_ids; of_id-compatible; of_id++)
+ if (!strcmp(of_id-compatible, soc))
+ break;
+
+ if (!of_id-compatible) {
+ pr_err(could not find a matching SoC family\n);
+ return -ENODEV;
+ }
+
+ mbus_state.soc = of_id-data;
+
+ return mvebu_mbus_common_init(mbus_state,
+ mbuswins_phys_base,
+ mbuswins_size,
+ sdramwins_phys_base,
+ sdramwins_size);
+}
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v7 17/22] ARM: mvebu: Initialize MBus using the DT binding
Now that the mbus device tree binding has been introduced, we can
switch over to it.
Also, and since the initialization of the mbus driver is quite
fundamental for the system to work properly, this patch adds a BUG()
in case mbus fails to initialize.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-mvebu/armada-370-xp.c | 34 +-
1 file changed, 1 insertion(+), 33 deletions(-)
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c
b/arch/arm/mach-mvebu/armada-370-xp.c
index 97cbb80..829b573 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -34,44 +34,12 @@ static void __init armada_370_xp_map_io(void)
debug_ll_io_init();
}
-/*
- * This initialization will be replaced by a DT-based
- * initialization once the mvebu-mbus driver gains DT support.
- */
-
-#define ARMADA_370_XP_MBUS_WINS_OFFS 0x2
-#define ARMADA_370_XP_MBUS_WINS_SIZE 0x100
-#define ARMADA_370_XP_SDRAM_WINS_OFFS 0x20180
-#define ARMADA_370_XP_SDRAM_WINS_SIZE 0x20
-
-static void __init armada_370_xp_mbus_init(void)
-{
- char *mbus_soc_name;
- struct device_node *dn;
- const __be32 mbus_wins_offs = cpu_to_be32(ARMADA_370_XP_MBUS_WINS_OFFS);
- const __be32 sdram_wins_offs =
cpu_to_be32(ARMADA_370_XP_SDRAM_WINS_OFFS);
-
- if (of_machine_is_compatible(marvell,armada370))
- mbus_soc_name = marvell,armada370-mbus;
- else
- mbus_soc_name = marvell,armadaxp-mbus;
-
- dn = of_find_node_by_name(NULL, internal-regs);
- BUG_ON(!dn);
-
- mvebu_mbus_init(mbus_soc_name,
- of_translate_address(dn, mbus_wins_offs),
- ARMADA_370_XP_MBUS_WINS_SIZE,
- of_translate_address(dn, sdram_wins_offs),
- ARMADA_370_XP_SDRAM_WINS_SIZE);
-}
-
static void __init armada_370_xp_timer_and_clk_init(void)
{
of_clk_init(NULL);
armada_370_xp_timer_init();
coherency_init();
- armada_370_xp_mbus_init();
+ BUG_ON(mvebu_mbus_dt_init());
#ifdef CONFIG_CACHE_L2X0
l2x0_of_init(0, ~0UL);
#endif
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v7 15/22] bus: mvebu-mbus: Factorize Armada 370/XP data structures
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
These structures were only different in the mapping tables.
Now that those tables have been removed, it doesn't make any sense
to keep different structures.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
drivers/bus/mvebu-mbus.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index f6e9192..d0a61ce 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -536,15 +536,7 @@ mvebu_mbus_dove_setup_cpu_target(struct mvebu_mbus_state
*mbus)
mvebu_mbus_dram_info.num_cs = cs;
}
-static const struct mvebu_mbus_soc_data armada_370_mbus_data = {
- .num_wins= 20,
- .num_remappable_wins = 8,
- .win_cfg_offset = armada_370_xp_mbus_win_offset,
- .setup_cpu_target= mvebu_mbus_default_setup_cpu_target,
- .show_cpu_target = mvebu_sdram_debug_show_orion,
-};
-
-static const struct mvebu_mbus_soc_data armada_xp_mbus_data = {
+static const struct mvebu_mbus_soc_data armada_370_xp_mbus_data = {
.num_wins= 20,
.num_remappable_wins = 8,
.win_cfg_offset = armada_370_xp_mbus_win_offset,
@@ -604,9 +596,9 @@ static const struct mvebu_mbus_soc_data mv78xx0_mbus_data =
{
*/
static const struct of_device_id of_mvebu_mbus_ids[] = {
{ .compatible = marvell,armada370-mbus,
- .data = armada_370_mbus_data, },
+ .data = armada_370_xp_mbus_data, },
{ .compatible = marvell,armadaxp-mbus,
- .data = armada_xp_mbus_data, },
+ .data = armada_370_xp_mbus_data, },
{ .compatible = marvell,kirkwood-mbus,
.data = kirkwood_mbus_data, },
{ .compatible = marvell,dove-mbus,
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v7 02/22] bus: mvebu-mbus: Add new API for window creation
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
We add an API to create MBus address decoding windows from the target
ID and attribute. This function will be used later and deprecate the
current name based scheme.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
drivers/bus/mvebu-mbus.c | 33 +
include/linux/mbus.h | 6 ++
2 files changed, 31 insertions(+), 8 deletions(-)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 33c6947..827468a 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -748,6 +748,22 @@ static const struct of_device_id of_mvebu_mbus_ids[] = {
/*
* Public API of the driver
*/
+int mvebu_mbus_add_window_remap_by_id(unsigned int target,
+ unsigned int attribute,
+ phys_addr_t base, size_t size,
+ phys_addr_t remap)
+{
+ struct mvebu_mbus_state *s = mbus_state;
+
+ if (!mvebu_mbus_window_conflicts(s, base, size, target, attribute)) {
+ pr_err(cannot add window '%x:%x', conflicts with another
window\n,
+ target, attribute);
+ return -EINVAL;
+ }
+
+ return mvebu_mbus_alloc_window(s, base, size, remap, target, attribute);
+}
+
int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
size_t size, phys_addr_t remap,
unsigned int flags)
@@ -776,14 +792,8 @@ int mvebu_mbus_add_window_remap_flags(const char *devname,
phys_addr_t base,
else if (flags == MVEBU_MBUS_PCI_WA)
attr |= 0x28;
- if (!mvebu_mbus_window_conflicts(s, base, size, target, attr)) {
- pr_err(cannot add window '%s', conflicts with another
window\n,
- devname);
- return -EINVAL;
- }
-
- return mvebu_mbus_alloc_window(s, base, size, remap, target, attr);
-
+ return mvebu_mbus_add_window_remap_by_id(target, attr, base,
+size, remap);
}
int mvebu_mbus_add_window(const char *devname, phys_addr_t base, size_t size)
@@ -792,6 +802,13 @@ int mvebu_mbus_add_window(const char *devname, phys_addr_t
base, size_t size)
MVEBU_MBUS_NO_REMAP, 0);
}
+int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
+ phys_addr_t base, size_t size)
+{
+ return mvebu_mbus_add_window_remap_by_id(target, attribute, base,
+size, MVEBU_MBUS_NO_REMAP);
+}
+
int mvebu_mbus_del_window(phys_addr_t base, size_t size)
{
int win;
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index dba482e..9245b66 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -62,8 +62,14 @@ static inline const struct mbus_dram_target_info
*mv_mbus_dram_info(void)
int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
size_t size, phys_addr_t remap,
unsigned int flags);
+int mvebu_mbus_add_window_remap_by_id(unsigned int target,
+ unsigned int attribute,
+ phys_addr_t base, size_t size,
+ phys_addr_t remap);
int mvebu_mbus_add_window(const char *devname, phys_addr_t base,
size_t size);
+int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
+ phys_addr_t base, size_t size);
int mvebu_mbus_del_window(phys_addr_t base, size_t size);
int mvebu_mbus_init(const char *soc, phys_addr_t mbus_phys_base,
size_t mbus_size, phys_addr_t sdram_phys_base,
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 11/22] PCI: mvebu: Adapt to the new device tree layout
On Tue, Jul 09, 2013 at 12:50:47PM -0600, Bjorn Helgaas wrote: On Tue, Jul 9, 2013 at 12:20 PM, Jason Cooper ja...@lakedaemon.net wrote: On Tue, Jul 09, 2013 at 01:41:13PM -0300, Ezequiel Garcia wrote: From: Thomas Petazzoni thomas.petazz...@free-electrons.com The new device tree layout encodes the window's target ID and attribute in the PCIe controller node's ranges property. This allows to parse such entries to obtain such information and use the recently introduced MBus API to create the windows, instead of using the current name based scheme. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com --- .../devicetree/bindings/pci/mvebu-pci.txt | 145 - drivers/pci/host/pci-mvebu.c | 113 +++- 2 files changed, 193 insertions(+), 65 deletions(-) After my conversation with tglx a few days ago [1], I'm even more inclined to push patches like this to the correct maintainers. However, looking at how this patch fits into the series, it may be better if we take it through mvebu/arm-soc with your Ack. It depends on the patches before it, and the patches after it depend on it. Unless I'm reading this wrong, I would have a branch that you would pull and base this patch on, which I would then pull and base the rest of the series on. Reshuffling the series to alleviate this wouldn't work in this case. :-/ Are you ok with that? (fwiw, the code changes are isolated to pci-mvebu.c) Yep, that makes sense to me. With dependencies both ways, it just seems much simpler to have you push it via mvebu/arm-soc. Acked-by: Bjorn Helgaas bhelg...@google.com Great, Thanks! Arnd, Jason (Gunthorpe): So, how does this look? If there isn't anything left, would you mind acking this so Jason (Cooper) can queue it somewhere? Thanks! -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 00/21] MBus DT binding: PCIe strikes back
On Mon, Jul 08, 2013 at 10:42:25AM -0600, Jason Gunthorpe wrote: On Sat, Jul 06, 2013 at 01:38:35AM +0200, Arnd Bergmann wrote: On Saturday 06 July 2013, Thomas Petazzoni wrote: Arnd, Jason, if you could confirm that you both agree with this DT binding soon, Ezequiel and I would quickly adapt the code accordingly, and hopefully converge towards a final patch set. Looks all good from what I can tell. It also looks fine to me. Ok, great. I'll see if I can rework it and submit something today. So, as far as I can tell, that would be v7 and would be ready for inclusion. Thanks a lot! -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v6 00/21] MBus DT binding: PCIe strikes back
See the previous version of this patchset for further context:
http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg35753.html
This new proposal is an attempt to address some issues raised about the PCIe
'fake' windows mapping present in the previous version.
Instead of defining a 'fake' MBUS_ID(0xf0, 0x02) region for the whole
PCIe memory and IO space, we use real target ID and attribute for the windows.
See the example below, where a somewhat complete device tree extract is shown:
soc {
compatible = marvell,armadaxp-mbus, simple-bus;
controller = mbusc;
ranges = MBUS_ID(0xf0, 0x01) 0 0 0xd000 0x10 /*
internal-regs */
MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10
MBUS_ID(0x01, 0x2f) 0 0 0xf000 0x800;
bootrom {
compatible = marvell,bootrom;
reg = MBUS_ID(0x01, 0x1d) 0 0x10;
};
devbus-bootcs {
status = okay;
ranges = 0 MBUS_ID(0x01, 0x2f) 0 0x800;
/* NOR */
nor {
compatible = cfi-flash;
reg = 0 0x800;
bank-width = 2;
};
};
pcie-controller {
compatible = marvell,armada-xp-pcie;
status = okay;
device_type = pci;
#address-cells = 3;
#size-cells = 2;
ranges =
0x8200 0 0x4 MBUS_ID(0xf0, 0x01)
0x4 0 0x2000 /* Port 0.0 registers */
0x8200 0 0x42000 MBUS_ID(0xf0, 0x01)
0x42000 0 0x2000 /* Port 2.0 registers */
0x8200 0 0x44000 MBUS_ID(0xf0, 0x01)
0x44000 0 0x2000 /* Port 0.1 registers */
0x8200 0 0x48000 MBUS_ID(0xf0, 0x01)
0x48000 0 0x2000 /* Port 0.2 registers */
0x8200 0 0x4c000 MBUS_ID(0xf0, 0x01)
0x4c000 0 0x2000 /* Port 0.3 registers */
0x82000800 0 0xe000 MBUS_ID(0x04, 0xe8)
0xe000 0 0x0800 /* Port 0.0 MEM */
0x81000800 0 0 MBUS_ID(0x04, 0xe0)
0xe800 0 0x0010 /* Port 0.0 IO */;
pcie@1,0 {
/* Port 0, Lane 0 */
status = okay;
};
};
internal-regs {
compatible = simple-bus;
#address-cells = 1;
#size-cells = 1;
ranges = 0 MBUS_ID(0xf0, 0x01) 0 0x10;
mbusc: mbus-controller@2 {
reg = 0x2 0x100, 0x20180 0x20;
};
interrupt-controller@2 {
reg = 0x20a00 0x2d0, 0x21070 0x58;
};
};
};
With this new approach there's no mbus-node ranges translation for the 'fake'
window that maps the PCIe regions. Such a translation was actually wrong
in the sense that the windows are allocated dynamically and hence the mappings
need to be created dynamically.
As the target ID and attribute is now encoded in the device tree, it's
now possible to remove the name-based window allocation scheme, replacing
it by a new one based in the IDs only.
This makes the MBus DT binding much consistent, as now both the statically
and dynamically allocated decoding window are defined in the same way.
I'd like to see this binding accepted more or less soon, so if the current
proposal is not accepted it'll be great to hear some hints on how to move
forward.
This series applies on top of today's linux-next. I will rebase it on v3.11-rc1
as soon as that's available.
Thanks a lot!
Ezequiel Garcia (11):
memory: mvebu-devbus: Remove address decoding window workaround
bus: mvebu-mbus: Factor out initialization details
bus: mvebu-mbus: Introduce device tree binding
bus: mvebu-mbus: Add static window allocation to the DT binding
ARM: mvebu: Remove the harcoded BootROM window allocation
ARM: mvebu: Initialize MBus using the DT binding
ARM: mvebu: Use the preprocessor on Armada 370/XP device tree files
ARM: mvebu: Add MBus to Armada 370/XP device tree
ARM: mvebu: Add BootROM to Armada 370/XP device tree
ARM: mvebu: Relocate Armada 370/XP DeviceBus device tree nodes
ARM: mvebu: Relocate Armada 370/XP PCIe device tree nodes
Thomas Petazzoni (10):
bus: mvebu-mbus: Add new API for window creation
ARM: kirkwood: Move to ID based MBus window creation
ARM
[PATCH v6 03/21] ARM: kirkwood: Move to ID based MBus window creation
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.
This will allow to deprecate the name based API, once every
user is removed.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/mach-kirkwood/common.c | 18 ++
arch/arm/mach-kirkwood/pcie.c | 40
2 files changed, 38 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-kirkwood/common.c
index e9238b5..165e751 100644
--- a/arch/arm/mach-kirkwood/common.c
+++ b/arch/arm/mach-kirkwood/common.c
@@ -37,6 +37,12 @@
#include linux/platform_data/dma-mv_xor.h
#include common.h
+/* These can go away once Kirkwood uses the mvebu-mbus DT binding */
+#define KIRKWOOD_MBUS_NAND_TARGET 0x01
+#define KIRKWOOD_MBUS_NAND_ATTR 0x2f
+#define KIRKWOOD_MBUS_SRAM_TARGET 0x03
+#define KIRKWOOD_MBUS_SRAM_ATTR 0x01
+
/*
* I/O Address Mapping
/
@@ -672,10 +678,14 @@ char * __init kirkwood_id(void)
void __init kirkwood_setup_wins(void)
{
- mvebu_mbus_add_window(nand, KIRKWOOD_NAND_MEM_PHYS_BASE,
- KIRKWOOD_NAND_MEM_SIZE);
- mvebu_mbus_add_window(sram, KIRKWOOD_SRAM_PHYS_BASE,
- KIRKWOOD_SRAM_SIZE);
+ mvebu_mbus_add_window_by_id(KIRKWOOD_MBUS_NAND_TARGET,
+ KIRKWOOD_MBUS_NAND_ATTR,
+ KIRKWOOD_NAND_MEM_PHYS_BASE,
+ KIRKWOOD_NAND_MEM_SIZE);
+ mvebu_mbus_add_window_by_id(KIRKWOOD_MBUS_SRAM_TARGET,
+ KIRKWOOD_MBUS_SRAM_ATTR,
+ KIRKWOOD_SRAM_PHYS_BASE,
+ KIRKWOOD_SRAM_SIZE);
}
void __init kirkwood_l2_init(void)
diff --git a/arch/arm/mach-kirkwood/pcie.c b/arch/arm/mach-kirkwood/pcie.c
index ddcb09f..12d86f3 100644
--- a/arch/arm/mach-kirkwood/pcie.c
+++ b/arch/arm/mach-kirkwood/pcie.c
@@ -20,6 +20,16 @@
#include mach/bridge-regs.h
#include common.h
+/* These can go away once Kirkwood uses the mvebu-mbus DT binding */
+#define KIRKWOOD_MBUS_PCIE0_MEM_TARGET0x4
+#define KIRKWOOD_MBUS_PCIE0_MEM_ATTR 0xe8
+#define KIRKWOOD_MBUS_PCIE0_IO_TARGET 0x4
+#define KIRKWOOD_MBUS_PCIE0_IO_ATTR 0xe0
+#define KIRKWOOD_MBUS_PCIE1_MEM_TARGET0x4
+#define KIRKWOOD_MBUS_PCIE1_MEM_ATTR 0xd8
+#define KIRKWOOD_MBUS_PCIE1_IO_TARGET 0x4
+#define KIRKWOOD_MBUS_PCIE1_IO_ATTR 0xd0
+
static void kirkwood_enable_pcie_clk(const char *port)
{
struct clk *clk;
@@ -254,26 +264,24 @@ static void __init add_pcie_port(int index, void __iomem
*base)
void __init kirkwood_pcie_init(unsigned int portmask)
{
- mvebu_mbus_add_window_remap_flags(pcie0.0,
+ mvebu_mbus_add_window_remap_by_id(KIRKWOOD_MBUS_PCIE0_IO_TARGET,
+ KIRKWOOD_MBUS_PCIE0_IO_ATTR,
KIRKWOOD_PCIE_IO_PHYS_BASE,
KIRKWOOD_PCIE_IO_SIZE,
- KIRKWOOD_PCIE_IO_BUS_BASE,
- MVEBU_MBUS_PCI_IO);
- mvebu_mbus_add_window_remap_flags(pcie0.0,
- KIRKWOOD_PCIE_MEM_PHYS_BASE,
- KIRKWOOD_PCIE_MEM_SIZE,
- MVEBU_MBUS_NO_REMAP,
- MVEBU_MBUS_PCI_MEM);
- mvebu_mbus_add_window_remap_flags(pcie1.0,
+ KIRKWOOD_PCIE_IO_BUS_BASE);
+ mvebu_mbus_add_window_by_id(KIRKWOOD_MBUS_PCIE0_MEM_TARGET,
+ KIRKWOOD_MBUS_PCIE0_MEM_ATTR,
+ KIRKWOOD_PCIE_MEM_PHYS_BASE,
+ KIRKWOOD_PCIE_MEM_SIZE);
+ mvebu_mbus_add_window_remap_by_id(KIRKWOOD_MBUS_PCIE1_IO_TARGET,
+ KIRKWOOD_MBUS_PCIE1_IO_ATTR,
KIRKWOOD_PCIE1_IO_PHYS_BASE,
KIRKWOOD_PCIE1_IO_SIZE,
- KIRKWOOD_PCIE1_IO_BUS_BASE,
- MVEBU_MBUS_PCI_IO);
- mvebu_mbus_add_window_remap_flags(pcie1.0,
- KIRKWOOD_PCIE1_MEM_PHYS_BASE,
- KIRKWOOD_PCIE1_MEM_SIZE,
- MVEBU_MBUS_NO_REMAP,
- MVEBU_MBUS_PCI_MEM);
+ KIRKWOOD_PCIE1_IO_BUS_BASE);
+
[PATCH v6 02/21] bus: mvebu-mbus: Add new API for window creation
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
We add an API to create MBus address decoding windows from the target
ID and attribute. This function will be used later and deprecate the
current name based scheme.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
drivers/bus/mvebu-mbus.c | 33 +
include/linux/mbus.h | 6 ++
2 files changed, 31 insertions(+), 8 deletions(-)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 33c6947..827468a 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -748,6 +748,22 @@ static const struct of_device_id of_mvebu_mbus_ids[] = {
/*
* Public API of the driver
*/
+int mvebu_mbus_add_window_remap_by_id(unsigned int target,
+ unsigned int attribute,
+ phys_addr_t base, size_t size,
+ phys_addr_t remap)
+{
+ struct mvebu_mbus_state *s = mbus_state;
+
+ if (!mvebu_mbus_window_conflicts(s, base, size, target, attribute)) {
+ pr_err(cannot add window '%x:%x', conflicts with another
window\n,
+ target, attribute);
+ return -EINVAL;
+ }
+
+ return mvebu_mbus_alloc_window(s, base, size, remap, target, attribute);
+}
+
int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
size_t size, phys_addr_t remap,
unsigned int flags)
@@ -776,14 +792,8 @@ int mvebu_mbus_add_window_remap_flags(const char *devname,
phys_addr_t base,
else if (flags == MVEBU_MBUS_PCI_WA)
attr |= 0x28;
- if (!mvebu_mbus_window_conflicts(s, base, size, target, attr)) {
- pr_err(cannot add window '%s', conflicts with another
window\n,
- devname);
- return -EINVAL;
- }
-
- return mvebu_mbus_alloc_window(s, base, size, remap, target, attr);
-
+ return mvebu_mbus_add_window_remap_by_id(target, attr, base,
+size, remap);
}
int mvebu_mbus_add_window(const char *devname, phys_addr_t base, size_t size)
@@ -792,6 +802,13 @@ int mvebu_mbus_add_window(const char *devname, phys_addr_t
base, size_t size)
MVEBU_MBUS_NO_REMAP, 0);
}
+int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
+ phys_addr_t base, size_t size)
+{
+ return mvebu_mbus_add_window_remap_by_id(target, attribute, base,
+size, MVEBU_MBUS_NO_REMAP);
+}
+
int mvebu_mbus_del_window(phys_addr_t base, size_t size)
{
int win;
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index dba482e..9245b66 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -62,8 +62,14 @@ static inline const struct mbus_dram_target_info
*mv_mbus_dram_info(void)
int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
size_t size, phys_addr_t remap,
unsigned int flags);
+int mvebu_mbus_add_window_remap_by_id(unsigned int target,
+ unsigned int attribute,
+ phys_addr_t base, size_t size,
+ phys_addr_t remap);
int mvebu_mbus_add_window(const char *devname, phys_addr_t base,
size_t size);
+int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
+ phys_addr_t base, size_t size);
int mvebu_mbus_del_window(phys_addr_t base, size_t size);
int mvebu_mbus_init(const char *soc, phys_addr_t mbus_phys_base,
size_t mbus_size, phys_addr_t sdram_phys_base,
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v6 01/21] memory: mvebu-devbus: Remove address decoding window workaround
Now that mbus device tree binding has been introduced, remove the address
decoding window management from this driver.
A suitable 'ranges' entry should be added to the devbus-compatible node in
the device tree, as described by the mbus binding documentation.
Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/memory/mvebu-devbus.c | 64 ++-
1 file changed, 2 insertions(+), 62 deletions(-)
diff --git a/drivers/memory/mvebu-devbus.c b/drivers/memory/mvebu-devbus.c
index 978e8e3..94c9248 100644
--- a/drivers/memory/mvebu-devbus.c
+++ b/drivers/memory/mvebu-devbus.c
@@ -208,16 +208,11 @@ static int mvebu_devbus_probe(struct platform_device
*pdev)
{
struct device *dev = pdev-dev;
struct device_node *node = pdev-dev.of_node;
- struct device_node *parent;
struct devbus *devbus;
struct resource *res;
struct clk *clk;
unsigned long rate;
- const __be32 *ranges;
- int err, cs;
- int addr_cells, p_addr_cells, size_cells;
- int ranges_len, tuple_len;
- u32 base, size;
+ int err;
devbus = devm_kzalloc(pdev-dev, sizeof(struct devbus), GFP_KERNEL);
if (!devbus)
@@ -248,68 +243,13 @@ static int mvebu_devbus_probe(struct platform_device
*pdev)
return err;
/*
-* Allocate an address window for this device.
-* If the device probing fails, then we won't be able to
-* remove the allocated address decoding window.
-*
-* FIXME: This is only a temporary hack! We need to do this here
-* because we still don't have device tree bindings for mbus.
-* Once that support is added, we will declare these address windows
-* statically in the device tree, and remove the window configuration
-* from here.
-*/
-
- /*
-* Get the CS to choose the window string.
-* This is a bit hacky, but it will be removed once the
-* address windows are declared in the device tree.
-*/
- cs = (((unsigned long)devbus-base) % 0x400) / 8;
-
- /*
-* Parse 'ranges' property to obtain a (base,size) window tuple.
-* This will be removed once the address windows
-* are declared in the device tree.
-*/
- parent = of_get_parent(node);
- if (!parent)
- return -EINVAL;
-
- p_addr_cells = of_n_addr_cells(parent);
- of_node_put(parent);
-
- addr_cells = of_n_addr_cells(node);
- size_cells = of_n_size_cells(node);
- tuple_len = (p_addr_cells + addr_cells + size_cells) * sizeof(__be32);
-
- ranges = of_get_property(node, ranges, ranges_len);
- if (ranges == NULL || ranges_len != tuple_len)
- return -EINVAL;
-
- base = of_translate_address(node, ranges + addr_cells);
- if (base == OF_BAD_ADDR)
- return -EINVAL;
- size = of_read_number(ranges + addr_cells + p_addr_cells, size_cells);
-
- /*
-* Create an mbus address windows.
-* FIXME: Remove this, together with the above code, once the
-* address windows are declared in the device tree.
-*/
- err = mvebu_mbus_add_window(devbus_wins[cs], base, size);
- if (err 0)
- return err;
-
- /*
* We need to create a child device explicitly from here to
* guarantee that the child will be probed after the timing
* parameters for the bus are written.
*/
err = of_platform_populate(node, NULL, NULL, dev);
- if (err 0) {
- mvebu_mbus_del_window(base, size);
+ if (err 0)
return err;
- }
return 0;
}
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v6 04/21] ARM: mv78xx0: Move to ID based window creation
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.
This will allow to deprecate the name based API, once every
user is removed.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/mach-mv78xx0/pcie.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-mv78xx0/pcie.c b/arch/arm/mach-mv78xx0/pcie.c
index dc26a65..397afde 100644
--- a/arch/arm/mach-mv78xx0/pcie.c
+++ b/arch/arm/mach-mv78xx0/pcie.c
@@ -18,6 +18,11 @@
#include mach/mv78xx0.h
#include common.h
+#define MV78XX0_MBUS_PCIE_MEM_TARGET(port, lane) ((port) ? 8 : 4)
+#define MV78XX0_MBUS_PCIE_MEM_ATTR(port, lane) (0xf8 ~(0x10 (lane)))
+#define MV78XX0_MBUS_PCIE_IO_TARGET(port, lane) ((port) ? 8 : 4)
+#define MV78XX0_MBUS_PCIE_IO_ATTR(port, lane)(0xf0 ~(0x10 (lane)))
+
struct pcie_port {
u8 maj;
u8 min;
@@ -71,7 +76,6 @@ static void __init mv78xx0_pcie_preinit(void)
start = MV78XX0_PCIE_MEM_PHYS_BASE;
for (i = 0; i num_pcie_ports; i++) {
struct pcie_port *pp = pcie_port + i;
- char winname[MVEBU_MBUS_MAX_WINNAME_SZ];
snprintf(pp-mem_space_name, sizeof(pp-mem_space_name),
PCIe %d.%d MEM, pp-maj, pp-min);
@@ -85,17 +89,12 @@ static void __init mv78xx0_pcie_preinit(void)
if (request_resource(iomem_resource, pp-res))
panic(can't allocate PCIe MEM sub-space);
- snprintf(winname, sizeof(winname), pcie%d.%d,
-pp-maj, pp-min);
-
- mvebu_mbus_add_window_remap_flags(winname,
- pp-res.start,
- resource_size(pp-res),
- MVEBU_MBUS_NO_REMAP,
- MVEBU_MBUS_PCI_MEM);
- mvebu_mbus_add_window_remap_flags(winname,
- i * SZ_64K, SZ_64K,
- 0, MVEBU_MBUS_PCI_IO);
+
mvebu_mbus_add_window_by_id(MV78XX0_MBUS_PCIE_MEM_TARGET(pp-maj, pp-min),
+ MV78XX0_MBUS_PCIE_MEM_ATTR(pp-maj,
pp-min),
+ pp-res.start,
resource_size(pp-res));
+
mvebu_mbus_add_window_remap_by_id(MV78XX0_MBUS_PCIE_IO_TARGET(pp-maj, pp-min),
+
MV78XX0_MBUS_PCIE_IO_ATTR(pp-maj, pp-min),
+ i * SZ_64K, SZ_64K, 0);
}
}
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v6 05/21] ARM: orion5x: Move to ID based window creation
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.
This will allow to deprecate the name based API, once every
user is removed.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/mach-orion5x/common.c | 36 ++
arch/arm/mach-orion5x/common.h | 17
arch/arm/mach-orion5x/d2net-setup.c| 6 +++--
arch/arm/mach-orion5x/db88f5281-setup.c| 24 +++--
arch/arm/mach-orion5x/dns323-setup.c | 6 +++--
arch/arm/mach-orion5x/edmini_v2-setup.c| 6 +++--
arch/arm/mach-orion5x/kurobox_pro-setup.c | 12 ++---
arch/arm/mach-orion5x/ls-chl-setup.c | 6 +++--
arch/arm/mach-orion5x/ls_hgl-setup.c | 6 +++--
arch/arm/mach-orion5x/lsmini-setup.c | 6 +++--
arch/arm/mach-orion5x/mss2-setup.c | 6 +++--
arch/arm/mach-orion5x/mv2120-setup.c | 6 +++--
arch/arm/mach-orion5x/net2big-setup.c | 6 +++--
arch/arm/mach-orion5x/pci.c| 9 +++
arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c | 6 +++--
arch/arm/mach-orion5x/rd88f5181l-ge-setup.c| 6 +++--
arch/arm/mach-orion5x/rd88f5182-setup.c| 13 ++
arch/arm/mach-orion5x/terastation_pro2-setup.c | 6 +++--
arch/arm/mach-orion5x/ts209-setup.c| 6 +++--
arch/arm/mach-orion5x/ts409-setup.c| 6 +++--
arch/arm/mach-orion5x/wnr854t-setup.c | 6 +++--
arch/arm/mach-orion5x/wrt350n-v2-setup.c | 6 +++--
22 files changed, 137 insertions(+), 70 deletions(-)
diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
index b41599f..91a5852 100644
--- a/arch/arm/mach-orion5x/common.c
+++ b/arch/arm/mach-orion5x/common.c
@@ -174,8 +174,10 @@ void __init orion5x_xor_init(void)
/
static void __init orion5x_crypto_init(void)
{
- mvebu_mbus_add_window(sram, ORION5X_SRAM_PHYS_BASE,
- ORION5X_SRAM_SIZE);
+ mvebu_mbus_add_window_by_id(ORION_MBUS_SRAM_TARGET,
+ ORION_MBUS_SRAM_ATTR,
+ ORION5X_SRAM_PHYS_BASE,
+ ORION5X_SRAM_SIZE);
orion_crypto_init(ORION5X_CRYPTO_PHYS_BASE, ORION5X_SRAM_PHYS_BASE,
SZ_8K, IRQ_ORION5X_CESA);
}
@@ -222,22 +224,24 @@ void orion5x_setup_wins(void)
* The PCIe windows will no longer be statically allocated
* here once Orion5x is migrated to the pci-mvebu driver.
*/
- mvebu_mbus_add_window_remap_flags(pcie0.0, ORION5X_PCIE_IO_PHYS_BASE,
+ mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
+ ORION_MBUS_PCIE_IO_ATTR,
+ ORION5X_PCIE_IO_PHYS_BASE,
ORION5X_PCIE_IO_SIZE,
- ORION5X_PCIE_IO_BUS_BASE,
- MVEBU_MBUS_PCI_IO);
- mvebu_mbus_add_window_remap_flags(pcie0.0, ORION5X_PCIE_MEM_PHYS_BASE,
- ORION5X_PCIE_MEM_SIZE,
- MVEBU_MBUS_NO_REMAP,
- MVEBU_MBUS_PCI_MEM);
- mvebu_mbus_add_window_remap_flags(pci0.0, ORION5X_PCI_IO_PHYS_BASE,
+ ORION5X_PCIE_IO_BUS_BASE);
+ mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
+ ORION_MBUS_PCIE_MEM_ATTR,
+ ORION5X_PCIE_MEM_PHYS_BASE,
+ ORION5X_PCIE_MEM_SIZE);
+ mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
+ ORION_MBUS_PCI_IO_ATTR,
+ ORION5X_PCI_IO_PHYS_BASE,
ORION5X_PCI_IO_SIZE,
- ORION5X_PCI_IO_BUS_BASE,
- MVEBU_MBUS_PCI_IO);
- mvebu_mbus_add_window_remap_flags(pci0.0, ORION5X_PCI_MEM_PHYS_BASE,
- ORION5X_PCI_MEM_SIZE,
- MVEBU_MBUS_NO_REMAP,
- MVEBU_MBUS_PCI_MEM);
+ ORION5X_PCI_IO_BUS_BASE);
+ mvebu_mbus_add_window_by_id(ORION_MBUS_PCI_MEM_TARGET,
+ ORION_MBUS_PCI_MEM_ATTR,
+ ORION5X_PCI_MEM_PHYS_BASE,
+ ORION5X_PCI_MEM_SIZE);
}
int orion5x_tclk;
diff --git a/arch/arm/mach-orion5x/common.h b/arch/arm/mach-orion5x/common.h
index
[PATCH v6 06/21] ARM: dove: Move to ID based window creation
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.
This will allow to deprecate the name based API, once every
user is removed.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/mach-dove/common.c | 68 ++---
1 file changed, 45 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-dove/common.c b/arch/arm/mach-dove/common.c
index 00247c7..bc22056 100644
--- a/arch/arm/mach-dove/common.c
+++ b/arch/arm/mach-dove/common.c
@@ -27,6 +27,22 @@
#include plat/time.h
#include common.h
+/* These can go away once Dove uses the mvebu-mbus DT binding */
+#define DOVE_MBUS_PCIE0_MEM_TARGET0x4
+#define DOVE_MBUS_PCIE0_MEM_ATTR 0xe8
+#define DOVE_MBUS_PCIE0_IO_TARGET 0x4
+#define DOVE_MBUS_PCIE0_IO_ATTR 0xe0
+#define DOVE_MBUS_PCIE1_MEM_TARGET0x8
+#define DOVE_MBUS_PCIE1_MEM_ATTR 0xe8
+#define DOVE_MBUS_PCIE1_IO_TARGET 0x8
+#define DOVE_MBUS_PCIE1_IO_ATTR 0xe0
+#define DOVE_MBUS_CESA_TARGET 0x3
+#define DOVE_MBUS_CESA_ATTR 0x1
+#define DOVE_MBUS_BOOTROM_TARGET 0x1
+#define DOVE_MBUS_BOOTROM_ATTR0xfd
+#define DOVE_MBUS_SCRATCHPAD_TARGET 0xd
+#define DOVE_MBUS_SCRATCHPAD_ATTR 0x0
+
/*
* I/O Address Mapping
/
@@ -332,34 +348,40 @@ void __init dove_setup_cpu_wins(void)
{
/*
* The PCIe windows will no longer be statically allocated
-* here once Dove is migrated to the pci-mvebu driver.
+* here once Dove is migrated to the pci-mvebu driver. The
+* non-PCIe windows will no longer be created here once Dove
+* fully moves to DT.
*/
- mvebu_mbus_add_window_remap_flags(pcie0.0,
+ mvebu_mbus_add_window_remap_by_id(DOVE_MBUS_PCIE0_IO_TARGET,
+ DOVE_MBUS_PCIE0_IO_ATTR,
DOVE_PCIE0_IO_PHYS_BASE,
DOVE_PCIE0_IO_SIZE,
- DOVE_PCIE0_IO_BUS_BASE,
- MVEBU_MBUS_PCI_IO);
- mvebu_mbus_add_window_remap_flags(pcie1.0,
+ DOVE_PCIE0_IO_BUS_BASE);
+ mvebu_mbus_add_window_remap_by_id(DOVE_MBUS_PCIE1_IO_TARGET,
+ DOVE_MBUS_PCIE1_IO_ATTR,
DOVE_PCIE1_IO_PHYS_BASE,
DOVE_PCIE1_IO_SIZE,
- DOVE_PCIE1_IO_BUS_BASE,
- MVEBU_MBUS_PCI_IO);
- mvebu_mbus_add_window_remap_flags(pcie0.0,
- DOVE_PCIE0_MEM_PHYS_BASE,
- DOVE_PCIE0_MEM_SIZE,
- MVEBU_MBUS_NO_REMAP,
- MVEBU_MBUS_PCI_MEM);
- mvebu_mbus_add_window_remap_flags(pcie1.0,
- DOVE_PCIE1_MEM_PHYS_BASE,
- DOVE_PCIE1_MEM_SIZE,
- MVEBU_MBUS_NO_REMAP,
- MVEBU_MBUS_PCI_MEM);
- mvebu_mbus_add_window(cesa, DOVE_CESA_PHYS_BASE,
- DOVE_CESA_SIZE);
- mvebu_mbus_add_window(bootrom, DOVE_BOOTROM_PHYS_BASE,
- DOVE_BOOTROM_SIZE);
- mvebu_mbus_add_window(scratchpad, DOVE_SCRATCHPAD_PHYS_BASE,
- DOVE_SCRATCHPAD_SIZE);
+ DOVE_PCIE1_IO_BUS_BASE);
+ mvebu_mbus_add_window_by_id(DOVE_MBUS_PCIE0_MEM_TARGET,
+ DOVE_MBUS_PCIE0_MEM_ATTR,
+ DOVE_PCIE0_MEM_PHYS_BASE,
+ DOVE_PCIE0_MEM_SIZE);
+ mvebu_mbus_add_window_by_id(DOVE_MBUS_PCIE1_MEM_TARGET,
+ DOVE_MBUS_PCIE1_MEM_ATTR,
+ DOVE_PCIE1_MEM_PHYS_BASE,
+ DOVE_PCIE1_MEM_SIZE);
+ mvebu_mbus_add_window_by_id(DOVE_MBUS_CESA_TARGET,
+ DOVE_MBUS_CESA_ATTR,
+ DOVE_CESA_PHYS_BASE,
+ DOVE_CESA_SIZE);
+ mvebu_mbus_add_window_by_id(DOVE_MBUS_BOOTROM_TARGET,
+ DOVE_MBUS_BOOTROM_ATTR,
+ DOVE_BOOTROM_PHYS_BASE,
+ DOVE_BOOTROM_SIZE);
+ mvebu_mbus_add_window_by_id(DOVE_MBUS_SCRATCHPAD_TARGET,
+ DOVE_MBUS_SCRATCHPAD_ATTR,
[PATCH v6 08/21] bus: mvebu-mbus: Introduce device tree binding
This patch adds the most fundamental device-tree initialization.
We only introduce what's required to be able to probe the mvebu-mbus
driver from the DT. Follow-up patches will extend the device tree binding,
allowing to describe static address decoding windows.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/bus/mvebu-mbus.c | 49
include/linux/mbus.h | 1 +
2 files changed, 50 insertions(+)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 1b17954..44a07c4 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -900,3 +900,52 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t
mbuswins_phys_base,
sdramwins_phys_base,
sdramwins_size);
}
+
+#ifdef CONFIG_OF
+int __init mvebu_mbus_dt_init(void)
+{
+ struct resource mbuswins_res, sdramwins_res;
+ struct device_node *np, *controller;
+ const struct of_device_id *of_id;
+ const __be32 *prop;
+ int ret;
+
+ np = of_find_matching_node(NULL, of_mvebu_mbus_ids);
+ if (!np) {
+ pr_err(could not find a matching SoC family\n);
+ return -ENODEV;
+ }
+
+ of_id = of_match_node(of_mvebu_mbus_ids, np);
+ mbus_state.soc = of_id-data;
+
+ prop = of_get_property(np, controller, NULL);
+ if (!prop) {
+ pr_err(required 'controller' property missing\n);
+ return -EINVAL;
+ }
+
+ controller = of_find_node_by_phandle(be32_to_cpup(prop));
+ if (!controller) {
+ pr_err(could not find an 'mbus-controller' node\n);
+ return -ENODEV;
+ }
+
+ if (of_address_to_resource(controller, 0, mbuswins_res)) {
+ pr_err(cannot get MBUS register address\n);
+ return -EINVAL;
+ }
+
+ if (of_address_to_resource(controller, 1, sdramwins_res)) {
+ pr_err(cannot get SDRAM register address\n);
+ return -EINVAL;
+ }
+
+ ret = mvebu_mbus_common_init(mbus_state,
+mbuswins_res.start,
+resource_size(mbuswins_res),
+sdramwins_res.start,
+resource_size(sdramwins_res));
+ return ret;
+}
+#endif
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index 9245b66..eadefd6 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -74,5 +74,6 @@ int mvebu_mbus_del_window(phys_addr_t base, size_t size);
int mvebu_mbus_init(const char *soc, phys_addr_t mbus_phys_base,
size_t mbus_size, phys_addr_t sdram_phys_base,
size_t sdram_size);
+int mvebu_mbus_dt_init(void);
#endif /* __LINUX_MBUS_H */
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v6 07/21] bus: mvebu-mbus: Factor out initialization details
We introduce a common initialization function mvebu_mbus_common_init()
that will be used by both legacy and device-tree initialization code.
This patch is an intermediate step, which will allow to introduce the
DT binding for this driver in a less intrusive way.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/bus/mvebu-mbus.c | 47 ++-
1 file changed, 30 insertions(+), 17 deletions(-)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 827468a..1b17954 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -847,26 +847,14 @@ static __init int mvebu_mbus_debugfs_init(void)
}
fs_initcall(mvebu_mbus_debugfs_init);
-int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
- size_t mbuswins_size,
- phys_addr_t sdramwins_phys_base,
- size_t sdramwins_size)
+static int __init mvebu_mbus_common_init(struct mvebu_mbus_state *mbus,
+phys_addr_t mbuswins_phys_base,
+size_t mbuswins_size,
+phys_addr_t sdramwins_phys_base,
+size_t sdramwins_size)
{
- struct mvebu_mbus_state *mbus = mbus_state;
- const struct of_device_id *of_id;
int win;
- for (of_id = of_mvebu_mbus_ids; of_id-compatible; of_id++)
- if (!strcmp(of_id-compatible, soc))
- break;
-
- if (!of_id-compatible) {
- pr_err(could not find a matching SoC family\n);
- return -ENODEV;
- }
-
- mbus-soc = of_id-data;
-
mbus-mbuswins_base = ioremap(mbuswins_phys_base, mbuswins_size);
if (!mbus-mbuswins_base)
return -ENOMEM;
@@ -887,3 +875,28 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t
mbuswins_phys_base,
return 0;
}
+
+int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
+ size_t mbuswins_size,
+ phys_addr_t sdramwins_phys_base,
+ size_t sdramwins_size)
+{
+ const struct of_device_id *of_id;
+
+ for (of_id = of_mvebu_mbus_ids; of_id-compatible; of_id++)
+ if (!strcmp(of_id-compatible, soc))
+ break;
+
+ if (!of_id-compatible) {
+ pr_err(could not find a matching SoC family\n);
+ return -ENODEV;
+ }
+
+ mbus_state.soc = of_id-data;
+
+ return mvebu_mbus_common_init(mbus_state,
+ mbuswins_phys_base,
+ mbuswins_size,
+ sdramwins_phys_base,
+ sdramwins_size);
+}
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v6 09/21] bus: mvebu-mbus: Add static window allocation to the binding
This patch adds static window allocation to the device tree binding.
Each first-child of the mbus-compatible node, with a suitable 'ranges'
property, declaring an address translation, will trigger an address
decoding window allocation.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
.../devicetree/bindings/bus/mvebu-mbus.txt | 253 +
drivers/bus/mvebu-mbus.c | 121 +-
2 files changed, 373 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/bus/mvebu-mbus.txt
diff --git a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
new file mode 100644
index 000..cce863f
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
@@ -0,0 +1,253 @@
+
+* Marvell MBus
+
+Required properties:
+
+- compatible: Should be set to one of the following:
+marvell,armada370-mbus
+marvell,armadaxp-mbus
+
+- address-cells: Must be '2'. The first cell for the MBus ID encoding,
+ the second cell for the address offset within the window.
+
+- size-cells:Must be '1'.
+
+- ranges:Must be set up to provide a proper translation for each child.
+See the examples below.
+
+- controller:Contains a single phandle referring to the MBus controller
+ node. This allows to specify the node that contains the
+registers that control the MBus, which is typically contained
+within the internal register window (see below).
+
+* Marvell MBus controller
+
+Required properties:
+
+- compatible: Should be set to marvell,mbus-controller.
+
+- reg: Device's register space.
+ Two entries are expected (see the examples below):
+ the first one controls the devices decoding window and
+ the second one controls the SDRAM decoding window.
+
+Example:
+
+ soc {
+ compatible = marvell,armada370-mbus, simple-bus;
+ #address-cells = 2;
+ #size-cells = 1;
+ controller = mbusc;
+
+ internal-regs {
+ compatible = simple-bus;
+
+ mbusc: mbus-controller@2 {
+ compatible = marvell,mbus-controller;
+ reg = 0x2 0x100, 0x20180 0x20;
+ };
+
+ /* more children ...*/
+ };
+ };
+
+** MBus address decoding window specification
+
+The MBus children address space is comprised of two cells: the first one for
+the window ID and the second one for the offset within the window.
+In order to allow to describe valid and non-valid window entries, the
+following encoding is used:
+
+ 0xSIAA 0x00oo
+
+Where:
+
+ S = 0x0 for a MBus valid window
+ S = 0xf for a non-valid window (see below)
+
+If S = 0x0, then:
+
+ I = 4-bit window target ID
+ AA = windpw attribute
+
+If S = 0xf, then:
+
+ I = don't care
+ AA = 1 for internal register
+
+Following the above encoding, for each ranges entry for a MBus valid window
+(S = 0x0), an address decoding window is allocated. On the other side,
+entries for translation that do not correspond to valid windows (S = 0xf)
+are skipped.
+
+ soc {
+ compatible = marvell,armada370-mbus, simple-bus;
+ #address-cells = 2;
+ #size-cells = 1;
+ controller = mbusc;
+
+ ranges = 0xf001 0 0 0xd000 0x10
+ 0x01e0 0 0 0xfff0 0x10;
+
+ bootrom {
+ compatible = marvell,bootrom;
+ reg = 0x01e0 0 0x10;
+ };
+
+ /* other children */
+ ...
+
+ internal-regs {
+ compatible = simple-bus;
+ ranges = 0 0xf001 0 0x10;
+
+ mbusc: mbus-controller@2 {
+ compatible = marvell,mbus-controller;
+ reg = 0x2 0x100, 0x20180 0x20;
+ };
+
+ /* more children ...*/
+ };
+ };
+
+In the shown example, the translation entry in the 'ranges' property is what
+makes the MBus driver create a static decoding window for the corresponding
+given child device. Note that the binding does not require child nodes to be
+present. Of course, child nodes are needed to probe the devices.
+
+Since each window is identified by its target ID and attribute ID there's
+a special macro that can be use to simplify the translation entries:
+
+#define MBUS_ID(target,attributes) (((target) 24) | ((attributes) 16))
+
+Using this macro, the above example would be:
+
+ soc {
+ compatible = marvell,armada370-mbus, simple-bus
[PATCH v6 11/21] bus: mvebu-mbus: Remove the no longer used name-based API
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
Now that every user of the deprecated name-based API has been
converted to using the ID-based API, let's remove the former one.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
drivers/bus/mvebu-mbus.c | 38 --
include/linux/mbus.h | 5 -
2 files changed, 43 deletions(-)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 8aa3b45..db68436 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -764,44 +764,6 @@ int mvebu_mbus_add_window_remap_by_id(unsigned int target,
return mvebu_mbus_alloc_window(s, base, size, remap, target, attribute);
}
-int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
- size_t size, phys_addr_t remap,
- unsigned int flags)
-{
- struct mvebu_mbus_state *s = mbus_state;
- u8 target, attr;
- int i;
-
- if (!s-soc-map)
- return -ENODEV;
-
- for (i = 0; s-soc-map[i].name; i++)
- if (!strcmp(s-soc-map[i].name, devname))
- break;
-
- if (!s-soc-map[i].name) {
- pr_err(unknown device '%s'\n, devname);
- return -ENODEV;
- }
-
- target = s-soc-map[i].target;
- attr = s-soc-map[i].attr;
-
- if (flags == MVEBU_MBUS_PCI_MEM)
- attr |= 0x8;
- else if (flags == MVEBU_MBUS_PCI_WA)
- attr |= 0x28;
-
- return mvebu_mbus_add_window_remap_by_id(target, attr, base,
-size, remap);
-}
-
-int mvebu_mbus_add_window(const char *devname, phys_addr_t base, size_t size)
-{
- return mvebu_mbus_add_window_remap_flags(devname, base, size,
-MVEBU_MBUS_NO_REMAP, 0);
-}
-
int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
phys_addr_t base, size_t size)
{
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index eadefd6..fa84dcb 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -59,15 +59,10 @@ static inline const struct mbus_dram_target_info
*mv_mbus_dram_info(void)
}
#endif
-int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
- size_t size, phys_addr_t remap,
- unsigned int flags);
int mvebu_mbus_add_window_remap_by_id(unsigned int target,
unsigned int attribute,
phys_addr_t base, size_t size,
phys_addr_t remap);
-int mvebu_mbus_add_window(const char *devname, phys_addr_t base,
- size_t size);
int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
phys_addr_t base, size_t size);
int mvebu_mbus_del_window(phys_addr_t base, size_t size);
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v6 10/21] pci: mvebu: Adapt to the new device tree layout
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
The new device tree layout encodes the window's target ID and attribute
in the PCIe controller node's ranges property. This allows to parse
such entries to obtain such information and use the recently introduced
MBus API to create the windows, instead of using the current name based
scheme.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
drivers/pci/host/pci-mvebu.c | 152 ++-
1 file changed, 120 insertions(+), 32 deletions(-)
diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index 13a633b..a146f44 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -123,6 +123,10 @@ struct mvebu_pcie_port {
u32 port;
u32 lane;
int devfn;
+ unsigned int mem_target;
+ unsigned int mem_attr;
+ unsigned int io_target;
+ unsigned int io_attr;
struct clk *clk;
struct mvebu_sw_pci_bridge bridge;
struct device_node *dn;
@@ -307,10 +311,9 @@ static void mvebu_pcie_handle_iobase_change(struct
mvebu_pcie_port *port)
(port-bridge.iolimitupper 16)) -
iobase);
- mvebu_mbus_add_window_remap_flags(port-name, port-iowin_base,
- port-iowin_size,
- iobase,
- MVEBU_MBUS_PCI_IO);
+ mvebu_mbus_add_window_remap_by_id(port-io_target, port-io_attr,
+ port-iowin_base, port-iowin_size,
+ iobase);
pci_ioremap_io(iobase, port-iowin_base);
}
@@ -342,10 +345,8 @@ static void mvebu_pcie_handle_membase_change(struct
mvebu_pcie_port *port)
(((port-bridge.memlimit 0xFFF0) 16) | 0xF) -
port-memwin_base;
- mvebu_mbus_add_window_remap_flags(port-name, port-memwin_base,
- port-memwin_size,
- MVEBU_MBUS_NO_REMAP,
- MVEBU_MBUS_PCI_MEM);
+ mvebu_mbus_add_window_by_id(port-mem_target, port-mem_attr,
+ port-memwin_base, port-memwin_size);
}
/*
@@ -755,12 +756,104 @@ mvebu_pcie_map_registers(struct platform_device *pdev,
return devm_request_and_ioremap(pdev-dev, regs);
}
+#define DT_FLAGS_TO_TYPE(flags) (((flags) 24) 0x03)
+#defineDT_TYPE_IO 0x1
+#defineDT_TYPE_MEM32 0x2
+#define DT_FLAGS_TO_DEVFN(flags) (((flags) 8) 0xFF)
+#define DT_CPUADDR_TO_ADDR(cpuaddr) ((cpuaddr) 0x)
+#define DT_CPUADDR_TO_TARGET(cpuaddr) (((cpuaddr) 56) 0xFF)
+#define DT_CPUADDR_TO_ATTR(cpuaddr) (((cpuaddr) 48) 0xFF)
+
+static int mvebu_get_resources(struct device_node *np, struct resource *mem,
+ struct resource *io, struct resource *realio)
+{
+ const int na = 3, ns = 2;
+ const __be32 *range;
+ int rlen, nranges, rangesz, pna, i;
+
+ range = of_get_property(np, ranges, rlen);
+ if (!range)
+ return -EINVAL;
+
+ pna = of_n_addr_cells(np);
+ rangesz = pna + na + ns;
+ nranges = rlen / sizeof(__be32) / rangesz;
+
+ for (i = 0; i nranges; i++) {
+ u32 flags = of_read_number(range, 1);
+ u64 pciaddr = of_read_number(range + 1, ns);
+ u64 cpuaddr = of_read_number(range + na, pna);
+ u64 size= of_read_number(range + na + pna, ns);
+
+ /* I/O */
+ if (DT_FLAGS_TO_TYPE(flags) == DT_TYPE_IO
+ DT_FLAGS_TO_DEVFN(flags) != 0) {
+ io-start = cpuaddr 0x;
+ io-end = io-start + size;
+ io-flags = IORESOURCE_IO;
+ realio-start = max_t(resource_size_t,
+ PCIBIOS_MIN_IO,
+ pciaddr);
+ realio-end = min_t(resource_size_t,
+ IO_SPACE_LIMIT,
+ pciaddr + size);
+ realio-flags = io-flags;
+ }
+ /* MEM */
+ else if (DT_FLAGS_TO_TYPE(flags) == DT_TYPE_MEM32
+DT_FLAGS_TO_DEVFN(flags) != 0) {
+ mem-start = cpuaddr 0x;
+ mem-end = mem-start + size;
+ mem-flags = IORESOURCE_MEM;
+ }
+
+ range += rangesz;
+ }
+
+ return 0;
+}
+
+static int mvebu_get_tgt_attr(struct device_node *np, int devfn,
+ unsigned long type, int *tgt, int *attr)
+{
+ const int na = 3, ns = 2;
+ const __be32
[PATCH v6 16/21] ARM: mvebu: Initialize MBus using the DT binding
Now that the mbus device tree binding has been introduced, we can
switch over to it.
Also, and since the initialization of the mbus driver is quite
fundamental for the system to work properly, this patch adds a BUG()
in case mbus fails to initialize.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-mvebu/armada-370-xp.c | 34 +-
1 file changed, 1 insertion(+), 33 deletions(-)
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c
b/arch/arm/mach-mvebu/armada-370-xp.c
index 97cbb80..829b573 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -34,44 +34,12 @@ static void __init armada_370_xp_map_io(void)
debug_ll_io_init();
}
-/*
- * This initialization will be replaced by a DT-based
- * initialization once the mvebu-mbus driver gains DT support.
- */
-
-#define ARMADA_370_XP_MBUS_WINS_OFFS 0x2
-#define ARMADA_370_XP_MBUS_WINS_SIZE 0x100
-#define ARMADA_370_XP_SDRAM_WINS_OFFS 0x20180
-#define ARMADA_370_XP_SDRAM_WINS_SIZE 0x20
-
-static void __init armada_370_xp_mbus_init(void)
-{
- char *mbus_soc_name;
- struct device_node *dn;
- const __be32 mbus_wins_offs = cpu_to_be32(ARMADA_370_XP_MBUS_WINS_OFFS);
- const __be32 sdram_wins_offs =
cpu_to_be32(ARMADA_370_XP_SDRAM_WINS_OFFS);
-
- if (of_machine_is_compatible(marvell,armada370))
- mbus_soc_name = marvell,armada370-mbus;
- else
- mbus_soc_name = marvell,armadaxp-mbus;
-
- dn = of_find_node_by_name(NULL, internal-regs);
- BUG_ON(!dn);
-
- mvebu_mbus_init(mbus_soc_name,
- of_translate_address(dn, mbus_wins_offs),
- ARMADA_370_XP_MBUS_WINS_SIZE,
- of_translate_address(dn, sdram_wins_offs),
- ARMADA_370_XP_SDRAM_WINS_SIZE);
-}
-
static void __init armada_370_xp_timer_and_clk_init(void)
{
of_clk_init(NULL);
armada_370_xp_timer_init();
coherency_init();
- armada_370_xp_mbus_init();
+ BUG_ON(mvebu_mbus_dt_init());
#ifdef CONFIG_CACHE_L2X0
l2x0_of_init(0, ~0UL);
#endif
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v6 14/21] bus: mvebu-mbus: Factorize Armada 370/XP data structures
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
These structures were only different in the mapping tables.
Now that those tables have been removed, it doesn't make any sense
to keep different structures.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
drivers/bus/mvebu-mbus.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 58d3c8f..0b7f9f7 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -534,15 +534,7 @@ mvebu_mbus_dove_setup_cpu_target(struct mvebu_mbus_state
*mbus)
mvebu_mbus_dram_info.num_cs = cs;
}
-static const struct mvebu_mbus_soc_data armada_370_mbus_data = {
- .num_wins= 20,
- .num_remappable_wins = 8,
- .win_cfg_offset = armada_370_xp_mbus_win_offset,
- .setup_cpu_target= mvebu_mbus_default_setup_cpu_target,
- .show_cpu_target = mvebu_sdram_debug_show_orion,
-};
-
-static const struct mvebu_mbus_soc_data armada_xp_mbus_data = {
+static const struct mvebu_mbus_soc_data armada_370_xp_mbus_data = {
.num_wins= 20,
.num_remappable_wins = 8,
.win_cfg_offset = armada_370_xp_mbus_win_offset,
@@ -602,9 +594,9 @@ static const struct mvebu_mbus_soc_data mv78xx0_mbus_data =
{
*/
static const struct of_device_id of_mvebu_mbus_ids[] = {
{ .compatible = marvell,armada370-mbus,
- .data = armada_370_mbus_data, },
+ .data = armada_370_xp_mbus_data, },
{ .compatible = marvell,armadaxp-mbus,
- .data = armada_xp_mbus_data, },
+ .data = armada_370_xp_mbus_data, },
{ .compatible = marvell,kirkwood-mbus,
.data = kirkwood_mbus_data, },
{ .compatible = marvell,dove-mbus,
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v6 12/21] bus: mvebu-mbus: Remove name - target, attribute mapping tables
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
This tables were used together with the name-based MBus window
creation API. Since that's has been removed, we can also remove
the tables.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
drivers/bus/mvebu-mbus.c | 150 +++
1 file changed, 7 insertions(+), 143 deletions(-)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index db68436..8240bd7 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -97,33 +97,6 @@
#define DOVE_DDR_BASE_CS_OFF(n) ((n) 4)
-struct mvebu_mbus_mapping {
- const char *name;
- u8 target;
- u8 attr;
- u8 attrmask;
-};
-
-/*
- * Masks used for the 'attrmask' field of mvebu_mbus_mapping. They
- * allow to get the real attribute value, discarding the special bits
- * used to select a PCI MEM region or a PCI WA region. This allows the
- * debugfs code to reverse-match the name of a device from its
- * target/attr values.
- *
- * For all devices except PCI, all bits of 'attr' must be
- * considered. For most SoCs, only bit 3 should be ignored (it allows
- * to select between PCI MEM and PCI I/O). On Orion5x however, there
- * is the special bit 5 to select a PCI WA region.
- */
-#define MAPDEF_NOMASK 0xff
-#define MAPDEF_PCIMASK 0xf7
-#define MAPDEF_ORIONPCIMASK 0xd7
-
-/* Macro used to define one mvebu_mbus_mapping entry */
-#define MAPDEF(__n, __t, __a, __m) \
- { .name = __n, .target = __t, .attr = __a, .attrmask = __m }
-
struct mvebu_mbus_state;
struct mvebu_mbus_soc_data {
@@ -133,7 +106,6 @@ struct mvebu_mbus_soc_data {
void (*setup_cpu_target)(struct mvebu_mbus_state *s);
int (*show_cpu_target)(struct mvebu_mbus_state *s,
struct seq_file *seq, void *v);
- const struct mvebu_mbus_mapping *map;
};
struct mvebu_mbus_state {
@@ -428,8 +400,7 @@ static int mvebu_devs_debug_show(struct seq_file *seq, void
*v)
u64 wbase, wremap;
u32 wsize;
u8 wtarget, wattr;
- int enabled, i;
- const char *name;
+ int enabled;
mvebu_mbus_read_window(mbus, win,
enabled, wbase, wsize,
@@ -440,18 +411,9 @@ static int mvebu_devs_debug_show(struct seq_file *seq,
void *v)
continue;
}
-
- for (i = 0; mbus-soc-map[i].name; i++)
- if (mbus-soc-map[i].target == wtarget
- mbus-soc-map[i].attr ==
- (wattr mbus-soc-map[i].attrmask))
- break;
-
- name = mbus-soc-map[i].name ?: unknown;
-
- seq_printf(seq, [%02d] %016llx - %016llx : %s,
+ seq_printf(seq, [%02d] %016llx - %016llx : %04x:%04x\n,
win, (unsigned long long)wbase,
- (unsigned long long)(wbase + wsize), name);
+ (unsigned long long)(wbase + wsize), wtarget, wattr);
if (win mbus-soc-num_remappable_wins) {
seq_printf(seq, (remap %016llx)\n,
@@ -576,45 +538,12 @@ mvebu_mbus_dove_setup_cpu_target(struct mvebu_mbus_state
*mbus)
mvebu_mbus_dram_info.num_cs = cs;
}
-static const struct mvebu_mbus_mapping armada_370_map[] = {
- MAPDEF(bootrom, 1, 0xe0, MAPDEF_NOMASK),
- MAPDEF(devbus-boot, 1, 0x2f, MAPDEF_NOMASK),
- MAPDEF(devbus-cs0, 1, 0x3e, MAPDEF_NOMASK),
- MAPDEF(devbus-cs1, 1, 0x3d, MAPDEF_NOMASK),
- MAPDEF(devbus-cs2, 1, 0x3b, MAPDEF_NOMASK),
- MAPDEF(devbus-cs3, 1, 0x37, MAPDEF_NOMASK),
- MAPDEF(pcie0.0, 4, 0xe0, MAPDEF_PCIMASK),
- MAPDEF(pcie1.0, 8, 0xe0, MAPDEF_PCIMASK),
- {},
-};
-
static const struct mvebu_mbus_soc_data armada_370_mbus_data = {
.num_wins= 20,
.num_remappable_wins = 8,
.win_cfg_offset = armada_370_xp_mbus_win_offset,
.setup_cpu_target= mvebu_mbus_default_setup_cpu_target,
.show_cpu_target = mvebu_sdram_debug_show_orion,
- .map = armada_370_map,
-};
-
-static const struct mvebu_mbus_mapping armada_xp_map[] = {
- MAPDEF(bootrom, 1, 0x1d, MAPDEF_NOMASK),
- MAPDEF(devbus-boot, 1, 0x2f, MAPDEF_NOMASK),
- MAPDEF(devbus-cs0, 1, 0x3e, MAPDEF_NOMASK),
- MAPDEF(devbus-cs1, 1, 0x3d, MAPDEF_NOMASK),
- MAPDEF(devbus-cs2, 1, 0x3b, MAPDEF_NOMASK),
- MAPDEF(devbus-cs3, 1, 0x37, MAPDEF_NOMASK),
- MAPDEF(pcie0.0, 4, 0xe0, MAPDEF_PCIMASK),
- MAPDEF(pcie0.1, 4, 0xd0, MAPDEF_PCIMASK),
- MAPDEF(pcie0.2, 4, 0xb0, MAPDEF_PCIMASK),
- MAPDEF(pcie0.3, 4, 0x70, MAPDEF_PCIMASK),
- MAPDEF(pcie1.0, 8, 0xe0, MAPDEF_PCIMASK),
- MAPDEF(pcie1.1, 8, 0xd0, MAPDEF_PCIMASK),
[PATCH v6 13/21] bus: mvebu-mbus: Update main description
From: Thomas Petazzoni thomas.petazz...@free-electrons.com After replacing the MBus name-based by the new ID-based API let's fix the general description of the driver at the beginning of the file. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com --- drivers/bus/mvebu-mbus.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c index 8240bd7..58d3c8f 100644 --- a/drivers/bus/mvebu-mbus.c +++ b/drivers/bus/mvebu-mbus.c @@ -35,13 +35,9 @@ * * - Provides an API for platform code or device drivers to * dynamically add or remove address decoding windows for the CPU - - * device accesses. This API is mvebu_mbus_add_window(), - * mvebu_mbus_add_window_remap_flags() and - * mvebu_mbus_del_window(). Since the (target, attribute) values - * differ from one SoC family to another, the API uses a 'const char - * *' string to identify devices, and this driver is responsible for - * knowing the mapping between the name of a device and its - * corresponding (target, attribute) in the current SoC family. + * device accesses. This API is mvebu_mbus_add_window_by_id(), + * mvebu_mbus_add_window_remap_by_id() and + * mvebu_mbus_del_window(). * * - Provides a debugfs interface in /sys/kernel/debug/mvebu-mbus/ to * see the list of CPU - SDRAM windows and their configuration -- 1.8.1.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v6 15/21] ARM: mvebu: Remove the harcoded BootROM window allocation
The address decoding window to access the BootROM should not be
allocated programatically, but instead declared in the device tree.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-mvebu/platsmp.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
index ce81d30..7be1ec2 100644
--- a/arch/arm/mach-mvebu/platsmp.c
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -21,6 +21,7 @@
#include linux/smp.h
#include linux/clk.h
#include linux/of.h
+#include linux/of_address.h
#include linux/mbus.h
#include asm/cacheflush.h
#include asm/smp_plat.h
@@ -29,6 +30,9 @@
#include pmsu.h
#include coherency.h
+#define AXP_BOOTROM_BASE 0xfff0
+#define AXP_BOOTROM_SIZE 0x10
+
void __init set_secondary_cpus_clock(void)
{
int thiscpu;
@@ -114,10 +118,29 @@ static void __init armada_xp_smp_init_cpus(void)
void __init armada_xp_smp_prepare_cpus(unsigned int max_cpus)
{
+ struct device_node *node;
+ struct resource res;
+ int err;
+
set_secondary_cpus_clock();
flush_cache_all();
set_cpu_coherent(cpu_logical_map(smp_processor_id()), 0);
- mvebu_mbus_add_window(bootrom, 0xfff0, SZ_1M);
+
+ /*
+* In order to boot the secondary CPUs we need to ensure
+* the bootROM is mapped at the correct address.
+*/
+ node = of_find_compatible_node(NULL, NULL, marvell,bootrom);
+ if (!node)
+ panic(Cannot find 'marvell,bootrom' compatible node);
+
+ err = of_address_to_resource(node, 0, res);
+ if (err 0)
+ panic(Cannot get 'bootrom' node address);
+
+ if (res.start != AXP_BOOTROM_BASE ||
+ resource_size(res) != AXP_BOOTROM_SIZE)
+ panic(The address for the BootROM is incorrect);
}
struct smp_operations armada_xp_smp_ops __initdata = {
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v6 17/21] ARM: mvebu: Use the preprocessor on Armada 370/XP device tree files
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-db.dts | 2 +-
arch/arm/boot/dts/armada-370-mirabox.dts | 2 +-
arch/arm/boot/dts/armada-370-rd.dts | 2 +-
arch/arm/boot/dts/armada-370.dtsi| 2 +-
arch/arm/boot/dts/armada-xp-db.dts | 2 +-
arch/arm/boot/dts/armada-xp-gp.dts | 2 +-
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 2 +-
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 2 +-
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 2 +-
arch/arm/boot/dts/armada-xp.dtsi | 2 +-
10 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index beee169..55b986c 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -14,7 +14,7 @@
*/
/dts-v1/;
-/include/ armada-370.dtsi
+#include armada-370.dtsi
/ {
model = Marvell Armada 370 Evaluation Board;
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index 45b1077..37530af 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -9,7 +9,7 @@
*/
/dts-v1/;
-/include/ armada-370.dtsi
+#include armada-370.dtsi
/ {
model = Globalscale Mirabox;
diff --git a/arch/arm/boot/dts/armada-370-rd.dts
b/arch/arm/boot/dts/armada-370-rd.dts
index a3a2fed..7aa2171 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -12,7 +12,7 @@
*/
/dts-v1/;
-/include/ armada-370.dtsi
+#include armada-370.dtsi
/ {
model = Marvell Armada 370 Reference Design;
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index fa3dfc6..08ec6e3 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -15,7 +15,7 @@
* common to all Armada SoCs.
*/
-/include/ armada-370-xp.dtsi
+#include armada-370-xp.dtsi
/include/ skeleton.dtsi
/ {
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index e28e68f..a9bd766 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -14,7 +14,7 @@
*/
/dts-v1/;
-/include/ armada-xp-mv78460.dtsi
+#include armada-xp-mv78460.dtsi
/ {
model = Marvell Armada XP Evaluation Board;
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts
b/arch/arm/boot/dts/armada-xp-gp.dts
index c87b2de..54843e5 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -14,7 +14,7 @@
*/
/dts-v1/;
-/include/ armada-xp-mv78460.dtsi
+#include armada-xp-mv78460.dtsi
/ {
model = Marvell Armada XP Development Board DB-MV784MP-GP;
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 2d9335d..985373a 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -13,7 +13,7 @@
* common to all Armada XP SoCs.
*/
-/include/ armada-xp.dtsi
+#include armada-xp.dtsi
/ {
model = Marvell Armada XP MV78260 SoC;
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index c7b1f4d..f8bf25a 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -13,7 +13,7 @@
* common to all Armada XP SoCs.
*/
-/include/ armada-xp.dtsi
+#include armada-xp.dtsi
/ {
model = Marvell Armada XP MV78460 SoC;
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 8f51045..d090264 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -11,7 +11,7 @@
*/
/dts-v1/;
-/include/ armada-xp-mv78260.dtsi
+#include armada-xp-mv78260.dtsi
/ {
model = PlatHome OpenBlocks AX3-4 board;
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 416eb94..8c07bfe 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -16,7 +16,7 @@
* common to all Armada SoCs.
*/
-/include/ armada-370-xp.dtsi
+#include armada-370-xp.dtsi
/ {
model = Marvell Armada XP family SoC;
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v6 20/21] ARM: mvebu: Relocate Armada 370/XP DeviceBus device tree nodes
Now that mbus has been added to the device tree, it's possible to
move the DeviceBus out of internal registers, placing it directly
below the mbus. This is a more accurate representation of the hardware.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-xp.dtsi | 94 +---
arch/arm/boot/dts/armada-xp-db.dts | 59 +++
arch/arm/boot/dts/armada-xp-gp.dts | 60 +++
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 65
4 files changed, 140 insertions(+), 138 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 62639b4..073dd20 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -45,6 +45,56 @@
controller = mbusc;
interrupt-parent = mpic;
+ devbus-bootcs {
+ compatible = marvell,mvebu-devbus;
+ reg = MBUS_ID(0xf0, 0x01) 0x10400 0x8;
+ ranges = 0 MBUS_ID(0x01, 0x2f) 0 0x;
+ #address-cells = 1;
+ #size-cells = 1;
+ clocks = coreclk 0;
+ status = disabled;
+ };
+
+ devbus-cs0 {
+ compatible = marvell,mvebu-devbus;
+ reg = MBUS_ID(0xf0, 0x01) 0x10408 0x8;
+ ranges = 0 MBUS_ID(0x01, 0x3e) 0 0x;
+ #address-cells = 1;
+ #size-cells = 1;
+ clocks = coreclk 0;
+ status = disabled;
+ };
+
+ devbus-cs1 {
+ compatible = marvell,mvebu-devbus;
+ reg = MBUS_ID(0xf0, 0x01) 0x10410 0x8;
+ ranges = 0 MBUS_ID(0x01, 0x3d) 0 0x;
+ #address-cells = 1;
+ #size-cells = 1;
+ clocks = coreclk 0;
+ status = disabled;
+ };
+
+ devbus-cs2 {
+ compatible = marvell,mvebu-devbus;
+ reg = MBUS_ID(0xf0, 0x01) 0x10418 0x8;
+ ranges = 0 MBUS_ID(0x01, 0x3b) 0 0x;
+ #address-cells = 1;
+ #size-cells = 1;
+ clocks = coreclk 0;
+ status = disabled;
+ };
+
+ devbus-cs3 {
+ compatible = marvell,mvebu-devbus;
+ reg = MBUS_ID(0xf0, 0x01) 0x10420 0x8;
+ ranges = 0 MBUS_ID(0x01, 0x37) 0 0x;
+ #address-cells = 1;
+ #size-cells = 1;
+ clocks = coreclk 0;
+ status = disabled;
+ };
+
internal-regs {
compatible = simple-bus;
#address-cells = 1;
@@ -200,50 +250,6 @@
status = disabled;
};
- devbus-bootcs@10400 {
- compatible = marvell,mvebu-devbus;
- reg = 0x10400 0x8;
- #address-cells = 1;
- #size-cells = 1;
- clocks = coreclk 0;
- status = disabled;
- };
-
- devbus-cs0@10408 {
- compatible = marvell,mvebu-devbus;
- reg = 0x10408 0x8;
- #address-cells = 1;
- #size-cells = 1;
- clocks = coreclk 0;
- status = disabled;
- };
-
- devbus-cs1@10410 {
- compatible = marvell,mvebu-devbus;
- reg = 0x10410 0x8;
- #address-cells = 1;
- #size-cells = 1;
- clocks = coreclk 0;
- status = disabled;
- };
-
- devbus-cs2@10418 {
- compatible = marvell,mvebu-devbus;
- reg = 0x10418 0x8;
- #address-cells = 1;
- #size-cells = 1;
- clocks = coreclk 0;
- status = disabled;
- };
-
- devbus-cs3@10420 {
- compatible = marvell,mvebu-devbus;
- reg = 0x10420 0x8
[PATCH v6 21/21] ARM: mvebu: Relocate Armada 370/XP PCIe device tree nodes
Now that mbus has been added to the device tree, it's possible to
move the PCIe nodes out of internal registers, placing it directly
below the mbus. This is a more accurate representation of the
hardware.
Moving the PCIe nodes, we now need to introduce an extra cell to
encode the window target ID and attribute. Since this depends on
the PCIe port, we split the ranges translation entries, to correspond
to each MBus window.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-mirabox.dts | 32 +-
arch/arm/boot/dts/armada-370.dtsi| 99 +++---
arch/arm/boot/dts/armada-xp-db.dts | 67 ++--
arch/arm/boot/dts/armada-xp-gp.dts | 42 +--
arch/arm/boot/dts/armada-xp-mv78230.dtsi | 217 +++--
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 256 ---
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 395 ---
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 18 +-
8 files changed, 584 insertions(+), 542 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index 19341d2..2471d9d 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -28,6 +28,22 @@
ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10
MBUS_ID(0x01, 0xe0) 0 0xfff0 0x10;
+ pcie-controller {
+ status = okay;
+
+ /* Internal mini-PCIe connector */
+ pcie@1,0 {
+ /* Port 0, Lane 0 */
+ status = okay;
+ };
+
+ /* Connected on the PCB to a USB 3.0 XHCI controller */
+ pcie@2,0 {
+ /* Port 1, Lane 0 */
+ status = okay;
+ };
+ };
+
internal-regs {
serial@12000 {
clock-frequency = 2;
@@ -123,22 +139,6 @@
reg = 0x25;
};
};
-
- pcie-controller {
- status = okay;
-
- /* Internal mini-PCIe connector */
- pcie@1,0 {
- /* Port 0, Lane 0 */
- status = okay;
- };
-
- /* Connected on the PCB to a USB 3.0 XHCI
controller */
- pcie@2,0 {
- /* Port 1, Lane 0 */
- status = okay;
- };
- };
};
};
};
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index bd21d49..066a79f 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -36,6 +36,57 @@
reg = MBUS_ID(0x01, 0xe0) 0 0x10;
};
+ pcie-controller {
+ compatible = marvell,armada-370-pcie;
+ status = disabled;
+ device_type = pci;
+
+ #address-cells = 3;
+ #size-cells = 2;
+
+ bus-range = 0x00 0xff;
+
+ ranges =
+ 0x8200 0 0x4MBUS_ID(0xf0, 0x01)
0x4 0 0x2000
+ 0x8200 0 0x8MBUS_ID(0xf0, 0x01)
0x8 0 0x2000
+ 0x82000800 0 0xe000 MBUS_ID(0x04, 0xe8)
0xe000 0 0x0800 /* Port 0.0 MEM */
+ 0x81000800 0 0 MBUS_ID(0x04, 0xe0)
0xe800 0 0x0010 /* Port 0.0 IO */
+ 0x82001000 0 0xe000 MBUS_ID(0x08, 0xe8)
0xe000 0 0x0800 /* Port 1.0 MEM */
+ 0x81001000 0 0 MBUS_ID(0x08, 0xe0)
0xe800 0 0x0010 /* Port 1.0 IO */;
+
+ pcie@1,0 {
+ device_type = pci;
+ assigned-addresses = 0x82000800 0 0x4 0
0x2000;
+ reg = 0x0800 0 0 0 0;
+ #address-cells = 3;
+ #size-cells = 2;
+ #interrupt-cells = 1;
+ ranges;
+ interrupt-map-mask = 0 0 0 0;
+ interrupt-map = 0 0 0 0 mpic 58;
+ marvell,pcie-port = 0
[PATCH v6 18/21] ARM: mvebu: Add MBus to Armada 370/XP device tree
The Armada 370/XP SoC family has a completely configurable address
space handled by the MBus controller.
This patch introduces the device tree layout of MBus, making the
'soc' node as mbus-compatible.
Since every peripheral/controller is a child of this 'soc' node,
this makes all of them sit behind the mbus, thus describing the
hardware accurately.
A translation entry has been added for the internal-regs mapping.
This can't be done in the common armada-370-xp.dtsi because A370
and AXP have different addressing width.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-db.dts | 2 ++
arch/arm/boot/dts/armada-370-mirabox.dts | 2 ++
arch/arm/boot/dts/armada-370-rd.dts | 2 ++
arch/arm/boot/dts/armada-370-xp.dtsi | 15 ++-
arch/arm/boot/dts/armada-370.dtsi| 4 ++--
arch/arm/boot/dts/armada-xp-db.dts | 4 +---
arch/arm/boot/dts/armada-xp-gp.dts | 4 +---
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 4 +---
arch/arm/boot/dts/armada-xp.dtsi | 2 ++
9 files changed, 23 insertions(+), 16 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index 55b986c..5920b4e 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,6 +30,8 @@
};
soc {
+ ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10;
+
internal-regs {
serial@12000 {
clock-frequency = 2;
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index 37530af..a4202b6 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,6 +25,8 @@
};
soc {
+ ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10;
+
internal-regs {
serial@12000 {
clock-frequency = 2;
diff --git a/arch/arm/boot/dts/armada-370-rd.dts
b/arch/arm/boot/dts/armada-370-rd.dts
index 7aa2171..dd0ba01 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,6 +28,8 @@
};
soc {
+ ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10;
+
internal-regs {
serial@12000 {
clock-frequency = 2;
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 90b1176..62639b4 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -18,6 +18,8 @@
/include/ skeleton64.dtsi
+#define MBUS_ID(target,attributes) (((target) 24) | ((attributes) 16))
+
/ {
model = Marvell Armada 370 and XP SoC;
compatible = marvell,armada-370-xp;
@@ -38,18 +40,21 @@
};
soc {
- #address-cells = 1;
+ #address-cells = 2;
#size-cells = 1;
- compatible = simple-bus;
+ controller = mbusc;
interrupt-parent = mpic;
- ranges = 0 0 0xd000 0x010 /* internal
registers */
- 0xe000 0 0xe000 0x810 /* PCIe */;
internal-regs {
compatible = simple-bus;
#address-cells = 1;
#size-cells = 1;
- ranges;
+ ranges = 0 MBUS_ID(0xf0, 0x01) 0 0x10;
+
+ mbusc: mbus-controller@2 {
+ compatible = marvell,mbus-controller;
+ reg = 0x2 0x100, 0x20180 0x20;
+ };
mpic: interrupt-controller@2 {
compatible = marvell,mpic;
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index 08ec6e3..4b54e51 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -29,8 +29,8 @@
};
soc {
- ranges = 0 0xd000 0x010 /* internal registers
*/
- 0xe000 0xe000 0x810 /* PCIe */;
+ compatible = marvell,armada370-mbus, simple-bus;
+
internal-regs {
system-controller@18200 {
compatible =
marvell,armada-370-xp-system-controller;
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index a9bd766..0d4ce54 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -30,9 +30,7 @@
};
soc {
- ranges = 0 0 0xd000 0x10 /* Internal
registers 1MiB
[PATCH v6 19/21] ARM: mvebu: Add BootROM to Armada 370/XP device tree
In order to access the SoC BootROM, we need to declare a mapping
(through a ranges property). The mbus driver will use this property
to allocate a suitable address decoding window.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-db.dts | 3 ++-
arch/arm/boot/dts/armada-370-mirabox.dts | 3 ++-
arch/arm/boot/dts/armada-370-rd.dts | 3 ++-
arch/arm/boot/dts/armada-370.dtsi| 5 +
arch/arm/boot/dts/armada-xp-db.dts | 3 ++-
arch/arm/boot/dts/armada-xp-gp.dts | 3 ++-
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 3 ++-
arch/arm/boot/dts/armada-xp.dtsi | 5 +
8 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index 5920b4e..90ce29d 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,7 +30,8 @@
};
soc {
- ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10;
+ ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10
+ MBUS_ID(0x01, 0xe0) 0 0xfff0 0x10;
internal-regs {
serial@12000 {
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index a4202b6..19341d2 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,7 +25,8 @@
};
soc {
- ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10;
+ ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10
+ MBUS_ID(0x01, 0xe0) 0 0xfff0 0x10;
internal-regs {
serial@12000 {
diff --git a/arch/arm/boot/dts/armada-370-rd.dts
b/arch/arm/boot/dts/armada-370-rd.dts
index dd0ba01..0b3acf3 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,7 +28,8 @@
};
soc {
- ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10;
+ ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10
+ MBUS_ID(0x01, 0xe0) 0 0xfff0 0x10;
internal-regs {
serial@12000 {
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index 4b54e51..bd21d49 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -31,6 +31,11 @@
soc {
compatible = marvell,armada370-mbus, simple-bus;
+ bootrom {
+ compatible = marvell,bootrom;
+ reg = MBUS_ID(0x01, 0xe0) 0 0x10;
+ };
+
internal-regs {
system-controller@18200 {
compatible =
marvell,armada-370-xp-system-controller;
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index 0d4ce54..857f272 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -30,7 +30,8 @@
};
soc {
- ranges = MBUS_ID(0xf0, 0x01) 0 0 0xd000 0x10;
+ ranges = MBUS_ID(0xf0, 0x01) 0 0 0xd000 0x10
+ MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10;
internal-regs {
serial@12000 {
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts
b/arch/arm/boot/dts/armada-xp-gp.dts
index 2fa9209..934dc46 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -39,7 +39,8 @@
};
soc {
- ranges = MBUS_ID(0xf0, 0x01) 0 0 0xd000 0x10;
+ ranges = MBUS_ID(0xf0, 0x01) 0 0 0xd000 0x10
+ MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10;
internal-regs {
serial@12000 {
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index a3e3a12..1700f6f 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -27,7 +27,8 @@
};
soc {
- ranges = MBUS_ID(0xf0, 0x01) 0 0 0xd000 0x10;
+ ranges = MBUS_ID(0xf0, 0x01) 0 0 0xd000 0x10
+ MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10;
internal-regs {
serial@12000 {
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 8033824..7ba99ce 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -29,6 +29,11 @@
soc {
compatible = marvell,armadaxp-mbus, simple-bus;
+ bootrom {
+ compatible = marvell,bootrom
[PATCH v5 00/12] MBus DT binding: A new hope
See the previous version of this patchset for further context: http://www.spinics.net/lists/arm-kernel/msg253342.html This is a new proposal, in an attempt to fix some obscurities in the previous MBus DT binding proposal. In the current proposal we have now required a 'controller' property to specify the MBus controller MMIO registers. To us this looks more appropriate, since the MBus registers are effectively located within the internal register region, behind the so-called internal-regs window. Personally, I can't see any disadvantage, and the binding looks much cleaner now. But of course I can be wrong, and I'm open to discussion. There's another pending issue. Arnd Bergmann has required to add a property to specify the available space within the CPU address space for decoding windows. This property would allow to support fully dynamic mbus window allocation. For now, this property is intentionally missing, and I expect that it can be added in the future, together with the full-dynamic MBus implementation. @Arnd, @Jason: Given the v4 patchset didn't receive any comments but wasn't accepted either, I'd like to know which other pending issues I'm forgetting to address. As usual, comments and feedback more than welcome. Thanks! Ezequiel Garcia (12): bus: mvebu-mbus: Factor out initialization details bus: mvebu-mbus: Introduce device tree binding bus: mvebu-mbus: Add static window allocation to the DT binding ARM: mvebu: Initialize MBus using the DT binding ARM: mvebu: Remove the harcoded BootROM window allocation memory: mvebu-devbus: Remove address decoding window workaround ARM: mvebu: Use the preprocessor on Armada 370/XP device tree files ARM: mvebu: Add MBus to Armada 370/XP device tree ARM: mvebu: Add BootROM to Armada 370/XP device tree ARM: mvebu: Relocate Armada 370/XP DeviceBus device tree nodes ARM: mvebu: Relocate Armada 370 PCIe device tree nodes ARM: mvebu: Relocate Armada XP PCIe device tree nodes .../devicetree/bindings/bus/mvebu-mbus.txt | 256 ++ arch/arm/boot/dts/armada-370-db.dts| 5 +- arch/arm/boot/dts/armada-370-mirabox.dts | 38 ++- arch/arm/boot/dts/armada-370-rd.dts| 5 +- arch/arm/boot/dts/armada-370-xp.dtsi | 109 +++--- arch/arm/boot/dts/armada-370.dtsi | 108 +++--- arch/arm/boot/dts/armada-xp-db.dts | 72 ++-- arch/arm/boot/dts/armada-xp-gp.dts | 108 +++--- arch/arm/boot/dts/armada-xp-mv78230.dtsi | 209 ++-- arch/arm/boot/dts/armada-xp-mv78260.dtsi | 247 +++--- arch/arm/boot/dts/armada-xp-mv78460.dtsi | 379 +++-- arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 84 ++--- arch/arm/boot/dts/armada-xp.dtsi | 9 +- arch/arm/mach-mvebu/armada-370-xp.c| 34 +- arch/arm/mach-mvebu/platsmp.c | 25 +- drivers/bus/mvebu-mbus.c | 209 +++- drivers/memory/mvebu-devbus.c | 64 +--- include/linux/mbus.h | 1 + 18 files changed, 1186 insertions(+), 776 deletions(-) create mode 100644 Documentation/devicetree/bindings/bus/mvebu-mbus.txt -- 1.8.1.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v5 02/12] bus: mvebu-mbus: Introduce device tree binding
This patch adds the most fundamental device-tree initialization.
We only introduce what's required to be able to probe the mvebu-mbus
driver from the DT. Follow-up patches will extend the device tree binding,
allowing to describe static address decoding windows.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/bus/mvebu-mbus.c | 49
include/linux/mbus.h | 1 +
2 files changed, 50 insertions(+)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index d0feee5..1f8b5c8 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -883,3 +883,52 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t
mbuswins_phys_base,
sdramwins_phys_base,
sdramwins_size);
}
+
+#ifdef CONFIG_OF
+int __init mvebu_mbus_dt_init(void)
+{
+ struct resource mbuswins_res, sdramwins_res;
+ struct device_node *np, *controller;
+ const struct of_device_id *of_id;
+ const __be32 *prop;
+ int ret;
+
+ np = of_find_matching_node(NULL, of_mvebu_mbus_ids);
+ if (!np) {
+ pr_err(could not find a matching SoC family\n);
+ return -ENODEV;
+ }
+
+ of_id = of_match_node(of_mvebu_mbus_ids, np);
+ mbus_state.soc = of_id-data;
+
+ prop = of_get_property(np, controller, NULL);
+ if (!prop) {
+ pr_err(required 'controller' property missing\n);
+ return -EINVAL;
+ }
+
+ controller = of_find_node_by_phandle(be32_to_cpup(prop));
+ if (!controller) {
+ pr_err(could not find an 'mbus-controller' node\n);
+ return -ENODEV;
+ }
+
+ if (of_address_to_resource(controller, 0, mbuswins_res)) {
+ pr_err(cannot get MBUS register address\n);
+ return -EINVAL;
+ }
+
+ if (of_address_to_resource(controller, 1, sdramwins_res)) {
+ pr_err(cannot get SDRAM register address\n);
+ return -EINVAL;
+ }
+
+ ret = mvebu_mbus_common_init(mbus_state,
+mbuswins_res.start,
+resource_size(mbuswins_res),
+sdramwins_res.start,
+resource_size(sdramwins_res));
+ return ret;
+}
+#endif
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index dba482e..a93c62b 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -68,5 +68,6 @@ int mvebu_mbus_del_window(phys_addr_t base, size_t size);
int mvebu_mbus_init(const char *soc, phys_addr_t mbus_phys_base,
size_t mbus_size, phys_addr_t sdram_phys_base,
size_t sdram_size);
+int mvebu_mbus_dt_init(void);
#endif /* __LINUX_MBUS_H */
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v5 03/12] bus: mvebu-mbus: Add static window allocation to the DT binding
This patch adds static window allocation to the device tree binding.
Each first-child of the mbus-compatible node, with a suitable 'ranges'
property, declaring an address translation, will trigger an address
decoding window allocation.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
.../devicetree/bindings/bus/mvebu-mbus.txt | 256 +
drivers/bus/mvebu-mbus.c | 121 +-
2 files changed, 376 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/bus/mvebu-mbus.txt
diff --git a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
new file mode 100644
index 000..66d17df
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
@@ -0,0 +1,256 @@
+
+* Marvell MBus
+
+Required properties:
+
+- compatible: Should be set to one of the following:
+marvell,armada370-mbus
+marvell,armadaxp-mbus
+
+- address-cells: Must be '2'. The first cell for the MBus ID encoding,
+ the second cell for the address offset within the window.
+
+- size-cells:Must be '1'.
+
+- ranges:Must be set up to provide a proper translation for each child.
+See the examples below.
+
+- controller:Contains a single phandle referring to the MBus controller
+ node. This allows to specify the node that contains the
+registers that control the MBus, which is typically contained
+within the internal register window (see below).
+
+* Marvell MBus controller
+
+Required properties:
+
+- compatible: Should be set to marvell,mbus-controller.
+
+- reg: Device's register space.
+ Two entries are expected (see the examples below):
+ the first one controls the devices decoding window and
+ the second one controls the SDRAM decoding windows.
+
+Example:
+
+ soc {
+ compatible = marvell,armada370-mbus, simple-bus;
+ #address-cells = 2;
+ #size-cells = 1;
+ controller = mbusc;
+
+ internal-regs {
+ compatible = simple-bus;
+
+ mbusc: mbus-controller@2 {
+ compatible = marvell,mbus-controller;
+ reg = 0x2 0x100, 0x20180 0x20;
+ };
+
+ /* more children ...*/
+ };
+ };
+
+** MBus address decoding window specification
+
+The MBus children address space is comprised of two cells: the first one for
+the window ID and the second one for the offset within the window.
+In order to allow to describe valid and non-valid window entries, the
+following encoding is used:
+
+ 0xSIAA 0x00oo
+
+Where:
+
+ S = 0x0 for a MBus valid window
+ S = 0xf for a non-valid window (see below)
+
+If S = 0x0, then:
+
+ I = 4-bit window target ID
+ AA = windpw attribute
+
+If S = 0xf, then:
+
+ I = don't care
+ AA = 1 for internal register
+ AA = 2 for PCI-E
+
+Following the above encoding, for each ranges entry for a MBus valid window
+(S = 0x0), an address decoding window is allocated. On the other side,
+entries for translation that do not correspond to valid windows (S = 0xf)
+are skipped.
+
+ soc {
+ compatible = marvell,armada370-mbus, simple-bus;
+ #address-cells = 2;
+ #size-cells = 1;
+ controller = mbusc;
+
+ ranges = 0xf001 0 0 0xd000 0x10
+ 0x01e0 0 0 0xfff0 0x10;
+
+ bootrom {
+ compatible = marvell,bootrom;
+ reg = 0x01e0 0 0x10;
+ };
+
+ /* other children */
+ ...
+
+ internal-regs {
+ compatible = simple-bus;
+ ranges = 0 0xf001 0 0x10;
+
+ mbusc: mbus-controller@2 {
+ compatible = marvell,mbus-controller;
+ reg = 0x2 0x100, 0x20180 0x20;
+ };
+
+ /* more children ...*/
+ };
+ };
+
+In the shown example, the translation entry in the 'ranges' property is what
+makes the MBus driver create a static decoding window for the corresponding
+given child device. Note that the binding does not require child nodes to be
+present. Of course, child nodes are needed to probe the devices.
+
+Since each window is identified by its target ID and attribute ID there's
+a special macro that can be use to simplify the translation entries:
+
+#define MBUS_ID(target,attributes) (((target) 24) | ((attributes) 16))
+
+Using this macro, the above example would be:
+
+ soc {
+ compatible = marvell,armada370
[PATCH v5 01/12] bus: mvebu-mbus: Factor out initialization details
We introduce a common initialization function mvebu_mbus_common_init()
that will be used by both legacy and device-tree initialization code.
This patch is an intermediate step, which will allow to introduce the
DT binding for this driver in a less intrusive way.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/bus/mvebu-mbus.c | 47 ++-
1 file changed, 30 insertions(+), 17 deletions(-)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 33c6947..d0feee5 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -830,26 +830,14 @@ static __init int mvebu_mbus_debugfs_init(void)
}
fs_initcall(mvebu_mbus_debugfs_init);
-int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
- size_t mbuswins_size,
- phys_addr_t sdramwins_phys_base,
- size_t sdramwins_size)
+static int __init mvebu_mbus_common_init(struct mvebu_mbus_state *mbus,
+phys_addr_t mbuswins_phys_base,
+size_t mbuswins_size,
+phys_addr_t sdramwins_phys_base,
+size_t sdramwins_size)
{
- struct mvebu_mbus_state *mbus = mbus_state;
- const struct of_device_id *of_id;
int win;
- for (of_id = of_mvebu_mbus_ids; of_id-compatible; of_id++)
- if (!strcmp(of_id-compatible, soc))
- break;
-
- if (!of_id-compatible) {
- pr_err(could not find a matching SoC family\n);
- return -ENODEV;
- }
-
- mbus-soc = of_id-data;
-
mbus-mbuswins_base = ioremap(mbuswins_phys_base, mbuswins_size);
if (!mbus-mbuswins_base)
return -ENOMEM;
@@ -870,3 +858,28 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t
mbuswins_phys_base,
return 0;
}
+
+int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
+ size_t mbuswins_size,
+ phys_addr_t sdramwins_phys_base,
+ size_t sdramwins_size)
+{
+ const struct of_device_id *of_id;
+
+ for (of_id = of_mvebu_mbus_ids; of_id-compatible; of_id++)
+ if (!strcmp(of_id-compatible, soc))
+ break;
+
+ if (!of_id-compatible) {
+ pr_err(could not find a matching SoC family\n);
+ return -ENODEV;
+ }
+
+ mbus_state.soc = of_id-data;
+
+ return mvebu_mbus_common_init(mbus_state,
+ mbuswins_phys_base,
+ mbuswins_size,
+ sdramwins_phys_base,
+ sdramwins_size);
+}
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v5 05/12] ARM: mvebu: Remove the harcoded BootROM window allocation
The address decoding window to access the BootROM should not be
allocated programatically, but instead declared in the device tree.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-mvebu/platsmp.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
index 93f2f3a..a952f8d 100644
--- a/arch/arm/mach-mvebu/platsmp.c
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -21,6 +21,7 @@
#include linux/smp.h
#include linux/clk.h
#include linux/of.h
+#include linux/of_address.h
#include linux/mbus.h
#include asm/cacheflush.h
#include asm/smp_plat.h
@@ -29,6 +30,9 @@
#include pmsu.h
#include coherency.h
+#define AXP_BOOTROM_BASE 0xfff0
+#define AXP_BOOTROM_SIZE 0x10
+
void __init set_secondary_cpus_clock(void)
{
int thiscpu;
@@ -115,10 +119,29 @@ static void __init armada_xp_smp_init_cpus(void)
void __init armada_xp_smp_prepare_cpus(unsigned int max_cpus)
{
+ struct device_node *node;
+ struct resource res;
+ int err;
+
set_secondary_cpus_clock();
flush_cache_all();
set_cpu_coherent(cpu_logical_map(smp_processor_id()), 0);
- mvebu_mbus_add_window(bootrom, 0xfff0, SZ_1M);
+
+ /*
+* In order to boot the secondary CPUs we need to ensure
+* the bootROM is mapped at the correct address.
+*/
+ node = of_find_compatible_node(NULL, NULL, marvell,bootrom);
+ if (!node)
+ panic(Cannot find 'marvell,bootrom' compatible node);
+
+ err = of_address_to_resource(node, 0, res);
+ if (err 0)
+ panic(Cannot get 'bootrom' node address);
+
+ if (res.start != AXP_BOOTROM_BASE ||
+ resource_size(res) != AXP_BOOTROM_SIZE)
+ panic(The address for the BootROM is incorrect);
}
struct smp_operations armada_xp_smp_ops __initdata = {
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v5 07/12] ARM: mvebu: Use the preprocessor on Armada 370/XP device tree files
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-db.dts | 2 +-
arch/arm/boot/dts/armada-370-mirabox.dts | 2 +-
arch/arm/boot/dts/armada-370-rd.dts | 2 +-
arch/arm/boot/dts/armada-370.dtsi| 2 +-
arch/arm/boot/dts/armada-xp-db.dts | 2 +-
arch/arm/boot/dts/armada-xp-gp.dts | 2 +-
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 2 +-
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 2 +-
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 2 +-
arch/arm/boot/dts/armada-xp.dtsi | 2 +-
10 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index 2353b1f..231f8b2 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -14,7 +14,7 @@
*/
/dts-v1/;
-/include/ armada-370.dtsi
+#include armada-370.dtsi
/ {
model = Marvell Armada 370 Evaluation Board;
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index 14e36e1..7005f27 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -9,7 +9,7 @@
*/
/dts-v1/;
-/include/ armada-370.dtsi
+#include armada-370.dtsi
/ {
model = Globalscale Mirabox;
diff --git a/arch/arm/boot/dts/armada-370-rd.dts
b/arch/arm/boot/dts/armada-370-rd.dts
index 130f839..5c3a1ec 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -12,7 +12,7 @@
*/
/dts-v1/;
-/include/ armada-370.dtsi
+#include armada-370.dtsi
/ {
model = Marvell Armada 370 Reference Design;
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index fa3dfc6..08ec6e3 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -15,7 +15,7 @@
* common to all Armada SoCs.
*/
-/include/ armada-370-xp.dtsi
+#include armada-370-xp.dtsi
/include/ skeleton.dtsi
/ {
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index d6cc8bf..9a6ad0e 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -14,7 +14,7 @@
*/
/dts-v1/;
-/include/ armada-xp-mv78460.dtsi
+#include armada-xp-mv78460.dtsi
/ {
model = Marvell Armada XP Evaluation Board;
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts
b/arch/arm/boot/dts/armada-xp-gp.dts
index 76db557..df1caa3 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -14,7 +14,7 @@
*/
/dts-v1/;
-/include/ armada-xp-mv78460.dtsi
+#include armada-xp-mv78460.dtsi
/ {
model = Marvell Armada XP Development Board DB-MV784MP-GP;
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 2d9335d..985373a 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -13,7 +13,7 @@
* common to all Armada XP SoCs.
*/
-/include/ armada-xp.dtsi
+#include armada-xp.dtsi
/ {
model = Marvell Armada XP MV78260 SoC;
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index 488ca5e..3874548 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -13,7 +13,7 @@
* common to all Armada XP SoCs.
*/
-/include/ armada-xp.dtsi
+#include armada-xp.dtsi
/ {
model = Marvell Armada XP MV78460 SoC;
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index fdea75c..5f59a17 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -11,7 +11,7 @@
*/
/dts-v1/;
-/include/ armada-xp-mv78260.dtsi
+#include armada-xp-mv78260.dtsi
/ {
model = PlatHome OpenBlocks AX3-4 board;
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 1ee8540..3e770db 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -16,7 +16,7 @@
* common to all Armada SoCs.
*/
-/include/ armada-370-xp.dtsi
+#include armada-370-xp.dtsi
/ {
model = Marvell Armada XP family SoC;
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v5 04/12] ARM: mvebu: Initialize MBus using the DT binding
Now that the mbus device tree binding has been introduced, we can
switch over to it.
Also, and since the initialization of the mbus driver is quite
fundamental for the system to work properly, this patch adds a BUG()
in case mbus fails to initialize.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-mvebu/armada-370-xp.c | 34 +-
1 file changed, 1 insertion(+), 33 deletions(-)
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c
b/arch/arm/mach-mvebu/armada-370-xp.c
index 0dbc370..4c312be 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -34,44 +34,12 @@ static void __init armada_370_xp_map_io(void)
debug_ll_io_init();
}
-/*
- * This initialization will be replaced by a DT-based
- * initialization once the mvebu-mbus driver gains DT support.
- */
-
-#define ARMADA_370_XP_MBUS_WINS_OFFS 0x2
-#define ARMADA_370_XP_MBUS_WINS_SIZE 0x100
-#define ARMADA_370_XP_SDRAM_WINS_OFFS 0x20180
-#define ARMADA_370_XP_SDRAM_WINS_SIZE 0x20
-
-static void __init armada_370_xp_mbus_init(void)
-{
- char *mbus_soc_name;
- struct device_node *dn;
- const __be32 mbus_wins_offs = cpu_to_be32(ARMADA_370_XP_MBUS_WINS_OFFS);
- const __be32 sdram_wins_offs =
cpu_to_be32(ARMADA_370_XP_SDRAM_WINS_OFFS);
-
- if (of_machine_is_compatible(marvell,armada370))
- mbus_soc_name = marvell,armada370-mbus;
- else
- mbus_soc_name = marvell,armadaxp-mbus;
-
- dn = of_find_node_by_name(NULL, internal-regs);
- BUG_ON(!dn);
-
- mvebu_mbus_init(mbus_soc_name,
- of_translate_address(dn, mbus_wins_offs),
- ARMADA_370_XP_MBUS_WINS_SIZE,
- of_translate_address(dn, sdram_wins_offs),
- ARMADA_370_XP_SDRAM_WINS_SIZE);
-}
-
static void __init armada_370_xp_timer_and_clk_init(void)
{
mvebu_clocks_init();
armada_370_xp_timer_init();
coherency_init();
- armada_370_xp_mbus_init();
+ BUG_ON(mvebu_mbus_dt_init());
#ifdef CONFIG_CACHE_L2X0
l2x0_of_init(0, ~0UL);
#endif
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v5 06/12] memory: mvebu-devbus: Remove address decoding window workaround
Now that mbus device tree binding has been introduced, remove the address
decoding window management from this driver.
A suitable 'ranges' entry should be added to the devbus-compatible node in
the device tree, as described by the mbus binding documentation.
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/memory/mvebu-devbus.c | 64 ++-
1 file changed, 2 insertions(+), 62 deletions(-)
diff --git a/drivers/memory/mvebu-devbus.c b/drivers/memory/mvebu-devbus.c
index 978e8e3..94c9248 100644
--- a/drivers/memory/mvebu-devbus.c
+++ b/drivers/memory/mvebu-devbus.c
@@ -208,16 +208,11 @@ static int mvebu_devbus_probe(struct platform_device
*pdev)
{
struct device *dev = pdev-dev;
struct device_node *node = pdev-dev.of_node;
- struct device_node *parent;
struct devbus *devbus;
struct resource *res;
struct clk *clk;
unsigned long rate;
- const __be32 *ranges;
- int err, cs;
- int addr_cells, p_addr_cells, size_cells;
- int ranges_len, tuple_len;
- u32 base, size;
+ int err;
devbus = devm_kzalloc(pdev-dev, sizeof(struct devbus), GFP_KERNEL);
if (!devbus)
@@ -248,68 +243,13 @@ static int mvebu_devbus_probe(struct platform_device
*pdev)
return err;
/*
-* Allocate an address window for this device.
-* If the device probing fails, then we won't be able to
-* remove the allocated address decoding window.
-*
-* FIXME: This is only a temporary hack! We need to do this here
-* because we still don't have device tree bindings for mbus.
-* Once that support is added, we will declare these address windows
-* statically in the device tree, and remove the window configuration
-* from here.
-*/
-
- /*
-* Get the CS to choose the window string.
-* This is a bit hacky, but it will be removed once the
-* address windows are declared in the device tree.
-*/
- cs = (((unsigned long)devbus-base) % 0x400) / 8;
-
- /*
-* Parse 'ranges' property to obtain a (base,size) window tuple.
-* This will be removed once the address windows
-* are declared in the device tree.
-*/
- parent = of_get_parent(node);
- if (!parent)
- return -EINVAL;
-
- p_addr_cells = of_n_addr_cells(parent);
- of_node_put(parent);
-
- addr_cells = of_n_addr_cells(node);
- size_cells = of_n_size_cells(node);
- tuple_len = (p_addr_cells + addr_cells + size_cells) * sizeof(__be32);
-
- ranges = of_get_property(node, ranges, ranges_len);
- if (ranges == NULL || ranges_len != tuple_len)
- return -EINVAL;
-
- base = of_translate_address(node, ranges + addr_cells);
- if (base == OF_BAD_ADDR)
- return -EINVAL;
- size = of_read_number(ranges + addr_cells + p_addr_cells, size_cells);
-
- /*
-* Create an mbus address windows.
-* FIXME: Remove this, together with the above code, once the
-* address windows are declared in the device tree.
-*/
- err = mvebu_mbus_add_window(devbus_wins[cs], base, size);
- if (err 0)
- return err;
-
- /*
* We need to create a child device explicitly from here to
* guarantee that the child will be probed after the timing
* parameters for the bus are written.
*/
err = of_platform_populate(node, NULL, NULL, dev);
- if (err 0) {
- mvebu_mbus_del_window(base, size);
+ if (err 0)
return err;
- }
return 0;
}
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v5 08/12] ARM: mvebu: Add MBus to Armada 370/XP device tree
The Armada 370/XP SoC family has a completely configurable address
space handled by the MBus controller.
This patch introduces the device tree layout of MBus, making the
'soc' node as mbus-compatible.
Since every peripheral/controller is a child of this 'soc' node,
this makes all of them sit behind the mbus, thus describing the
hardware accurately.
A translation entry has been added for the internal-regs mapping.
This can't be done in the common armada-370-xp.dtsi because A370
and AXP have different addressing width.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-db.dts | 2 ++
arch/arm/boot/dts/armada-370-mirabox.dts | 2 ++
arch/arm/boot/dts/armada-370-rd.dts | 2 ++
arch/arm/boot/dts/armada-370-xp.dtsi | 15 ++-
arch/arm/boot/dts/armada-370.dtsi| 4 ++--
arch/arm/boot/dts/armada-xp-db.dts | 2 ++
arch/arm/boot/dts/armada-xp-gp.dts | 4 +---
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 4 +---
arch/arm/boot/dts/armada-xp.dtsi | 2 ++
9 files changed, 24 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index 231f8b2..4f08b4d 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,6 +30,8 @@
};
soc {
+ ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10;
+
internal-regs {
serial@12000 {
clock-frequency = 2;
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index 7005f27..df30065 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,6 +25,8 @@
};
soc {
+ ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10;
+
internal-regs {
serial@12000 {
clock-frequency = 2;
diff --git a/arch/arm/boot/dts/armada-370-rd.dts
b/arch/arm/boot/dts/armada-370-rd.dts
index 5c3a1ec..7601b24 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,6 +28,8 @@
};
soc {
+ ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10;
+
internal-regs {
serial@12000 {
clock-frequency = 2;
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 52a1f5e..98f540b 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -18,6 +18,8 @@
/include/ skeleton64.dtsi
+#define MBUS_ID(target,attributes) (((target) 24) | ((attributes) 16))
+
/ {
model = Marvell Armada 370 and XP SoC;
compatible = marvell,armada-370-xp;
@@ -29,18 +31,21 @@
};
soc {
- #address-cells = 1;
+ #address-cells = 2;
#size-cells = 1;
- compatible = simple-bus;
+ controller = mbusc;
interrupt-parent = mpic;
- ranges = 0 0 0xd000 0x010 /* internal
registers */
- 0xe000 0 0xe000 0x810 /* PCIe */;
internal-regs {
compatible = simple-bus;
#address-cells = 1;
#size-cells = 1;
- ranges;
+ ranges = 0 MBUS_ID(0xf0, 0x01) 0 0x10;
+
+ mbusc: mbus-controller@2 {
+ compatible = marvell,mbus-controller;
+ reg = 0x2 0x100, 0x20180 0x20;
+ };
mpic: interrupt-controller@2 {
compatible = marvell,mpic;
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index 08ec6e3..4b54e51 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -29,8 +29,8 @@
};
soc {
- ranges = 0 0xd000 0x010 /* internal registers
*/
- 0xe000 0xe000 0x810 /* PCIe */;
+ compatible = marvell,armada370-mbus, simple-bus;
+
internal-regs {
system-controller@18200 {
compatible =
marvell,armada-370-xp-system-controller;
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index 9a6ad0e..5bc9dcb 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -30,6 +30,8 @@
};
soc {
+ ranges = MBUS_ID(0xf0, 0x01) 0 0 0xd000 0x10;
+
internal-regs
[PATCH v5 10/12] ARM: mvebu: Relocate Armada 370/XP DeviceBus device tree nodes
Now that mbus has been added to the device tree, it's possible to
move the DeviceBus out of internal registers, placing it directly
below the mbus. This is a more accurate representation of the hardware.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-xp.dtsi | 94 +---
arch/arm/boot/dts/armada-xp-gp.dts | 60 +++
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 60 +++
3 files changed, 110 insertions(+), 104 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 98f540b..cbad967 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -36,6 +36,56 @@
controller = mbusc;
interrupt-parent = mpic;
+ devbus-bootcs {
+ compatible = marvell,mvebu-devbus;
+ reg = MBUS_ID(0xf0, 0x01) 0x10400 0x8;
+ ranges = 0 MBUS_ID(0x01, 0x2f) 0 0x;
+ #address-cells = 1;
+ #size-cells = 1;
+ clocks = coreclk 0;
+ status = disabled;
+ };
+
+ devbus-cs0 {
+ compatible = marvell,mvebu-devbus;
+ reg = MBUS_ID(0xf0, 0x01) 0x10408 0x8;
+ ranges = 0 MBUS_ID(0x01, 0x3e) 0 0x;
+ #address-cells = 1;
+ #size-cells = 1;
+ clocks = coreclk 0;
+ status = disabled;
+ };
+
+ devbus-cs1 {
+ compatible = marvell,mvebu-devbus;
+ reg = MBUS_ID(0xf0, 0x01) 0x10410 0x8;
+ ranges = 0 MBUS_ID(0x01, 0x3d) 0 0x;
+ #address-cells = 1;
+ #size-cells = 1;
+ clocks = coreclk 0;
+ status = disabled;
+ };
+
+ devbus-cs2 {
+ compatible = marvell,mvebu-devbus;
+ reg = MBUS_ID(0xf0, 0x01) 0x10418 0x8;
+ ranges = 0 MBUS_ID(0x01, 0x3b) 0 0x;
+ #address-cells = 1;
+ #size-cells = 1;
+ clocks = coreclk 0;
+ status = disabled;
+ };
+
+ devbus-cs3 {
+ compatible = marvell,mvebu-devbus;
+ reg = MBUS_ID(0xf0, 0x01) 0x10420 0x8;
+ ranges = 0 MBUS_ID(0x01, 0x37) 0 0x;
+ #address-cells = 1;
+ #size-cells = 1;
+ clocks = coreclk 0;
+ status = disabled;
+ };
+
internal-regs {
compatible = simple-bus;
#address-cells = 1;
@@ -187,50 +237,6 @@
status = disabled;
};
- devbus-bootcs@10400 {
- compatible = marvell,mvebu-devbus;
- reg = 0x10400 0x8;
- #address-cells = 1;
- #size-cells = 1;
- clocks = coreclk 0;
- status = disabled;
- };
-
- devbus-cs0@10408 {
- compatible = marvell,mvebu-devbus;
- reg = 0x10408 0x8;
- #address-cells = 1;
- #size-cells = 1;
- clocks = coreclk 0;
- status = disabled;
- };
-
- devbus-cs1@10410 {
- compatible = marvell,mvebu-devbus;
- reg = 0x10410 0x8;
- #address-cells = 1;
- #size-cells = 1;
- clocks = coreclk 0;
- status = disabled;
- };
-
- devbus-cs2@10418 {
- compatible = marvell,mvebu-devbus;
- reg = 0x10418 0x8;
- #address-cells = 1;
- #size-cells = 1;
- clocks = coreclk 0;
- status = disabled;
- };
-
- devbus-cs3@10420 {
- compatible = marvell,mvebu-devbus;
- reg = 0x10420 0x8;
- #address-cells = 1;
- #size-cells = 1
[PATCH v5 09/12] ARM: mvebu: Add BootROM to Armada 370/XP device tree
In order to access the SoC BootROM, we need to declare a mapping
(through a ranges property). The mbus driver will use this property
to allocate a suitable address decoding window.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-db.dts | 3 ++-
arch/arm/boot/dts/armada-370-mirabox.dts | 3 ++-
arch/arm/boot/dts/armada-370-rd.dts | 3 ++-
arch/arm/boot/dts/armada-370.dtsi| 5 +
arch/arm/boot/dts/armada-xp-db.dts | 3 ++-
arch/arm/boot/dts/armada-xp-gp.dts | 3 ++-
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 3 ++-
arch/arm/boot/dts/armada-xp.dtsi | 5 +
8 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index 4f08b4d..519a24b 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,7 +30,8 @@
};
soc {
- ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10;
+ ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10
+ MBUS_ID(0x01, 0xe0) 0 0xfff0 0x10;
internal-regs {
serial@12000 {
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index df30065..69bb7aa 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,7 +25,8 @@
};
soc {
- ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10;
+ ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10
+ MBUS_ID(0x01, 0xe0) 0 0xfff0 0x10;
internal-regs {
serial@12000 {
diff --git a/arch/arm/boot/dts/armada-370-rd.dts
b/arch/arm/boot/dts/armada-370-rd.dts
index 7601b24..d0daa9e 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,7 +28,8 @@
};
soc {
- ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10;
+ ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10
+ MBUS_ID(0x01, 0xe0) 0 0xfff0 0x10;
internal-regs {
serial@12000 {
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index 4b54e51..bd21d49 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -31,6 +31,11 @@
soc {
compatible = marvell,armada370-mbus, simple-bus;
+ bootrom {
+ compatible = marvell,bootrom;
+ reg = MBUS_ID(0x01, 0xe0) 0 0x10;
+ };
+
internal-regs {
system-controller@18200 {
compatible =
marvell,armada-370-xp-system-controller;
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index 5bc9dcb..d157387 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -30,7 +30,8 @@
};
soc {
- ranges = MBUS_ID(0xf0, 0x01) 0 0 0xd000 0x10;
+ ranges = MBUS_ID(0xf0, 0x01) 0 0 0xd000 0x10
+ MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10;
internal-regs {
serial@12000 {
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts
b/arch/arm/boot/dts/armada-xp-gp.dts
index 6c27a76..946c695 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -39,7 +39,8 @@
};
soc {
- ranges = MBUS_ID(0xf0, 0x01) 0 0 0xd000 0x10;
+ ranges = MBUS_ID(0xf0, 0x01) 0 0 0xd000 0x10
+ MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10;
internal-regs {
serial@12000 {
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 61b17f4..889ca6ef 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -27,7 +27,8 @@
};
soc {
- ranges = MBUS_ID(0xf0, 0x01) 0 0 0xd000 0x10;
+ ranges = MBUS_ID(0xf0, 0x01) 0 0 0xd000 0x10
+ MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10;
internal-regs {
serial@12000 {
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 9a950d0..ea747b5 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -25,6 +25,11 @@
soc {
compatible = marvell,armadaxp-mbus, simple-bus;
+ bootrom {
+ compatible = marvell,bootrom
[PATCH v5 12/12] ARM: mvebu: Relocate Armada XP PCIe device tree nodes
Now that mbus has been added to the device tree, it's possible to
move the PCIe nodes out of internal registers, placing it directly
below the mbus. This is a more accurate representation of the
hardware.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-xp-db.dts | 67 ++--
arch/arm/boot/dts/armada-xp-gp.dts | 43 +--
arch/arm/boot/dts/armada-xp-mv78230.dtsi | 209 ++---
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 245 +++
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 377 ---
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 19 +-
6 files changed, 483 insertions(+), 477 deletions(-)
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index d157387..ef0d2c5 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -31,8 +31,42 @@
soc {
ranges = MBUS_ID(0xf0, 0x01) 0 0 0xd000 0x10
+ MBUS_ID(0xf0, 0x02) 0xe000 0 0xe000 0x810
MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10;
+ pcie-controller {
+ status = okay;
+
+ /*
+* All 6 slots are physically present as
+* standard PCIe slots on the board.
+*/
+ pcie@1,0 {
+ /* Port 0, Lane 0 */
+ status = okay;
+ };
+ pcie@2,0 {
+ /* Port 0, Lane 1 */
+ status = okay;
+ };
+ pcie@3,0 {
+ /* Port 0, Lane 2 */
+ status = okay;
+ };
+ pcie@4,0 {
+ /* Port 0, Lane 3 */
+ status = okay;
+ };
+ pcie@9,0 {
+ /* Port 2, Lane 0 */
+ status = okay;
+ };
+ pcie@10,0 {
+ /* Port 3, Lane 0 */
+ status = okay;
+ };
+ };
+
internal-regs {
serial@12000 {
clock-frequency = 25000;
@@ -125,39 +159,6 @@
spi-max-frequency = 2000;
};
};
-
- pcie-controller {
- status = okay;
-
- /*
-* All 6 slots are physically present as
-* standard PCIe slots on the board.
-*/
- pcie@1,0 {
- /* Port 0, Lane 0 */
- status = okay;
- };
- pcie@2,0 {
- /* Port 0, Lane 1 */
- status = okay;
- };
- pcie@3,0 {
- /* Port 0, Lane 2 */
- status = okay;
- };
- pcie@4,0 {
- /* Port 0, Lane 3 */
- status = okay;
- };
- pcie@9,0 {
- /* Port 2, Lane 0 */
- status = okay;
- };
- pcie@10,0 {
- /* Port 3, Lane 0 */
- status = okay;
- };
- };
};
};
};
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts
b/arch/arm/boot/dts/armada-xp-gp.dts
index 30bf645..c328538 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -40,6 +40,7 @@
soc {
ranges = MBUS_ID(0xf0, 0x01) 0 0 0xd000 0x10
+ MBUS_ID(0xf0, 0x02) 0xe000 0 0xe000 0x810
MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10
MBUS_ID(0x01, 0x2f) 0 0 0xf000 0x100;
@@ -71,6 +72,27 @@
};
};
+ pcie-controller {
+ status = okay;
+
+ /*
+* The 3 slots
[PATCH v5 11/12] ARM: mvebu: Relocate Armada 370 PCIe device tree nodes
Now that mbus has been added to the device tree, it's possible to
move the PCIe nodes out of internal registers, placing it directly
below the mbus. This is a more accurate representation of the
hardware.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-mirabox.dts | 33 +--
arch/arm/boot/dts/armada-370.dtsi| 97
2 files changed, 66 insertions(+), 64 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index 69bb7aa..750f65e 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -26,8 +26,25 @@
soc {
ranges = MBUS_ID(0xf0, 0x01) 0 0xd000 0x10
+ MBUS_ID(0xf0, 0x02) 0xe000 0xe000 0x810
MBUS_ID(0x01, 0xe0) 0 0xfff0 0x10;
+ pcie-controller {
+ status = okay;
+
+ /* Internal mini-PCIe connector */
+ pcie@1,0 {
+ /* Port 0, Lane 0 */
+ status = okay;
+ };
+
+ /* Connected on the PCB to a USB 3.0 XHCI controller */
+ pcie@2,0 {
+ /* Port 1, Lane 0 */
+ status = okay;
+ };
+ };
+
internal-regs {
serial@12000 {
clock-frequency = 2;
@@ -122,22 +139,6 @@
reg = 0x25;
};
};
-
- pcie-controller {
- status = okay;
-
- /* Internal mini-PCIe connector */
- pcie@1,0 {
- /* Port 0, Lane 0 */
- status = okay;
- };
-
- /* Connected on the PCB to a USB 3.0 XHCI
controller */
- pcie@2,0 {
- /* Port 1, Lane 0 */
- status = okay;
- };
- };
};
};
};
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index bd21d49..bb48823 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -36,6 +36,55 @@
reg = MBUS_ID(0x01, 0xe0) 0 0x10;
};
+ pcie-controller {
+ compatible = marvell,armada-370-pcie;
+ status = disabled;
+ device_type = pci;
+
+ #address-cells = 3;
+ #size-cells = 2;
+
+ bus-range = 0x00 0xff;
+
+ ranges =
+ 0x8200 0 0x4MBUS_ID(0xf0, 0x01)
0x4 0 0x2000
+ 0x8200 0 0x8MBUS_ID(0xf0, 0x01)
0x8 0 0x2000
+ 0x8200 0 0xe000 MBUS_ID(0xf0, 0x02)
0xe000 0 0x0800
+ 0x8100 0 0 MBUS_ID(0xf0, 0x02)
0xe800 0 0x0010;
+
+ pcie@1,0 {
+ device_type = pci;
+ assigned-addresses = 0x82000800 0 0x4 0
0x2000;
+ reg = 0x0800 0 0 0 0;
+ #address-cells = 3;
+ #size-cells = 2;
+ #interrupt-cells = 1;
+ ranges;
+ interrupt-map-mask = 0 0 0 0;
+ interrupt-map = 0 0 0 0 mpic 58;
+ marvell,pcie-port = 0;
+ marvell,pcie-lane = 0;
+ clocks = gateclk 5;
+ status = disabled;
+ };
+
+ pcie@2,0 {
+ device_type = pci;
+ assigned-addresses = 0x82002800 0 0x8 0
0x2000;
+ reg = 0x1000 0 0 0 0;
+ #address-cells = 3;
+ #size-cells = 2;
+ #interrupt-cells = 1;
+ ranges;
+ interrupt-map-mask = 0 0 0 0;
+ interrupt-map = 0 0 0 0 mpic 62;
+ marvell,pcie-port = 1;
+ marvell,pcie-lane = 0
Re: [PATCH v3 05/12] ARM: mvebu: Remove the harcoded BootROM window allocation
On Tue, Jun 18, 2013 at 11:39:06AM -0600, Jason Gunthorpe wrote: On Tue, Jun 18, 2013 at 08:25:30AM -0300, Ezequiel Garcia wrote: The address decoding window to access the BootROM should not be allocated programatically, but instead declared in the device tree. Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com arch/arm/mach-mvebu/platsmp.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c index 93f2f3a..d419fac 100644 +++ b/arch/arm/mach-mvebu/platsmp.c @@ -118,7 +118,6 @@ void __init armada_xp_smp_prepare_cpus(unsigned int max_cpus) set_secondary_cpus_clock(); flush_cache_all(); set_cpu_coherent(cpu_logical_map(smp_processor_id()), 0); - mvebu_mbus_add_window(bootrom, 0xfff0, SZ_1M); } I think some kind of test is needed here. As I understand it the SMP startup uses a trampoline in the boot rom and the boot rom *must* be mapped to 0xfff0 ? Indeed, setting up 0xfff0 is a *must*. Verifying the DT is setup this way and aborting if it is not seems like a good idea.. I agree it's a nice idea, but I'm not too sure how to accomplish this in a simple and generic way. There's nothing in the DT that allows you to know which of the ranges entries correspond to the BootROM, unless you go through each of the entries comparing against the known target ID and attribute. You could also do a 'of_find_node_by_name(NULL, bootrom);' but the binding no longer requires to even have any children for the window. Any ideas? -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 11/12] ARM: mvebu: Relocate Armada 370 PCIe device tree nodes
Arnd,
Going through this a couple questions came out...
On Tue, Jun 18, 2013 at 11:35:50PM +0200, Arnd Bergmann wrote:
On Tuesday 18 June 2013, Ezequiel Garcia wrote:
+
+ ranges =
+ 0x8200 0 0x40x0001 0x4
0 0x2000
+ 0x8200 0 0x80x0001 0x8
0 0x2000
+ 0x8200 0 0xe000 0x0002 0
0 0x0800
+ 0x8100 0 0 0x0002
0x800 0 0x0010;
As pointed out on IRC, this is not a good representation of the memory space,
since it requires a non-zero sys-mem_offset, and it conflicts with the
straight
mapping I suggested.
I think it should be
0x8200 0 0xe000 0x0002 0
0xe000 0x0800
So far, so good.
if we want to encode the aperture in the ranges property here, i.e. have
a 1:1 mapping between PCI memory space and MBUS space, and in mbus,
you need the corresponding
- 0x0002 0 0xe000 0x810
+ 0x0002 0xe000 0xe000 0x810
... I obviously got something wrong, but I thought you said that
this change allowed to *not* have any mbus-node ranges translation.
so that mbus actually translates the right addresses. You could also
have the PCI memory space start at 0, which would mean
0x8200 0 0 0x0002 0 0 0x0800
and
0x0002 0 0xe000 0x810
Mmm.. and why is this option acceptable?
Note that the driver doesn't actually handle the generic case correctly, you
would
need to apply this patch
This patch does not apply. I tried to understand what you did, but I'm
confused by the fact I don't need to apply any patch to make it work
on my boxes, using your proposed ranges translations.
diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index 13a633b..aa674f4 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -790,6 +790,7 @@ static int __init mvebu_pcie_probe(struct platform_device
*pdev)
}
if (restype == IORESOURCE_MEM) {
of_pci_range_to_resource(range, np, pcie-mem);
+ sys-mem_offset = range.cpu_addr - range.pci_addr;
pcie-mem.name = MEM;
}
}
to deal with the generic case where the bus address is different from the
CPU address.
Thanks!
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
