* [RFC] [PATCH 4/5] [POWERPC] Move device_to_mask() to dma-mapping.h
From: markn @ 2008-04-30 7:46 UTC (permalink / raw)
To: olof; +Cc: Mark Nelson, linuxppc-dev
In-Reply-To: <20080430074621.104662132@au1.ibm.com>
Move device_to_mask() to dma-mapping.h because we need to use it from
outside dma_64.c in a later patch.
Signed-off-by: Mark Nelson <markn@au1.ibm.com>
---
arch/powerpc/kernel/dma_64.c | 9 ---------
include/asm-powerpc/dma-mapping.h | 9 +++++++++
2 files changed, 9 insertions(+), 9 deletions(-)
Index: upstream/arch/powerpc/kernel/dma_64.c
===================================================================
--- upstream.orig/arch/powerpc/kernel/dma_64.c
+++ upstream/arch/powerpc/kernel/dma_64.c
@@ -15,15 +15,6 @@
* Generic iommu implementation
*/
-static inline unsigned long device_to_mask(struct device *dev)
-{
- if (dev->dma_mask && *dev->dma_mask)
- return *dev->dma_mask;
- /* Assume devices without mask can take 32 bit addresses */
- return 0xfffffffful;
-}
-
-
/* Allocates a contiguous real buffer and creates mappings over it.
* Returns the virtual address of the buffer and sets dma_handle
* to the dma address (mapping) of the first page.
Index: upstream/include/asm-powerpc/dma-mapping.h
===================================================================
--- upstream.orig/include/asm-powerpc/dma-mapping.h
+++ upstream/include/asm-powerpc/dma-mapping.h
@@ -45,6 +45,15 @@ extern void __dma_sync_page(struct page
#endif /* ! CONFIG_NOT_COHERENT_CACHE */
#ifdef CONFIG_PPC64
+
+static inline unsigned long device_to_mask(struct device *dev)
+{
+ if (dev->dma_mask && *dev->dma_mask)
+ return *dev->dma_mask;
+ /* Assume devices without mask can take 32 bit addresses */
+ return 0xfffffffful;
+}
+
/*
* DMA operations are abstracted for G5 vs. i/pSeries, PCI vs. VIO
*/
--
^ permalink raw reply
* [RFC] [PATCH 0/5] [POWERPC] Implement dma_*map*_attrs() and DMA_ATTR_WEAK_ORDERING and use on Cell
From: markn @ 2008-04-30 7:46 UTC (permalink / raw)
To: olof; +Cc: linuxppc-dev
--
Was Re: [PATCH] [POWERPC] Add struct iommu_table argument to iommu_map_sg()
Here's the patch series that follows on from the patch:
Add struct iommu_table argument to iommu_map_sg()
Thanks!
Mark.
^ permalink raw reply
* [RFC] [PATCH 5/5] [POWERPC] Add DMA_ATTR_WEAK_ORDERING dma attribute and use in Cell IOMMU code
From: markn @ 2008-04-30 7:46 UTC (permalink / raw)
To: olof; +Cc: Mark Nelson, linuxppc-dev
In-Reply-To: <20080430074621.104662132@au1.ibm.com>
Introduce a new dma attriblue DMA_ATTR_WEAK_ORDERING to use weak ordering
on DMA mappings in the Cell processor. Add the code to the Cell's IOMMU
implementation to use this code.
Dynamic mappings can be weakly or strongly ordered on an individual basis
but the fixed mapping has to be either completely strong or completely weak.
This is currently decided by a kernel boot option (pass iommu_fixed=weak
for a weakly ordered fixed linear mapping, strongly ordered is the default).
Signed-off-by: Mark Nelson <markn@au1.ibm.com>
---
Documentation/DMA-attributes.txt | 9 ++
arch/powerpc/platforms/cell/iommu.c | 113 ++++++++++++++++++++++++++++++++++--
include/linux/dma-attrs.h | 1
3 files changed, 118 insertions(+), 5 deletions(-)
Index: upstream/arch/powerpc/platforms/cell/iommu.c
===================================================================
--- upstream.orig/arch/powerpc/platforms/cell/iommu.c
+++ upstream/arch/powerpc/platforms/cell/iommu.c
@@ -199,6 +199,8 @@ static void tce_build_cell(struct iommu_
base_pte = IOPTE_PP_W | IOPTE_PP_R | IOPTE_M | IOPTE_SO_RW |
(window->ioid & IOPTE_IOID_Mask);
#endif
+ if (unlikely(dma_get_attr(DMA_ATTR_WEAK_ORDERING, attrs)))
+ base_pte &= ~IOPTE_SO_RW;
io_pte = (unsigned long *)tbl->it_base + (index - tbl->it_offset);
@@ -539,7 +541,9 @@ static struct cbe_iommu *cell_iommu_for_
static unsigned long cell_dma_direct_offset;
static unsigned long dma_iommu_fixed_base;
-struct dma_mapping_ops dma_iommu_fixed_ops;
+
+/* iommu_fixed_is_weak is set if booted with iommu_fixed=weak */
+static int iommu_fixed_is_weak;
static struct iommu_table *cell_get_iommu_table(struct device *dev)
{
@@ -563,6 +567,98 @@ static struct iommu_table *cell_get_iomm
return &window->table;
}
+/* A coherent allocation implies strong ordering */
+
+static void *dma_fixed_alloc_coherent(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t flag)
+{
+ if (iommu_fixed_is_weak)
+ return iommu_alloc_coherent(dev, cell_get_iommu_table(dev),
+ size, dma_handle,
+ device_to_mask(dev), flag,
+ dev->archdata.numa_node);
+ else
+ return dma_direct_ops.alloc_coherent(dev, size, dma_handle,
+ flag);
+}
+
+static void dma_fixed_free_coherent(struct device *dev, size_t size,
+ void *vaddr, dma_addr_t dma_handle)
+{
+ if (iommu_fixed_is_weak)
+ iommu_free_coherent(cell_get_iommu_table(dev), size, vaddr,
+ dma_handle);
+ else
+ dma_direct_ops.free_coherent(dev, size, vaddr, dma_handle);
+}
+
+static dma_addr_t dma_fixed_map_single(struct device *dev, void *ptr,
+ size_t size,
+ enum dma_data_direction direction,
+ struct dma_attrs *attrs)
+{
+ if (iommu_fixed_is_weak == dma_get_attr(DMA_ATTR_WEAK_ORDERING, attrs))
+ return dma_direct_ops.map_single(dev, ptr, size, direction,
+ attrs);
+ else
+ return iommu_map_single(dev, cell_get_iommu_table(dev), ptr,
+ size, device_to_mask(dev), direction,
+ attrs);
+}
+
+static void dma_fixed_unmap_single(struct device *dev, dma_addr_t dma_addr,
+ size_t size,
+ enum dma_data_direction direction,
+ struct dma_attrs *attrs)
+{
+ if (iommu_fixed_is_weak == dma_get_attr(DMA_ATTR_WEAK_ORDERING, attrs))
+ dma_direct_ops.unmap_single(dev, dma_addr, size, direction,
+ attrs);
+ else
+ iommu_unmap_single(cell_get_iommu_table(dev), dma_addr, size,
+ direction, attrs);
+}
+
+static int dma_fixed_map_sg(struct device *dev, struct scatterlist *sg,
+ int nents, enum dma_data_direction direction,
+ struct dma_attrs *attrs)
+{
+ if (iommu_fixed_is_weak == dma_get_attr(DMA_ATTR_WEAK_ORDERING, attrs))
+ return dma_direct_ops.map_sg(dev, sg, nents, direction, attrs);
+ else
+ return iommu_map_sg(dev, cell_get_iommu_table(dev), sg, nents,
+ device_to_mask(dev), direction, attrs);
+}
+
+static void dma_fixed_unmap_sg(struct device *dev, struct scatterlist *sg,
+ int nents, enum dma_data_direction direction,
+ struct dma_attrs *attrs)
+{
+ if (iommu_fixed_is_weak == dma_get_attr(DMA_ATTR_WEAK_ORDERING, attrs))
+ dma_direct_ops.unmap_sg(dev, sg, nents, direction, attrs);
+ else
+ iommu_unmap_sg(cell_get_iommu_table(dev), sg, nents, direction,
+ attrs);
+}
+
+static int dma_fixed_dma_supported(struct device *dev, u64 mask)
+{
+ return mask == DMA_64BIT_MASK;
+}
+
+static int dma_set_mask_and_switch(struct device *dev, u64 dma_mask);
+
+struct dma_mapping_ops dma_iommu_fixed_ops = {
+ .alloc_coherent = dma_fixed_alloc_coherent,
+ .free_coherent = dma_fixed_free_coherent,
+ .map_single = dma_fixed_map_single,
+ .unmap_single = dma_fixed_unmap_single,
+ .map_sg = dma_fixed_map_sg,
+ .unmap_sg = dma_fixed_unmap_sg,
+ .dma_supported = dma_fixed_dma_supported,
+ .set_dma_mask = dma_set_mask_and_switch,
+};
+
static void cell_dma_dev_setup_fixed(struct device *dev);
static void cell_dma_dev_setup(struct device *dev)
@@ -919,9 +1015,16 @@ static void cell_iommu_setup_fixed_ptab(
pr_debug("iommu: mapping 0x%lx pages from 0x%lx\n", fsize, fbase);
- base_pte = IOPTE_PP_W | IOPTE_PP_R | IOPTE_M | IOPTE_SO_RW
+ base_pte = IOPTE_PP_W | IOPTE_PP_R | IOPTE_M
| (cell_iommu_get_ioid(np) & IOPTE_IOID_Mask);
+ if (iommu_fixed_is_weak)
+ pr_info("IOMMU: Using weak ordering for fixed mapping\n");
+ else {
+ pr_info("IOMMU: Using strong ordering for fixed mapping\n");
+ base_pte |= IOPTE_SO_RW;
+ }
+
for (uaddr = 0; uaddr < fsize; uaddr += (1 << 24)) {
/* Don't touch the dynamic region */
ioaddr = uaddr + fbase;
@@ -1037,9 +1140,6 @@ static int __init cell_iommu_fixed_mappi
cell_iommu_setup_window(iommu, np, dbase, dsize, 0);
}
- dma_iommu_fixed_ops = dma_direct_ops;
- dma_iommu_fixed_ops.set_dma_mask = dma_set_mask_and_switch;
-
dma_iommu_ops.set_dma_mask = dma_set_mask_and_switch;
set_pci_dma_ops(&dma_iommu_ops);
@@ -1053,6 +1153,9 @@ static int __init setup_iommu_fixed(char
if (strcmp(str, "off") == 0)
iommu_fixed_disabled = 1;
+ else if (strcmp(str, "weak") == 0)
+ iommu_fixed_is_weak = 1;
+
return 1;
}
__setup("iommu_fixed=", setup_iommu_fixed);
Index: upstream/Documentation/DMA-attributes.txt
===================================================================
--- upstream.orig/Documentation/DMA-attributes.txt
+++ upstream/Documentation/DMA-attributes.txt
@@ -22,3 +22,12 @@ ready and available in memory. The DMA
could race with data DMA. Mapping the memory used for completion
indications with DMA_ATTR_WRITE_BARRIER would prevent the race.
+DMA_ATTR_WEAK_ORDERING
+----------------------
+
+DMA_ATTR_WEAK_ORDERING specifies that reads and writes to the mapping
+may be weakly ordered, that is that reads and writes may pass each other.
+
+Since it is optional for platforms to implement DMA_ATTR_WEAK_ORDERING,
+those that do not will simply ignore the attribute and exhibit default
+behavior.
Index: upstream/include/linux/dma-attrs.h
===================================================================
--- upstream.orig/include/linux/dma-attrs.h
+++ upstream/include/linux/dma-attrs.h
@@ -12,6 +12,7 @@
*/
enum dma_attr {
DMA_ATTR_WRITE_BARRIER,
+ DMA_ATTR_WEAK_ORDERING,
DMA_ATTR_MAX,
};
--
^ permalink raw reply
* [RFC] [PATCH 3/5] [POWERPC] Make cell_dma_dev_setup_iommu() return the iommu table
From: markn @ 2008-04-30 7:46 UTC (permalink / raw)
To: olof; +Cc: Mark Nelson, linuxppc-dev
In-Reply-To: <20080430074621.104662132@au1.ibm.com>
Make cell_dma_dev_setup_iommu() return a pointer to the struct iommu_table
(or NULL if no table can be found) rather than putting this pointer into
dev->archdata.dma_data (let the caller do that), and rename this function
to cell_get_iommu_table() to reflect this change.
This will allow us to get the iommu table for a device that doesn't have
the table in the archdata.
Signed-off-by: Mark Nelson <markn@au1.ibm.com>
---
arch/powerpc/platforms/cell/iommu.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
Index: upstream/arch/powerpc/platforms/cell/iommu.c
===================================================================
--- upstream.orig/arch/powerpc/platforms/cell/iommu.c
+++ upstream/arch/powerpc/platforms/cell/iommu.c
@@ -541,7 +541,7 @@ static unsigned long cell_dma_direct_off
static unsigned long dma_iommu_fixed_base;
struct dma_mapping_ops dma_iommu_fixed_ops;
-static void cell_dma_dev_setup_iommu(struct device *dev)
+static struct iommu_table *cell_get_iommu_table(struct device *dev)
{
struct iommu_window *window;
struct cbe_iommu *iommu;
@@ -556,11 +556,11 @@ static void cell_dma_dev_setup_iommu(str
printk(KERN_ERR "iommu: missing iommu for %s (node %d)\n",
archdata->of_node ? archdata->of_node->full_name : "?",
archdata->numa_node);
- return;
+ return NULL;
}
window = list_entry(iommu->windows.next, struct iommu_window, list);
- archdata->dma_data = &window->table;
+ return &window->table;
}
static void cell_dma_dev_setup_fixed(struct device *dev);
@@ -573,7 +573,7 @@ static void cell_dma_dev_setup(struct de
if (get_dma_ops(dev) == &dma_iommu_fixed_ops)
cell_dma_dev_setup_fixed(dev);
else if (get_pci_dma_ops() == &dma_iommu_ops)
- cell_dma_dev_setup_iommu(dev);
+ archdata->dma_data = cell_get_iommu_table(dev);
else if (get_pci_dma_ops() == &dma_direct_ops)
archdata->dma_data = (void *)cell_dma_direct_offset;
else
--
^ permalink raw reply
* Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro
From: Kumar Gala @ 2008-04-30 8:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18455.59014.305281.949578@cargo.ozlabs.ibm.com>
On Apr 29, 2008, at 10:24 PM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>>> Wouldn't it be better and safer to have the exception prolog for
>>> critical interrupts save SRR0/1 in the stack frame, and have the
>>> prolog for machine checks save SRR0/1 and CSRR0/1 likewise?
>>
>> If we do this I guess we can use SRR0/1 regardless of which level we
>> came from.
>
> That's the idea. I actually thought the booke exception prologs
> already did that, but it seems I'm wrong.
>
> What sort of things do you expect critical and machine-check handlers
> to be needing to do?
It varies on the parts but remember critical level can be anything
from watchdog, critical input (equivalent of external input, but at
the critical level), and debug. So there is a pretty wide set of
possibility.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro
From: Kumar Gala @ 2008-04-30 8:02 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1209537128.18023.225.camel@pasglop>
On Apr 30, 2008, at 1:32 AM, Benjamin Herrenschmidt wrote:
>
> On Tue, 2008-04-29 at 18:52 -0500, Kumar Gala wrote:
>> On Apr 29, 2008, at 4:28 PM, Paul Mackerras wrote:
>>> Kumar Gala writes:
>>>
>>>> We need to have unique transfer_to_handler paths for each exception
>>>> level
>>>> that is supported. We need to use the proper xSRR0/1 depending on
>>>> which
>>>> exception level the interrupt was from. The macro conversion
>>>> lets up
>>>> templatize this code path.
>>>
>>> It seems to me that this implies you are assuming that you will
>>> never
>>> ever get a synchronous normal interrupt such as a TLB miss while you
>>> are in a critical or machine check handler.
>>
>> Grr.. one more thing to fix :)
>>
>>> Wouldn't it be better and safer to have the exception prolog for
>>> critical interrupts save SRR0/1 in the stack frame, and have the
>>> prolog for machine checks save SRR0/1 and CSRR0/1 likewise?
>>
>> If we do this I guess we can use SRR0/1 regardless of which level we
>> came from.
>
> Also consider saving/restoring MAS
got that. Does 40x/44x have anything similar we need to save/restore?
^ permalink raw reply
* Re: MPC83xx Power Management support
From: Guennadi Liakhovetski @ 2008-04-30 8:31 UTC (permalink / raw)
To: Perrine MARTIGNONI; +Cc: linuxppc-dev
In-Reply-To: <1de232e40804300113k12a1f9cg277a8e3e2b52ee83@mail.gmail.com>
On Wed, 30 Apr 2008, Perrine MARTIGNONI wrote:
Please, in the future direct your questions to the respective mailing
list, thanks. Added to cc.
> Hello,
>
> Currently, I try to use the Power Management patches and I have some issues.
>
> With which version of linux the patches are written ?
> I try on linux-2.6.23 and there are some rejects.
The patches are against a recent powerpc git tree snapshot.
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: [PATCH 6/6] [POWERPC] booting-without-of: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
From: Wolfgang Grandegger @ 2008-04-30 8:36 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080429190057.GF21203@polina.dev.rtsoft.ru>
Hi Anton,
Anton Vorontsov wrote:
> This patch adds few bindings for the new drivers to be submitted through
> appropriate maintainers.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> Documentation/powerpc/booting-without-of.txt | 125 ++++++++++++++++++++++++++
> 1 files changed, 125 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index 4fefc44..6564e0a 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -61,6 +61,10 @@ Table of Contents
> r) Freescale Display Interface Unit
> s) Freescale on board FPGA
> t) Freescale General-purpose Timers Module
> + u) Freescale QUICC Engine USB Controller
> + v) LEDs on GPIOs
> + w) Freescale MCU with MPC8349E-mITX compatible firmware
> + x) Freescale Localbus UPM programmed to work with NAND flash
>
> VII - Marvell Discovery mv64[345]6x System Controller chips
> 1) The /system-controller node
> @@ -2916,6 +2920,127 @@ platforms are moved over to use the flattened-device-tree model.
> clock-frequency = <0>;
> };
>
> + u) Freescale QUICC Engine USB Controller
> +
> + Required properties:
> + - compatible : should be "fsl,<chip>-qe-usb", "fsl,mpc8323-qe-usb";
> + - reg : the first two cells should contain gtm registers location and
> + length, the next two two cells should contain PRAM location and
> + length.
> + - interrupts : should contain USB interrupt.
> + - interrupt-parent : interrupt source phandle.
> + - fsl,fullspeed-clock : specifies the full speed USB clock source in
> + "clk<num>" or "brg<num>" format.
> + - fsl,lowspeed-clock : specifies the low speed USB clock source in
> + "clk<num>" or "brg<num>" format.
> + - fsl,usb-mode : should be "host".
> + - linux,hub-power-budget : optional, USB power budget for the root hub
> + in mA.
> + - gpios : should specify GPIOs in this order: USBOE, USBTP, USBTN, USBRP,
> + USBRN, SPEED (optional), and POWER (optional).
> +
> + Example:
> +
> + usb@6c0 {
> + compatible = "fsl,mpc8360-qe-usb", "fsl,mpc8323-qe-usb";
> + reg = <0x6c0 0x40 0x8b00 0x100>;
> + interrupts = <11>;
> + interrupt-parent = <&qeic>;
> + fsl,fullspeed-clock = "clk21";
> + fsl,usb-mode = "host";
> + gpios = <&qe_pio_b 2 0 /* USBOE */
> + &qe_pio_b 3 0 /* USBTP */
> + &qe_pio_b 8 0 /* USBTN */
> + &qe_pio_b 9 0 /* USBRP */
> + &qe_pio_b 11 0 /* USBRN */
> + &qe_pio_e 20 0 /* SPEED */
> + &qe_pio_e 21 0 /* POWER */>;
> + };
> +
> + v) LEDs on GPIOs
> +
> + Required properties:
> + - compatible : should be "linux,gpio-led".
> + - linux,name : LED name.
> + - linux,active-low : property should be present if LED wired as
> + active-low.
> + - linux,default-trigger : Linux default trigger for this LED.
> + - linux,brightness : default brightness.
> + - gpios : should specify LED GPIO.
> +
> + Example:
> +
> + led@0 {
> + compatible = "linux,gpio-led";
> + linux,name = "pwr";
> + linux,brightness = <1>;
> + linux,active-low;
> + gpios = <&mcu_pio 0>;
> + };
> +
> + led@1 {
> + compatible = "linux,gpio-led";
> + linux,name = "hdd";
> + linux,default-trigger = "ide-disk";
> + linux,active-low;
> + gpios = <&mcu_pio 1>;
> + };
> +
> + w) Freescale MCU with MPC8349E-mITX compatible firmware
> +
> + Required properties:
> + - compatible : "fsl,<mcu-chip>-<board>", "fsl,mcu-mpc8349emitx";
> + - reg : should specify I2C address (0x0a).
> + - #address-cells : should be 0.
> + - #size-cells : should be 0.
> + - #gpio-cells : should be 2.
> + - gpio-controller : should be present;
> +
> + Example:
> +
> + mcu_pio: mcu@0a {
> + #address-cells = <0>;
> + #size-cells = <0>;
> + #gpio-cells = <2>;
> + compatible = "fsl,mc9s08qg8-mpc8349emitx",
> + "fsl,mcu-mpc8349emitx";
> + reg = <0x0a>;
> + gpio-controller;
> + };
> +
> + x) Freescale Localbus UPM programmed to work with NAND flash
> +
> + Required properties:
> + - #address-cells : should be 0;
> + - #size-cells : should be 0;
> + - compatible : "fsl,upm-nand".
> + - reg : should specify localbus chip select and size used for the chip.
> + - fsl,upm-addr-offset : UPM pattern offset for the address latch.
> + - fsl,upm-cmd-offset : UPM pattern offset for the command latch.
> + - gpios : may specify optional GPIO connected to the Ready-Not-Busy pin.
> +
> + Example:
> +
> + upm@1,0 {
> + #address-cells = <0>;
> + #size-cells = <0>;
> + compatible = "fsl,upm-nand";
> + reg = <1 0 1>;
> + fsl,upm-addr-offset = <16>;
> + fsl,upm-cmd-offset = <8>;
> + gpios = <&qe_pio_e 18 0>;
> +
> + flash {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "stmicro,NAND512W3A2BN6E";
> +
> + partition@0 {
> + ...
> + };
> + };
> + };
Where can I find the code for that binding? fsl_upm_nand.c from
http://patchwork.ozlabs.org/linuxppc/patch?q=upm&id=17306 does not parse
OF partitions. Are there any plans to push the fsl_upm_nand driver
upstream? I'm currently implementing NAND support for the TQM8548 and
want to base it on common code.
Thanks,
Wolfgang.
^ permalink raw reply
* RE: SKB corruption on heavy traffic
From: Franca, Jose (NSN - PT/Portugal - MiniMD) @ 2008-04-30 8:43 UTC (permalink / raw)
To: ext Scott Wood; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <20080429191510.GC8955@ld0162-tx32.am.freescale.net>
Hello!
Thank you for replying!
It't quite dificult to say if the problem exists without our changes, =
since the all software is dependent on this changes so to work with the =
hardware. I can't answer to that right now on that, but I forgot to add =
one thing: we have ring buffer full problems on our fcc_enet driver from =
time to time. So, I think the problem could be on linux configurations =
(related to hw) because there is a lot of posts on the web related to =
problems similar to this (none of them has really solved the bottom =
problem).=20
Regards,
Filipe=20
-----Original Message-----
From: ext Scott Wood [mailto:scottwood@freescale.com]=20
Sent: ter=E7a-feira, 29 de Abril de 2008 20:15
To: Franca, Jose (NSN - PT/Portugal - MiniMD)
Cc: linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org
Subject: Re: SKB corruption on heavy traffic
On Tue, Apr 29, 2008 at 07:39:07PM +0100, Franca, Jose (NSN - =
PT/Portugal - MiniMD) wrote:
> We are developing a MPC8247 based telecom board (512MB), using
> linux 2.4 with some proprietary changes on IP stack and we are facing
> some problems when we have heavy traffic on our Ethernet interfaces...
Do you see these problems without the proprietary changes, and with a
current kernel?
-Scott
^ permalink raw reply
* [PATCH] [POWERPC] Move to runtime allocated exception stacks
From: Kumar Gala @ 2008-04-30 8:57 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
For the additonal exception levels (critical, debug, machine check) on
40x/book-e we were using "static" allocations of the stack in the
associated head.S.
Move to a runtime allocation to make the code a bit easier to read as
we mimic how we handle IRQ stacks. Its also a bit easier to setup the
stack with a "dummy" thread_info in C code.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Josh, can you test this on 40x and 44x. (make sure gdb single step still
functions).
This is the first in a sequence of patches towards fixing up the exception
level stack functionality. I'm posting them in pieces to get review and
make it easier to bisect if the patches introduce issues in the future.
- k
arch/powerpc/kernel/head_40x.S | 14 ++------------
arch/powerpc/kernel/head_44x.S | 9 ---------
arch/powerpc/kernel/head_booke.h | 27 ++++++++++-----------------
arch/powerpc/kernel/head_fsl_booke.S | 9 ---------
arch/powerpc/kernel/irq.c | 33 +++++++++++++++++++++++++++++++++
arch/powerpc/kernel/setup_32.c | 24 ++++++++++++++++++++++++
include/asm-powerpc/irq.h | 13 +++++++++++++
7 files changed, 82 insertions(+), 47 deletions(-)
diff --git a/arch/powerpc/kernel/head_40x.S b/arch/powerpc/kernel/head_40x.S
index 8552e67..ca75eaf 100644
--- a/arch/powerpc/kernel/head_40x.S
+++ b/arch/powerpc/kernel/head_40x.S
@@ -148,8 +148,8 @@ _ENTRY(crit_r11)
mfcr r10; /* save CR in r10 for now */\
mfspr r11,SPRN_SRR3; /* check whether user or kernel */\
andi. r11,r11,MSR_PR; \
- lis r11,critical_stack_top@h; \
- ori r11,r11,critical_stack_top@l; \
+ lis r11,critirq_ctx@ha; \
+ lwz r11,critirq_ctx@l(r11); \
beq 1f; \
/* COMING FROM USER MODE */ \
mfspr r11,SPRN_SPRG3; /* if from user, start at top of */\
@@ -996,16 +996,6 @@ empty_zero_page:
swapper_pg_dir:
.space PGD_TABLE_SIZE
-
-/* Stack for handling critical exceptions from kernel mode */
- .section .bss
- .align 12
-exception_stack_bottom:
- .space 4096
-critical_stack_top:
- .globl exception_stack_top
-exception_stack_top:
-
/* Room for two PTE pointers, usually the kernel and current user pointers
* to their respective root page table.
*/
diff --git a/arch/powerpc/kernel/head_44x.S b/arch/powerpc/kernel/head_44x.S
index b84ec6a..2041248 100644
--- a/arch/powerpc/kernel/head_44x.S
+++ b/arch/powerpc/kernel/head_44x.S
@@ -730,15 +730,6 @@ empty_zero_page:
swapper_pg_dir:
.space PGD_TABLE_SIZE
-/* Reserved 4k for the critical exception stack & 4k for the machine
- * check stack per CPU for kernel mode exceptions */
- .section .bss
- .align 12
-exception_stack_bottom:
- .space BOOKE_EXCEPTION_STACK_SIZE
- .globl exception_stack_top
-exception_stack_top:
-
/*
* Room for two PTE pointers, usually the kernel and current user pointers
* to their respective root page table.
diff --git a/arch/powerpc/kernel/head_booke.h b/arch/powerpc/kernel/head_booke.h
index aefafc6..d647e05 100644
--- a/arch/powerpc/kernel/head_booke.h
+++ b/arch/powerpc/kernel/head_booke.h
@@ -43,9 +43,7 @@
SAVE_2GPRS(7, r11)
/* To handle the additional exception priority levels on 40x and Book-E
- * processors we allocate a 4k stack per additional priority level. The various
- * head_xxx.S files allocate space (exception_stack_top) for each priority's
- * stack times the number of CPUs
+ * processors we allocate a stack per additional priority level.
*
* On 40x critical is the only additional level
* On 44x/e500 we have critical and machine check
@@ -61,36 +59,31 @@
* going to critical or their own debug level we aren't currently
* providing configurations that micro-optimize space usage.
*/
-#ifdef CONFIG_44x
-#define NUM_EXCEPTION_LVLS 2
-#else
-#define NUM_EXCEPTION_LVLS 3
-#endif
-#define BOOKE_EXCEPTION_STACK_SIZE (4096 * NUM_EXCEPTION_LVLS)
/* CRIT_SPRG only used in critical exception handling */
#define CRIT_SPRG SPRN_SPRG2
/* MCHECK_SPRG only used in machine check exception handling */
#define MCHECK_SPRG SPRN_SPRG6W
-#define MCHECK_STACK_TOP (exception_stack_top - 4096)
-#define CRIT_STACK_TOP (exception_stack_top)
+#define MCHECK_STACK_TOP mcheckirq_ctx
+#define CRIT_STACK_TOP critirq_ctx
/* only on e200 for now */
-#define DEBUG_STACK_TOP (exception_stack_top - 8192)
+#define DEBUG_STACK_TOP dbgirq_ctx
#define DEBUG_SPRG SPRN_SPRG6W
#ifdef CONFIG_SMP
#define BOOKE_LOAD_EXC_LEVEL_STACK(level) \
mfspr r8,SPRN_PIR; \
- mulli r8,r8,BOOKE_EXCEPTION_STACK_SIZE; \
- neg r8,r8; \
+ slwi r8,r8,2; \
addis r8,r8,level##_STACK_TOP@ha; \
- addi r8,r8,level##_STACK_TOP@l
+ lwz r8,level##_STACK_TOP@l(r8); \
+ addi r8,r8,THREAD_SIZE;
#else
#define BOOKE_LOAD_EXC_LEVEL_STACK(level) \
- lis r8,level##_STACK_TOP@h; \
- ori r8,r8,level##_STACK_TOP@l
+ lis r8,level##_STACK_TOP@ha; \
+ lwz r8,level##_STACK_TOP@l(r8); \
+ addi r8,r8,THREAD_SIZE;
#endif
/*
diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
index e581524..503f860 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -1080,15 +1080,6 @@ empty_zero_page:
swapper_pg_dir:
.space PGD_TABLE_SIZE
-/* Reserved 4k for the critical exception stack & 4k for the machine
- * check stack per CPU for kernel mode exceptions */
- .section .bss
- .align 12
-exception_stack_bottom:
- .space BOOKE_EXCEPTION_STACK_SIZE * NR_CPUS
- .globl exception_stack_top
-exception_stack_top:
-
/*
* Room for two PTE pointers, usually the kernel and current user pointers
* to their respective root page table.
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 2f73f70..b519975 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -356,9 +356,42 @@ void __init init_IRQ(void)
{
if (ppc_md.init_IRQ)
ppc_md.init_IRQ();
+
+ exc_lvl_ctx_init();
+
irq_ctx_init();
}
+#if defined(CONFIG_BOOKE) || defined(CONFIG_40x)
+struct thread_info *critirq_ctx[NR_CPUS] __read_mostly;
+struct thread_info *dbgirq_ctx[NR_CPUS] __read_mostly;
+struct thread_info *mcheckirq_ctx[NR_CPUS] __read_mostly;
+
+void exc_lvl_ctx_init(void)
+{
+ struct thread_info *tp;
+ int i;
+
+ for_each_possible_cpu(i) {
+ memset((void *)critirq_ctx[i], 0, THREAD_SIZE);
+ tp = critirq_ctx[i];
+ tp->cpu = i;
+ tp->preempt_count = 0;
+
+#ifdef CONFIG_BOOKE
+ memset((void *)dbgirq_ctx[i], 0, THREAD_SIZE);
+ tp = dbgirq_ctx[i];
+ tp->cpu = i;
+ tp->preempt_count = 0;
+
+ memset((void *)mcheckirq_ctx[i], 0, THREAD_SIZE);
+ tp = mcheckirq_ctx[i];
+ tp->cpu = i;
+ tp->preempt_count = HARDIRQ_OFFSET;
+#endif
+ }
+}
+#endif
#ifdef CONFIG_IRQSTACKS
struct thread_info *softirq_ctx[NR_CPUS] __read_mostly;
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 5112a4a..bef0be3 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -248,6 +248,28 @@ static void __init irqstack_early_init(void)
#define irqstack_early_init()
#endif
+#if defined(CONFIG_BOOKE) || defined(CONFIG_40x)
+static void __init exc_lvl_early_init(void)
+{
+ unsigned int i;
+
+ /* interrupt stacks must be in lowmem, we get that for free on ppc32
+ * as the lmb is limited to lowmem by LMB_REAL_LIMIT */
+ for_each_possible_cpu(i) {
+ critirq_ctx[i] = (struct thread_info *)
+ __va(lmb_alloc(THREAD_SIZE, THREAD_SIZE));
+#ifdef CONFIG_BOOKE
+ dbgirq_ctx[i] = (struct thread_info *)
+ __va(lmb_alloc(THREAD_SIZE, THREAD_SIZE));
+ mcheckirq_ctx[i] = (struct thread_info *)
+ __va(lmb_alloc(THREAD_SIZE, THREAD_SIZE));
+#endif
+ }
+}
+#else
+#define exc_lvl_early_init()
+#endif
+
/* Warning, IO base is not yet inited */
void __init setup_arch(char **cmdline_p)
{
@@ -305,6 +327,8 @@ void __init setup_arch(char **cmdline_p)
init_mm.end_data = (unsigned long) _edata;
init_mm.brk = klimit;
+ exc_lvl_early_init();
+
irqstack_early_init();
/* set up the bootmem stuff with available memory */
diff --git a/include/asm-powerpc/irq.h b/include/asm-powerpc/irq.h
index b5c0312..8892066 100644
--- a/include/asm-powerpc/irq.h
+++ b/include/asm-powerpc/irq.h
@@ -621,6 +621,19 @@ struct pt_regs;
extern void __do_softirq(void);
+#if defined(CONFIG_BOOKE) || defined(CONFIG_40x)
+/*
+ * Per-cpu stacks for handling critical, debug and machine check
+ * level interrupts.
+ */
+extern struct thread_info *critirq_ctx[NR_CPUS];
+extern struct thread_info *dbgirq_ctx[NR_CPUS];
+extern struct thread_info *mcheckirq_ctx[NR_CPUS];
+extern void exc_lvl_ctx_init(void);
+#else
+#define exc_lvl_ctx_init()
+#endif
+
#ifdef CONFIG_IRQSTACKS
/*
* Per-cpu stacks for handling hard and soft interrupts.
--
1.5.4.1
^ permalink raw reply related
* FW: SKB corruption on heavy traffic
From: Franca, Jose (NSN - PT/Portugal - MiniMD) @ 2008-04-30 9:07 UTC (permalink / raw)
To: linuxppc-dev, linuxppc-embedded
>From our latest debugs we found that the problem occurs mainly on skbuff =
code. After some variable time kfree or kalloc result in kernel oops.
-----Original Message-----
From: Franca, Jose (NSN - PT/Portugal - MiniMD)=20
Sent: quarta-feira, 30 de Abril de 2008 9:44
To: 'ext Scott Wood'
Cc: =09
Subject: RE: SKB corruption on heavy traffic
Hello!
Thank you for replying!
It't quite dificult to say if the problem exists without our changes, =
since the all software is dependent on this changes so to work with the =
hardware. I can't answer to that right now on that, but I forgot to add =
one thing: we have ring buffer full problems on our fcc_enet driver from =
time to time. So, I think the problem could be on linux configurations =
(related to hw) because there is a lot of posts on the web related to =
problems similar to this (none of them has really solved the bottom =
problem).=20
Regards,
Filipe=20
-----Original Message-----
From: ext Scott Wood [mailto:scottwood@freescale.com]=20
Sent: ter=E7a-feira, 29 de Abril de 2008 20:15
To: Franca, Jose (NSN - PT/Portugal - MiniMD)
Cc: linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org
Subject: Re: SKB corruption on heavy traffic
On Tue, Apr 29, 2008 at 07:39:07PM +0100, Franca, Jose (NSN - =
PT/Portugal - MiniMD) wrote:
> We are developing a MPC8247 based telecom board (512MB), using
> linux 2.4 with some proprietary changes on IP stack and we are facing
> some problems when we have heavy traffic on our Ethernet interfaces...
Do you see these problems without the proprietary changes, and with a
current kernel?
-Scott
^ permalink raw reply
* [PATCH] [POWERPC] Rework EXC_LEVEL_EXCEPTION_PROLOG code
From: Kumar Gala @ 2008-04-30 9:27 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt; +Cc: linuxppc-dev
* Cleanup the code a bit my allocating an INT_FRAME on our exception
stack there by make references go from GPR11-INT_FRAME_SIZE(r8) to
just GPR(r8)
* simplify {lvl}_transfer_to_handler code by moving the copying of the
temp registers we use if we come from user space into the PROLOG
* If the exception came from kernel mode copy thread_info flags,
preempt, and task pointer from the process thread_info.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
I'm not sure if the copying of TI_FLAGS, TI_PREEMPT, and TI_TASK
are really needed. I'm a bit concerned what to do if we get a
CriticalInput while in kernel mode and the handler causes a reschedule.
arch/powerpc/kernel/entry_32.S | 13 ----------
arch/powerpc/kernel/head_booke.h | 47 ++++++++++++++++++++++++-------------
2 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 0c8614d..816dd54 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -44,29 +44,16 @@
#endif
#ifdef CONFIG_BOOKE
-#include "head_booke.h"
-#define TRANSFER_TO_HANDLER_EXC_LEVEL(exc_level) \
- mtspr exc_level##_SPRG,r8; \
- BOOKE_LOAD_EXC_LEVEL_STACK(exc_level); \
- lwz r0,GPR10-INT_FRAME_SIZE(r8); \
- stw r0,GPR10(r11); \
- lwz r0,GPR11-INT_FRAME_SIZE(r8); \
- stw r0,GPR11(r11); \
- mfspr r8,exc_level##_SPRG
-
.globl mcheck_transfer_to_handler
mcheck_transfer_to_handler:
- TRANSFER_TO_HANDLER_EXC_LEVEL(MCHECK)
b transfer_to_handler_full
.globl debug_transfer_to_handler
debug_transfer_to_handler:
- TRANSFER_TO_HANDLER_EXC_LEVEL(DEBUG)
b transfer_to_handler_full
.globl crit_transfer_to_handler
crit_transfer_to_handler:
- TRANSFER_TO_HANDLER_EXC_LEVEL(CRIT)
/* fall through */
#endif
diff --git a/arch/powerpc/kernel/head_booke.h b/arch/powerpc/kernel/head_booke.h
index d647e05..78baec5 100644
--- a/arch/powerpc/kernel/head_booke.h
+++ b/arch/powerpc/kernel/head_booke.h
@@ -78,12 +78,12 @@
slwi r8,r8,2; \
addis r8,r8,level##_STACK_TOP@ha; \
lwz r8,level##_STACK_TOP@l(r8); \
- addi r8,r8,THREAD_SIZE;
+ addi r8,r8,THREAD_SIZE-INT_FRAME_SIZE;
#else
#define BOOKE_LOAD_EXC_LEVEL_STACK(level) \
lis r8,level##_STACK_TOP@ha; \
lwz r8,level##_STACK_TOP@l(r8); \
- addi r8,r8,THREAD_SIZE;
+ addi r8,r8,THREAD_SIZE-INT_FRAME_SIZE;
#endif
/*
@@ -97,22 +97,35 @@
#define EXC_LEVEL_EXCEPTION_PROLOG(exc_level, exc_level_srr0, exc_level_srr1) \
mtspr exc_level##_SPRG,r8; \
BOOKE_LOAD_EXC_LEVEL_STACK(exc_level);/* r8 points to the exc_level stack*/ \
- stw r10,GPR10-INT_FRAME_SIZE(r8); \
- stw r11,GPR11-INT_FRAME_SIZE(r8); \
+ stw r9,GPR9(r8); /* save various registers */\
+ stw r10,GPR10(r8); \
+ stw r11,GPR11(r8); \
+ mfspr r11,SPRN_SPRG3; /* if from user, start at top of */\
+ lwz r11,THREAD_INFO-THREAD(r11); /* this thread's kernel stack */\
+ addi r11,r11,THREAD_SIZE-INT_FRAME_SIZE; /* Alloc exception frm */\
mfcr r10; /* save CR in r10 for now */\
- mfspr r11,exc_level_srr1; /* check whether user or kernel */\
- andi. r11,r11,MSR_PR; \
- mr r11,r8; \
- mfspr r8,exc_level##_SPRG; \
+ mfspr r9,exc_level_srr1; /* check whether user or kernel */\
+ andi. r9,r9,MSR_PR; \
beq 1f; \
/* COMING FROM USER MODE */ \
- mfspr r11,SPRN_SPRG3; /* if from user, start at top of */\
- lwz r11,THREAD_INFO-THREAD(r11); /* this thread's kernel stack */\
- addi r11,r11,THREAD_SIZE; \
-1: subi r11,r11,INT_FRAME_SIZE; /* Allocate an exception frame */\
+ lwz r9,GPR9(r8); /* copy regs from exception stack */\
+ stw r9,GPR9(r11); \
+ lwz r9,GPR10(r8); \
+ stw r9,GPR10(r11); \
+ lwz r9,GPR11(r8); \
+ stw r9,GPR11(r11); \
+ b 2f; \
+ /* COMING FROM PRIV MODE */ \
+1: lwz r9,TI_FLAGS-THREAD_SIZE(r11); \
+ stw r9,TI_FLAGS-THREAD_SIZE(r8); \
+ lwz r9,TI_PREEMPT-THREAD_SIZE(r11); \
+ stw r9,TI_PREEMPT-THREAD_SIZE(r8); \
+ lwz r9,TI_TASK-THREAD_SIZE(r11); \
+ stw r9,TI_TASK-THREAD_SIZE(r8); \
+ mr r11,r8; \
+2: mfspr r8,exc_level##_SPRG; \
stw r10,_CCR(r11); /* save various registers */\
stw r12,GPR12(r11); \
- stw r9,GPR9(r11); \
mflr r10; \
stw r10,_LINK(r11); \
mfspr r12,SPRN_DEAR; /* save DEAR and ESR in the frame */\
@@ -255,8 +268,8 @@ label:
lwz r12,GPR12(r11); \
mtspr DEBUG_SPRG,r8; \
BOOKE_LOAD_EXC_LEVEL_STACK(DEBUG); /* r8 points to the debug stack */ \
- lwz r10,GPR10-INT_FRAME_SIZE(r8); \
- lwz r11,GPR11-INT_FRAME_SIZE(r8); \
+ lwz r10,GPR10(r8); \
+ lwz r11,GPR11(r8); \
mfspr r8,DEBUG_SPRG; \
\
RFDI; \
@@ -308,8 +321,8 @@ label:
lwz r12,GPR12(r11); \
mtspr CRIT_SPRG,r8; \
BOOKE_LOAD_EXC_LEVEL_STACK(CRIT); /* r8 points to the debug stack */ \
- lwz r10,GPR10-INT_FRAME_SIZE(r8); \
- lwz r11,GPR11-INT_FRAME_SIZE(r8); \
+ lwz r10,GPR10(r8); \
+ lwz r11,GPR11(r8); \
mfspr r8,CRIT_SPRG; \
\
rfci; \
--
1.5.4.1
^ permalink raw reply related
* [git pull] Please pull powerpc.git master branch
From: Paul Mackerras @ 2008-04-30 10:31 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, akpm, linux-kernel
Linus,
Please do:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git master
once more. There are a bunch of updates for the embedded MPC5200
based platforms, some spufs updates for Cell, and two bug fixes from
Michael Ellerman.
Sorry about missing the diffstat last time.
Thanks,
Paul.
.../powerpc/mpc52xx-device-tree-bindings.txt | 12
arch/powerpc/boot/dts/cm5200.dts | 98 +-
arch/powerpc/boot/dts/lite5200.dts | 132 +-
arch/powerpc/boot/dts/lite5200b.dts | 146 +-
arch/powerpc/boot/dts/motionpro.dts | 118 +-
arch/powerpc/boot/dts/pcm030.dts | 363 ++++++
arch/powerpc/boot/dts/tqm5200.dts | 80 +
arch/powerpc/configs/52xx/cm5200_defconfig | 1099 ++++++++++++++++++
arch/powerpc/configs/52xx/lite5200b_defconfig | 1049 +++++++++++++++++
arch/powerpc/configs/52xx/motionpro_defconfig | 1107 ++++++++++++++++++
arch/powerpc/configs/52xx/pcm030_defconfig | 1115 ++++++++++++++++++
arch/powerpc/configs/52xx/tqm5200_defconfig | 1214 ++++++++++++++++++++
arch/powerpc/kernel/machine_kexec.c | 12
arch/powerpc/kernel/setup_64.c | 9
arch/powerpc/platforms/52xx/Kconfig | 6
arch/powerpc/platforms/52xx/Makefile | 2
arch/powerpc/platforms/52xx/mpc5200_simple.c | 1
arch/powerpc/platforms/52xx/mpc52xx_gpio.c | 465 ++++++++
arch/powerpc/platforms/52xx/mpc52xx_pic.c | 38 +
arch/powerpc/platforms/cell/spufs/.gitignore | 2
arch/powerpc/platforms/cell/spufs/context.c | 4
arch/powerpc/platforms/cell/spufs/file.c | 166 +++
arch/powerpc/platforms/cell/spufs/run.c | 2
arch/powerpc/platforms/cell/spufs/sched.c | 4
arch/powerpc/platforms/cell/spufs/spufs.h | 33 +
arch/powerpc/platforms/cell/spufs/sputrace.c | 36 -
drivers/net/fec_mpc52xx.c | 23
drivers/serial/mpc52xx_uart.c | 2
28 files changed, 7009 insertions(+), 329 deletions(-)
create mode 100644 arch/powerpc/boot/dts/pcm030.dts
create mode 100644 arch/powerpc/configs/52xx/cm5200_defconfig
create mode 100644 arch/powerpc/configs/52xx/lite5200b_defconfig
create mode 100644 arch/powerpc/configs/52xx/motionpro_defconfig
create mode 100644 arch/powerpc/configs/52xx/pcm030_defconfig
create mode 100644 arch/powerpc/configs/52xx/tqm5200_defconfig
create mode 100644 arch/powerpc/platforms/52xx/mpc52xx_gpio.c
create mode 100644 arch/powerpc/platforms/cell/spufs/.gitignore
Bartlomiej Sieka (1):
[POWERPC] mpc5200: defconfigs for CM5200, Lite5200B, Motion-PRO and TQM5200
Christoph Hellwig (1):
[POWERPC] spufs: add context switch notification log
Grant Likely (2):
[POWERPC] mpc5200: Fix unterminated of_device_id table
[POWERPC] mpc5200: Switch mpc5200 dts files to dts-v1 format
Julio M. Merino Vidal (4):
[POWERPC] spufs: add sputrace marker parameter names
[POWERPC] spufs: add marker for destroy_spu_context
[POWERPC] spufs: fix marker name for find_victim
[POWERPC] spufs: trace spu_acquire_saved events
Kumar Gala (1):
[POWERPC] spufs: add .gitignore for spu_save_dump.h & spu_restore_dump.h
Michael Ellerman (2):
[POWERPC] Make emergency stack safe for current_thread_info() use
[POWERPC] Fix crashkernel= handling when no crashkernel= specified
Sascha Hauer (2):
[POWERPC] mpc5200: add interrupt type function
[POWERPC] mpc5200: Fix FEC error handling on FIFO errors
s.hauer@pengutronix.de (2):
[POWERPC] mpc5200: add gpiolib support for mpc5200
[POWERPC] mpc5200: add Phytec pcm030 board support
^ permalink raw reply
* Re: [PATCH 1/7] Implement arch disable/enable irq hooks.
From: Guennadi Liakhovetski @ 2008-04-30 10:33 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <18454.42926.213374.977098@cargo.ozlabs.ibm.com>
On Tue, 29 Apr 2008, Paul Mackerras wrote:
> Scott Wood writes:
>
> > On Fri, Apr 25, 2008 at 02:57:24PM +0200, Guennadi Liakhovetski wrote:
> > > is there any specific reason, why out of these 7 patches only the first
> > > one made it into the mainline? AFAICS, there has been only one comment,
> > > suggesting to replace printk with dev_err on two occasions in one of
> > > the patches...
> >
> > A while ago Paul said on IRC he'd prefer to do the TLF_SLEEPING hack more
> > like the soft IRQ disabling that 64-bit uses. I haven't yet had a chance
> > to look into it, so the patch collects dust, despite the current
> > implementation of TLF_SLEEPING working just fine.
>
> I have taken a closer look at the TLF_SLEEPING patch and crystallized
> my thoughts about it a bit:
>
> 1. Too many ifdefs - it's only a few instructions extra, so if we're
> going to have the TLF_SLEEPING stuff we might as well have it
> unconditionally.
>
> 2. It seems convoluted to me to go through transfer_to_handler_cont
> and ret_from_except when we could just get out directly through
> fast_exception_return, given that we are not calling a handler. The
> only thing to watch out for there is that r7 and r8 haven't been
> modified (or have been restored if they have).
>
> 3. The style in all the assembly code is not to have spaces after
> commas separating instruction operands.
>
> The untested patch below is what I was thinking of. If you'd like to
> try it out, I'd be interested to hear how it goes.
The patch (with the _TLF_SLEEPING fix you mentioned in a later email)
works for me. Shall I submit it "From: <you>" or would you prefer to post
it yourself? But, I guess, you have to put your "S-o-b" under it yourself,
don't you?
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* [PATCH] [POWERPC] 40x/Book-E: Save/restore volatile exception registers
From: Kumar Gala @ 2008-04-30 10:31 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt; +Cc: linuxppc-dev
On machines with more than one exception level any system register that
might be modified by the "normal" exception level needs to be saved and
restored on taking a higher level exception. We already are saving
and restoring ESR and DEAR.
For critical level add SRR0/1.
For debug level add CSRR0/1 and SRR0/1.
For machine check level add DSRR0/1, CSRR0/1, and SRR0/1.
On FSL Book-E parts we always save/restore the MAS registers for critical,
debug, and machine check level exceptions.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
I'm not sure if I got the 40x restore right. I'm also a bit concerned
about the path that returns via user_exc_return and uses SRR0/1. I think
this is ok because we have to ensure no SRR0/1 level exceptions occur at
this point already.
- k
arch/powerpc/kernel/asm-offsets.c | 20 +++++++++
arch/powerpc/kernel/entry_32.S | 85 ++++++++++++++++++++++++++++++++++++-
arch/powerpc/kernel/head_40x.S | 4 ++
arch/powerpc/kernel/head_booke.h | 24 ++++++++++-
4 files changed, 129 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index af1d2c8..0d1a36e 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -51,6 +51,10 @@
#include <asm/iseries/alpaca.h>
#endif
+#if defined(CONFIG_BOOKE) || defined(CONFIG_40x)
+#include "head_booke.h"
+#endif
+
#define DEFINE(sym, val) \
asm volatile("\n->" #sym " %0 " #val : : "i" (val))
@@ -246,6 +250,22 @@ int main(void)
DEFINE(_SRR1, STACK_FRAME_OVERHEAD+sizeof(struct pt_regs)+8);
#endif /* CONFIG_PPC64 */
+#if defined(CONFIG_BOOKE) || defined(CONFIG_40x)
+ DEFINE(EXC_LVL_SIZE, STACK_EXC_LVL_FRAME_SIZE);
+ DEFINE(MAS0, STACK_INT_FRAME_SIZE+offsetof(struct exception_regs, mas0));
+ DEFINE(MAS1, STACK_INT_FRAME_SIZE+offsetof(struct exception_regs, mas1));
+ DEFINE(MAS2, STACK_INT_FRAME_SIZE+offsetof(struct exception_regs, mas2));
+ DEFINE(MAS3, STACK_INT_FRAME_SIZE+offsetof(struct exception_regs, mas3));
+ DEFINE(MAS6, STACK_INT_FRAME_SIZE+offsetof(struct exception_regs, mas6));
+ DEFINE(MAS7, STACK_INT_FRAME_SIZE+offsetof(struct exception_regs, mas7));
+ DEFINE(_SRR0, STACK_INT_FRAME_SIZE+offsetof(struct exception_regs, srr0));
+ DEFINE(_SRR1, STACK_INT_FRAME_SIZE+offsetof(struct exception_regs, srr1));
+ DEFINE(_CSRR0, STACK_INT_FRAME_SIZE+offsetof(struct exception_regs, csrr0));
+ DEFINE(_CSRR1, STACK_INT_FRAME_SIZE+offsetof(struct exception_regs, csrr1));
+ DEFINE(_DSRR0, STACK_INT_FRAME_SIZE+offsetof(struct exception_regs, dsrr0));
+ DEFINE(_DSRR1, STACK_INT_FRAME_SIZE+offsetof(struct exception_regs, dsrr1));
+#endif
+
DEFINE(CLONE_VM, CLONE_VM);
DEFINE(CLONE_UNTRACED, CLONE_UNTRACED);
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 816dd54..ab86ab9 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -46,14 +46,42 @@
#ifdef CONFIG_BOOKE
.globl mcheck_transfer_to_handler
mcheck_transfer_to_handler:
- b transfer_to_handler_full
+ mfspr r0,SPRN_DSRR0
+ stw r0,_DSRR0(r11)
+ mfspr r0,SPRN_DSRR1
+ stw r0,_DSRR1(r11)
+ /* fall through */
.globl debug_transfer_to_handler
debug_transfer_to_handler:
- b transfer_to_handler_full
+ mfspr r0,SPRN_CSRR0
+ stw r0,_CSRR0(r11)
+ mfspr r0,SPRN_CSRR1
+ stw r0,_CSRR1(r11)
+ /* fall through */
.globl crit_transfer_to_handler
crit_transfer_to_handler:
+#ifdef CONFIG_FSL_BOOKE
+ mfspr r0,SPRN_MAS0
+ stw r0,MAS0(r11)
+ mfspr r0,SPRN_MAS1
+ stw r0,MAS1(r11)
+ mfspr r0,SPRN_MAS2
+ stw r0,MAS2(r11)
+ mfspr r0,SPRN_MAS3
+ stw r0,MAS3(r11)
+ mfspr r0,SPRN_MAS6
+ stw r0,MAS6(r11)
+#ifdef CONFIG_PHYS_64BIT
+ mfspr r0,SPRN_MAS7
+ stw r0,MAS7(r11)
+#endif /* CONFIG_PHYS_64BIT */
+#endif /* CONFIG_FSL_BOOKE */
+ mfspr r0,SPRN_SRR0
+ stw r0,_SRR0(r11)
+ mfspr r0,SPRN_SRR1
+ stw r0,_SRR1(r11)
/* fall through */
#endif
@@ -64,6 +92,10 @@ crit_transfer_to_handler:
stw r0,GPR10(r11)
lwz r0,crit_r11@l(0)
stw r0,GPR11(r11)
+ mfspr r0,SPRN_SRR0
+ stw r0,crit_srr0@l(0)
+ mfspr r0,SPRN_SRR1
+ stw r0,crit_srr1@l(0)
/* fall through */
#endif
@@ -846,17 +878,66 @@ exc_exit_restart_end:
exc_lvl_rfi; \
b .; /* prevent prefetch past exc_lvl_rfi */
+#define RESTORE_xSRR(exc_lvl_srr0, exc_lvl_srr1) \
+ lwz r9,_##exc_lvl_srr0(r1); \
+ lwz r10,_##exc_lvl_srr1(r1); \
+ mtspr SPRN_##exc_lvl_srr0,r9; \
+ mtspr SPRN_##exc_lvl_srr1,r10;
+
+#ifdef CONFIG_FSL_BOOKE
+#ifdef CONFIG_PHYS_64BIT
+#define RESTORE_MAS7 \
+ lwz r11,MAS7(r1); \
+ mtspr SPRN_MAS7,r11;
+#else
+#define RESTORE_MAS7
+#endif /* CONFIG_PHYS_64BIT */
+#define RESTORE_MAS_REGS \
+ lwz r9,MAS0(r1); \
+ lwz r10,MAS1(r1); \
+ lwz r11,MAS2(r1); \
+ mtspr SPRN_MAS0,r9; \
+ lwz r9,MAS3(r1); \
+ mtspr SPRN_MAS1,r10; \
+ lwz r10,MAS6(r1); \
+ mtspr SPRN_MAS2,r11; \
+ mtspr SPRN_MAS3,r9; \
+ mtspr SPRN_MAS6,r10; \
+ RESTORE_MAS7;
+#else
+#define RESTORE_MAS_REGS
+#endif
+
+#ifdef CONFIG_40x
.globl ret_from_crit_exc
ret_from_crit_exc:
+ lwz r9,crit_srr0@l(0);
+ lwz r10,crit_srr1@l(0);
+ mtspr SPRN_SRR0,r9;
+ mtspr SPRN_SRR1,r10;
RET_FROM_EXC_LEVEL(SPRN_CSRR0, SPRN_CSRR1, RFCI)
+#endif /* CONFIG_40x */
#ifdef CONFIG_BOOKE
+ .globl ret_from_crit_exc
+ret_from_crit_exc:
+ RESTORE_xSRR(SRR0,SRR1);
+ RESTORE_MAS_REGS;
+ RET_FROM_EXC_LEVEL(SPRN_CSRR0, SPRN_CSRR1, RFCI)
+
.globl ret_from_debug_exc
ret_from_debug_exc:
+ RESTORE_xSRR(SRR0,SRR1);
+ RESTORE_xSRR(CSRR0,CSRR1);
+ RESTORE_MAS_REGS;
RET_FROM_EXC_LEVEL(SPRN_DSRR0, SPRN_DSRR1, RFDI)
.globl ret_from_mcheck_exc
ret_from_mcheck_exc:
+ RESTORE_xSRR(SRR0,SRR1);
+ RESTORE_xSRR(CSRR0,CSRR1);
+ RESTORE_xSRR(DSRR0,DSRR1);
+ RESTORE_MAS_REGS;
RET_FROM_EXC_LEVEL(SPRN_MCSRR0, SPRN_MCSRR1, RFMCI)
#endif /* CONFIG_BOOKE */
diff --git a/arch/powerpc/kernel/head_40x.S b/arch/powerpc/kernel/head_40x.S
index ca75eaf..3c819a1 100644
--- a/arch/powerpc/kernel/head_40x.S
+++ b/arch/powerpc/kernel/head_40x.S
@@ -93,6 +93,10 @@ _ENTRY(crit_r10)
.space 4
_ENTRY(crit_r11)
.space 4
+_ENTRY(crit_srr0)
+ .space 4
+_ENTRY(crit_srr1)
+ .space 4
/*
* Exception vector entry code. This code runs with address translation
diff --git a/arch/powerpc/kernel/head_booke.h b/arch/powerpc/kernel/head_booke.h
index 78baec5..5f5429f 100644
--- a/arch/powerpc/kernel/head_booke.h
+++ b/arch/powerpc/kernel/head_booke.h
@@ -78,12 +78,12 @@
slwi r8,r8,2; \
addis r8,r8,level##_STACK_TOP@ha; \
lwz r8,level##_STACK_TOP@l(r8); \
- addi r8,r8,THREAD_SIZE-INT_FRAME_SIZE;
+ addi r8,r8,THREAD_SIZE-INT_FRAME_SIZE-EXC_LVL_SIZE;
#else
#define BOOKE_LOAD_EXC_LEVEL_STACK(level) \
lis r8,level##_STACK_TOP@ha; \
lwz r8,level##_STACK_TOP@l(r8); \
- addi r8,r8,THREAD_SIZE-INT_FRAME_SIZE;
+ addi r8,r8,THREAD_SIZE-INT_FRAME_SIZE-EXC_LVL_SIZE;
#endif
/*
@@ -373,4 +373,24 @@ label:
addi r3,r1,STACK_FRAME_OVERHEAD; \
EXC_XFER_EE_LITE(0x800, kernel_fp_unavailable_exception)
+#ifndef __ASSEMBLY__
+/* ensure this structure is always sized to a multiple of the stack alignment */
+struct exception_regs {
+ unsigned long mas0;
+ unsigned long mas1;
+ unsigned long mas2;
+ unsigned long mas3;
+ unsigned long mas6;
+ unsigned long mas7;
+ unsigned long srr0;
+ unsigned long srr1;
+ unsigned long csrr0;
+ unsigned long csrr1;
+ unsigned long dsrr0;
+ unsigned long dsrr1;
+};
+
+#define STACK_EXC_LVL_FRAME_SIZE (sizeof (struct exception_regs))
+
+#endif /* __ASSEMBLY__ */
#endif /* __HEAD_BOOKE_H__ */
--
1.5.4.1
^ permalink raw reply related
* [PATCH] [POWERPC] Set lower flag bits in regs->trap to indicate debug level exception
From: Kumar Gala @ 2008-04-30 10:44 UTC (permalink / raw)
To: linuxppc-dev
We use the low bits of regs->trap as flag bits. We already indicate
critical and machine check level exceptions via this mechanism. Extend it
to indicate debug level exceptions.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/kernel/head_booke.h | 2 +-
include/asm-powerpc/ptrace.h | 1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/head_booke.h b/arch/powerpc/kernel/head_booke.h
index 5f5429f..24cc6b8 100644
--- a/arch/powerpc/kernel/head_booke.h
+++ b/arch/powerpc/kernel/head_booke.h
@@ -278,7 +278,7 @@ label:
/* continue normal handling for a critical exception... */ \
2: mfspr r4,SPRN_DBSR; \
addi r3,r1,STACK_FRAME_OVERHEAD; \
- EXC_XFER_TEMPLATE(DebugException, 0x2002, (MSR_KERNEL & ~(MSR_ME|MSR_DE|MSR_CE)), NOCOPY, debug_transfer_to_handler, ret_from_debug_exc)
+ EXC_XFER_TEMPLATE(DebugException, 0x2008, (MSR_KERNEL & ~(MSR_ME|MSR_DE|MSR_CE)), NOCOPY, debug_transfer_to_handler, ret_from_debug_exc)
#define DEBUG_CRIT_EXCEPTION \
START_EXCEPTION(DebugCrit); \
diff --git a/include/asm-powerpc/ptrace.h b/include/asm-powerpc/ptrace.h
index 39023dd..38d87e5 100644
--- a/include/asm-powerpc/ptrace.h
+++ b/include/asm-powerpc/ptrace.h
@@ -119,6 +119,7 @@ extern int ptrace_put_reg(struct task_struct *task, int regno,
#ifndef __powerpc64__
#define IS_CRITICAL_EXC(regs) (((regs)->trap & 2) != 0)
#define IS_MCHECK_EXC(regs) (((regs)->trap & 4) != 0)
+#define IS_DEBUG_EXC(regs) (((regs)->trap & 8) != 0)
#endif /* ! __powerpc64__ */
#define TRAP(regs) ((regs)->trap & ~0xF)
#ifdef __powerpc64__
--
1.5.4.1
^ permalink raw reply related
* Re: [PATCH 6/6] [POWERPC] booting-without-of: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
From: Anton Vorontsov @ 2008-04-30 11:16 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev
In-Reply-To: <48182FA6.5010900@grandegger.com>
On Wed, Apr 30, 2008 at 10:36:54AM +0200, Wolfgang Grandegger wrote:
> Hi Anton,
[...]
> > + upm@1,0 {
> > + #address-cells = <0>;
> > + #size-cells = <0>;
> > + compatible = "fsl,upm-nand";
> > + reg = <1 0 1>;
> > + fsl,upm-addr-offset = <16>;
> > + fsl,upm-cmd-offset = <8>;
> > + gpios = <&qe_pio_e 18 0>;
> > +
> > + flash {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "stmicro,NAND512W3A2BN6E";
> > +
> > + partition@0 {
> > + ...
> > + };
> > + };
> > + };
>
> Where can I find the code for that binding? fsl_upm_nand.c from
> http://patchwork.ozlabs.org/linuxppc/patch?q=upm&id=17306 does not parse
> OF partitions. Are there any plans to push the fsl_upm_nand driver
> upstream?
David already pushed UPM NAND driver upstream, but true, it was an "old"
version, i.e. without approved bindings. I'll send the update (inlining
here) if/when these bindings will be applied to the powerpc tree.
- - - -
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Subject: [NAND] update FSL UPM NAND driver for the new OF bindings
- get rid of fsl,wait-pattern and fsl,wait-write. I think this isn't
chip-specific, and we should always do waits. I saw one board that
didn't need fsl,wait-pattern, but I assume it was exception that
proves general rule;
- get rid of chip-delay. Today there are no users for this, and if
anyone really need this they should push the OF bindings beforehand;
- Now flash chips should be child nodes of the FSL UPM nand controller;
- Implement OF partition parsing.
Signed-off-by: not yet.
---
drivers/mtd/nand/fsl_upm.c | 62 +++++++++++++++++++++++++++-----------------
1 files changed, 38 insertions(+), 24 deletions(-)
diff --git a/drivers/mtd/nand/fsl_upm.c b/drivers/mtd/nand/fsl_upm.c
index 1ebfd87..f91c950 100644
--- a/drivers/mtd/nand/fsl_upm.c
+++ b/drivers/mtd/nand/fsl_upm.c
@@ -36,9 +36,6 @@ struct fsl_upm_nand {
uint8_t upm_cmd_offset;
void __iomem *io_base;
int rnb_gpio;
- const uint32_t *wait_pattern;
- const uint32_t *wait_write;
- int chip_delay;
};
#define to_fsl_upm_nand(mtd) container_of(mtd, struct fsl_upm_nand, mtd)
@@ -89,8 +86,7 @@ static void fun_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
fsl_upm_run_pattern(&fun->upm, fun->io_base, cmd);
- if (fun->wait_pattern)
- fun_wait_rnb(fun);
+ fun_wait_rnb(fun);
}
static uint8_t fun_read_byte(struct mtd_info *mtd)
@@ -116,14 +112,16 @@ static void fun_write_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
for (i = 0; i < len; i++) {
out_8(fun->chip.IO_ADDR_W, buf[i]);
- if (fun->wait_write)
- fun_wait_rnb(fun);
+ fun_wait_rnb(fun);
}
}
-static int __devinit fun_chip_init(struct fsl_upm_nand *fun)
+static int __devinit fun_chip_init(struct fsl_upm_nand *fun,
+ const struct device_node *upm_np,
+ const struct resource *io_res)
{
int ret;
+ struct device_node *flash_np;
#ifdef CONFIG_MTD_PARTITIONS
static const char *part_types[] = { "cmdlinepart", NULL, };
#endif
@@ -131,7 +129,7 @@ static int __devinit fun_chip_init(struct fsl_upm_nand *fun)
fun->chip.IO_ADDR_R = fun->io_base;
fun->chip.IO_ADDR_W = fun->io_base;
fun->chip.cmd_ctrl = fun_cmd_ctrl;
- fun->chip.chip_delay = fun->chip_delay;
+ fun->chip.chip_delay = 50;
fun->chip.read_byte = fun_read_byte;
fun->chip.read_buf = fun_read_buf;
fun->chip.write_buf = fun_write_buf;
@@ -143,18 +141,42 @@ static int __devinit fun_chip_init(struct fsl_upm_nand *fun)
fun->mtd.priv = &fun->chip;
fun->mtd.owner = THIS_MODULE;
+ flash_np = of_get_next_child(upm_np, NULL);
+ if (!flash_np)
+ return -ENODEV;
+
+ fun->mtd.name = kasprintf(GFP_KERNEL, "%x.%s", io_res->start,
+ flash_np->name);
+ if (!fun->mtd.name) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
ret = nand_scan(&fun->mtd, 1);
if (ret)
- return ret;
-
- fun->mtd.name = fun->dev->bus_id;
+ goto err;
#ifdef CONFIG_MTD_PARTITIONS
ret = parse_mtd_partitions(&fun->mtd, part_types, &fun->parts, 0);
+
+#ifdef CONFIG_MTD_OF_PARTS
+ if (ret <= 0) {
+ ret = of_mtd_parse_partitions(fun->dev, &fun->mtd,
+ flash_np, &fun->parts);
+ if (ret < 0) {
+ ret = -EINVAL;
+ goto err;
+ }
+ }
+#endif
if (ret > 0)
- return add_mtd_partitions(&fun->mtd, fun->parts, ret);
+ ret = add_mtd_partitions(&fun->mtd, fun->parts, ret);
+ else
#endif
- return add_mtd_device(&fun->mtd);
+ ret = add_mtd_device(&fun->mtd);
+err:
+ of_node_put(flash_np);
+ return ret;
}
static int __devinit fun_probe(struct of_device *ofdev,
@@ -220,17 +242,8 @@ static int __devinit fun_probe(struct of_device *ofdev,
fun->dev = &ofdev->dev;
fun->last_ctrl = NAND_CLE;
- fun->wait_pattern = of_get_property(ofdev->node, "fsl,wait-pattern",
- NULL);
- fun->wait_write = of_get_property(ofdev->node, "fsl,wait-write", NULL);
-
- prop = of_get_property(ofdev->node, "chip-delay", NULL);
- if (prop)
- fun->chip_delay = *prop;
- else
- fun->chip_delay = 50;
- ret = fun_chip_init(fun);
+ ret = fun_chip_init(fun, ofdev->node, &io_res);
if (ret)
goto err2;
@@ -251,6 +264,7 @@ static int __devexit fun_remove(struct of_device *ofdev)
struct fsl_upm_nand *fun = dev_get_drvdata(&ofdev->dev);
nand_release(&fun->mtd);
+ kfree(fun->mtd.name);
if (fun->rnb_gpio >= 0)
gpio_free(fun->rnb_gpio);
--
1.5.5.1
^ permalink raw reply related
* Re: FW: SKB corruption on heavy traffic
From: Gerhard Pircher @ 2008-04-30 12:25 UTC (permalink / raw)
To: Franca, Jose (NSN - PT/Portugal - MiniMD), Scott Wood
Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <56DEE2D3217CD946B290399093C8FA7C212E48@PTLIEXC001.nsn-intra.net>
Hi,
I think I have the same problem here with all versions of the 2.6.x kernel
series (tested with kernel v2.6.8/14/16/18/25 on a PPC7455 machine with
different PCI network cards by transferring a big file over NFS/SCP). Data
corruption occurs under high load, but I don't get any kernel oops.
regards,
Gerhard
-------- Original-Nachricht --------
> Datum: Wed, 30 Apr 2008 10:07:15 +0100
> Von: "Franca, Jose (NSN - PT/Portugal - MiniMD)" <jose.franca@nsn.com>
> An: linuxppc-dev@ozlabs.org, linuxppc-embedded@ozlabs.org
> Betreff: FW: SKB corruption on heavy traffic
> >From our latest debugs we found that the problem occurs mainly on skbuff
> code. After some variable time kfree or kalloc result in kernel oops.
>
> -----Original Message-----
> From: Franca, Jose (NSN - PT/Portugal - MiniMD)
> Sent: quarta-feira, 30 de Abril de 2008 9:44
> To: 'ext Scott Wood'
> Cc:
> Subject: RE: SKB corruption on heavy traffic
>
> Hello!
>
> Thank you for replying!
> It't quite dificult to say if the problem exists without our
> changes, since the all software is dependent on this changes so to work
> with the hardware. I can't answer to that right now on that, but I forgot
> to add one thing: we have ring buffer full problems on our fcc_enet
> driver from time to time. So, I think the problem could be on linux
> configurations (related to hw) because there is a lot of posts on the web
> related to problems similar to this (none of them has really solved the
> bottom problem).
>
> Regards,
> Filipe
>
> -----Original Message-----
> From: ext Scott Wood [mailto:scottwood@freescale.com]
> Sent: terça-feira, 29 de Abril de 2008 20:15
> To: Franca, Jose (NSN - PT/Portugal - MiniMD)
> Cc: linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org
> Subject: Re: SKB corruption on heavy traffic
>
> On Tue, Apr 29, 2008 at 07:39:07PM +0100, Franca, Jose (NSN - PT/Portugal
> - MiniMD) wrote:
> > We are developing a MPC8247 based telecom board (512MB), using
> > linux 2.4 with some proprietary changes on IP stack and we are facing
> > some problems when we have heavy traffic on our Ethernet interfaces...
>
> Do you see these problems without the proprietary changes, and with a
> current kernel?
>
> -Scott
--
Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games!
http://games.entertainment.gmx.net/de/entertainment/games/free
^ permalink raw reply
* RE: FW: SKB corruption on heavy traffic
From: Franca, Jose (NSN - PT/Portugal - MiniMD) @ 2008-04-30 13:03 UTC (permalink / raw)
To: ext Gerhard Pircher, Scott Wood; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <20080430122556.40830@gmx.net>
Hi!
There was a sugestion to change slab to slub alocation method... I =
don't know quite well yet what is necessary to do this, but it seems =
that the current implementation of slub is more commonly available on =
2.6 kernels, not in 2.4 that I use :(...
Any guesses or hints on this?
Regards!
Filipe.
-----Original Message-----
From: ext Gerhard Pircher [mailto:gerhard_pircher@gmx.net]=20
Sent: quarta-feira, 30 de Abril de 2008 13:26
To: Franca, Jose (NSN - PT/Portugal - MiniMD); Scott Wood
Cc: linuxppc-embedded@ozlabs.org; linuxppc-dev@ozlabs.org
Subject: Re: FW: SKB corruption on heavy traffic
Hi,
I think I have the same problem here with all versions of the 2.6.x =
kernel
series (tested with kernel v2.6.8/14/16/18/25 on a PPC7455 machine with
different PCI network cards by transferring a big file over NFS/SCP). =
Data
corruption occurs under high load, but I don't get any kernel oops.
regards,
Gerhard
-------- Original-Nachricht --------
> Datum: Wed, 30 Apr 2008 10:07:15 +0100
> Von: "Franca, Jose (NSN - PT/Portugal - MiniMD)" <jose.franca@nsn.com>
> An: linuxppc-dev@ozlabs.org, linuxppc-embedded@ozlabs.org
> Betreff: FW: SKB corruption on heavy traffic
> >From our latest debugs we found that the problem occurs mainly on =
skbuff
> code. After some variable time kfree or kalloc result in kernel oops.
>=20
> -----Original Message-----
> From: Franca, Jose (NSN - PT/Portugal - MiniMD)=20
> Sent: quarta-feira, 30 de Abril de 2008 9:44
> To: 'ext Scott Wood'
> Cc: =09
> Subject: RE: SKB corruption on heavy traffic
>=20
> Hello!
>=20
> Thank you for replying!
> It't quite dificult to say if the problem exists without our
> changes, since the all software is dependent on this changes so to =
work
> with the hardware. I can't answer to that right now on that, but I =
forgot=20
> to add one thing: we have ring buffer full problems on our fcc_enet
> driver from time to time. So, I think the problem could be on linux
> configurations (related to hw) because there is a lot of posts on the =
web=20
> related to problems similar to this (none of them has really solved =
the
> bottom problem).=20
>=20
> Regards,
> Filipe=20
>=20
> -----Original Message-----
> From: ext Scott Wood [mailto:scottwood@freescale.com]=20
> Sent: ter=E7a-feira, 29 de Abril de 2008 20:15
> To: Franca, Jose (NSN - PT/Portugal - MiniMD)
> Cc: linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org
> Subject: Re: SKB corruption on heavy traffic
>=20
> On Tue, Apr 29, 2008 at 07:39:07PM +0100, Franca, Jose (NSN - =
PT/Portugal
> - MiniMD) wrote:
> > We are developing a MPC8247 based telecom board (512MB), using
> > linux 2.4 with some proprietary changes on IP stack and we are =
facing
> > some problems when we have heavy traffic on our Ethernet =
interfaces...
>=20
> Do you see these problems without the proprietary changes, and with a
> current kernel?
>=20
> -Scott
--=20
Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games! =
http://games.entertainment.gmx.net/de/entertainment/games/free
^ permalink raw reply
* Re: [PATCH] [POWERPC] mpc5200: Allow for fixed speed MII configurations
From: Grant Likely @ 2008-04-30 13:07 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: netdev, linuxppc-dev, paulus, domen.puncer
In-Reply-To: <1209540962.18445.8.camel@gentoo-jocke.transmode.se>
On Wed, Apr 30, 2008 at 1:36 AM, Joakim Tjernlund
<joakim.tjernlund@transmode.se> wrote:
>
> On Tue, 2008-04-29 at 17:06 -0600, Grant Likely wrote:
> > From: Grant Likely <grant.likely@secretlab.ca>
> >
> > Various improvements for configuring the MPC5200 MII link from the
> > device tree:
> > * Look for 'current-speed' property for fixed speed MII links
>
> Not that I have looked, but why can't you use the fixed-link property?
fixed-link seems to be a recent invention, whereas current-speed is
better know having already been in use with serial devices. It seemed
to me to be a better choice, but my opinion can probably be swayed
(arguments welcome).
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: EXT_IRQ0 @ MPC834x
From: André Schwarz @ 2008-04-30 13:09 UTC (permalink / raw)
To: linux-ppc list
In-Reply-To: <48175059.9080001@matrix-vision.de>
Issue solved !
IRQ has been requested with IRQF_SHARED.
Obviously this is not neccessary and caused this bogus behaviour.
Don't know if it's a bug or a feature.
Cheers,
Andr=E9
Andre Schwarz schrieb:
> All,
>=20
> actually I'm having trouble getting the IRQ0 work on a MPC8343 with
> 2.6.25-rc8.
> There's an external PCI device connected to it ....
>=20
>=20
> Regarding to the manual IRQ0 is somewhat special and has Vector 48 assi=
gned.
>=20
> Therefore my dts entry for this device looks like :
>=20
> interrupt-map =3D <0x5800 0 0 1 &ipic 0x30 0x8
> ... >;
>=20
> Having a look on virq mapping gives :
>=20
> mvBL-M7> cat /sys/kernel/debug/powerpc/virq_mapping
> virq hwirq chip name host name
> 16 0x0000e IPIC /soc@e0000000/pic@700
> 17 0x0000f IPIC /soc@e0000000/pic@700
> 18 0x00009 IPIC /soc@e0000000/pic@700
> 20 0x00010 IPIC /soc@e0000000/pic@700
> 32 0x00020 IPIC /soc@e0000000/pic@700
> 33 0x00021 IPIC /soc@e0000000/pic@700
> 34 0x00022 IPIC /soc@e0000000/pic@700
> 38 0x00026 IPIC /soc@e0000000/pic@700
> 48 0x00030 IPIC /soc@e0000000/pic@700
>=20
>=20
> After loading the device driver (=3Dmvbcdma) the irq shows up correctly=
.
>=20
> mvBL-M7> cat /proc/interrupts
> CPU0
> 16: 603 IPIC Level i2c-mpc
> 17: 8 IPIC Level i2c-mpc
> 18: 295 IPIC Level serial
> 20: 341 IPIC Level mpc83xx_spi
> 32: 2 IPIC Level enet_tx
> 33: 3 IPIC Level enet_rx
> 34: 0 IPIC Level enet_error
> 38: 0 IPIC Level ehci_hcd:usb1
> 48: 0 IPIC Level mvbcdma0
> BAD: 0
>=20
>=20
> As soon as the device generates an interrupt I get :
>=20
> irq 48: nobody cared (try booting with the "irqpoll" option)
> handlers:
> [<d18d66e8>] (mvbcdma_irq+0x0/0x180 [mvbcdma])
> Disabling IRQ #48
>=20
>=20
> The handler _would_ have returned IRQ_RETVAL(1).
> Obviously the handler isn't called at all - but why ?
>=20
>=20
> Using "nm" on the kernel module gives :
>=20
> 000006e8 t mvbcdma_irq
>=20
> ->offset 0x6e8 inside module matches with output regarding handler.
>=20
>=20
> Any help is welcome !
>=20
>=20
> regards,
> Andre Schwarz
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> MATRIX VISION GmbH, Talstra=DFe 16, DE-71570 Oppenweiler - Registerger=
icht: Amtsgericht Stuttgart, HRB 271090
> Gesch=E4ftsf=FChrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
MATRIX VISION GmbH, Talstra=DFe 16, DE-71570 Oppenweiler - Registergeric=
ht: Amtsgericht Stuttgart, HRB 271090
Gesch=E4ftsf=FChrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
^ permalink raw reply
* Re: [PATCH] [POWERPC] mpc5200: Allow for fixed speed MII configurations
From: Joakim Tjernlund @ 2008-04-30 13:10 UTC (permalink / raw)
To: Grant Likely; +Cc: netdev, linuxppc-dev, paulus, domen.puncer
In-Reply-To: <fa686aa40804300607k72ef9985m43b3c4111cad6085@mail.gmail.com>
On Wed, 2008-04-30 at 07:07 -0600, Grant Likely wrote:
> On Wed, Apr 30, 2008 at 1:36 AM, Joakim Tjernlund
> <joakim.tjernlund@transmode.se> wrote:
> >
> > On Tue, 2008-04-29 at 17:06 -0600, Grant Likely wrote:
> > > From: Grant Likely <grant.likely@secretlab.ca>
> > >
> > > Various improvements for configuring the MPC5200 MII link from the
> > > device tree:
> > > * Look for 'current-speed' property for fixed speed MII links
> >
> > Not that I have looked, but why can't you use the fixed-link property?
>
> fixed-link seems to be a recent invention, whereas current-speed is
> better know having already been in use with serial devices. It seemed
> to me to be a better choice, but my opinion can probably be swayed
> (arguments welcome).
yes it is fairly new. You get alot more than just speed: Duplex/Pause
You need these too.
Jocke
^ permalink raw reply
* Re: [PATCH 6/6] [POWERPC] booting-without-of: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
From: Wolfgang Grandegger @ 2008-04-30 13:19 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080430111656.GA14148@polina.dev.rtsoft.ru>
Anton Vorontsov wrote:
> On Wed, Apr 30, 2008 at 10:36:54AM +0200, Wolfgang Grandegger wrote:
>> Hi Anton,
> [...]
>>> + upm@1,0 {
>>> + #address-cells = <0>;
>>> + #size-cells = <0>;
>>> + compatible = "fsl,upm-nand";
>>> + reg = <1 0 1>;
>>> + fsl,upm-addr-offset = <16>;
>>> + fsl,upm-cmd-offset = <8>;
>>> + gpios = <&qe_pio_e 18 0>;
>>> +
>>> + flash {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + compatible = "stmicro,NAND512W3A2BN6E";
>>> +
>>> + partition@0 {
>>> + ...
>>> + };
>>> + };
>>> + };
>> Where can I find the code for that binding? fsl_upm_nand.c from
>> http://patchwork.ozlabs.org/linuxppc/patch?q=upm&id=17306 does not parse
>> OF partitions. Are there any plans to push the fsl_upm_nand driver
>> upstream?
>
> David already pushed UPM NAND driver upstream, but true, it was an "old"
> version, i.e. without approved bindings. I'll send the update (inlining
> here) if/when these bindings will be applied to the powerpc tree.
OK, thanks a lot.
> - - - -
> From: Anton Vorontsov <avorontsov@ru.mvista.com>
> Subject: [NAND] update FSL UPM NAND driver for the new OF bindings
>
> - get rid of fsl,wait-pattern and fsl,wait-write. I think this isn't
> chip-specific, and we should always do waits. I saw one board that
> didn't need fsl,wait-pattern, but I assume it was exception that
> proves general rule;
> - get rid of chip-delay. Today there are no users for this, and if
> anyone really need this they should push the OF bindings beforehand;
> - Now flash chips should be child nodes of the FSL UPM nand controller;
> - Implement OF partition parsing.
On what hardware did you test the NAND-UPM driver? Unfortunately, the
TQM8548 does not support the R/B pin and therefore GPIO support is not
needed but a chip delay. Furthermore some "asm sync" are required when
executing the run pattern:
static inline int fsl_upm_run_pattern(struct fsl_upm *upm,
void __iomem *io_base, u32 mar)
{
int ret = 0, i;
unsigned long flags;
spin_lock_irqsave(&fsl_lbc_lock, flags);
out_be32(&fsl_lbc_regs->mar, mar << (32 - upm->width));
asm("sync; isync; msync");
switch (upm->width) {
case 8:
out_8(io_base, 0x0);
break;
case 16:
out_be16(io_base, 0x0);
break;
case 32:
out_be32(io_base, 0x0);
break;
default:
ret = -EINVAL;
break;
}
asm("sync; isync; msync");
spin_unlock_irqrestore(&fsl_lbc_lock, flags);
return ret;
}
Is this a known problem with the MPC85xx? How do we handle it?
Wolfgang.
^ permalink raw reply
* Re: [PATCH] [POWERPC] mpc5200: Allow for fixed speed MII configurations
From: Grant Likely @ 2008-04-30 13:26 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: netdev, linuxppc-dev, paulus, domen.puncer
In-Reply-To: <1209561053.16926.2.camel@gentoo-jocke.transmode.se>
On Wed, Apr 30, 2008 at 7:10 AM, Joakim Tjernlund
<joakim.tjernlund@transmode.se> wrote:
>
>
> On Wed, 2008-04-30 at 07:07 -0600, Grant Likely wrote:
> > On Wed, Apr 30, 2008 at 1:36 AM, Joakim Tjernlund
> > <joakim.tjernlund@transmode.se> wrote:
> > >
> > > On Tue, 2008-04-29 at 17:06 -0600, Grant Likely wrote:
> > > > From: Grant Likely <grant.likely@secretlab.ca>
> > > >
> > > > Various improvements for configuring the MPC5200 MII link from the
> > > > device tree:
> > > > * Look for 'current-speed' property for fixed speed MII links
> > >
> > > Not that I have looked, but why can't you use the fixed-link property?
> >
> > fixed-link seems to be a recent invention, whereas current-speed is
> > better know having already been in use with serial devices. It seemed
> > to me to be a better choice, but my opinion can probably be swayed
> > (arguments welcome).
>
> yes it is fairly new. You get alot more than just speed: Duplex/Pause
> You need these too.
duplex I've got. pause I don't need.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 6/6] [POWERPC] booting-without-of: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
From: Anton Vorontsov @ 2008-04-30 14:07 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev
In-Reply-To: <481871E9.5000101@grandegger.com>
On Wed, Apr 30, 2008 at 03:19:37PM +0200, Wolfgang Grandegger wrote:
> Anton Vorontsov wrote:
> > On Wed, Apr 30, 2008 at 10:36:54AM +0200, Wolfgang Grandegger wrote:
> >> Hi Anton,
> > [...]
> >>> + upm@1,0 {
> >>> + #address-cells = <0>;
> >>> + #size-cells = <0>;
> >>> + compatible = "fsl,upm-nand";
> >>> + reg = <1 0 1>;
> >>> + fsl,upm-addr-offset = <16>;
> >>> + fsl,upm-cmd-offset = <8>;
> >>> + gpios = <&qe_pio_e 18 0>;
> >>> +
> >>> + flash {
> >>> + #address-cells = <1>;
> >>> + #size-cells = <1>;
> >>> + compatible = "stmicro,NAND512W3A2BN6E";
> >>> +
> >>> + partition@0 {
> >>> + ...
> >>> + };
> >>> + };
> >>> + };
> >> Where can I find the code for that binding? fsl_upm_nand.c from
> >> http://patchwork.ozlabs.org/linuxppc/patch?q=upm&id=17306 does not parse
> >> OF partitions. Are there any plans to push the fsl_upm_nand driver
> >> upstream?
> >
> > David already pushed UPM NAND driver upstream, but true, it was an "old"
> > version, i.e. without approved bindings. I'll send the update (inlining
> > here) if/when these bindings will be applied to the powerpc tree.
>
> OK, thanks a lot.
>
> > - - - -
> > From: Anton Vorontsov <avorontsov@ru.mvista.com>
> > Subject: [NAND] update FSL UPM NAND driver for the new OF bindings
> >
> > - get rid of fsl,wait-pattern and fsl,wait-write. I think this isn't
> > chip-specific, and we should always do waits. I saw one board that
> > didn't need fsl,wait-pattern, but I assume it was exception that
> > proves general rule;
> > - get rid of chip-delay. Today there are no users for this, and if
> > anyone really need this they should push the OF bindings beforehand;
> > - Now flash chips should be child nodes of the FSL UPM nand controller;
> > - Implement OF partition parsing.
>
> On what hardware did you test the NAND-UPM driver? Unfortunately, the
> TQM8548 does not support the R/B pin and therefore GPIO support is not
> needed but a chip delay. Furthermore some "asm sync" are required when
> executing the run pattern:
Too bad you need this. Oh well, you need to discuss property name with
the OF guys, or think out some other way to deliver the chip delay
value.
> static inline int fsl_upm_run_pattern(struct fsl_upm *upm,
> void __iomem *io_base, u32 mar)
> {
> int ret = 0, i;
> unsigned long flags;
>
> spin_lock_irqsave(&fsl_lbc_lock, flags);
>
> out_be32(&fsl_lbc_regs->mar, mar << (32 - upm->width));
>
> asm("sync; isync; msync");
>
> switch (upm->width) {
> case 8:
> out_8(io_base, 0x0);
> break;
> case 16:
> out_be16(io_base, 0x0);
> break;
> case 32:
> out_be32(io_base, 0x0);
> break;
> default:
> ret = -EINVAL;
> break;
> }
>
> asm("sync; isync; msync");
>
> spin_unlock_irqrestore(&fsl_lbc_lock, flags);
>
> return ret;
> }
>
>
> Is this a known problem with the MPC85xx? How do we handle it?
I did test this driver on MPC8555 and MPC8360 UPMs. They didn't need
these syncs.. quite suspicious syncs, I must say. Maybe you should
check TLB setup, for the UPM NAND it should be non-cacheable and
guarded, IIRC.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox