[RESEND PATCH v7 00/22] MBus DT binding: The return of PCIe

[ezequiel.garcia@free-electrons.com (Ezequiel Garcia)]

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 (lunn at 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  : 0xffff0000 - 0xffff1000   (   4 kB)
> >     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
> >     vmalloc : 0xe0800000 - 0xff000000   ( 488 MB)
> >     lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
> >     modules : 0xbf000000 - 0xc0000000   (  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=200000000.
> > 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
[...]
> 
> 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