Re: [linux-yocto] Back-porting a new driver to Yocto kernel(s)..and device firmware

2014-06-19 Thread Allan, Bruce W
 -Original Message-
 From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
 Sent: Wednesday, June 18, 2014 7:51 PM
 To: Kamble, Nitin A; Allan, Bruce W; linux-yocto@yoctoproject.org
 Subject: Re: [linux-yocto] Back-porting a new driver to Yocto kernel(s)..and
 device firmware
 
 On 2014-06-18, 9:51 PM, Kamble, Nitin A wrote:
 
  On 6/18/2014 4:24 PM, Allan, Bruce W wrote:
 
  We have a new hardware crypto device driver currently out for RFC on
  the linux-crypto mailing list and would like to back-port it to the
  Yocto Linux kernels once it is committed upstream. What is the process
  for getting it into the current dev kernel as well as linux-yocto-3.10
  and linux-yocto-3.14? I've already done the back-port to the three
  Yocto Linux kernels and found that just 1 or 2 (depending on the
  kernel) other patches would also be needed. Is back-porting these
  patches also allowed as long as they do no harm to anything else?
 
 
  Hi Bruce,
 
  The right way is to push these backported patches in the respective
  stable kernel trees. If that is not working, then the patches can be
  pushed in the linux-yocto kernel repositories as features.
 
 Actually no .. not for the normal kernel.org -stable trees. From
 the description, these are new features, not stable patches. So they
 aren't something that can go to the korg stable. Shooting for LTSI is
 an option, but the cycle time for that to propagate to linux-yocto is
 really quite long.
 
 I'm happy to take the commits when they are Ack'd and headed to
 mainline, or even soak them on a feature branch (like I did with EDF
 before it merged).
 
 As long as the commits are upstream quality, we won't have any trouble,
 and I'll merge the RFC/staged changes when the cycle around through
 other trees.
 
 Bruce
 
 
  The device also requires a firmware component which has already been
  committed to the upstream linux-firmware repository. How does this get
  into Yocto?
 
  Then there may not be any thing done for the linux-firmware, as we
  always try to be up to date with upstream. If you need automatic loading
  of some modules, then you nay need to add configuration for that to
  BSPs. Which hardware is this feature for? Possibly we already has a BSP
  for that hardware, otherwise a new BSP can be created.
 
 
  Nitin
 
  Thanks,
 
  Bruce Allan.

Excellent!  Thanks for the info.  Will probably push the patches in the next 
few weeks.

Bruce Allan.

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


[linux-yocto] [PATCH 4/9] dma: lsi-dma32: Remove debug printks

2014-06-19 Thread Charlie Paul
From: Anders Berg anders.b...@avagotech.com

Signed-off-by: Anders Berg anders.b...@avagotech.com
---
 drivers/dma/lsi-dma32.c |2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/dma/lsi-dma32.c b/drivers/dma/lsi-dma32.c
index a5f3804..a488eec 100644
--- a/drivers/dma/lsi-dma32.c
+++ b/drivers/dma/lsi-dma32.c
@@ -173,7 +173,6 @@ static struct gpdma_desc *get_descriptor(struct 
gpdma_engine *engine)
list_del(desc-vdesc.node);
new = desc;
new-chain = NULL;
-   pr_info( get_desc %p\n, new);
break;
}
}
@@ -243,7 +242,6 @@ static void free_descriptor(struct virt_dma_desc *vd)
 
spin_lock_irqsave(engine-lock, flags);
while (desc) {
-   pr_info(free_desc %p\n, desc);
list_add_tail(desc-vdesc.node, engine-free_list);
desc = desc-chain;
}
-- 
1.7.9.5

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


[linux-yocto] [PATCH 2/9] sysdev LSI_POWERPC: Adding 3500 PCIe inbound mapping support

2014-06-19 Thread Charlie Paul
From: SangeethaRao sangeetha@lsi.com

Signed-off-by: SangeethaRao sangeetha@lsi.com
---
 arch/powerpc/sysdev/lsi_pci.c |   42 ++---
 1 file changed, 35 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/sysdev/lsi_pci.c b/arch/powerpc/sysdev/lsi_pci.c
index e9beadc..2c99507 100644
--- a/arch/powerpc/sysdev/lsi_pci.c
+++ b/arch/powerpc/sysdev/lsi_pci.c
@@ -753,16 +753,44 @@ configure_acp_pciex_PIMs(struct pciex_port *port,
  window.  We use this elsewhere to set up the
  dma_base.
*/
-
-   pci_dram_offset = size;
-   hose-dma_window_base_cur = size;
-
-   out_le32(mbase + PCI_BASE_ADDRESS_0, RES_TO_U32_LOW(size));
-   out_le32(mbase + PCI_BASE_ADDRESS_1, RES_TO_U32_HIGH(size));
+   if (0x10 == port-acpChipType) {
+   /* For 3500, set base address to pci base */
+   pci_dram_offset = res-start;
+   hose-dma_window_base_cur = res-start;
+   } else {
+   pci_dram_offset = size;
+   hose-dma_window_base_cur = size;
+   }
 
if (5 == port-acpChipType) {
-   pr_warn(Setting SIZE for 2500\n);
+   pr_info(Setting SIZE for 2500\n);
out_le32(mbase + 0x11f4, 0xf000UL);
+   out_le32(mbase + PCI_BASE_ADDRESS_0,
+   RES_TO_U32_LOW(size));
+   out_le32(mbase + PCI_BASE_ADDRESS_1,
+   RES_TO_U32_HIGH(size));
+   } else if (0x10 == port-acpChipType) {
+   pr_info(Setting SIZE for 3500\n);
+   out_le32(mbase + 0x11f4, size);
+   /* Verify BAR0 size */
+   {
+   u32 bar0_size;
+   out_le32(mbase + PCI_BASE_ADDRESS_0, ~0);
+   out_le32(mbase + PCI_BASE_ADDRESS_1, ~0);
+   bar0_size = in_le32(mbase + PCI_BASE_ADDRESS_0);
+   if ((bar0_size  ~0xf) != size)
+   pr_err(PCIE%d: Config BAR0 failed\n, 
port-index);
+   bar0_size = in_le32(mbase + PCI_BASE_ADDRESS_1);
+   }
+   /* Set the BASE0 address to start of PCIe base */
+   out_le32(mbase + PCI_BASE_ADDRESS_0, res-start);
+   /* Set the BASE1 address to 0x0 */
+   out_le32(mbase + PCI_BASE_ADDRESS_1, 0x0);
+   } else {
+   out_le32(mbase + PCI_BASE_ADDRESS_0,
+   RES_TO_U32_LOW(size));
+   out_le32(mbase + PCI_BASE_ADDRESS_1,
+   RES_TO_U32_HIGH(size));
}
 
/*
-- 
1.7.9.5

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


[linux-yocto] [PATCH 1/9] dma: lsi-dma32: Add support for sg operation

2014-06-19 Thread Charlie Paul
From: Anders Berg anders.b...@lsi.com

The driver is extended with implementation of DMA scatterlist operation
(device_prep_dma_sg). This allows for DMA operations to be performed on
non-contiguous ranges of memory.

Due to hardware limitations, each entry in the scatterlist needs to have
identical (physical) address bits [36:32]. The reason behind this is that the
top address bits are not maintained per-descriptor, but held in a per-channel
register and is initialized when a transfer is started (with the address bits
from the first scatterlist entry).

Signed-off-by: Anders Berg anders.b...@lsi.com
---
 drivers/dma/lsi-dma32.c |  235 +++
 drivers/dma/lsi-dma32.h |7 +-
 2 files changed, 181 insertions(+), 61 deletions(-)

diff --git a/drivers/dma/lsi-dma32.c b/drivers/dma/lsi-dma32.c
index 0977ef4..a5f3804 100644
--- a/drivers/dma/lsi-dma32.c
+++ b/drivers/dma/lsi-dma32.c
@@ -145,11 +145,13 @@ static int alloc_desc_table(struct gpdma_engine *engine)
engine_dbg(engine, order=%d pa=%#llx va=%p\n,
   engine-pool.order, engine-pool.phys, engine-pool.va);
 
-   engine-pool.free = NULL;
-   for (i = 0; i  GPDMA_MAX_DESCRIPTORS-1; i++)
-   engine-pool.va[i].chain = engine-pool.va[i+1];
-   engine-pool.va[GPDMA_MAX_DESCRIPTORS-1].chain = NULL;
-   engine-pool.free = engine-pool.va[0];
+   INIT_LIST_HEAD(engine-free_list);
+   for (i = 0; i  GPDMA_MAX_DESCRIPTORS; i++) {
+   struct gpdma_desc *desc = engine-pool.va[i];
+   async_tx_ack(desc-vdesc.tx);
+   desc-engine = engine;
+   list_add_tail(desc-vdesc.node, engine-free_list);
+   }
 
return 0;
 }
@@ -163,18 +165,59 @@ static void free_desc_table(struct gpdma_engine *engine)
 static struct gpdma_desc *get_descriptor(struct gpdma_engine *engine)
 {
unsigned long flags;
-   struct gpdma_desc *desc;
+   struct gpdma_desc *new = NULL, *desc, *tmp;
 
spin_lock_irqsave(engine-lock, flags);
-   desc = engine-pool.free;
-   if (desc) {
-   engine-pool.free = desc-chain;
-   desc-chain = NULL;
-   desc-engine = engine;
+   list_for_each_entry_safe(desc, tmp, engine-free_list, vdesc.node) {
+   if (async_tx_test_ack(desc-vdesc.tx)) {
+   list_del(desc-vdesc.node);
+   new = desc;
+   new-chain = NULL;
+   pr_info( get_desc %p\n, new);
+   break;
+   }
}
spin_unlock_irqrestore(engine-lock, flags);
 
-   return desc;
+   return new;
+}
+
+/**
+ * init_descriptor - Fill out all descriptor fields
+ */
+static void init_descriptor(struct gpdma_desc *desc,
+   dma_addr_t src, u32 src_acc,
+   dma_addr_t dst, u32 dst_acc,
+   size_t len)
+{
+   u32 src_count = len  src_acc;
+   u32 dst_count = len  dst_acc;
+   u32 rot_len = (2 * (1  src_acc)) - 1;
+
+   BUG_ON(src_count * (1src_acc) != len);
+   BUG_ON(dst_count * (1dst_acc) != len);
+
+   desc-src = src;
+   desc-dst = dst;
+
+   desc-hw.src_x_ctr = cpu_to_le16(src_count - 1);
+   desc-hw.src_y_ctr = 0;
+   desc-hw.src_x_mod = cpu_to_le32(1  src_acc);
+   desc-hw.src_y_mod = 0;
+   desc-hw.src_addr  = cpu_to_le32(src  0x);
+   desc-hw.src_data_mask = ~0;
+   desc-hw.src_access= cpu_to_le16((rot_len  6) |
+   (src_acc  3) |
+   (burst  7));
+   desc-hw.dst_access= cpu_to_le16((dst_acc  3) |
+   (burst  7));
+   desc-hw.ch_config = cpu_to_le32(DMA_CONFIG_ONE_SHOT(1));
+   desc-hw.next_ptr  = 0;
+   desc-hw.dst_x_ctr = cpu_to_le16(dst_count - 1);
+   desc-hw.dst_y_ctr = 0;
+   desc-hw.dst_x_mod = cpu_to_le32(1  dst_acc);
+   desc-hw.dst_y_mod = 0;
+   desc-hw.dst_addr  = cpu_to_le32(dst  0x);
 }
 
 static phys_addr_t desc_to_paddr(const struct gpdma_channel *dmac,
@@ -195,16 +238,15 @@ static void free_descriptor(struct virt_dma_desc *vd)
struct gpdma_desc *desc = to_gpdma_desc(vd);
struct gpdma_engine *engine = desc-engine;
unsigned long flags;
-   struct gpdma_desc *tail;
 
BUG_ON(desc == NULL);
 
-   for (tail = desc; tail-chain != NULL; tail = tail-chain)
-   ;
-
spin_lock_irqsave(engine-lock, flags);
-   tail-chain = engine-pool.free;
-   engine-pool.free = desc;
+   while (desc) {
+   pr_info(free_desc %p\n, desc);
+   list_add_tail(desc-vdesc.node, engine-free_list);
+   desc = desc-chain;
+   }
spin_unlock_irqrestore(engine-lock, flags);
 }
 
@@ -388,10 +430,8 @@ 

[linux-yocto] [PATCH 6/9] arch/arm: virtio

2014-06-19 Thread Charlie Paul
From: John Jacques john.jacq...@lsi.com

Signed-off-by: John Jacques john.jacq...@lsi.com
---
 arch/arm/boot/dts/axm5504-sim.dts |6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/axm5504-sim.dts 
b/arch/arm/boot/dts/axm5504-sim.dts
index 7580ae5..7c99c9f 100644
--- a/arch/arm/boot/dts/axm5504-sim.dts
+++ b/arch/arm/boot/dts/axm5504-sim.dts
@@ -42,6 +42,12 @@
};
};
 
+   virtio_block@013 {
+compatible = virtio,mmio;
+reg = 0x20 0x101f 0 0x1;
+interrupts = 0 255 4;
+   };
+
sim {
compatible = arm,amba-bus, simple-bus;
device_type = soc;
-- 
1.7.9.5

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


[linux-yocto] [PATCH 3/9] board/powerpc: Update the Device Tree for 3500

2014-06-19 Thread Charlie Paul
From: John Jacques john.jacq...@lsi.com

Update the compatibility field and peripherals to support
the 3500.

Signed-off-by: John Jacques john.jacq...@lsi.com
---
 arch/powerpc/boot/dts/acp35xx.dts |   68 +++--
 1 file changed, 19 insertions(+), 49 deletions(-)

diff --git a/arch/powerpc/boot/dts/acp35xx.dts 
b/arch/powerpc/boot/dts/acp35xx.dts
index b03680b..b46b10d 100644
--- a/arch/powerpc/boot/dts/acp35xx.dts
+++ b/arch/powerpc/boot/dts/acp35xx.dts
@@ -20,7 +20,7 @@
#address-cells = 2;
#size-cells = 1;
model = ibm,acpx1-4xx;
-   compatible = lsi,acp3500, lsi,acp, ibm,acpx1-4xx;
+   compatible = lsi,acp3500, lsi,axxia35xx, lsi,acp, ibm,acpx1-4xx;
dcr-parent = {/cpus/cpu@0};
 
aliases {
@@ -64,7 +64,7 @@
dcr-access-method = native;
status = disabled;
enable-method = spin-table;
-   cpu-release-addr = 0 0; // Fixed by the boot loader
+   cpu-release-addr = 0; // filled in by U-Boot
reset-type = 3; // 1=core, 2=chip, 3=system (default)
};
 
@@ -82,7 +82,7 @@
dcr-access-method = native;
status = disabled;
enable-method = spin-table;
-   cpu-release-addr = 0 0; // Fixed by the boot loader
+   cpu-release-addr = 0; // filled in by U-Boot
reset-type = 3; // 1=core, 2=chip, 3=system (default)
};
 
@@ -101,11 +101,11 @@
dcr-access-method = native;
status = disabled;
enable-method = spin-table;
-   cpu-release-addr = 0 0; // Fixed by the boot loader
+   cpu-release-addr = 0; // filled in by U-Boot
reset-type = 3; // 1=core, 2=chip, 3=system (default)
};
 
-   cpu@4 {
+   cpu@4 {
device_type = cpu;
model = PowerPC,4xx; // real CPU changed in sim
reg = 4;
@@ -119,11 +119,11 @@
dcr-access-method = native;
status = disabled;
enable-method = spin-table;
-   cpu-release-addr = 0 0; // Fixed by the boot loader
+   cpu-release-addr = 0; // filled in by U-Boot
reset-type = 3; // 1=core, 2=chip, 3=system (default)
};
 
-   cpu@5 {
+   cpu@5 {
device_type = cpu;
model = PowerPC,4xx; // real CPU changed in sim
reg = 5;
@@ -137,22 +137,19 @@
dcr-access-method = native;
status = disabled;
enable-method = spin-table;
-   cpu-release-addr = 0 0; // Fixed by the boot loader
+   cpu-release-addr = 0; // filled in by U-Boot
reset-type = 3; // 1=core, 2=chip, 3=system (default)
};
-
-
-
};
 
 memory@0 {
 device_type = memory;
-reg = 0x 0x 0x; // filled in by 
U-Boot
+   reg = 0 0 0; // filled in by U-Boot
 };
 
 memory@8000 {
 device_type = memory;
-reg = 0x 0x0800 0x; // filled in by 
U-Boot
+reg = 0 0 0; // filled in by U-Boot
 };
 
MPIC: interrupt-controller {
@@ -189,7 +186,7 @@
enabled = 0;
reg = 0x00424000 0x1000;
clock-reg = 0x00429040 0x20;
-   clock-frequency = 0;
+   clock-frequency = 2;
current-speed = 9600;
interrupt-parent = MPIC;
interrupts = 29;
@@ -202,7 +199,7 @@
enabled = 0;
reg = 0x00425000 0x1000;
clock-reg = 0x00429060 0x20;
-   clock-frequency = 0;
+   clock-frequency = 2;
current-speed = 9600;
interrupt-parent = MPIC;
interrupts = 30;
@@ -211,42 +208,18 @@
USB0: usb0 {
device_type = usb;
compatible = acp-usb;
-   enabled = 1;
-   reg = 0x20 0x004a 0x0 0x0002,
-  0x20 0x0040c000 0x0 0x1000;
+   enabled = 0;
+

[linux-yocto] [PATCH 7/9] arch/arm: Add Virtio Block Support to Axxia Simulation

2014-06-19 Thread Charlie Paul
From: John Jacques john.jacq...@lsi.com

Signed-off-by: John Jacques john.jacq...@lsi.com
---
 arch/arm/boot/dts/axm5504-sim.dts |   12 ++--
 arch/arm/boot/dts/axm5516-sim.dts |6 ++
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/axm5504-sim.dts 
b/arch/arm/boot/dts/axm5504-sim.dts
index 7c99c9f..bbb922a 100644
--- a/arch/arm/boot/dts/axm5504-sim.dts
+++ b/arch/arm/boot/dts/axm5504-sim.dts
@@ -42,12 +42,6 @@
};
};
 
-   virtio_block@013 {
-compatible = virtio,mmio;
-reg = 0x20 0x101f 0 0x1;
-interrupts = 0 255 4;
-   };
-
sim {
compatible = arm,amba-bus, simple-bus;
device_type = soc;
@@ -56,6 +50,12 @@
interrupt-parent = gic;
ranges;
 
+   virtio_block@013 {
+compatible = virtio,mmio;
+reg = 0x20 0x101f 0 0x1;
+interrupts = 0 223 4;
+   };
+
mmci@020101E {
compatible = arm,pl180, arm,primecell;
reg = 0x20 0x101E 0x00 0x1000;
diff --git a/arch/arm/boot/dts/axm5516-sim.dts 
b/arch/arm/boot/dts/axm5516-sim.dts
index e8cd01a..3ea5f05 100644
--- a/arch/arm/boot/dts/axm5516-sim.dts
+++ b/arch/arm/boot/dts/axm5516-sim.dts
@@ -50,6 +50,12 @@
interrupt-parent = gic;
ranges;
 
+   virtio_block@013 {
+compatible = virtio,mmio;
+reg = 0x20 0x101f 0 0x1;
+interrupts = 0 223 4;
+   };
+
mmci@020101E {
compatible = arm,pl180, arm,primecell;
reg = 0x20 0x101E 0x00 0x1000;
-- 
1.7.9.5

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


Re: [linux-yocto] [PATCH 0/9] LSI AXXIA updates to 3.10 standard/axxia/base

2014-06-19 Thread Bruce Ashfield

On 14-06-19 04:13 PM, Charlie Paul wrote:

Adding RAPIDIO code and support files

Anders Berg (3):
   dma: lsi-dma32: Add support for sg operation
   dma: lsi-dma32: Remove debug printks
   ARM: dts: axxia: Fix flash partitions

John Jacques (4):
   board/powerpc: Update the Device Tree for 3500
   arch/arm: virtio
   arch/arm: Add Virtio Block Support to Axxia Simulation
   arch/arm/mach-axxia: Update Device Tree for KVM

Palani (1):
   LSI AXM55xx RAPIDIO: Added support for the sRIO controller in the
 AXM55xx devices.

SangeethaRao (1):
   sysdev LSI_POWERPC: Adding 3500 PCIe inbound mapping support


A great improvement in the presentation and log messages. I can't
say that I dug into the implementation details of the PCIe inbound
mapping support.

So I'll ask one question. Can you confirm that the new additions
are all checkpatch.pl clean ?

Other than that, the changes are segmented pretty well, and won't
harm any other board, so no major concerns.



  arch/arm/Kconfig  |   13 +
  arch/arm/boot/dts/axm5504-sim.dts |6 +
  arch/arm/boot/dts/axm5508-amarillo.dts|2 +-
  arch/arm/boot/dts/axm5512-amarillo.dts|2 +-
  arch/arm/boot/dts/axm5516-amarillo.dts|2 +-
  arch/arm/boot/dts/axm5516-sim.dts |6 +
  arch/arm/boot/dts/axm55xx.dtsi|1 +


It would be nice if the DTS patches were separate from the implementation.
Smaller chunks are easier to review and merge.

Bruce


  arch/arm/mach-axxia/Makefile  |1 +
  arch/arm/mach-axxia/axxia.c   |7 +
  arch/arm/mach-axxia/include/mach/rio.h|   44 +
  arch/arm/mach-axxia/rapidio.c |  108 ++
  arch/powerpc/boot/dts/acp35xx.dts |   68 +-
  arch/powerpc/sysdev/lsi_pci.c |   42 +-
  drivers/dma/lsi-dma32.c   |  233 ++-
  drivers/dma/lsi-dma32.h   |7 +-
  drivers/rapidio/devices/Kconfig   |2 +
  drivers/rapidio/devices/Makefile  |2 +
  drivers/rapidio/devices/lsi/Kconfig   |   47 +
  drivers/rapidio/devices/lsi/Makefile  |5 +
  drivers/rapidio/devices/lsi/axxia-rio-irq.c   | 2532 +
  drivers/rapidio/devices/lsi/axxia-rio-irq.h   |  195 ++
  drivers/rapidio/devices/lsi/axxia-rio-sysfs.c |  278 +++
  drivers/rapidio/devices/lsi/axxia-rio.c   | 1751 +
  drivers/rapidio/devices/lsi/axxia-rio.h   |  595 ++
  24 files changed, 5829 insertions(+), 120 deletions(-)
  create mode 100644 arch/arm/mach-axxia/include/mach/rio.h
  create mode 100644 arch/arm/mach-axxia/rapidio.c
  create mode 100644 drivers/rapidio/devices/lsi/Kconfig
  create mode 100644 drivers/rapidio/devices/lsi/Makefile
  create mode 100644 drivers/rapidio/devices/lsi/axxia-rio-irq.c
  create mode 100644 drivers/rapidio/devices/lsi/axxia-rio-irq.h
  create mode 100644 drivers/rapidio/devices/lsi/axxia-rio-sysfs.c
  create mode 100644 drivers/rapidio/devices/lsi/axxia-rio.c
  create mode 100644 drivers/rapidio/devices/lsi/axxia-rio.h



--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


[linux-yocto] [PULL REQUEST] Kernel: 3.10 Branch: standard/axxia/base

2014-06-19 Thread Paul, Charlie
The following changes since commit 0651cf0a88bb3a8026328436bffc72da221f6ddf:

  Merge branch 'standard/base' into standard/axxia/base (2014-06-16 12:25:09 
-0400)

are available in the git repository at:


  https://github.com/z8cpaul/lsikernel-3.10 sab-next

for you to fetch changes up to d55b27f965f65b2d4b459e66c4f57093ce3646fc:

  Merge branch 'sab-next' of https://github.com/z8cpaul/lsikernel-3.10 into 
sab-next (2014-06-19 13:57:45 -0700)



Anders Berg (11):
  i2c: axxia: Minor cosmetic cleanup
  i2c: axxia: Fall back to polling mode when no IRQ
  misc: lsi-smmon: Bug when probing with IRQ pending
  misc: lsi-smmon: Add parameter panic_on_fatal
  ARM: dts: axxia: Added memory controllers
  dma: lsi-dma32: Add support for sg operation
  dma: lsi-dma32: Remove debug printks
  ARM: dts: axxia: Fix flash partitions
  dma: lsi-dma32: Add support for sg operation
  dma: lsi-dma32: Remove debug printks
  ARM: dts: axxia: Fix flash partitions

Charlie Paul (1):
  Merge branch 'sab-next' of https://github.com/z8cpaul/lsikernel-3.10 into 
sab-next

John Jacques (11):
  arch/arm/mach-axxia: Enable Secondary Cores when in Hyp Mode
  arch/arm/mach-axxia: Remove Unused Device Tree
  arch/arm/mach-axxia: Device Trees for New 5500 Variants
  board/powerpc: Update the Device Tree for 3500
  arch/arm: virtio
  arch/arm: Add Virtio Block Support to Axxia Simulation
  arch/arm/mach-axxia: Update Device Tree for KVM
  board/powerpc: Update the Device Tree for 3500
  arch/arm: virtio
  arch/arm: Add Virtio Block Support to Axxia Simulation
  arch/arm/mach-axxia: Update Device Tree for KVM

Palani (2):
  LSI AXM55xx RAPIDIO: Added support for the sRIO controller in the AXM55xx 
devices.
  LSI AXM55xx RAPIDIO: Added support for the sRIO controller in the AXM55xx 
devices.

SangeethaRao (2):
  sysdev LSI_POWERPC: Adding 3500 PCIe inbound mapping support
  sysdev LSI_POWERPC: Adding 3500 PCIe inbound mapping support

arch/arm/Kconfig  |   13 +
arch/arm/boot/dts/axm5504-sim.dts |6 +
arch/arm/boot/dts/axm5508-amarillo.dts|2 +-
arch/arm/boot/dts/axm5512-amarillo.dts|2 +-
arch/arm/boot/dts/axm5516-amarillo.dts|2 +-
arch/arm/boot/dts/axm5516-sim.dts |6 +
arch/arm/boot/dts/axm55xx.dtsi|1 +
arch/arm/mach-axxia/Makefile  |1 +
arch/arm/mach-axxia/axxia.c   |7 +
arch/arm/mach-axxia/include/mach/rio.h|   44 +
arch/arm/mach-axxia/rapidio.c |  108 ++
arch/powerpc/boot/dts/acp35xx.dts |   68 +-
arch/powerpc/sysdev/lsi_pci.c |   42 +-
drivers/dma/lsi-dma32.c   |  233 ++-
drivers/dma/lsi-dma32.h   |7 +-
drivers/rapidio/devices/Kconfig   |2 +
drivers/rapidio/devices/Makefile  |2 +
drivers/rapidio/devices/lsi/Kconfig   |   47 +
drivers/rapidio/devices/lsi/Makefile  |5 +
drivers/rapidio/devices/lsi/axxia-rio-irq.c   | 2532 +
drivers/rapidio/devices/lsi/axxia-rio-irq.h   |  195 ++
drivers/rapidio/devices/lsi/axxia-rio-sysfs.c |  278 +++
drivers/rapidio/devices/lsi/axxia-rio.c   | 1751 +
drivers/rapidio/devices/lsi/axxia-rio.h   |  595 ++
24 files changed, 5829 insertions(+), 120 deletions(-)
create mode 100644 arch/arm/mach-axxia/include/mach/rio.h
create mode 100644 arch/arm/mach-axxia/rapidio.c
create mode 100644 drivers/rapidio/devices/lsi/Kconfig
create mode 100644 drivers/rapidio/devices/lsi/Makefile
create mode 100644 drivers/rapidio/devices/lsi/axxia-rio-irq.c
create mode 100644 drivers/rapidio/devices/lsi/axxia-rio-irq.h
create mode 100644 drivers/rapidio/devices/lsi/axxia-rio-sysfs.c
create mode 100644 drivers/rapidio/devices/lsi/axxia-rio.c
create mode 100644 drivers/rapidio/devices/lsi/axxia-rio.h
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto