[PATCH] powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536
For MPC8572/MPC8536, the status of GPIOs defined as output cannot be determined by reading GPDAT register, so the code use shadow data register instead. But if the input pins are asserted high, they will always read high due to the shadow data, even if the pins are set to low. So the input pins should be read directly from GPDAT, not the shadow data. Signed-off-by: Liu Gang --- drivers/gpio/gpio-mpc8xxx.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c index 9ae29cc..1d4ac75 100644 --- a/drivers/gpio/gpio-mpc8xxx.c +++ b/drivers/gpio/gpio-mpc8xxx.c @@ -71,6 +71,7 @@ static int mpc8572_gpio_get(struct gpio_chip *gc, unsigned int gpio) struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm); val = in_be32(mm->regs + GPIO_DAT) & ~in_be32(mm->regs + GPIO_DIR); + mpc8xxx_gc->data &= in_be32(mm->regs + GPIO_DIR); return (val | mpc8xxx_gc->data) & mpc8xxx_gpio2mask(gpio); } -- 1.8.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536
On Tue, 2013-11-19 at 16:32 +0100, Anatolij Gustschin wrote: > On Fri, 15 Nov 2013 15:16:29 +0800 > Liu Gang wrote: > > > For MPC8572/MPC8536, the status of GPIOs defined as output > > cannot be determined by reading GPDAT register, so the code > > use shadow data register instead. But if the input pins are > > asserted high, they will always read high due to the shadow > > data, even if the pins are set to low. > > Could you please add a better description of the problem? > I'm having some difficulties to understand the last sentence > above. Does the issue appear if some pins were configured as > inputs and were asserted high before booting the kernel, and > therefore the shadow data has been initialized with these pin > values? > > Or does the issue appear if some pin has been configured as output > first and has been set to the high value, then reconfigured as > input? Now reading the pin state will always return high even > if the actual pin state is low? > > It seems the issue will appear in both cases. If so, please add > this information to the commit message. > Yes, you are right. I'll updated the description more clear. > > val = in_be32(mm->regs + GPIO_DAT) & ~in_be32(mm->regs + GPIO_DIR); > > + mpc8xxx_gc->data &= in_be32(mm->regs + GPIO_DIR); > > we can reduce one in_be32() call here, i.e. > > u32 out_mask; > ... > out_mask = in_be32(mm->regs + GPIO_DIR); > val = in_be32(mm->regs + GPIO_DAT) & ~out_mask; > mpc8xxx_gc->data &= out_mask; > > > return (val | mpc8xxx_gc->data) & mpc8xxx_gpio2mask(gpio); > > } > > Thanks, > > Anatolij > Granted, it will be better to reduce one in_be32() call. I'll improve the method based on your and Scott's comments. Thanks Liu Gang ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536
On Tue, 2013-11-19 at 16:51 -0600, Scott Wood wrote: > > @@ -71,6 +71,7 @@ static int mpc8572_gpio_get(struct gpio_chip *gc, > > unsigned int gpio) > > struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm); > > > > val = in_be32(mm->regs + GPIO_DAT) & ~in_be32(mm->regs + GPIO_DIR); > > + mpc8xxx_gc->data &= in_be32(mm->regs + GPIO_DIR); > > > > return (val | mpc8xxx_gc->data) & mpc8xxx_gpio2mask(gpio); > > } > > It seems odd to update ->data in a function that's supposed to be > reading things... Perhaps it would be better to keep ->data in a good > state from the beginning. > > -Scott Yes, keeping the ->data in a good state from the beginning will be better. But this will need more code in different functions to cover all the scenarios. First, we should check the direct of the pin in the function "mpc8xxx_gpio_set", and clean the input bit in ->data after setting operation. In addition, we may change a output pin to input and then read the input status. So we also should update the ->data in "mpc8xxx_gpio_dir_in" function. So maybe it's better to eliminate the effects of the ->data to the input pins when reading the status, regardless of the possible changes of the pins and the data. Do you think so? Best Regards, Liu Gang ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536
On Wed, 2013-11-20 at 18:32 -0600, Scott Wood wrote: > For userspace value setting, it looks like gpiolib blocks the write if > the pin if FLAG_IS_OUT is set. This suggests that this is an error > condition for other uses as well. Though, I notice that > mpc8xxx_gpio_dir_out() calls gpio_set() before actually changing the > direction. So it may be useful to avoid races where the wrong value is > output briefly after the direction is changed (especially in open drain > situations, where the signal could have a meaningful default even before > we begin outputting). But that raises the question of how you'd do that > from userspace, and it also renders the to-be-output value as write-only > data (until the direction is actually changed), since a readback would > get the input value instead. > > > So maybe it's better to eliminate the effects of the ->data to the > > input pins when reading the status, regardless of the possible changes > > of the pins and the data. > > Do you think so? > > Perhaps, but that doesn't require you to modify ->data in the get() > function. > > -Scott > I think you considered about this more comprehensive. I'll update the code without the modification of ->data in the get() function, and also with the comments from Anatolij. Best Regards, Liu Gang ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536
For MPC8572/MPC8536, the status of GPIOs defined as output cannot be determined by reading GPDAT register, so the code use shadow data register instead. But the code may give the wrong status of GPIOs defined as input under some scenarios: 1. If some pins were configured as inputs and were asserted high before booting the kernel, the shadow data has been initialized with those pin values. 2. Some pins have been configured as output first and have been set to the high value, then reconfigured as input. The above cases will make the shadow data for those input pins to be set to high. Then reading the pin status will always return high even if the actual pin status is low. The code should eliminate the effects of the shadow data to the input pins, and the status of those pins should be read directly from GPDAT. Signed-off-by: Liu Gang --- changes in v2: - Added more description of the problem. - Reduced one in_be32() call. - Do not modify the shadow data. drivers/gpio/gpio-mpc8xxx.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c index 914e859..d7d6d72 100644 --- a/drivers/gpio/gpio-mpc8xxx.c +++ b/drivers/gpio/gpio-mpc8xxx.c @@ -70,10 +70,14 @@ static int mpc8572_gpio_get(struct gpio_chip *gc, unsigned int gpio) u32 val; struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc); struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm); + u32 out_mask, out_shadow; - val = in_be32(mm->regs + GPIO_DAT) & ~in_be32(mm->regs + GPIO_DIR); + out_mask = in_be32(mm->regs + GPIO_DIR); - return (val | mpc8xxx_gc->data) & mpc8xxx_gpio2mask(gpio); + val = in_be32(mm->regs + GPIO_DAT) & ~out_mask; + out_shadow = mpc8xxx_gc->data & out_mask; + + return (val | out_shadow) & mpc8xxx_gpio2mask(gpio); } static int mpc8xxx_gpio_get(struct gpio_chip *gc, unsigned int gpio) -- 1.8.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536
On Fri, 2013-11-22 at 14:51 -0600, Kumar Gala wrote: > > drivers/gpio/gpio-mpc8xxx.c | 8 ++-- > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c > > index 914e859..d7d6d72 100644 > > --- a/drivers/gpio/gpio-mpc8xxx.c > > +++ b/drivers/gpio/gpio-mpc8xxx.c > > @@ -70,10 +70,14 @@ static int mpc8572_gpio_get(struct gpio_chip *gc, > > unsigned int gpio) > > u32 val; > > struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc); > > struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm); > > + u32 out_mask, out_shadow; > > > > - val = in_be32(mm->regs + GPIO_DAT) & ~in_be32(mm->regs + GPIO_DIR); > > + out_mask = in_be32(mm->regs + GPIO_DIR); > > > > - return (val | mpc8xxx_gc->data) & mpc8xxx_gpio2mask(gpio); > > + val = in_be32(mm->regs + GPIO_DAT) & ~out_mask; > > + out_shadow = mpc8xxx_gc->data & out_mask; > > + > > + return (val | out_shadow) & mpc8xxx_gpio2mask(gpio); > > } > > I really think a comment is worth adding here about why we do this. > > - k Hi, Kumar, Thanks for your comment. In fact, there already had some comments above the function: /* Workaround GPIO 1 errata on MPC8572/MPC8536. The status of GPIOs * defined as output cannot be determined by reading GPDAT register, * so we use shadow data register instead. The status of input pins * is determined by reading GPDAT register. */ Best Regards, Liu Gang ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/rmu: Fix the error memory free parameters
There are error parameters should be corrected when
calling dma_free_coherent to free rmu rx-ring buffers
in fsl_open_inb_mbox() function.
Signed-off-by: Liu Gang
Reported-by: Dan Carpenter
---
arch/powerpc/sysdev/fsl_rmu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rmu.c b/arch/powerpc/sysdev/fsl_rmu.c
index 00e224a..b48197a 100644
--- a/arch/powerpc/sysdev/fsl_rmu.c
+++ b/arch/powerpc/sysdev/fsl_rmu.c
@@ -881,9 +881,9 @@ fsl_open_inb_mbox(struct rio_mport *mport, void *dev_id,
int mbox, int entries)
rc = request_irq(IRQ_RIO_RX(mport), fsl_rio_rx_handler, 0,
"msg_rx", (void *)mport);
if (rc < 0) {
- dma_free_coherent(priv->dev, RIO_MSG_BUFFER_SIZE,
- rmu->msg_tx_ring.virt_buffer[i],
- rmu->msg_tx_ring.phys_buffer[i]);
+ dma_free_coherent(priv->dev,
+ rmu->msg_rx_ring.size * RIO_MAX_MSG_SIZE,
+ rmu->msg_rx_ring.virt, rmu->msg_rx_ring.phys);
goto out;
}
--
1.8.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] fsl-rio: Release rapidio port I/O region resource if port failed to initialize
The "struct rio_mport" contains a member of master port I/O memory resource structure "struct resource iores". This resource will be read from device tree and be used for rapidio R/W transaction memory space. Rapidio requests the port I/O memory resource under the root resource "iomem_resource". struct rio_mport *port; port = kzalloc(sizeof(struct rio_mport), GFP_KERNEL); request_resource(&iomem_resource, &port->iores); When port failed to initialize, allocated "rio_mport" structure memory will be freed, and the port I/O memory resource structure pointer "&port->iores" will be invalid. If other requests resource under "iomem_resource", "&port->iores" node may be operated in the child resources list and this will cause the system to crash. So the requested port I/O memory resource should be released before freeing allocated "rio_mport" structure. Signed-off-by: Liu Gang --- arch/powerpc/sysdev/fsl_rio.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c index c65f75a..22ffccd 100644 --- a/arch/powerpc/sysdev/fsl_rio.c +++ b/arch/powerpc/sysdev/fsl_rio.c @@ -1608,6 +1608,7 @@ int fsl_rio_setup(struct platform_device *dev) return 0; err: iounmap(priv->regs_win); + release_resource(&port->iores); err_res: kfree(priv); err_priv: -- 1.7.3.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/4] p4080ds-dts: Add two rapidio ports and message units support
Add two message units and number of ports according to the p4080 reference
manual.
Signed-off-by: Li Yang
Signed-off-by: Jin Qing
Signed-off-by: Liu Gang
---
arch/powerpc/boot/dts/p4080ds.dts |4 +-
arch/powerpc/boot/dts/p4080si.dtsi | 37 +++
2 files changed, 30 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/boot/dts/p4080ds.dts
b/arch/powerpc/boot/dts/p4080ds.dts
index eb11098..94a0cd4 100644
--- a/arch/powerpc/boot/dts/p4080ds.dts
+++ b/arch/powerpc/boot/dts/p4080ds.dts
@@ -101,9 +101,9 @@
};
};
- rapidio0: rapidio@ffe0c {
+ rapidio: rapidio@ffe0c {
reg = <0xf 0xfe0c 0 0x2>;
- ranges = <0 0 0xc 0x2000 0 0x0100>;
+ ranges = <0 0 0xc 0x2000 0 0x2000>;
};
localbus@ffe124000 {
diff --git a/arch/powerpc/boot/dts/p4080si.dtsi
b/arch/powerpc/boot/dts/p4080si.dtsi
index b71051f..816a629 100644
--- a/arch/powerpc/boot/dts/p4080si.dtsi
+++ b/arch/powerpc/boot/dts/p4080si.dtsi
@@ -69,8 +69,9 @@
rtic_c = &rtic_c;
rtic_d = &rtic_d;
sec_mon = &sec_mon;
+ rmu = &rmu;
- rio0 = &rapidio0;
+ rio = &rapidio;
};
cpus {
@@ -555,20 +556,38 @@
interrupt-parent = <&mpic>;
interrupts = <93 2 0 0>;
};
+
+ rmu: rmu@d3000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,rmu";
+ reg = <0xd3000 0x200>;
+
+ message-unit@0 {
+ reg = <0x0 0x100>;
+ interrupts = <
+ 60 2 0 0 /* msg1_tx_irq */
+ 61 2 0 0>;/* msg1_rx_irq */
+ };
+ message-unit@1 {
+ reg = <0x100 0x100>;
+ interrupts = <
+ 62 2 0 0 /* msg2_tx_irq */
+ 63 2 0 0>;/* msg2_rx_irq */
+ };
+ };
};
- rapidio0: rapidio@ffe0c {
+ rapidio: rapidio@ffe0c {
#address-cells = <2>;
#size-cells = <2>;
compatible = "fsl,rapidio-delta";
interrupts = <
- 16 2 1 11 /* err_irq */
- 56 2 0 0 /* bell_outb_irq */
- 57 2 0 0 /* bell_inb_irq */
- 60 2 0 0 /* msg1_tx_irq */
- 61 2 0 0 /* msg1_rx_irq */
- 62 2 0 0 /* msg2_tx_irq */
- 63 2 0 0>; /* msg2_rx_irq */
+ 16 2 1 11 /* err_irq */
+ 56 2 0 0 /* bell_outb_irq */
+ 57 2 0 0>;/* bell_inb_irq */
+ fsl,rio-num-ports = <2>;
+ rmu-handle = <&rmu>;
};
localbus@ffe124000 {
--
1.7.3.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/4] fsl-rio: Add two ports and rapidio message units support
Usually, freescale rapidio endpoint can support one 1X or two 4X LP-Serial link
interfaces,
and rapidio message transactions can be implemented by two message units. This
patch adds the
support of two rapidio ports and initializes message unit 0 and message unit 1.
And these ports
and message units can work simultaneously.
Signed-off-by: Li Yang
Signed-off-by: Jin Qing
Signed-off-by: Liu Gang
---
arch/powerpc/sysdev/fsl_rio.c | 336 +--
arch/powerpc/sysdev/fsl_rio.h | 73 +++-
arch/powerpc/sysdev/fsl_rmu.c | 434 -
3 files changed, 502 insertions(+), 341 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index 9484484..c7f8080 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -45,7 +45,6 @@
#define RIO_PORT1_IECSR0x10130
#define RIO_PORT2_IECSR0x101B0
-#define RIO_ATMU_REGS_OFFSET 0x10c00
#define RIO_GCCSR 0x13c
#define RIO_ESCSR 0x158
#define ESCSR_CLEAR0x07120204
@@ -74,6 +73,11 @@
: "b" (addr), "i" (-EFAULT), "0" (err))
void __iomem *rio_regs_win;
+void __iomem *rmu_regs_win;
+resource_size_t rio_law_start;
+
+struct fsl_rio_dbell *dbell;
+struct fsl_rio_pw *pw;
#ifdef CONFIG_E500
int fsl_rio_mcheck_exception(struct pt_regs *regs)
@@ -120,7 +124,7 @@ static int fsl_local_config_read(struct rio_mport *mport,
{
struct rio_priv *priv = mport->priv;
pr_debug("fsl_local_config_read: index %d offset %8.8x\n", index,
- offset);
+offset);
*data = in_be32(priv->regs_win + offset);
return 0;
@@ -173,7 +177,7 @@ fsl_rio_config_read(struct rio_mport *mport, int index, u16
destid,
pr_debug
("fsl_rio_config_read:"
" index %d destid %d hopcount %d offset %8.8x len %d\n",
-index, destid, hopcount, offset, len);
+ index, destid, hopcount, offset, len);
/* 16MB maintenance window possible */
/* allow only aligned access to maintenance registers */
@@ -230,8 +234,8 @@ fsl_rio_config_write(struct rio_mport *mport, int index,
u16 destid,
u8 *data;
pr_debug
("fsl_rio_config_write:"
- "index %d destid %d hopcount %d offset %8.8x len %d val
%8.8x\n",
-index, destid, hopcount, offset, len, val);
+ " index %d destid %d hopcount %d offset %8.8x len %d val
%8.8x\n",
+ index, destid, hopcount, offset, len, val);
/* 16MB maintenance windows possible */
/* allow only aligned access to maintenance registers */
@@ -260,7 +264,7 @@ fsl_rio_config_write(struct rio_mport *mport, int index,
u16 destid,
return 0;
}
-void fsl_rio_port_error_handler(struct rio_mport *port, int offset)
+void fsl_rio_port_error_handler(int offset)
{
/*XXX: Error recovery is not implemented, we just clear errors */
out_be32((u32 *)(rio_regs_win + RIO_LTLEDCSR), 0);
@@ -331,12 +335,17 @@ int fsl_rio_setup(struct platform_device *dev)
struct rio_mport *port;
struct rio_priv *priv;
int rc = 0;
- const u32 *dt_range, *cell;
- struct resource regs;
- int rlen;
+ const u32 *dt_range, *cell, *ports_num;
+ u32 active_ports = 0;
+ struct resource regs, rmu_regs;
+ struct device_node *np, *rmu_node;
+ int rlen, len;
u32 ccsr;
u64 law_start, law_size;
int paw, aw, sw;
+ int i;
+ static int tmp;
+ struct device_node *rmu_np[MAX_MSG_UNIT_NUM] = {NULL};
if (!dev->dev.of_node) {
dev_err(&dev->dev, "Device OF-Node is NULL");
@@ -360,6 +369,14 @@ int fsl_rio_setup(struct platform_device *dev)
return -EFAULT;
}
+ ports_num = of_get_property(dev->dev.of_node,
+ "fsl,rio-num-ports", &len);
+ if (!ports_num || len < sizeof(*ports_num)) {
+ dev_err(&dev->dev, "Can't get %s property 'rio-num-ports'\n",
+ dev->dev.of_node->full_name);
+ return -EFAULT;
+ }
+
/* Get node address wide */
cell = of_get_property(dev->dev.of_node, "#address-cells", NULL);
if (cell)
@@ -378,8 +395,17 @@ int fsl_rio_setup(struct platform_device *dev)
law_start = of_read_number(dt_range + aw, paw);
law_size = of_read_number(dt_range + aw + paw, sw);
+ rio_law_start = law_start;
+
dev_info(&dev->dev, "LAW start 0x%016llx, size 0x%016llx.\n",
law_start, law_size);
+ rio_regs_win = ioremap(regs.start, resource_size(®s));
+
+ if (!rio_
[PATCH 4/4] powerpc/fsl: Document rapidio node binding-information
This document is created for powerpc rapidio and rmu nodes in dts file. These
nodes
can support two rapidio ports and message units. In addition, It explicates the
properties
and gives examples about rapidio and rmu nodes.
Signed-off-by: Li Yang
Signed-off-by: Jin Qing
Signed-off-by: Liu Gang
---
.../devicetree/bindings/powerpc/fsl/srio.txt | 85
1 files changed, 85 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/srio.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/srio.txt
b/Documentation/devicetree/bindings/powerpc/fsl/srio.txt
new file mode 100644
index 000..01f2da1
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/srio.txt
@@ -0,0 +1,85 @@
+* Freescale Rapidio Controller
+
+Rapidio port node:
+Properties:
+ - compatible: "fsl,rapidio-delta".
+ "fsl,rapidio-delta" should be listed for any chip whose rapidio
controller is compatible.
+ At first, rapidio controller was introduced with the version of delta
and has no revision
+ register. Rapidio driver and controller were matched by
"fsl,rapidio-delta". After the
+ addition of two revision registers in rapidio controller, we can read
some revision and
+ configuration information about rapidio controller IP block, and the
compatible with
+ "fsl,rapidio-delta" was still used.
+
+ - reg: For devices compatible with "fsl,rapidio-delta", should contain
the address and
+ the length about all the rapidio controller's registers.
+
+ - ranges: Should be defined according to the u-boot settings about
SRIO. Describe the memory
+ mapped I/O space used by the rapidio controller.
+
+ - interrupts: Interrupt mapping for rapidio IRQ. Three interrupts in
the group, and starting
+ with SRIO error/port-write IRQ, an error interrupt and with interrupt
type 1. The other
+ two interrupts are doorbell outbound IRQ and doorbell inbound IRQ,
and they are external
+ interrupts.
+
+ - fsl,rio-num-ports: The number of rapidio ports supported by this
controller.
+
+ - fsl,liodn: The logical I/O device number for the PAMU to be correctly
configured for SRIO
+ accesses. This property is added in SRIO node by u-boot and usually
used by hypervisor.
+ The number of elements may either be 2 or 4 LIODN values. For HW that
only supports LIODNs
+ for ALL memory & maintenance transactions we have 2 cells. For HW
that has separate LIODNs
+ for memory & maintenance transaction we utilize 4 cells.
+
+ - rmu-handle: The phandle for the rmu connected to this rapidio
controller.
+
+Example:
+
+ rapidio: rapidio@ffe0c {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ compatible = "fsl,rapidio-delta";
+ interrupts = <
+ 16 2 1 11 /* err_irq */
+ 56 2 0 0 /* bell_outb_irq */
+ 57 2 0 0>;/* bell_inb_irq */
+ fsl,rio-num-ports = <2>;
+ rmu-handle = <&rmu>;
+ };
+
+Message unit node:
+Properties:
+ - compatible: "fsl,rmu".
+ "fsl,rmu" should be listed for any chip whose message unit is
compatible. In addition,
+ RMAN will replace RMU for rapidio message transaction in some chips
using DPAA architecture.
+ Then instead of RMU node, RMAN node will be used in dts file and the
compatible property
+ "fsl,rmu" should be replaced.
+
+ - reg: Registers mapping for message unit.
+
+ - interrupts: Interrupt mapping for message unit controller. Every
message
+ unit controller has two external interrupts: message outbound IRQ and
+ message inbound IRQ.
+
+ - fsl,liodn: The logical I/O device number for rmuliodnr and added by
u-boot.
+
+Example:
+
+ rmu: rmu@d3000 {
+ fsl,liodn = <0xc8>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,rmu";
+ reg = <0xd3000 0x200>;
+
+ message-unit@0 {
+ reg = <0x0 0x100>;
+ interrupts = <
+ 60 2 0 0 /* msg1_tx_irq */
+ 61 2 0 0>;/* msg1_rx_irq */
+ };
+ message-unit@1 {
+ reg = <0x100 0x100>;
+ interrupts = <
+ 62 2 0 0 /* msg2_tx_irq */
+ 63 2 0 0>;/* msg2_rx_irq */
+ };
+ };
--
1.7.3.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] fsl-rio: fix compile error
The "#include " was replaced by "#include " in the patch "powerpc: various straight conversions from module.h --> export.h". This will cause the following compile problem: arch/powerpc/sysdev/fsl_rio.c: In function 'fsl_rio_mcheck_exception': arch/powerpc/sysdev/fsl_rio.c:296: error: implicit declaration of function 'search_exception_tables'. The file fsl_rio.c needs the declaration of function "search_exception_tables" in the header file "linux/module.h". Signed-off-by: Liu Gang --- arch/powerpc/sysdev/fsl_rio.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c index de170fd..22ffccd 100644 --- a/arch/powerpc/sysdev/fsl_rio.c +++ b/arch/powerpc/sysdev/fsl_rio.c @@ -23,7 +23,7 @@ */ #include -#include +#include #include #include #include -- 1.7.3.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/5, v3] powerpc/8xxx: Update device tree bus probe for new RapidIO node binding
From: Kai Jiang
Update of_platform_bus_probe() RapidIO node to be compitable with
new RapidIO dts compatible property.
Signed-off-by: Kai Jiang
Signed-off-by: Kumar Gala
---
arch/powerpc/platforms/85xx/corenet_ds.c |2 +-
arch/powerpc/platforms/85xx/mpc85xx_mds.c |2 +-
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/corenet_ds.c
b/arch/powerpc/platforms/85xx/corenet_ds.c
index 802ad11..c48b661 100644
--- a/arch/powerpc/platforms/85xx/corenet_ds.c
+++ b/arch/powerpc/platforms/85xx/corenet_ds.c
@@ -112,7 +112,7 @@ static const struct of_device_id of_device_ids[]
__devinitconst = {
.compatible = "simple-bus"
},
{
- .compatible = "fsl,rapidio-delta",
+ .compatible = "fsl,srio",
},
{
.compatible = "fsl,p4080-pcie",
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index a23a3ff..7968ced 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -433,7 +433,7 @@ static struct of_device_id mpc85xx_ids[] = {
{ .compatible = "soc", },
{ .compatible = "simple-bus", },
{ .compatible = "gianfar", },
- { .compatible = "fsl,rapidio-delta", },
+ { .compatible = "fsl,srio", },
{ .compatible = "fsl,mpc8548-guts", },
{ .compatible = "gpio-leds", },
{},
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
index b11c353..569262c 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -161,7 +161,7 @@ mpc86xx_time_init(void)
static __initdata struct of_device_id of_bus_ids[] = {
{ .compatible = "simple-bus", },
- { .compatible = "fsl,rapidio-delta", },
+ { .compatible = "fsl,srio", },
{ .compatible = "gianfar", },
{},
};
--
1.7.3.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/5, v3] fsl-rio: Add two ports and rapidio message units support
Usually, freescale rapidio endpoint can support one or two 1x or 4X
LP-Serial link interfaces, and rapidio message transactions can be
implemented by two message units. This adds the support of two
rapidio ports and initializes message unit 0 and message unit 1. And
these ports and message units can work simultaneously.
Signed-off-by: Li Yang
Signed-off-by: Jin Qing
Signed-off-by: Liu Gang
Signed-off-by: Kumar Gala
---
arch/powerpc/sysdev/fsl_rio.c | 391 +---
arch/powerpc/sysdev/fsl_rio.h | 75 ++-
arch/powerpc/sysdev/fsl_rmu.c | 502 ++---
3 files changed, 545 insertions(+), 423 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index 9484484..a4c4f4a 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -45,7 +45,6 @@
#define RIO_PORT1_IECSR0x10130
#define RIO_PORT2_IECSR0x101B0
-#define RIO_ATMU_REGS_OFFSET 0x10c00
#define RIO_GCCSR 0x13c
#define RIO_ESCSR 0x158
#define ESCSR_CLEAR0x07120204
@@ -74,6 +73,11 @@
: "b" (addr), "i" (-EFAULT), "0" (err))
void __iomem *rio_regs_win;
+void __iomem *rmu_regs_win;
+resource_size_t rio_law_start;
+
+struct fsl_rio_dbell *dbell;
+struct fsl_rio_pw *pw;
#ifdef CONFIG_E500
int fsl_rio_mcheck_exception(struct pt_regs *regs)
@@ -120,7 +124,7 @@ static int fsl_local_config_read(struct rio_mport *mport,
{
struct rio_priv *priv = mport->priv;
pr_debug("fsl_local_config_read: index %d offset %8.8x\n", index,
- offset);
+offset);
*data = in_be32(priv->regs_win + offset);
return 0;
@@ -173,7 +177,7 @@ fsl_rio_config_read(struct rio_mport *mport, int index, u16
destid,
pr_debug
("fsl_rio_config_read:"
" index %d destid %d hopcount %d offset %8.8x len %d\n",
-index, destid, hopcount, offset, len);
+ index, destid, hopcount, offset, len);
/* 16MB maintenance window possible */
/* allow only aligned access to maintenance registers */
@@ -230,8 +234,8 @@ fsl_rio_config_write(struct rio_mport *mport, int index,
u16 destid,
u8 *data;
pr_debug
("fsl_rio_config_write:"
- "index %d destid %d hopcount %d offset %8.8x len %d val
%8.8x\n",
-index, destid, hopcount, offset, len, val);
+ " index %d destid %d hopcount %d offset %8.8x len %d val
%8.8x\n",
+ index, destid, hopcount, offset, len, val);
/* 16MB maintenance windows possible */
/* allow only aligned access to maintenance registers */
@@ -260,7 +264,7 @@ fsl_rio_config_write(struct rio_mport *mport, int index,
u16 destid,
return 0;
}
-void fsl_rio_port_error_handler(struct rio_mport *port, int offset)
+void fsl_rio_port_error_handler(int offset)
{
/*XXX: Error recovery is not implemented, we just clear errors */
out_be32((u32 *)(rio_regs_win + RIO_LTLEDCSR), 0);
@@ -331,16 +335,21 @@ int fsl_rio_setup(struct platform_device *dev)
struct rio_mport *port;
struct rio_priv *priv;
int rc = 0;
- const u32 *dt_range, *cell;
- struct resource regs;
+ const u32 *dt_range, *cell, *port_index;
+ u32 active_ports = 0;
+ struct resource regs, rmu_regs;
+ struct device_node *np, *rmu_node;
int rlen;
u32 ccsr;
- u64 law_start, law_size;
+ u64 range_start, range_size;
int paw, aw, sw;
+ u32 i;
+ static int tmp;
+ struct device_node *rmu_np[MAX_MSG_UNIT_NUM] = {NULL};
if (!dev->dev.of_node) {
dev_err(&dev->dev, "Device OF-Node is NULL");
- return -EFAULT;
+ return -ENODEV;
}
rc = of_address_to_resource(dev->dev.of_node, 0, ®s);
@@ -353,34 +362,13 @@ int fsl_rio_setup(struct platform_device *dev)
dev->dev.of_node->full_name);
dev_info(&dev->dev, "Regs: %pR\n", ®s);
- dt_range = of_get_property(dev->dev.of_node, "ranges", &rlen);
- if (!dt_range) {
- dev_err(&dev->dev, "Can't get %s property 'ranges'\n",
- dev->dev.of_node->full_name);
- return -EFAULT;
+ rio_regs_win = ioremap(regs.start, resource_size(®s));
+ if (!rio_regs_win) {
+ dev_err(&dev->dev, "Unable to map rio register window\n");
+ rc = -ENOMEM;
+ goto err_rio_regs;
}
- /* Get node address wide */
- cell = of_get_property(dev->dev.of_node, "#address-cells", NULL);
-
[PATCH 5/5, v3] powerpc/fsl: Document rapidio node binding-information
This document is created for powerpc rapidio and rmu nodes in dts file.
These nodes can support two rapidio ports and message units. In addition,
It explicates the properties and gives examples about rapidio and rmu nodes.
Signed-off-by: Li Yang
Signed-off-by: Jin Qing
Signed-off-by: Liu Gang
Signed-off-by: Kumar Gala
---
.../devicetree/bindings/powerpc/fsl/srio-rmu.txt | 163
.../devicetree/bindings/powerpc/fsl/srio.txt | 103
2 files changed, 266 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/srio-rmu.txt
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/srio.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/srio-rmu.txt
b/Documentation/devicetree/bindings/powerpc/fsl/srio-rmu.txt
new file mode 100644
index 000..b9a8a2b
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/srio-rmu.txt
@@ -0,0 +1,163 @@
+Message unit node:
+
+For SRIO controllers that implement the message unit as part of the controller
+this node is required. For devices with RMAN this node should NOT exist. The
+node is composed of three types of sub-nodes ("fsl-srio-msg-unit",
+"fsl-srio-dbell-unit" and "fsl-srio-port-write-unit").
+
+See srio.txt for more details about generic SRIO controller details.
+
+ - compatible
+ Usage: required
+ Value type:
+ Definition: Must include "fsl,srio-rmu-vX.Y", "fsl,srio-rmu".
+
+ The version X.Y should match the general SRIO controller's IP Block
+ revision register's Major(X) and Minor (Y) value.
+
+ - reg
+ Usage: required
+ Value type:
+ Definition: A standard property. Specifies the physical address and
+ length of the SRIO configuration registers for message units
+ and doorbell units.
+
+ - fsl,liodn
+ Usage: optional-but-recommended (for devices with PAMU)
+ Value type:
+ Definition: The logical I/O device number for the PAMU (IOMMU) to be
+ correctly configured for SRIO accesses. The property should
+ not exist on devices that do not support PAMU.
+
+ The LIODN value is associated with all RMU transactions
+ (msg-unit, doorbell, port-write).
+
+Sub-Nodes for RMU: The RMU node is composed of multiple sub-nodes that
+correspond to the actual sub-controllers in the RMU. The manual for a given
+SoC will detail which and how many of these sub-controllers are implemented.
+
+Message Unit:
+
+ - compatible
+ Usage: required
+ Value type:
+ Definition: Must include "fsl,srio-msg-unit-vX.Y", "fsl,srio-msg-unit".
+
+ The version X.Y should match the general SRIO controller's IP Block
+ revision register's Major(X) and Minor (Y) value.
+
+ - reg
+ Usage: required
+ Value type:
+ Definition: A standard property. Specifies the physical address and
+ length of the SRIO configuration registers for message units
+ and doorbell units.
+
+ - interrupts
+ Usage: required
+ Value type:
+ Definition: Specifies the interrupts generated by this device. The
+ value of the interrupts property consists of one interrupt
+ specifier. The format of the specifier is defined by the
+ binding document describing the node's interrupt parent.
+
+ A pair of IRQs are specified in this property. The first
+ element is associated with the transmit (TX) interrupt and the
+ second element is associated with the receive (RX) interrupt.
+
+Doorbell Unit:
+
+ - compatible
+ Usage: required
+ Value type:
+ Definition: Must include:
+ "fsl,srio-dbell-unit-vX.Y", "fsl,srio-dbell-unit"
+
+ The version X.Y should match the general SRIO controller's IP Block
+ revision register's Major(X) and Minor (Y) value.
+
+ - reg
+ Usage: required
+ Value type:
+ Definition: A standard property. Specifies the physical address and
+ length of the SRIO configuration registers for message units
+ and doorbell units.
+
+ - interrupts
+ Usage: required
+ Value type:
+ Definition: Specifies the interrupts generated by this device. The
+ value of the interrupts property consists of one interrupt
+ specifier. The format of the specifier is defined by the
+ binding document describing the node's interrupt parent.
+
+ A pair of IRQs are specified in this property. The first
+ element is associated with the transmit (TX) interrupt and the
+ second element is associated with the receive (RX) interrupt.
+
+Port-Write Unit:
+
+ - compati
[PATCH 3/5,v3] powerpc/85xx: Update SRIO device tree nodes
From: Kumar Gala
Update all dts files that support SRIO controllers to match the new
fsl,srio device tree binding.
Signed-off-by: Kumar Gala
---
arch/powerpc/boot/dts/mpc8568mds.dts | 66 ++---
arch/powerpc/boot/dts/mpc8569mds.dts | 72 +--
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 69 ---
arch/powerpc/boot/dts/p2041rdb.dts | 11 +
arch/powerpc/boot/dts/p2041si.dtsi | 20 +
arch/powerpc/boot/dts/p3041ds.dts | 11 +
arch/powerpc/boot/dts/p3041si.dtsi | 26 ---
arch/powerpc/boot/dts/p4080ds.dts | 12 -
arch/powerpc/boot/dts/p4080si.dtsi | 64 +++-
arch/powerpc/boot/dts/p5020ds.dts | 11 +
arch/powerpc/boot/dts/p5020si.dtsi | 26 ---
11 files changed, 314 insertions(+), 74 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts
b/arch/powerpc/boot/dts/mpc8568mds.dts
index 647daf8..2ca5387 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -26,7 +26,6 @@
serial1 = &serial1;
pci0 = &pci0;
pci1 = &pci1;
- rapidio0 = &rio0;
};
cpus {
@@ -331,6 +330,41 @@
};
};
+ rmu: rmu@d3000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,srio-rmu";
+ reg = <0xd3000 0x500>;
+ ranges = <0x0 0xd3000 0x500>;
+
+ message-unit@0 {
+ compatible = "fsl,srio-msg-unit";
+ reg = <0x0 0x100>;
+ interrupts = <
+ 53 2 /* msg1_tx_irq */
+ 54 2>;/* msg1_rx_irq */
+ };
+ message-unit@100 {
+ compatible = "fsl,srio-msg-unit";
+ reg = <0x100 0x100>;
+ interrupts = <
+ 55 2 /* msg2_tx_irq */
+ 56 2>;/* msg2_rx_irq */
+ };
+ doorbell-unit@400 {
+ compatible = "fsl,srio-dbell-unit";
+ reg = <0x400 0x80>;
+ interrupts = <
+ 49 2 /* bell_outb_irq */
+ 50 2>;/* bell_inb_irq */
+ };
+ port-write-unit@4e0 {
+ compatible = "fsl,srio-port-write-unit";
+ reg = <0x4e0 0x20>;
+ interrupts = <48 2>;
+ };
+ };
+
global-utilities@e {
#address-cells = <1>;
#size-cells = <1>;
@@ -638,22 +672,22 @@
};
};
- rio0: rapidio@e00c0 {
- #address-cells = <2>;
- #size-cells = <2>;
- compatible = "fsl,mpc8568-rapidio", "fsl,rapidio-delta";
- reg = <0xe00c 0x2>;
- ranges = <0x0 0x0 0xc000 0x0 0x2000>;
- interrupts = <48 2 /* error */
- 49 2 /* bell_outb */
- 50 2 /* bell_inb */
- 53 2 /* msg1_tx */
- 54 2 /* msg1_rx */
- 55 2 /* msg2_tx */
- 56 2 /* msg2_rx */>;
+ rapidio@e00c {
+ reg = <0xe00c 0x11000>;
+ compatible = "fsl,srio";
interrupt-parent = <&mpic>;
- sleep = <&pmc 0x0008 /* controller */
-&pmc 0x0004>; /* message unit */
+ interrupts = <48 2>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ fsl,srio-rmu-handle = <&rmu>;
+ ranges;
+
+ port1 {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ cell-index = <1>;
+ ranges = <0x0 0x0 0xc000 0x0 0x2000>;
+ };
};
leds {
diff --git a/arch/powerpc/boot/dts/mpc8569mds.dts
b/arch/powerpc/boot/dts/mpc8569mds.dts
index 8b72eaf..0d9d167 100644
--- a/arch/powerpc/boot/dts/mpc8569mds.dts
+++ b/arch/powerpc/boot/dts/mpc8569mds.dts
@@ -27,7 +27,6 @@
ethernet5 = &enet5;
ethernet7 = &enet7;
pci1 = &pci1;
- rapidio0 = &rio0;
};
cpus {
@@ -326,6 +325,41 @@
interrupt-
Re: [PATCH/RFC] rapidio: temporarily exclude FSL_RIO from 64 bit builds
On Sun, 2012-02-26 at 20:26 -0500, Paul Gortmaker wrote: > Hi Ben, > > Given a week has passed with the absence of any feedback > with respect to SRIO on 64 bit, are you OK with applying the > below patch[1] pretty much as-is? Hi, Paul, Ben, Sorry for the late reply because of my other urgent issues. I also found these errors of 64bit building last week. I'll provide patch for this issue as soon as possible. Thanks. Best Regards, Liu Gang ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/srio: Fix the compile errors when building with 64bit
For the file "arch/powerpc/sysdev/fsl_rmu.c", there will be some compile
errors while using the corenet64_smp_defconfig:
.../fsl_rmu.c:315: error: cast from pointer to integer of different size
.../fsl_rmu.c:320: error: cast to pointer from integer of different size
.../fsl_rmu.c:320: error: cast to pointer from integer of different size
.../fsl_rmu.c:320: error: cast to pointer from integer of different size
.../fsl_rmu.c:330: error: cast to pointer from integer of different size
.../fsl_rmu.c:332: error: cast to pointer from integer of different size
.../fsl_rmu.c:339: error: cast to pointer from integer of different size
.../fsl_rmu.c:340: error: cast to pointer from integer of different size
.../fsl_rmu.c:341: error: cast to pointer from integer of different size
.../fsl_rmu.c:348: error: cast to pointer from integer of different size
.../fsl_rmu.c:348: error: cast to pointer from integer of different size
.../fsl_rmu.c:348: error: cast to pointer from integer of different size
.../fsl_rmu.c:659: error: cast from pointer to integer of different size
.../fsl_rmu.c:659: error: format '%8.8x' expects type 'unsigned int',
but argument 5 has type 'size_t'
.../fsl_rmu.c:985: error: cast from pointer to integer of different size
.../fsl_rmu.c:997: error: cast to pointer from integer of different size
Rewrote the corresponding code with the support of 64bit building.
Signed-off-by: Liu Gang
Signed-off-by: Shaohui Xie
Signed-off-by: Paul Gortmaker
---
arch/powerpc/sysdev/fsl_rmu.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rmu.c b/arch/powerpc/sysdev/fsl_rmu.c
index 1548578..468011e 100644
--- a/arch/powerpc/sysdev/fsl_rmu.c
+++ b/arch/powerpc/sysdev/fsl_rmu.c
@@ -311,8 +311,8 @@ fsl_rio_dbell_handler(int irq, void *dev_instance)
/* XXX Need to check/dispatch until queue empty */
if (dsr & DOORBELL_DSR_DIQI) {
- u32 dmsg =
- (u32) fsl_dbell->dbell_ring.virt +
+ unsigned long dmsg =
+ (unsigned long) fsl_dbell->dbell_ring.virt +
(in_be32(&fsl_dbell->dbell_regs->dqdpar) & 0xfff);
struct rio_dbell *dbell;
int found = 0;
@@ -657,7 +657,8 @@ fsl_add_outb_message(struct rio_mport *mport, struct
rio_dev *rdev, int mbox,
int ret = 0;
pr_debug("RIO: fsl_add_outb_message(): destid %4.4x mbox %d buffer " \
-"%8.8x len %8.8x\n", rdev->destid, mbox, (int)buffer, len);
+"%8.8lx len %8.8zx\n", rdev->destid, mbox,
+ (unsigned long)buffer, len);
if ((len < 8) || (len > RIO_MAX_MSG_SIZE)) {
ret = -EINVAL;
goto out;
@@ -972,7 +973,7 @@ out:
void *fsl_get_inb_message(struct rio_mport *mport, int mbox)
{
struct fsl_rmu *rmu = GET_RMM_HANDLE(mport);
- u32 phys_buf, virt_buf;
+ unsigned long phys_buf, virt_buf;
void *buf = NULL;
int buf_idx;
@@ -982,7 +983,7 @@ void *fsl_get_inb_message(struct rio_mport *mport, int mbox)
if (phys_buf == in_be32(&rmu->msg_regs->ifqepar))
goto out2;
- virt_buf = (u32) rmu->msg_rx_ring.virt + (phys_buf
+ virt_buf = (unsigned long) rmu->msg_rx_ring.virt + (phys_buf
- rmu->msg_rx_ring.phys);
buf_idx = (phys_buf - rmu->msg_rx_ring.phys) / RIO_MAX_MSG_SIZE;
buf = rmu->msg_rx_ring.virt_buffer[buf_idx];
--
1.7.0.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/srio: Fix the compile errors when building with 64bit
Hi, Paul, On Fri, 2012-03-02 at 09:30 -0500, Paul Gortmaker wrote: > > Signed-off-by: Liu Gang > > Signed-off-by: Shaohui Xie > > Signed-off-by: Paul Gortmaker > > Hi Liu, > > You can't just go adding a "Signed-off-by:" line for me to a patch that > I've never seen before. Perhaps you meant to add "Reported-by:" ? > > Paul. I'm sorry for this. I added "Signed-off-by" for you because I wanted to thank you found this issue. I'll add "Reported-by:" if needed in the future. Best Regards, Liu Gang ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/srio: Fix the compile errors when building with 64bit
Hi, Kumar,
On Fri, 2012-03-02 at 09:11 -0600, Kumar Gala wrote:
> > diff --git a/arch/powerpc/sysdev/fsl_rmu.c b/arch/powerpc/sysdev/fsl_rmu.c
> > index 1548578..468011e 100644
> > --- a/arch/powerpc/sysdev/fsl_rmu.c
> > +++ b/arch/powerpc/sysdev/fsl_rmu.c
> > @@ -311,8 +311,8 @@ fsl_rio_dbell_handler(int irq, void *dev_instance)
> >
> > /* XXX Need to check/dispatch until queue empty */
> > if (dsr & DOORBELL_DSR_DIQI) {
> > - u32 dmsg =
> > - (u32) fsl_dbell->dbell_ring.virt +
> > + unsigned long dmsg =
> > + (unsigned long) fsl_dbell->dbell_ring.virt +
> > (in_be32(&fsl_dbell->dbell_regs->dqdpar) & 0xfff);
> > struct rio_dbell *dbell;
> > int found = 0;
> > @@ -657,7 +657,8 @@ fsl_add_outb_message(struct rio_mport *mport, struct
> > rio_dev *rdev, int mbox,
> > int ret = 0;
> >
> > pr_debug("RIO: fsl_add_outb_message(): destid %4.4x mbox %d buffer " \
> > -"%8.8x len %8.8x\n", rdev->destid, mbox, (int)buffer, len);
> > +"%8.8lx len %8.8zx\n", rdev->destid, mbox,
> > + (unsigned long)buffer, len);
> > if ((len < 8) || (len > RIO_MAX_MSG_SIZE)) {
> > ret = -EINVAL;
> > goto out;
>
> For this case it seems as if some cast should be added to DBELL_* macros
Do you mean the DBELL_* macro should be added the cast "u16" and like
this:
#define DBELL_SID(x)(u16)(*(u16 *)(x + DOORBELL_SID_OFFSET))
> > @@ -972,7 +973,7 @@ out:
> > void *fsl_get_inb_message(struct rio_mport *mport, int mbox)
> > {
> > struct fsl_rmu *rmu = GET_RMM_HANDLE(mport);
> > - u32 phys_buf, virt_buf;
> > + unsigned long phys_buf, virt_buf;
>
> Do you really want to change phys_buf to an 'unsigned long'?
>
> Should virt_buf really be void * here?
I think you are right, the phys_buf should not be changed to 'unsigned
long' and the virt_buf should be void *. I'll correct this in next
version.
> > @@ -982,7 +983,7 @@ void *fsl_get_inb_message(struct rio_mport *mport, int
> > mbox)
>
> The memcpy later could remove a cast if you make virt_buf a void *.
Thanks a lot, will remove.
Best Regards,
Liu Gang
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/srio: Fix the relocation errors when building with 64bit
For the file "arch/powerpc/sysdev/fsl_rio.c", there will be some relocation errors while using the corenet64_smp_defconfig: WARNING: modpost: Found 6 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' GEN .version CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 arch/powerpc/sysdev/built-in.o:(__ex_table+0x0): relocation truncated to fit: R_PPC64_ADDR16 against `.text'+3208 arch/powerpc/sysdev/built-in.o:(__ex_table+0x2): relocation truncated to fit: R_PPC64_ADDR16 against `.fixup' arch/powerpc/sysdev/built-in.o:(__ex_table+0x4): relocation truncated to fit: R_PPC64_ADDR16 against `.text'+3230 arch/powerpc/sysdev/built-in.o:(__ex_table+0x6): relocation truncated to fit: R_PPC64_ADDR16 against `.fixup'+c arch/powerpc/sysdev/built-in.o:(__ex_table+0x8): relocation truncated to fit: R_PPC64_ADDR16 against `.text'+3250 arch/powerpc/sysdev/built-in.o:(__ex_table+0xa): relocation truncated to fit: R_PPC64_ADDR16 against `.fixup'+18 Rewrote the corresponding code with the support of 64bit building. Signed-off-by: Liu Gang --- arch/powerpc/sysdev/fsl_rio.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c index a4c4f4a..5b6f556 100644 --- a/arch/powerpc/sysdev/fsl_rio.c +++ b/arch/powerpc/sysdev/fsl_rio.c @@ -66,8 +66,8 @@ " li %0,%3\n" \ " b 2b\n" \ ".section __ex_table,\"a\"\n" \ - " .align 2\n" \ - " .long 1b,3b\n" \ + PPC_LONG_ALIGN "\n" \ + PPC_LONG "1b,3b\n" \ ".text" \ : "=r" (err), "=r" (x) \ : "b" (addr), "i" (-EFAULT), "0" (err)) -- 1.7.0.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/srio: Fix the compile errors when building with 64bit
Hi, Kumar,
On Tue, 2012-03-06 at 11:46 -0600, Kumar Gala wrote:
> How about a struct instead:
>
> struct rmu_dmsg {
> u16 dummy;
> u16 tid;
> u16 sid;
> u16 info;
> };
>
> struct rmu_dmsg *dmsg = fsl_dbell->dbell_ring.virt +
> (in_be32(&fsl_dbell->dbell_regs->dqdpar) & 0xfff);
>
> Than you can git rid of the DBELL_* macros.
Yes, this can really git rid of the DBELL_* macros and some other code.
I'll update the patch based on your comments.
Thanks a lot.
Liu Gang
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] powerpc/srio: Fix the compile errors when building with 64bit
For the file "arch/powerpc/sysdev/fsl_rmu.c", there will be some compile
errors while using the corenet64_smp_defconfig:
.../fsl_rmu.c:315: error: cast from pointer to integer of different size
.../fsl_rmu.c:320: error: cast to pointer from integer of different size
.../fsl_rmu.c:320: error: cast to pointer from integer of different size
.../fsl_rmu.c:320: error: cast to pointer from integer of different size
.../fsl_rmu.c:330: error: cast to pointer from integer of different size
.../fsl_rmu.c:332: error: cast to pointer from integer of different size
.../fsl_rmu.c:339: error: cast to pointer from integer of different size
.../fsl_rmu.c:340: error: cast to pointer from integer of different size
.../fsl_rmu.c:341: error: cast to pointer from integer of different size
.../fsl_rmu.c:348: error: cast to pointer from integer of different size
.../fsl_rmu.c:348: error: cast to pointer from integer of different size
.../fsl_rmu.c:348: error: cast to pointer from integer of different size
.../fsl_rmu.c:659: error: cast from pointer to integer of different size
.../fsl_rmu.c:659: error: format '%8.8x' expects type 'unsigned int',
but argument 5 has type 'size_t'
.../fsl_rmu.c:985: error: cast from pointer to integer of different size
.../fsl_rmu.c:997: error: cast to pointer from integer of different size
Rewrote the corresponding code with the support of 64bit building.
Signed-off-by: Liu Gang
Signed-off-by: Shaohui Xie
Reported-by: Paul Gortmaker
---
Changes in v2:
- Add the struct "rio_dbell_msg" to instead of some DBELL_* macros.
- Change the "virt_buf" to be "void *" type.
- Change "Signed-off-by" to "Reported-by" for Paul.
arch/powerpc/sysdev/fsl_rmu.c | 43 +---
1 files changed, 23 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rmu.c b/arch/powerpc/sysdev/fsl_rmu.c
index 1548578..1bba6d1 100644
--- a/arch/powerpc/sysdev/fsl_rmu.c
+++ b/arch/powerpc/sysdev/fsl_rmu.c
@@ -100,14 +100,8 @@
#define DOORBELL_DSR_TE0x0080
#define DOORBELL_DSR_QFI 0x0010
#define DOORBELL_DSR_DIQI 0x0001
-#define DOORBELL_TID_OFFSET0x02
-#define DOORBELL_SID_OFFSET0x04
-#define DOORBELL_INFO_OFFSET 0x06
#define DOORBELL_MESSAGE_SIZE 0x08
-#define DBELL_SID(x) (*(u16 *)(x + DOORBELL_SID_OFFSET))
-#define DBELL_TID(x) (*(u16 *)(x + DOORBELL_TID_OFFSET))
-#define DBELL_INF(x) (*(u16 *)(x + DOORBELL_INFO_OFFSET))
struct rio_msg_regs {
u32 omr;
@@ -193,6 +187,13 @@ struct fsl_rmu {
int rxirq;
};
+struct rio_dbell_msg {
+ u16 pad1;
+ u16 tid;
+ u16 sid;
+ u16 info;
+};
+
/**
* fsl_rio_tx_handler - MPC85xx outbound message interrupt handler
* @irq: Linux interrupt number
@@ -311,8 +312,8 @@ fsl_rio_dbell_handler(int irq, void *dev_instance)
/* XXX Need to check/dispatch until queue empty */
if (dsr & DOORBELL_DSR_DIQI) {
- u32 dmsg =
- (u32) fsl_dbell->dbell_ring.virt +
+ struct rio_dbell_msg *dmsg =
+ fsl_dbell->dbell_ring.virt +
(in_be32(&fsl_dbell->dbell_regs->dqdpar) & 0xfff);
struct rio_dbell *dbell;
int found = 0;
@@ -320,25 +321,25 @@ fsl_rio_dbell_handler(int irq, void *dev_instance)
pr_debug
("RIO: processing doorbell,"
" sid %2.2x tid %2.2x info %4.4x\n",
- DBELL_SID(dmsg), DBELL_TID(dmsg), DBELL_INF(dmsg));
+ dmsg->sid, dmsg->tid, dmsg->info);
for (i = 0; i < MAX_PORT_NUM; i++) {
if (fsl_dbell->mport[i]) {
list_for_each_entry(dbell,
&fsl_dbell->mport[i]->dbells, node) {
if ((dbell->res->start
- <= DBELL_INF(dmsg))
+ <= dmsg->info)
&& (dbell->res->end
- >= DBELL_INF(dmsg))) {
+ >= dmsg->info)) {
found = 1;
break;
}
}
if (found && dbell->dinb) {
dbell->dinb(fsl_dbell->mport[i],
- dbell->dev_id, DBELL_SID(dmsg),
-
RE: [PATCH v2] powerpc/srio: Fix the compile errors when building with 64bit
Hi, David,
On Wed, 2012-03-07 at 13:18 +, David Laight wrote:
> > pr_debug("RIO: fsl_add_outb_message(): destid %4.4x mbox %d
> buffer " \
> > -"%8.8x len %8.8x\n", rdev->destid, mbox, (int)buffer,
> len);
> > +"%8.8lx len %8.8zx\n", rdev->destid, mbox,
> > + (unsigned long)buffer, len);
>
> Should 'buffer' be printed with %p ??
Yes, printing with "%p" can get rid of the cast, although they have the
same print results.
Thanks a lot.
Liu Gang
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3] powerpc/srio: Fix the compile errors when building with 64bit
For the file "arch/powerpc/sysdev/fsl_rmu.c", there will be some compile
errors while using the corenet64_smp_defconfig:
.../fsl_rmu.c:315: error: cast from pointer to integer of different size
.../fsl_rmu.c:320: error: cast to pointer from integer of different size
.../fsl_rmu.c:320: error: cast to pointer from integer of different size
.../fsl_rmu.c:320: error: cast to pointer from integer of different size
.../fsl_rmu.c:330: error: cast to pointer from integer of different size
.../fsl_rmu.c:332: error: cast to pointer from integer of different size
.../fsl_rmu.c:339: error: cast to pointer from integer of different size
.../fsl_rmu.c:340: error: cast to pointer from integer of different size
.../fsl_rmu.c:341: error: cast to pointer from integer of different size
.../fsl_rmu.c:348: error: cast to pointer from integer of different size
.../fsl_rmu.c:348: error: cast to pointer from integer of different size
.../fsl_rmu.c:348: error: cast to pointer from integer of different size
.../fsl_rmu.c:659: error: cast from pointer to integer of different size
.../fsl_rmu.c:659: error: format '%8.8x' expects type 'unsigned int',
but argument 5 has type 'size_t'
.../fsl_rmu.c:985: error: cast from pointer to integer of different size
.../fsl_rmu.c:997: error: cast to pointer from integer of different size
Rewrote the corresponding code with the support of 64bit building.
Signed-off-by: Liu Gang
Signed-off-by: Shaohui Xie
Reported-by: Paul Gortmaker
---
Changes in v2:
- Add the struct "rio_dbell_msg" to instead of some DBELL_* macros.
- Change the "virt_buf" to be "void *" type.
- Change "Signed-off-by" to "Reported-by" for Paul.
Changes in v3:
- Change the "%8.8lx" to be "%p" and remove the cast of the "buffer"
arch/powerpc/sysdev/fsl_rmu.c | 42 +---
1 files changed, 22 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rmu.c b/arch/powerpc/sysdev/fsl_rmu.c
index 1548578..14bd522 100644
--- a/arch/powerpc/sysdev/fsl_rmu.c
+++ b/arch/powerpc/sysdev/fsl_rmu.c
@@ -100,14 +100,8 @@
#define DOORBELL_DSR_TE0x0080
#define DOORBELL_DSR_QFI 0x0010
#define DOORBELL_DSR_DIQI 0x0001
-#define DOORBELL_TID_OFFSET0x02
-#define DOORBELL_SID_OFFSET0x04
-#define DOORBELL_INFO_OFFSET 0x06
#define DOORBELL_MESSAGE_SIZE 0x08
-#define DBELL_SID(x) (*(u16 *)(x + DOORBELL_SID_OFFSET))
-#define DBELL_TID(x) (*(u16 *)(x + DOORBELL_TID_OFFSET))
-#define DBELL_INF(x) (*(u16 *)(x + DOORBELL_INFO_OFFSET))
struct rio_msg_regs {
u32 omr;
@@ -193,6 +187,13 @@ struct fsl_rmu {
int rxirq;
};
+struct rio_dbell_msg {
+ u16 pad1;
+ u16 tid;
+ u16 sid;
+ u16 info;
+};
+
/**
* fsl_rio_tx_handler - MPC85xx outbound message interrupt handler
* @irq: Linux interrupt number
@@ -311,8 +312,8 @@ fsl_rio_dbell_handler(int irq, void *dev_instance)
/* XXX Need to check/dispatch until queue empty */
if (dsr & DOORBELL_DSR_DIQI) {
- u32 dmsg =
- (u32) fsl_dbell->dbell_ring.virt +
+ struct rio_dbell_msg *dmsg =
+ fsl_dbell->dbell_ring.virt +
(in_be32(&fsl_dbell->dbell_regs->dqdpar) & 0xfff);
struct rio_dbell *dbell;
int found = 0;
@@ -320,25 +321,25 @@ fsl_rio_dbell_handler(int irq, void *dev_instance)
pr_debug
("RIO: processing doorbell,"
" sid %2.2x tid %2.2x info %4.4x\n",
- DBELL_SID(dmsg), DBELL_TID(dmsg), DBELL_INF(dmsg));
+ dmsg->sid, dmsg->tid, dmsg->info);
for (i = 0; i < MAX_PORT_NUM; i++) {
if (fsl_dbell->mport[i]) {
list_for_each_entry(dbell,
&fsl_dbell->mport[i]->dbells, node) {
if ((dbell->res->start
- <= DBELL_INF(dmsg))
+ <= dmsg->info)
&& (dbell->res->end
- >= DBELL_INF(dmsg))) {
+ >= dmsg->info)) {
found = 1;
break;
}
}
if (found && dbell->dinb) {
dbell->dinb(fsl_dbell->mport[i],
-
[PATCH] fsl-rio: Correct IECSR register clear value
The RETE bit in IECSR is cleared by writing a 1 to it.
Signed-off-by: Liu Gang
---
arch/powerpc/sysdev/fsl_rio.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index b3fd081..cdd765b 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -54,6 +54,7 @@
#define ODSR_CLEAR 0x1c00
#define LTLEECSR_ENABLE_ALL0xFFC000FC
#define ESCSR_CLEAR0x07120204
+#define IECSR_CLEAR0x8000
#define RIO_PORT1_EDCSR0x0640
#define RIO_PORT2_EDCSR0x0680
@@ -1089,11 +1090,11 @@ static void port_error_handler(struct rio_mport *port,
int offset)
if (offset == 0) {
out_be32((u32 *)(rio_regs_win + RIO_PORT1_EDCSR), 0);
- out_be32((u32 *)(rio_regs_win + RIO_PORT1_IECSR), 0);
+ out_be32((u32 *)(rio_regs_win + RIO_PORT1_IECSR), IECSR_CLEAR);
out_be32((u32 *)(rio_regs_win + RIO_ESCSR), ESCSR_CLEAR);
} else {
out_be32((u32 *)(rio_regs_win + RIO_PORT2_EDCSR), 0);
- out_be32((u32 *)(rio_regs_win + RIO_PORT2_IECSR), 0);
+ out_be32((u32 *)(rio_regs_win + RIO_PORT2_IECSR), IECSR_CLEAR);
out_be32((u32 *)(rio_regs_win + RIO_PORT2_ESCSR), ESCSR_CLEAR);
}
}
--
1.7.3.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] rio: Use discovered bit to test if enumeration is complete
The discovered bit in PGCCSR register indicates if the device has been discovered by system host. In Rapidio system, some agent devices can also be master devices. They can issue requests into the system. Signed-off-by: Liu Gang --- drivers/rapidio/rio-scan.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/rapidio/rio-scan.c b/drivers/rapidio/rio-scan.c index ee89358..2dac1f0 100644 --- a/drivers/rapidio/rio-scan.c +++ b/drivers/rapidio/rio-scan.c @@ -924,7 +924,7 @@ static int __devinit rio_enum_peer(struct rio_net *net, struct rio_mport *port, * rio_enum_complete- Tests if enumeration of a network is complete * @port: Master port to send transaction * - * Tests the Component Tag CSR for non-zero value (enumeration + * Tests the PGCCSR discovered bit for non-zero value (enumeration * complete flag). Return %1 if enumeration is complete or %0 if * enumeration is incomplete. */ @@ -934,7 +934,7 @@ static int rio_enum_complete(struct rio_mport *port) rio_local_read_config_32(port, port->phys_efptr + RIO_PORT_GEN_CTL_CSR, ®val); - return (regval & RIO_PORT_GEN_MASTER) ? 1 : 0; + return (regval & RIO_PORT_GEN_DISCOVERED) ? 1 : 0; } /** -- 1.7.3.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 4/4] powerpc/fsl: Document rapidio node binding-information
Thanks Kumar! I'll update these SRIO patches following all your comments.
Regards,
Liu Gang
-Original Message-
From: Kumar Gala [mailto:ga...@kernel.crashing.org]
Sent: Thursday, September 29, 2011 10:21 PM
To: Liu Gang-B34182
Cc: linuxppc-dev@lists.ozlabs.org; a...@linux-foundation.org;
linux-ker...@vger.kernel.org; Li Yang-R58472; Gala Kumar-B11780; Zang
Roy-R61911; Li Yang-R58472; Jin Qing
Subject: Re: [PATCH 4/4] powerpc/fsl: Document rapidio node binding-information
On Sep 28, 2011, at 9:29 PM, Liu Gang wrote:
> This document is created for powerpc rapidio and rmu nodes in dts
> file. These nodes can support two rapidio ports and message units. In
> addition, It explicates the properties and gives examples about rapidio and
> rmu nodes.
>
> Signed-off-by: Li Yang
> Signed-off-by: Jin Qing
> Signed-off-by: Liu Gang
> ---
> .../devicetree/bindings/powerpc/fsl/srio.txt | 85
> 1 files changed, 85 insertions(+), 0 deletions(-) create mode 100644
> Documentation/devicetree/bindings/powerpc/fsl/srio.txt
You need to fix this for 80 char column line wrap.
>
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/srio.txt
> b/Documentation/devicetree/bindings/powerpc/fsl/srio.txt
> new file mode 100644
> index 000..01f2da1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/srio.txt
> @@ -0,0 +1,85 @@
> +* Freescale Rapidio Controller
> +
> +Rapidio port node:
> +Properties:
> + - compatible: "fsl,rapidio-delta".
> + "fsl,rapidio-delta" should be listed for any chip whose rapidio
> controller is compatible.
> + At first, rapidio controller was introduced with the version of delta
> and has no revision
> + register. Rapidio driver and controller were matched by
> "fsl,rapidio-delta". After the
> + addition of two revision registers in rapidio controller, we can read
> some revision and
> + configuration information about rapidio controller IP block, and the
> compatible with
> + "fsl,rapidio-delta" was still used.
Lets go ahead and change this from 'fsl,rapdio-delta' to 'fsl,srio' since
you're changing how the binding is defined completely. This way old .dts will
fail graceful with the new code.
> +
> + - reg: For devices compatible with "fsl,rapidio-delta", should contain
> the address and
> + the length about all the rapidio controller's registers.
> +
> + - ranges: Should be defined according to the u-boot settings about
> SRIO. Describe the memory
> + mapped I/O space used by the rapidio controller.
> +
> + - interrupts: Interrupt mapping for rapidio IRQ. Three interrupts in
> the group, and starting
> + with SRIO error/port-write IRQ, an error interrupt and with interrupt
> type 1. The other
> + two interrupts are doorbell outbound IRQ and doorbell inbound IRQ,
> and they are external
> + interrupts.
be clear about the order of the interrupts
> +
> + - fsl,rio-num-ports: The number of rapidio ports supported by this
> controller.
> +
> + - fsl,liodn: The logical I/O device number for the PAMU to be correctly
> configured for SRIO
> + accesses. This property is added in SRIO node by u-boot and usually
> used by hypervisor.
> + The number of elements may either be 2 or 4 LIODN values. For HW that
> only supports LIODNs
> + for ALL memory & maintenance transactions we have 2 cells.
We need to add something like:
In this case, the first cell is the LIODN associated with the port 1 and the
second LIODN is associated with port 2.
> For HW that has separate LIODNs
> + for memory & maintenance transaction we utilize 4 cells.
In this case, the first pair of cells are associated with port 1. The first
cell is the LIODN associated with memory transactions, the second cell is the
LIODN associated with maintenance transactions. The 3 and 4 cells follow the
same pattern for port 2.
> +
> + - rmu-handle: The phandle for the rmu connected to this rapidio
> controller.
> +
> +Example:
> +
> + rapidio: rapidio@ffe0c {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + compatible = "fsl,rapidio-delta";
> + interrupts = <
> + 16 2 1 11 /* err_irq */
> + 56 2 0 0 /* bell_outb_irq */
> + 57 2 0 0>;/* bell_inb_irq */
> + fsl,rio-num-ports = <2>;
> + rmu-handle = <&rmu>;
> + };
> +
> +Message unit node:
> +Properties:
> + - compatible: "fsl,rmu&quo
RE: [PATCH 3/5][v2] fsl-rio: Add two ports and rapidio message units support
Hi, Alex,
Thanks for your comments, please find my replies inlines.
-Original Message-
From: Bounine, Alexandre [mailto:alexandre.boun...@idt.com]
Sent: Thursday, October 20, 2011 3:54 AM
To: Kumar Gala; linuxppc-...@ozlabs.org
Cc: Andrew Morton; Liu Gang-B34182; linux-ker...@vger.kernel.org
Subject: RE: [PATCH 3/5][v2] fsl-rio: Add two ports and rapidio message units
support
On Thu, Oct 13, 2011 at 10:09 AM, Kumar Gala wrote:
>
> From: Liu Gang
>
> Usually, freescale rapidio endpoint can support one 1X or two 4X LP-
> Serial link interfaces, and rapidio message transactions can be
> implemented
by
> two
Is the number of 1x ports described correctly?
Can we have two 1x ports as well?
[Liu Gang-B34182] Yes you are right. endpoint can also have two 1x ports. I'll
correct it.
> message units. This patch adds the support of two rapidio ports and
> initializes message unit 0 and message unit 1. And these ports and
> message
... skip ...
> +
> + /* Probe the master port phy type */
> + ccsr = in_be32(priv->regs_win + RIO_CCSR + i*0x20);
> + port->phy_type = (ccsr & 1) ? RIO_PHY_SERIAL :
> RIO_PHY_PARALLEL;
> + dev_info(&dev->dev, "RapidIO PHY type: %s\n",
> +(port->phy_type == RIO_PHY_PARALLEL) ?
> +"parallel" :
> +((port->phy_type == RIO_PHY_SERIAL) ?
"serial"
> :
> + "unknown"));
> + /* Checking the port training status */
> + if (in_be32((priv->regs_win + RIO_ESCSR + i*0x20)) & 1)
{
> + dev_err(&dev->dev, "Port %d is not ready. "
> +"Try to restart connection...\n", i);
> + switch (port->phy_type) {
> + case RIO_PHY_SERIAL:
> +/* Disable ports */
> +out_be32(priv->regs_win
> + + RIO_CCSR + i*0x20, 0);
> +/* Set 1x lane */
> +setbits32(priv->regs_win
> + + RIO_CCSR + i*0x20,
0x0200);
> +/* Enable ports */
> +setbits32(priv->regs_win
> + + RIO_CCSR + i*0x20,
0x0060);
> +break;
> + case RIO_PHY_PARALLEL:
> +/* Disable ports */
> +out_be32(priv->regs_win
> + + RIO_CCSR + i*0x20,
0x2200);
> +/* Enable ports */
> +out_be32(priv->regs_win
> + + RIO_CCSR + i*0x20,
0x4400);
> +break;
> + }
Probably this may be a good moment to drop the support for parallel link.
Especially after you renamed controller to "srio" in the device tree.
[Liu Gang-B34182] I'm also considering if we should drop the parallel link
support and doorbell outbound ATMU configuration.
I found some older powerpc chips support parallel link, like mpc8540 and so on.
But DTS files of these chips do not support
Rapidio nodes. For example we can't find rapidio node in
arch/powerpc/boot/dts/mpc8540ads.dts file. So can we conclude that
these chips with parallel rapidio link do not need the support for rapidio
module and the code for parallel link can be removed?
> + msleep(100);
> + if (in_be32((priv->regs_win
> + + RIO_ESCSR + i*0x20)) & 1) {
> +dev_err(&dev->dev,
> + "Port %d restart failed.\n", i);
> +release_resource(&port->iores);
> +kfree(priv);
> +kfree(port);
> +continue;
> + }
> + dev_info(&dev->dev, "Port %d restart
success!\n", i);
> + }
> + fsl_rio_info(&dev->dev, ccsr);
> +
... skip ...
>
> struct rio_msg_regs {
> - u32 omr; /* 0xD_3000 - Outbound message 0 mode register
*/
> - u32 osr; /* 0xD_3004 - Outbound message 0 status register
*/
> + u32 omr;
> + u32 osr;
> u32 pad1;
> - u32 odqdpar; /* 0xD_300C - Outbound message 0 descriptor
> queue
> - dequeue pointer address register */
> + u32 odqdpar;
> u32 pad2;
> - u32 osar; /* 0xD_3014 - Outbound message 0 source address
> - register */
> - u32 odpr; /* 0xD_3018 - Outbound message 0 destination
port
> - register */
> - u32 odatr; /* 0xD_301C - Outbound message 0 destination
> attributes
> - Register*/
> - u32 odcr; /* 0xD_3020 - Outbound message 0 double-word
count
> - register */
> + u32 osar;
> + u32 odpr;
> + u32 odatr;
> + u32 odcr;
> u32 pad3;
> - u32 odqepar; /* 0xD_3028 - Outbound message 0 descriptor
> queue
> - enqueue pointer address register */
> + u32 odqepar;
> u32 pad4[13];
> - u32 imr; /* 0xD_3060 - Inbound message 0 mode register */
> - u32 isr; /* 0xD_3064 - Inbound message 0 status register
*/
> + u32 imr;
> + u32 isr;
> u32 pad5;
> - u32 ifqdpar; /* 0xD_306C - Inbound message 0 frame queue
> dequeue
> - pointer address register*/
> + u32 ifqdpar;
> u32 pad6;
> - u32 ifqepar; /* 0xD_3074 - Inbound message 0 frame queue
> enqueue
> -
RE: [PATCH 3/5][v2] fsl-rio: Add two ports and rapidio message units support
-Original Message-
From: Bounine, Alexandre [mailto:alexandre.boun...@idt.com]
Sent: Monday, October 24, 2011 9:51 PM
To: Liu Gang-B34182; Kumar Gala; linuxppc-...@ozlabs.org; Zang Roy-R61911
Cc: Andrew Morton; linux-ker...@vger.kernel.org
Subject: RE: [PATCH 3/5][v2] fsl-rio: Add two ports and rapidio message units
support
On Sat, Oct 22, 2011 at 1:15 AM, Liu Gang-B34182
wrote:
>
> From: Bounine, Alexandre [mailto:alexandre.boun...@idt.com]
> Sent: Thursday, October 20, 2011 3:54 AM
> To: Kumar Gala; linuxppc-...@ozlabs.org
> Cc: Andrew Morton; Liu Gang-B34182; linux-ker...@vger.kernel.org
> Subject: RE: [PATCH 3/5][v2] fsl-rio: Add two ports and rapidio
message
> units support
>
> On Thu, Oct 13, 2011 at 10:09 AM, Kumar Gala wrote:
> >
> > From: Liu Gang
> >
> > Usually, freescale rapidio endpoint can support one 1X or two 4X LP-
> > Serial link interfaces, and rapidio message transactions can be
> > implemented
> by
> > two
>
> Is the number of 1x ports described correctly?
> Can we have two 1x ports as well?
> [Liu Gang-B34182] Yes you are right. endpoint can also have two 1x
> ports. I'll correct it.
>
> > message units. This patch adds the support of two rapidio ports and
> > initializes message unit 0 and message unit 1. And these ports and
> > message
> ... skip ...
> > +
> > + /* Probe the master port phy type */ ccsr =
> > + in_be32(priv->regs_win + RIO_CCSR + i*0x20); port->phy_type =
> > + (ccsr & 1) ? RIO_PHY_SERIAL :
> > RIO_PHY_PARALLEL;
> > + dev_info(&dev->dev, "RapidIO PHY type: %s\n",
> > +(port->phy_type == RIO_PHY_PARALLEL) ?
> > +"parallel" :
> > +((port->phy_type == RIO_PHY_SERIAL) ?
> "serial"
> > :
> > + "unknown"));
> > + /* Checking the port training status */ if
> > + (in_be32((priv->regs_win + RIO_ESCSR + i*0x20)) & 1)
> {
> > + dev_err(&dev->dev, "Port %d is not ready. "
> > +"Try to restart connection...\n", i);
> > + switch (port->phy_type) {
> > + case RIO_PHY_SERIAL:
> > +/* Disable ports */
> > +out_be32(priv->regs_win
> > + + RIO_CCSR + i*0x20, 0);
> > +/* Set 1x lane */
> > +setbits32(priv->regs_win
> > + + RIO_CCSR + i*0x20,
> 0x0200);
> > +/* Enable ports */
> > +setbits32(priv->regs_win
> > + + RIO_CCSR + i*0x20,
> 0x0060);
> > +break;
> > + case RIO_PHY_PARALLEL:
> > +/* Disable ports */
> > +out_be32(priv->regs_win
> > + + RIO_CCSR + i*0x20,
> 0x2200);
> > +/* Enable ports */
> > +out_be32(priv->regs_win
> > + + RIO_CCSR + i*0x20,
> 0x4400);
> > +break;
> > + }
>
> Probably this may be a good moment to drop the support for parallel
> link.
> Especially after you renamed controller to "srio" in the device tree.
> [Liu Gang-B34182] I'm also considering if we should drop the parallel
> link support and doorbell outbound ATMU configuration.
> I found some older powerpc chips support parallel link, like mpc8540
> and so on. But DTS files of these chips do not support Rapidio nodes.
> For example we can't find rapidio node in
> arch/powerpc/boot/dts/mpc8540ads.dts file. So can we conclude that
> these chips with parallel rapidio link do not need the support for
> rapidio module and the code for parallel link can be removed?
We are not aware about any use of tsi500 P-RIO switches.
[Liu Gang-B34182] Yes perhaps no one uses the P-RIO switches now. I have used
the tsi578 and remembered that this switch supports only 1x and 4x srio ports.
I would consider parallel implementation as an early stage of RapidIO
development which may be safely dropped.
[Liu Gang-B34182] Yeah, I agree with you.
I will keep P-RIO related definitions only because they are part of the spec. I
consider removing tsi500 switch driver as well.
[Liu Gang-B34182] I'll remove the support for P-RIO in fsl-rio driver. I think
it's better to keep clear code than keep a rarely used function.
Moreover, we can provide separate patches if P-RIO needed again.
>
> > + msleep(100);
... skip ...
>
> >
> > @@ -340,35 +327,45 @@ fsl_rio_dbell_handler(int irq, void
> > *dev_instance)
> > " sid %2.2x tid %2.2x info %4.4x\n",
> > DBELL_SID(dmsg), DBELL_TID(dmsg),
> DBELL_INF(dmsg));
> >
> > - list_for_each_entry(dbell, &port->dbells, node) {
> > - if ((dbell->res->start <= DBELL_INF(dmsg)) &&
> > -
RE: [PATCH] fsl-rio: fix compile error
Yes, I'm afraid srio was not enabled when you compiled. Regards, Liu Gang -Original Message- From: Paul Gortmaker [mailto:paul.gortma...@windriver.com] Sent: Friday, November 11, 2011 11:48 PM To: Liu Gang-B34182 Cc: linuxppc-dev@lists.ozlabs.org; alexandre.boun...@idt.com; a...@linux-foundation.org; linux-ker...@vger.kernel.org; Li Yang-R58472; Gala Kumar-B11780; Zang Roy-R61911 Subject: Re: [PATCH] fsl-rio: fix compile error On 11-11-11 08:48 AM, Liu Gang wrote: > The "#include " was replaced by "#include " > in the patch "powerpc: various straight conversions from module.h --> > export.h". > This will cause the following compile problem: > arch/powerpc/sysdev/fsl_rio.c: In function 'fsl_rio_mcheck_exception': > arch/powerpc/sysdev/fsl_rio.c:296: error: implicit declaration of function > 'search_exception_tables'. > > The file fsl_rio.c needs the declaration of function "search_exception_tables" > in the header file "linux/module.h". Thanks -- not sure why this never showed up in my builds of all the powerpc configs, _or_ the linux-next builds. Maybe srio isn't enabled in any of them? In any case it looks fine to me. Having the search_exception_tables live in module.h seems odd, but that is an independent issue for later. I can queue this unless someone else has already done so. Paul. > > Signed-off-by: Liu Gang > --- > arch/powerpc/sysdev/fsl_rio.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/powerpc/sysdev/fsl_rio.c > b/arch/powerpc/sysdev/fsl_rio.c index de170fd..22ffccd 100644 > --- a/arch/powerpc/sysdev/fsl_rio.c > +++ b/arch/powerpc/sysdev/fsl_rio.c > @@ -23,7 +23,7 @@ > */ > > #include > -#include > +#include > #include > #include > #include ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 4/5, v3] powerpc/8xxx: Update device tree bus probe for new RapidIO node binding
Yeah, send binding first should be better for reviewing entire set of patches.
Thanks!
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, November 15, 2011 1:37 AM
To: Liu Gang-B34182
Cc: Li Yang-R58472; Jiang Kai-B18973; linux-ker...@vger.kernel.org; Zang
Roy-R61911; alexandre.boun...@idt.com; a...@linux-foundation.org;
linuxppc-dev@lists.ozlabs.org; Gala Kumar-B11780
Subject: Re: [PATCH 4/5, v3] powerpc/8xxx: Update device tree bus probe for new
RapidIO node binding
On 11/14/2011 11:35 AM, Scott Wood wrote:
> On 11/12/2011 06:02 AM, Liu Gang wrote:
>> From: Kai Jiang
>>
>> Update of_platform_bus_probe() RapidIO node to be compitable with new
>> RapidIO dts compatible property.
>>
>> Signed-off-by: Kai Jiang
>> Signed-off-by: Kumar Gala
>> ---
>> arch/powerpc/platforms/85xx/corenet_ds.c |2 +-
>> arch/powerpc/platforms/85xx/mpc85xx_mds.c |2 +-
>> arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |2 +-
>> 3 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/85xx/corenet_ds.c
>> b/arch/powerpc/platforms/85xx/corenet_ds.c
>> index 802ad11..c48b661 100644
>> --- a/arch/powerpc/platforms/85xx/corenet_ds.c
>> +++ b/arch/powerpc/platforms/85xx/corenet_ds.c
>> @@ -112,7 +112,7 @@ static const struct of_device_id of_device_ids[]
>> __devinitconst = {
>> .compatible = "simple-bus"
>> },
>> {
>> -.compatible = "fsl,rapidio-delta",
>> +.compatible = "fsl,srio",
>
> fsl,srio is too vague. We need to identify the specific hardware (or
> at least a concrete programming interface document), not just the bus
> that the hardware implements.
Never mind, I see that the binding is more specific about what this string
means.
Next time have the binding come first. :-)
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v3] powerpc/srio: Fix the compile errors when building with 64bit
Hi, Kumar, Can you help to apply the two patches? powerpc/srio: Fix the compile errors when building with 64bit http://patchwork.ozlabs.org/patch/145687/ powerpc/srio: Fix the relocation errors when building with 64bit http://patchwork.ozlabs.org/patch/144829/ Thanks a lot. Best Regards, Liu Gang ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] rio: Use discovered bit to test if enumeration is complete
Hi, Andrew, Could you please apply this patch into your tree? Thanks a lot! Regards, Liu Gang -Original Message- From: Bounine, Alexandre [mailto:alexandre.boun...@idt.com] Sent: Tuesday, August 09, 2011 8:36 PM To: Liu Gang-B34182; linux-ker...@vger.kernel.org Cc: Li Yang-R58472; Zang Roy-R61911; linuxppc-...@ozlabs.org; Liu Gang-B34182; a...@linux-foundation.org; Gala Kumar-B11780 Subject: RE: [PATCH] rio: Use discovered bit to test if enumeration is complete On Monday, August 08, 2011 at 10:17 PM, Liu Gang wrote: > Subject: [PATCH] rio: Use discovered bit to test if enumeration is > complete > > The discovered bit in PGCCSR register indicates if the device has been > discovered by system host. In Rapidio system, some agent devices can > also be master devices. They can issue requests into the system. > > Signed-off-by: Liu Gang > --- > drivers/rapidio/rio-scan.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) Acked-by: Alexandre Bounine ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] fsl-rio: Correct IECSR register clear value
Hi, Andrew,
Thank you for applying the patch "[PATCH] rio: Use discovered bit to test if
enumeration is complete "!
So far the following patch "[PATCH] fsl-rio: Correct IECSR register clear value
" has no comment or response.
So could you please apply this patch into your tree?
Thanks a lot!
Regards,
Liu Gang
-Original Message-
From: Liu Gang-B34182
Sent: Monday, August 08, 2011 6:14 PM
To: linuxppc-...@ozlabs.org
Cc: a...@linux-foundation.org; Li Yang-R58472; Gala Kumar-B11780; Zang
Roy-R61911; Liu Gang-B34182; Liu Gang-B34182
Subject: [PATCH] fsl-rio: Correct IECSR register clear value
The RETE bit in IECSR is cleared by writing a 1 to it.
Signed-off-by: Liu Gang
---
arch/powerpc/sysdev/fsl_rio.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index b3fd081..cdd765b 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -54,6 +54,7 @@
#define ODSR_CLEAR 0x1c00
#define LTLEECSR_ENABLE_ALL0xFFC000FC
#define ESCSR_CLEAR0x07120204
+#define IECSR_CLEAR0x8000
#define RIO_PORT1_EDCSR0x0640
#define RIO_PORT2_EDCSR0x0680
@@ -1089,11 +1090,11 @@ static void port_error_handler(struct rio_mport *port,
int offset)
if (offset == 0) {
out_be32((u32 *)(rio_regs_win + RIO_PORT1_EDCSR), 0);
- out_be32((u32 *)(rio_regs_win + RIO_PORT1_IECSR), 0);
+ out_be32((u32 *)(rio_regs_win + RIO_PORT1_IECSR), IECSR_CLEAR);
out_be32((u32 *)(rio_regs_win + RIO_ESCSR), ESCSR_CLEAR);
} else {
out_be32((u32 *)(rio_regs_win + RIO_PORT2_EDCSR), 0);
- out_be32((u32 *)(rio_regs_win + RIO_PORT2_IECSR), 0);
+ out_be32((u32 *)(rio_regs_win + RIO_PORT2_IECSR), IECSR_CLEAR);
out_be32((u32 *)(rio_regs_win + RIO_PORT2_ESCSR), ESCSR_CLEAR);
}
}
--
1.7.3.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] fsl-rio: Correct IECSR register clear value
Hi, Andrew,
Thanks for your comments.
I think you are right and a more detailed description will be better.
This bug causes the IECSR register clear failure.
In this case, the RETE (retry error threshold exceeded) interrupt will be
generated and cannot be cleared.
So the related ISR may be called persistently.
Thanks again!
Regards,
Liu Gang
-Original Message-
From: Andrew Morton [mailto:a...@linux-foundation.org]
Sent: Thursday, August 25, 2011 2:54 AM
To: Liu Gang-B34182
Cc: 'linuxppc-dev@lists.ozlabs.org'; Li Yang-R58472; Gala Kumar-B11780; Zang
Roy-R61911
Subject: Re: [PATCH] fsl-rio: Correct IECSR register clear value
On Wed, 24 Aug 2011 09:31:21 +0000
Liu Gang-B34182 wrote:
> Hi, Andrew,
>
> Thank you for applying the patch "[PATCH] rio: Use discovered bit to test if
> enumeration is complete "!
>
> So far the following patch "[PATCH] fsl-rio: Correct IECSR register clear
> value " has no comment or response.
Perhaps because you didn't tell anyone what the patch does.
> To: linuxppc-...@ozlabs.org
> Cc: a...@linux-foundation.org; Li Yang-R58472; Gala Kumar-B11780; Zang
> Roy-R61911; Liu Gang-B34182; Liu Gang-B34182
> Subject: [PATCH] fsl-rio: Correct IECSR register clear value
>
> The RETE bit in IECSR is cleared by writing a 1 to it.
>
> Signed-off-by: Liu Gang
> ---
> arch/powerpc/sysdev/fsl_rio.c |5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/fsl_rio.c
> b/arch/powerpc/sysdev/fsl_rio.c index b3fd081..cdd765b 100644
> --- a/arch/powerpc/sysdev/fsl_rio.c
> +++ b/arch/powerpc/sysdev/fsl_rio.c
> @@ -54,6 +54,7 @@
> #define ODSR_CLEAR 0x1c00
> #define LTLEECSR_ENABLE_ALL 0xFFC000FC
> #define ESCSR_CLEAR 0x07120204
> +#define IECSR_CLEAR 0x8000
>
> #define RIO_PORT1_EDCSR 0x0640
> #define RIO_PORT2_EDCSR 0x0680
> @@ -1089,11 +1090,11 @@ static void port_error_handler(struct
> rio_mport *port, int offset)
>
> if (offset == 0) {
> out_be32((u32 *)(rio_regs_win + RIO_PORT1_EDCSR), 0);
> - out_be32((u32 *)(rio_regs_win + RIO_PORT1_IECSR), 0);
> + out_be32((u32 *)(rio_regs_win + RIO_PORT1_IECSR), IECSR_CLEAR);
> out_be32((u32 *)(rio_regs_win + RIO_ESCSR), ESCSR_CLEAR);
> } else {
> out_be32((u32 *)(rio_regs_win + RIO_PORT2_EDCSR), 0);
> - out_be32((u32 *)(rio_regs_win + RIO_PORT2_IECSR), 0);
> + out_be32((u32 *)(rio_regs_win + RIO_PORT2_IECSR), IECSR_CLEAR);
> out_be32((u32 *)(rio_regs_win + RIO_PORT2_ESCSR), ESCSR_CLEAR);
> }
> }
Apparently it fixes some bug. But because you didn't tell us what the
user-visible effects of that bug are, I am unable to determine what kernel
versions (if any) the patch should be merged into.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
