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
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 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 Unable to handle kernel paging request at virtual address 1804 pgd = c0004000 [1804] *pgd= Internal error: Oops: 805 [#1] PREEMPT ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 3.11.0-rc1-00022-g44e8c39 #35 task: df848000 ti: df84a000 task.ti: df84a000 PC is at mvebu_pcie_setup+0x84/0x2b4 LR is at mvebu_pcie_setup+0x74/0x2b4 pc : []lr : []psr: 2053 sp : df84bd70 ip : fp : r10: r9 : c06435f4 r8 : df84be0c r7 : r6 : df8359d0 r5 : df9e8410 r4 : df9e7180 r3 : 1804 r2 : r1 : ffe0 r0 : c06435f4 Flags: nzCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment kernel Control: 0005397f Table: 4000 DAC: 0017 Process swapper (pid: 1, stack limit = 0xdf84a1b8) Stack: (0xdf84bd70 to 0xdf84c000) bd60: df801e00 df8f8a10 df9e7180 bd80: df9e71a0 df8f8a00 df84be0c df84bdb0 c000d438 bda0: 0018 c0206e58 c04db1d8 df84bdb0 df84bdb0 df9e8410 df9e8410 bdc0: df8359d0 df8f8a00 df8f8a10 c0c89170 df9e8410 c0561f98 bde0: df9e842c df911fa0 a1ff 7846 11ab 0604 df84be0c be00: c059615c 0001 df84be34 c0562260 c01d3468 be20: c0562230 c01d2b88 df8359d0 df8f8a10 be40: df8f8a10 c059611c c0646070 c054e380 c05b4434 c020bdd8 be60: c020ac28 df8f8a10 df8f8a44 c059611c c020adb8 c0561d0c c020ae44 be80: df84be90 c059611c c02093f8 df80de8c df8f9e10 df9e72d4 df804b00 bea0: df9e72a0 c059611c c059dc50 c0209c3c c04d7b78 c01cf608 c0596108 c0596108 bec0: c059611c 0005 009c c020b208 c0596108 c056f73c 0005 bee0: 009c c020c0e8 c05760f8 c056f73c 0005 c0008684 c0411b70 c0638b64 bf00: 003f 6053 bf20
Re: [RESEND PATCH v7 00/22] MBus DT binding: The return of PCIe
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 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 Andrew ___ 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 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: [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 > > > > 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 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 [...] > > Any ideas? > The patchset works only for Armada 370 and Armada XP SoC, not for Kirkwood. For some reason I was completely sure there wasn't any DT-enabled Kirkwood boards with PCIe support. I apologize for not noticing this before! My plan was to get this patchset acked/merged and then add MBus DT to Kirkwood. The reason for this is that it's a simple change, but probably *very* intrusive on the DTS files. Of course, this plan was based on the assumption that the wasn't breaking anything. However, now I guess there's no other solution than adding Kirkwood to the patchset. So unless anyone has any better idea, I'll be sending a v8. Thanks again for the test! -- 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
> The patchset works only for Armada 370 and Armada XP SoC, not for Kirkwood. > For some reason I was completely sure there wasn't any DT-enabled Kirkwood > boards with PCIe support. I had a quick look at Dove and Orion5x. It looks like there are none with PCIe support. So only Kirkwood is broken. Andrew ___ 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
Dear Andrew Lunn, On Sat, 20 Jul 2013 21:45:59 +0200, Andrew Lunn wrote: > > The patchset works only for Armada 370 and Armada XP SoC, not for Kirkwood. > > For some reason I was completely sure there wasn't any DT-enabled Kirkwood > > boards with PCIe support. > > I had a quick look at Dove and Orion5x. It looks like there are none > with PCIe support. So only Kirkwood is broken. There are some Dove and Orion5x with PCIe support, but none of them are using the new PCIe driver yet. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
