[PATCH] Merge Axon MSI trigger debugging
I've forward-ported this patch three times now, so we should just put it in the tree and save the trouble. It's all inside #ifdef DEBUG so causes no harm unless it's enabled. Signed-off-by: Michael Ellerman [EMAIL PROTECTED] --- arch/powerpc/platforms/cell/axon_msi.c | 58 1 files changed, 58 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/platforms/cell/axon_msi.c b/arch/powerpc/platforms/cell/axon_msi.c index c39f5c2..8b055bc 100644 --- a/arch/powerpc/platforms/cell/axon_msi.c +++ b/arch/powerpc/platforms/cell/axon_msi.c @@ -14,6 +14,7 @@ #include linux/pci.h #include linux/msi.h #include linux/of_platform.h +#include linux/debugfs.h #include asm/dcr.h #include asm/machdep.h @@ -69,8 +70,19 @@ struct axon_msic { dma_addr_t fifo_phys; dcr_host_t dcr_host; u32 read_offset; +#ifdef DEBUG + u32 __iomem *trigger; +#endif }; +#ifdef DEBUG +void axon_msi_debug_setup(struct device_node *dn, struct axon_msic *msic); +#else +static inline void axon_msi_debug_setup(struct device_node *dn, + struct axon_msic *msic) { } +#endif + + static void msic_dcr_write(struct axon_msic *msic, unsigned int dcr_n, u32 val) { pr_debug(axon_msi: dcr_write(0x%x, 0x%x)\n, val, dcr_n); @@ -381,6 +393,8 @@ static int axon_msi_probe(struct of_device *device, ppc_md.teardown_msi_irqs = axon_msi_teardown_msi_irqs; ppc_md.msi_check_device = axon_msi_check_device; + axon_msi_debug_setup(dn, msic); + printk(KERN_DEBUG axon_msi: setup MSIC on %s\n, dn-full_name); return 0; @@ -418,3 +432,47 @@ static int __init axon_msi_init(void) return of_register_platform_driver(axon_msi_driver); } subsys_initcall(axon_msi_init); + + +#ifdef DEBUG +static int msic_set(void *data, u64 val) +{ + struct axon_msic *msic = data; + out_le32(msic-trigger, val); + return 0; +} + +static int msic_get(void *data, u64 *val) +{ + *val = 0; + return 0; +} + +DEFINE_SIMPLE_ATTRIBUTE(fops_msic, msic_get, msic_set, %llu\n); + +void axon_msi_debug_setup(struct device_node *dn, struct axon_msic *msic) +{ + char name[8]; + u64 addr; + + addr = of_translate_address(dn, of_get_property(dn, reg, NULL)); + if (addr == OF_BAD_ADDR) { + pr_debug(axon_msi: couldn't translate reg property\n); + return; + } + + msic-trigger = ioremap(addr, 0x4); + if (!msic-trigger) { + pr_debug(axon_msi: ioremap failed\n); + return; + } + + snprintf(name, sizeof(name), msic_%d, of_node_to_nid(dn)); + + if (!debugfs_create_file(name, 0600, powerpc_debugfs_root, +msic, fops_msic)) { + pr_debug(axon_msi: debugfs_create_file failed!\n); + return; + } +} +#endif /* DEBUG */ -- 1.5.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[GIT PULL] Please pull spufs master branch
Hi Paul, Please do a: git-pull git://git.kernel.org/pub/scm/linux/kernel/git/jk/spufs.git For some updates for 2.6.26. This includes some sputrace updates and a new switch_log for spufs contexts. Cheers, Jeremy --- 6 commits: [POWERPC] spufs: add context switch notification log Christoph Hellwig [EMAIL PROTECTED] arch/powerpc/platforms/cell/spufs/context.c|1 arch/powerpc/platforms/cell/spufs/file.c | 166 ++ arch/powerpc/platforms/cell/spufs/run.c|2 arch/powerpc/platforms/cell/spufs/sched.c |2 arch/powerpc/platforms/cell/spufs/spufs.h | 29 + 5 files changed, 200 insertions(+) [POWERPC] spufs: add sputrace marker parameter names Julio M. Merino Vidal [EMAIL PROTECTED] arch/powerpc/platforms/cell/spufs/spufs.h |4 - arch/powerpc/platforms/cell/spufs/sputrace.c | 36 +- 2 files changed, 20 insertions(+), 20 deletions(-) [POWERPC] spufs: add marker for destroy_spu_context Julio M. Merino Vidal [EMAIL PROTECTED] arch/powerpc/platforms/cell/spufs/context.c|1 + 1 file changed, 1 insertion(+) [POWERPC] spufs: fix marker name for find_victim Julio M. Merino Vidal [EMAIL PROTECTED] arch/powerpc/platforms/cell/spufs/sched.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) [POWERPC] spufs: trace spu_acquire_saved events Julio M. Merino Vidal [EMAIL PROTECTED] arch/powerpc/platforms/cell/spufs/context.c|2 ++ 1 file changed, 2 insertions(+) [POWERPC] spufs: add .gitignore for spu_save_dump.h spu_restore_dump.h Kumar Gala [EMAIL PROTECTED] arch/powerpc/platforms/cell/spufs/.gitignore |0 arch/powerpc/platforms/cell/spufs/.gitignore |2 ++ 2 files changed, 2 insertions(+) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] mpc5200: Allow for fixed speed MII configurations
On Tue, 2008-04-29 at 17:06 -0600, Grant Likely wrote: From: Grant Likely [EMAIL PROTECTED] 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? Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC] [PATCH 1/5] [POWERPC] dma: implement new dma_*map*_attrs() interfaces
Update powerpc to use the new dma_*map*_attrs() interfaces. In doing so update struct dma_mapping_ops to accept a struct dma_attrs and propagate these changes through to all users of the code (generic IOMMU and the 64bit DMA code, and the iseries and ps3 platform code). The old dma_*map_*() interfaces are reimplemented as calls to the corresponding new interfaces. Signed-off-by: Mark Nelson [EMAIL PROTECTED] --- arch/powerpc/Kconfig|1 arch/powerpc/kernel/dma_64.c| 34 ++--- arch/powerpc/kernel/ibmebus.c | 12 ++- arch/powerpc/kernel/iommu.c | 11 +-- arch/powerpc/platforms/iseries/iommu.c |4 - arch/powerpc/platforms/ps3/system-bus.c | 17 ++-- include/asm-powerpc/dma-mapping.h | 116 +++- include/asm-powerpc/iommu.h | 12 ++- 8 files changed, 144 insertions(+), 63 deletions(-) Index: upstream/arch/powerpc/Kconfig === --- upstream.orig/arch/powerpc/Kconfig +++ upstream/arch/powerpc/Kconfig @@ -110,6 +110,7 @@ config PPC select HAVE_KPROBES select HAVE_KRETPROBES select HAVE_LMB + select HAVE_DMA_ATTRS config EARLY_PRINTK bool Index: upstream/arch/powerpc/kernel/dma_64.c === --- upstream.orig/arch/powerpc/kernel/dma_64.c +++ upstream/arch/powerpc/kernel/dma_64.c @@ -50,32 +50,38 @@ static void dma_iommu_free_coherent(stru */ static dma_addr_t dma_iommu_map_single(struct device *dev, void *vaddr, size_t size, - enum dma_data_direction direction) + enum dma_data_direction direction, + struct dma_attrs *attrs) { return iommu_map_single(dev, dev-archdata.dma_data, vaddr, size, - device_to_mask(dev), direction); + device_to_mask(dev), direction, attrs); } static void dma_iommu_unmap_single(struct device *dev, dma_addr_t dma_handle, size_t size, - enum dma_data_direction direction) + enum dma_data_direction direction, + struct dma_attrs *attrs) { - iommu_unmap_single(dev-archdata.dma_data, dma_handle, size, direction); + iommu_unmap_single(dev-archdata.dma_data, dma_handle, size, direction, + attrs); } static int dma_iommu_map_sg(struct device *dev, struct scatterlist *sglist, - int nelems, enum dma_data_direction direction) + int nelems, enum dma_data_direction direction, + struct dma_attrs *attrs) { return iommu_map_sg(dev, dev-archdata.dma_data, sglist, nelems, - device_to_mask(dev), direction); + device_to_mask(dev), direction, attrs); } static void dma_iommu_unmap_sg(struct device *dev, struct scatterlist *sglist, - int nelems, enum dma_data_direction direction) + int nelems, enum dma_data_direction direction, + struct dma_attrs *attrs) { - iommu_unmap_sg(dev-archdata.dma_data, sglist, nelems, direction); + iommu_unmap_sg(dev-archdata.dma_data, sglist, nelems, direction, + attrs); } /* We support DMA to/from any memory page via the iommu */ @@ -148,19 +154,22 @@ static void dma_direct_free_coherent(str static dma_addr_t dma_direct_map_single(struct device *dev, void *ptr, size_t size, - enum dma_data_direction direction) + enum dma_data_direction direction, + struct dma_attrs *attrs) { return virt_to_abs(ptr) + get_dma_direct_offset(dev); } static void dma_direct_unmap_single(struct device *dev, dma_addr_t dma_addr, size_t size, - enum dma_data_direction direction) + enum dma_data_direction direction, + struct dma_attrs *attrs) { } static int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl, -int nents, enum dma_data_direction direction) +int nents, enum dma_data_direction direction, +struct dma_attrs *attrs) { struct scatterlist *sg; int i; @@ -174,7 +183,8 @@ static int dma_direct_map_sg(struct devi } static void dma_direct_unmap_sg(struct device *dev, struct scatterlist *sg, - int nents, enum dma_data_direction direction) +
[RFC] [PATCH 2/5] [POWERPC] dma: use the struct dma_attrs in iommu code
Update iommu_alloc() to take the struct dma_attrs and pass them on to tce_build(). This change propagates down to the tce_build functions of all the platforms. Signed-off-by: Mark Nelson [EMAIL PROTECTED] --- arch/powerpc/kernel/iommu.c| 13 - arch/powerpc/platforms/cell/iommu.c|5 +++-- arch/powerpc/platforms/iseries/iommu.c |3 ++- arch/powerpc/platforms/pasemi/iommu.c |3 ++- arch/powerpc/platforms/pseries/iommu.c | 13 - arch/powerpc/sysdev/dart_iommu.c |3 ++- include/asm-powerpc/machdep.h |3 ++- 7 files changed, 27 insertions(+), 16 deletions(-) Index: upstream/arch/powerpc/kernel/iommu.c === --- upstream.orig/arch/powerpc/kernel/iommu.c +++ upstream/arch/powerpc/kernel/iommu.c @@ -186,7 +186,8 @@ static unsigned long iommu_range_alloc(s static dma_addr_t iommu_alloc(struct device *dev, struct iommu_table *tbl, void *page, unsigned int npages, enum dma_data_direction direction, - unsigned long mask, unsigned int align_order) + unsigned long mask, unsigned int align_order, + struct dma_attrs *attrs) { unsigned long entry, flags; dma_addr_t ret = DMA_ERROR_CODE; @@ -205,7 +206,7 @@ static dma_addr_t iommu_alloc(struct dev /* Put the TCEs in the HW table */ ppc_md.tce_build(tbl, entry, npages, (unsigned long)page IOMMU_PAGE_MASK, -direction); +direction, attrs); /* Flush/invalidate TLB caches if necessary */ @@ -336,7 +337,8 @@ int iommu_map_sg(struct device *dev, str npages, entry, dma_addr); /* Insert into HW table */ - ppc_md.tce_build(tbl, entry, npages, vaddr IOMMU_PAGE_MASK, direction); + ppc_md.tce_build(tbl, entry, npages, vaddr IOMMU_PAGE_MASK, +direction, attrs); /* If we are in an open segment, try merging */ if (segstart != s) { @@ -573,7 +575,8 @@ dma_addr_t iommu_map_single(struct devic align = PAGE_SHIFT - IOMMU_PAGE_SHIFT; dma_handle = iommu_alloc(dev, tbl, vaddr, npages, direction, -mask IOMMU_PAGE_SHIFT, align); +mask IOMMU_PAGE_SHIFT, align, +attrs); if (dma_handle == DMA_ERROR_CODE) { if (printk_ratelimit()) { printk(KERN_INFO iommu_alloc failed, @@ -642,7 +645,7 @@ void *iommu_alloc_coherent(struct device nio_pages = size IOMMU_PAGE_SHIFT; io_order = get_iommu_order(size); mapping = iommu_alloc(dev, tbl, ret, nio_pages, DMA_BIDIRECTIONAL, - mask IOMMU_PAGE_SHIFT, io_order); + mask IOMMU_PAGE_SHIFT, io_order, NULL); if (mapping == DMA_ERROR_CODE) { free_pages((unsigned long)ret, order); return NULL; Index: upstream/arch/powerpc/platforms/cell/iommu.c === --- upstream.orig/arch/powerpc/platforms/cell/iommu.c +++ upstream/arch/powerpc/platforms/cell/iommu.c @@ -173,7 +173,8 @@ static void invalidate_tce_cache(struct } static void tce_build_cell(struct iommu_table *tbl, long index, long npages, - unsigned long uaddr, enum dma_data_direction direction) + unsigned long uaddr, enum dma_data_direction direction, + struct dma_attrs *attrs) { int i; unsigned long *io_pte, base_pte; @@ -519,7 +520,7 @@ cell_iommu_setup_window(struct cbe_iommu __set_bit(0, window-table.it_map); tce_build_cell(window-table, window-table.it_offset, 1, - (unsigned long)iommu-pad_page, DMA_TO_DEVICE); + (unsigned long)iommu-pad_page, DMA_TO_DEVICE, NULL); window-table.it_hint = window-table.it_blocksize; return window; Index: upstream/arch/powerpc/platforms/iseries/iommu.c === --- upstream.orig/arch/powerpc/platforms/iseries/iommu.c +++ upstream/arch/powerpc/platforms/iseries/iommu.c @@ -42,7 +42,8 @@ #include asm/iseries/iommu.h static void tce_build_iSeries(struct iommu_table *tbl, long index, long npages, - unsigned long uaddr, enum dma_data_direction direction) + unsigned long uaddr, enum dma_data_direction direction, + struct dma_attrs *attrs) { u64 rc; u64 tce, rpn; Index: upstream/arch/powerpc/platforms/pasemi/iommu.c === ---
[RFC] [PATCH 4/5] [POWERPC] Move device_to_mask() to dma-mapping.h
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 [EMAIL PROTECTED] --- 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 0xul; -} - - /* 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 0xul; +} + /* * DMA operations are abstracted for G5 vs. i/pSeries, PCI vs. VIO */ -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC] [PATCH 0/5] [POWERPC] Implement dma_*map*_attrs() and DMA_ATTR_WEAK_ORDERING and use on Cell
-- 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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC] [PATCH 5/5] [POWERPC] Add DMA_ATTR_WEAK_ORDERING dma attribute and use in Cell IOMMU code
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 [EMAIL PROTECTED] --- 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 ==
[RFC] [PATCH 3/5] [POWERPC] Make cell_dma_dev_setup_iommu() return the iommu table
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 [EMAIL PROTECTED] --- 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 -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro
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? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC83xx Power Management support
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
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:[EMAIL PROTECTED] Sent: terça-feira, 29 de Abril de 2008 20:15 To: Franca, Jose (NSN - PT/Portugal - MiniMD) Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED] 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/6] [POWERPC] booting-without-of: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
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 [EMAIL PROTECTED] --- 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 +clknum or brgnum format. + - fsl,lowspeed-clock : specifies the low speed USB clock source in +clknum or brgnum 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: + + [EMAIL PROTECTED] { + 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: + + [EMAIL PROTECTED] { + compatible = linux,gpio-led; + linux,name = pwr; + linux,brightness = 1; + linux,active-low; + gpios = mcu_pio 0; + }; + + [EMAIL PROTECTED] { + 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: [EMAIL PROTECTED] { + #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: + + [EMAIL PROTECTED],0 { + #address-cells = 0; + #size-cells = 0; +
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:[EMAIL PROTECTED] Sent: terça-feira, 29 de Abril de 2008 20:15 To: Franca, Jose (NSN - PT/Portugal - MiniMD) Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED] 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Move to runtime allocated exception stacks
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 [EMAIL PROTECTED] --- 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) mfcrr10;/* save CR in r10 for now */\ mfspr r11,SPRN_SRR3; /* check whether user or kernel*/\ andi. r11,r11,MSR_PR; \ - lis r11,[EMAIL PROTECTED]; \ - ori r11,r11,[EMAIL PROTECTED]; \ + lis r11,[EMAIL PROTECTED]; \ + lwz r11,[EMAIL PROTECTED](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_SPRGSPRN_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_TOPdbgirq_ctx #define DEBUG_SPRG SPRN_SPRG6W #ifdef CONFIG_SMP #define BOOKE_LOAD_EXC_LEVEL_STACK(level)
[PATCH] [POWERPC] Rework EXC_LEVEL_EXCEPTION_PROLOG code
* 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 [EMAIL PROTECTED] --- 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 @@ slwir8,r8,2;\ addis r8,r8,[EMAIL PROTECTED];\ lwz r8,[EMAIL PROTECTED](r8); \ - addir8,r8,THREAD_SIZE; + addir8,r8,THREAD_SIZE-INT_FRAME_SIZE; #else #define BOOKE_LOAD_EXC_LEVEL_STACK(level) \ lis r8,[EMAIL PROTECTED]; \ lwz r8,[EMAIL PROTECTED](r8); \ - addir8,r8,THREAD_SIZE; + addir8,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 */\ + addir11,r11,THREAD_SIZE-INT_FRAME_SIZE; /* Alloc exception frm */\ mfcrr10;/* 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 */\ - addir11,r11,THREAD_SIZE; \ -1: subir11,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); \ +
[git pull] Please pull powerpc.git master branch
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 [EMAIL PROTECTED] (2): [POWERPC] mpc5200: add gpiolib support for mpc5200 [POWERPC] mpc5200: add Phytec pcm030 board support ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] 40x/Book-E: Save/restore volatile exception registers
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 [EMAIL PROTECTED] --- 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,[EMAIL PROTECTED](0) stw r0,GPR11(r11) + mfspr r0,SPRN_SRR0 + stw r0,[EMAIL PROTECTED](0) + mfspr r0,SPRN_SRR1 + stw r0,[EMAIL PROTECTED](0) /* fall through */ #endif @@ -846,17 +878,66 @@ exc_exit_restart_end: exc_lvl_rfi;\ b .; /* prevent prefetch past exc_lvl_rfi */ +#defineRESTORE_xSRR(exc_lvl_srr0, exc_lvl_srr1) \ + lwz r9,_##exc_lvl_srr0(r1); \ + lwz r10,_##exc_lvl_srr1(r1);\
Re: [PATCH 1/7] Implement arch disable/enable irq hooks.
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/6] [POWERPC] booting-without-of: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
On Wed, Apr 30, 2008 at 10:36:54AM +0200, Wolfgang Grandegger wrote: Hi Anton, [...] + [EMAIL PROTECTED],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; + + [EMAIL PROTECTED] { + ... + }; + }; + }; Where can I find the code for that binding? fsl_upm_nand.c from http://patchwork.ozlabs.org/linuxppc/patch?q=upmid=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 [EMAIL PROTECTED] 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 -
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) [EMAIL PROTECTED] An: linuxppc-dev@ozlabs.org, [EMAIL PROTECTED] 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:[EMAIL PROTECTED] Sent: terça-feira, 29 de Abril de 2008 20:15 To: Franca, Jose (NSN - PT/Portugal - MiniMD) Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED] 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: FW: SKB corruption on heavy traffic
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:[EMAIL PROTECTED] Sent: quarta-feira, 30 de Abril de 2008 13:26 To: Franca, Jose (NSN - PT/Portugal - MiniMD); Scott Wood Cc: [EMAIL PROTECTED]; 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) [EMAIL PROTECTED] An: linuxppc-dev@ozlabs.org, [EMAIL PROTECTED] 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:[EMAIL PROTECTED] Sent: terça-feira, 29 de Abril de 2008 20:15 To: Franca, Jose (NSN - PT/Portugal - MiniMD) Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED] 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] mpc5200: Allow for fixed speed MII configurations
On Wed, Apr 30, 2008 at 1:36 AM, Joakim Tjernlund [EMAIL PROTECTED] wrote: On Tue, 2008-04-29 at 17:06 -0600, Grant Likely wrote: From: Grant Likely [EMAIL PROTECTED] 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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: EXT_IRQ0 @ MPC834x
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é Andre Schwarz schrieb: All, 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 Regarding to the manual IRQ0 is somewhat special and has Vector 48 assigned. Therefore my dts entry for this device looks like : interrupt-map = 0x5800 0 0 1 ipic 0x30 0x8 ... ; Having a look on virq mapping gives : mvBL-M7 cat /sys/kernel/debug/powerpc/virq_mapping virq hwirqchip namehost name 16 0xe IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED] 17 0xf IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED] 18 0x9 IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED] 20 0x00010 IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED] 32 0x00020 IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED] 33 0x00021 IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED] 34 0x00022 IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED] 38 0x00026 IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED] 48 0x00030 IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED] After loading the device driver (=mvbcdma) the irq shows up correctly. 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 As soon as the device generates an interrupt I get : irq 48: nobody cared (try booting with the irqpoll option) handlers: [d18d66e8] (mvbcdma_irq+0x0/0x180 [mvbcdma]) Disabling IRQ #48 The handler _would_ have returned IRQ_RETVAL(1). Obviously the handler isn't called at all - but why ? Using nm on the kernel module gives : 06e8 t mvbcdma_irq -offset 0x6e8 inside module matches with output regarding handler. Any help is welcome ! regards, Andre Schwarz MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: 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ße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/6] [POWERPC] booting-without-of: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
Anton Vorontsov wrote: On Wed, Apr 30, 2008 at 10:36:54AM +0200, Wolfgang Grandegger wrote: Hi Anton, [...] + [EMAIL PROTECTED],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; + + [EMAIL PROTECTED] { + ... + }; + }; + }; Where can I find the code for that binding? fsl_upm_nand.c from http://patchwork.ozlabs.org/linuxppc/patch?q=upmid=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 [EMAIL PROTECTED] 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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] mpc5200: Allow for fixed speed MII configurations
On Wed, Apr 30, 2008 at 7:10 AM, Joakim Tjernlund [EMAIL PROTECTED] wrote: On Wed, 2008-04-30 at 07:07 -0600, Grant Likely wrote: On Wed, Apr 30, 2008 at 1:36 AM, Joakim Tjernlund [EMAIL PROTECTED] wrote: On Tue, 2008-04-29 at 17:06 -0600, Grant Likely wrote: From: Grant Likely [EMAIL PROTECTED] 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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] mpc5200: Allow for fixed speed MII configurations
On Wed, 2008-04-30 at 07:07 -0600, Grant Likely wrote: On Wed, Apr 30, 2008 at 1:36 AM, Joakim Tjernlund [EMAIL PROTECTED] wrote: On Tue, 2008-04-29 at 17:06 -0600, Grant Likely wrote: From: Grant Likely [EMAIL PROTECTED] 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/6] [POWERPC] booting-without-of: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
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, [...] + [EMAIL PROTECTED],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; + + [EMAIL PROTECTED] { + ... + }; + }; + }; Where can I find the code for that binding? fsl_upm_nand.c from http://patchwork.ozlabs.org/linuxppc/patch?q=upmid=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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] mpc5200: Allow for fixed speed MII configurations
On Wed, 2008-04-30 at 07:26 -0600, Grant Likely wrote: On Wed, Apr 30, 2008 at 7:10 AM, Joakim Tjernlund [EMAIL PROTECTED] wrote: On Wed, 2008-04-30 at 07:07 -0600, Grant Likely wrote: On Wed, Apr 30, 2008 at 1:36 AM, Joakim Tjernlund [EMAIL PROTECTED] wrote: On Tue, 2008-04-29 at 17:06 -0600, Grant Likely wrote: From: Grant Likely [EMAIL PROTECTED] 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. dunno how you speify Half/Full Duplex, but isn't it possible that someone else wants to use Pause in the future? Isn't the point that everyone should use fixed-link when it is there for this purpose? Jocke Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
DPMS for Radeon 9600 in G5
Anyone one have any suggestions on how to get DPMS working for a Radeon 9600? Using a DVI cable? Thanks! kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: DPMS for Radeon 9600 in G5
Kevin, Have you tried posting to the xorg (http://lists.freedesktop.org/mailman/listinfo/xorg) mailing list? They helped me fix an issue I was seeing with my Radeon 9600 and G5. I'm running YDL6 with two LCDs hanging off the back of my Radeon. Rob -Original Message- From: [EMAIL PROTECTED] on behalf of Kevin Diggs Sent: Wed 4/30/2008 11:13 AM To: linuxppc-dev@ozlabs.org Subject: DPMS for Radeon 9600 in G5 Anyone one have any suggestions on how to get DPMS working for a Radeon 9600? Using a DVI cable? Thanks! kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: SKB corruption on heavy traffic
On Wed, Apr 30, 2008 at 09:43:33AM +0100, Franca, Jose (NSN - PT/Portugal - MiniMD) wrote: 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). One thing you could try is to enable slab debugging, rather than your custom debugging code; this will poison the memory upon free, making it more likely that whatever is accessing it will crash immediately rather than just cause corruption. Or, if you want to mantain the delay, do the poisoning yourself. Of course, this won't help if the access is write-only, or if the corruption is happening via DMA. When you say you have a full ring buffer, do you mean tx or rx? Does it recover gracefully? Do you think it's caused by something other than sending data faster than the line can support (tx) or receiving packets faster than the cpu can handle (rx)? Are any of the other problem reports from recent, unmodified kernels (2.4 is very old)? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] mpc5200: Allow for fixed speed MII configurations
On Wed, 2008-04-30 at 08:28 -0600, Grant Likely wrote: On Wed, Apr 30, 2008 at 8:16 AM, Joakim Tjernlund [EMAIL PROTECTED] wrote: On Wed, 2008-04-30 at 07:26 -0600, Grant Likely wrote: On Wed, Apr 30, 2008 at 7:10 AM, Joakim Tjernlund [EMAIL PROTECTED] wrote: On Wed, 2008-04-30 at 07:07 -0600, Grant Likely wrote: On Wed, Apr 30, 2008 at 1:36 AM, Joakim Tjernlund [EMAIL PROTECTED] wrote: On Tue, 2008-04-29 at 17:06 -0600, Grant Likely wrote: From: Grant Likely [EMAIL PROTECTED] 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. dunno how you speify Half/Full Duplex, but isn't it possible that someone else wants to use Pause in the future? Isn't the point that everyone should use fixed-link when it is there for this purpose? The format of the data is pretty much entirely device dependent (much like interrupt and gpio specifiers are controller dependent). I see any need in trying to define a common format for this data since it is entirely local to the device. ie. there is requirement for this data to be in the same format for every device. Also, by not trying to lock it down into a common format it gives future devices freedom to specify additional flags and parameters in the data. so, * gianfar: needs 5 bits of data. * 5200 FEC: only needs 2. As for 'current-speed' vs. 'fixed-link'. I just think 'current-speed' is the better name. :-) Then some day someone else needs Pause or need to control Duplex. Then you end up with several impl. Maybe fixed-link isn't the best name, but it is designed for this purpose. Anyhow, I not going to argue this more. Seems like I am the only one thinking it would be better to use fixed-link instead so I guess I am wrong here. Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: SKB corruption on heavy traffic
Ok... We will try to enable debug on slab! :) Ring buffer full occurs on tx in spite of having free bd's in the ring, it doesn't use them... And it does not recover. The problems that I refered are from previous kernel versions to ours (our base of development was 2.4.31) and even on 2.6 kernels. Filipe -Original Message- From: ext Scott Wood [mailto:[EMAIL PROTECTED] Sent: quarta-feira, 30 de Abril de 2008 16:01 To: Franca, Jose (NSN - PT/Portugal - MiniMD) Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED] Subject: Re: SKB corruption on heavy traffic On Wed, Apr 30, 2008 at 09:43:33AM +0100, Franca, Jose (NSN - PT/Portugal - MiniMD) wrote: 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). One thing you could try is to enable slab debugging, rather than your custom debugging code; this will poison the memory upon free, making it more likely that whatever is accessing it will crash immediately rather than just cause corruption. Or, if you want to mantain the delay, do the poisoning yourself. Of course, this won't help if the access is write-only, or if the corruption is happening via DMA. When you say you have a full ring buffer, do you mean tx or rx? Does it recover gracefully? Do you think it's caused by something other than sending data faster than the line can support (tx) or receiving packets faster than the cpu can handle (rx)? Are any of the other problem reports from recent, unmodified kernels (2.4 is very old)? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Xilinx: Fix compile warnings
arch/powerpc/sysdev/xilinx_intc.c: In function âxilinx_intc_initâ: arch/powerpc/sysdev/xilinx_intc.c:111: warning: format â%08Xâ expects type âunsigned intâ, but argument 2 has type âresource_size_tâ drivers/char/xilinx_hwicap/xilinx_hwicap.c: In function âhwicap_setupâ: drivers/char/xilinx_hwicap/xilinx_hwicap.c:626: warning: cast to pointer from integer of different size drivers/char/xilinx_hwicap/xilinx_hwicap.c:646: warning: format â%xâ expects type âunsigned intâ, but argument 6 has type âresource_size_tâ Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- arch/powerpc/sysdev/xilinx_intc.c |2 +- drivers/char/xilinx_hwicap/xilinx_hwicap.c |6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/sysdev/xilinx_intc.c b/arch/powerpc/sysdev/xilinx_intc.c index ba8eea2..b7aefd0 100644 --- a/arch/powerpc/sysdev/xilinx_intc.c +++ b/arch/powerpc/sysdev/xilinx_intc.c @@ -107,7 +107,7 @@ xilinx_intc_init(struct device_node *np) } regs = ioremap(res.start, 32); - printk(KERN_INFO Xilinx intc at 0x%08X mapped to 0x%p\n, + printk(KERN_INFO Xilinx intc at 0x%08LX mapped to 0x%p\n, res.start, regs); /* Setup interrupt controller */ diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.c b/drivers/char/xilinx_hwicap/xilinx_hwicap.c index dfe6907..3edf1fc 100644 --- a/drivers/char/xilinx_hwicap/xilinx_hwicap.c +++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.c @@ -623,8 +623,8 @@ static int __devinit hwicap_setup(struct device *dev, int id, if (!request_mem_region(drvdata-mem_start, drvdata-mem_size, DRIVER_NAME)) { - dev_err(dev, Couldn't lock memory region at %p\n, - (void *)regs_res-start); + dev_err(dev, Couldn't lock memory region at %Lx\n, + regs_res-start); retval = -EBUSY; goto failed1; } @@ -643,7 +643,7 @@ static int __devinit hwicap_setup(struct device *dev, int id, mutex_init(drvdata-sem); drvdata-is_open = 0; - dev_info(dev, ioremap %lx to %p with size %x\n, + dev_info(dev, ioremap %lx to %p with size %Lx\n, (unsigned long int)drvdata-mem_start, drvdata-base_address, drvdata-mem_size); -- 1.5.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Xilinx: Fix compile warnings
Hi Kumar, On Wed, 30 Apr 2008 10:25:46 -0500 (CDT) Kumar Gala [EMAIL PROTECTED] wrote: arch/powerpc/sysdev/xilinx_intc.c: In function âxilinx_intc_initâ: arch/powerpc/sysdev/xilinx_intc.c:111: warning: format â%08Xâ expects type âunsigned intâ, but argument 2 has type âresource_size_tâ drivers/char/xilinx_hwicap/xilinx_hwicap.c: In function âhwicap_setupâ: drivers/char/xilinx_hwicap/xilinx_hwicap.c:626: warning: cast to pointer from integer of different size drivers/char/xilinx_hwicap/xilinx_hwicap.c:646: warning: format â%xâ expects type âunsigned intâ, but argument 6 has type âresource_size_tâ If you compile with LANG=C, you don't get those strange annotations in your error messages ... The fix looks good though. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpgZvO3HERAm.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] devres: Add devm_ioremap_flags()
From: Emil Medve [EMAIL PROTECTED] We provide an ioremap_flags so provide a coresphonding devm_ioremap_flags. Signed-off-by: Emil Medve [EMAIL PROTECTED] Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- Which tree should this go through, powerpc.git? arch/powerpc/lib/Makefile |1 + include/asm-powerpc/io.h |8 +++- include/linux/io.h|1 + lib/devres.c |2 +- 4 files changed, 10 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile index 4bb023f..f1d2cdc 100644 --- a/arch/powerpc/lib/Makefile +++ b/arch/powerpc/lib/Makefile @@ -23,3 +23,4 @@ obj-$(CONFIG_SMP) += locks.o endif obj-$(CONFIG_PPC_LIB_RHEAP) += rheap.o +obj-$(CONFIG_HAS_IOMEM)+= devres.o diff --git a/include/asm-powerpc/io.h b/include/asm-powerpc/io.h index afae069..3b8c334 100644 --- a/include/asm-powerpc/io.h +++ b/include/asm-powerpc/io.h @@ -2,7 +2,7 @@ #define _ASM_POWERPC_IO_H #ifdef __KERNEL__ -/* +/* * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version @@ -18,6 +18,9 @@ extern int check_legacy_ioport(unsigned long base_port); #define _PNPWRP0xa79 #define PNPBIOS_BASE 0xf000 +#include linux/device.h +#include linux/io.h + #include linux/compiler.h #include asm/page.h #include asm/byteorder.h @@ -744,6 +747,9 @@ static inline void * bus_to_virt(unsigned long address) #define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set) +void __iomem *devm_ioremap_flags(struct device *dev, resource_size_t offset, +size_t size, unsigned long flags); + #endif /* __KERNEL__ */ #endif /* _ASM_POWERPC_IO_H */ diff --git a/include/linux/io.h b/include/linux/io.h index 831f57c..7a390cf 100644 --- a/include/linux/io.h +++ b/include/linux/io.h @@ -58,6 +58,7 @@ static inline void devm_ioport_unmap(struct device *dev, void __iomem *addr) } #endif +void devm_ioremap_release(struct device *dev, void *res); void __iomem * devm_ioremap(struct device *dev, resource_size_t offset, unsigned long size); void __iomem * devm_ioremap_nocache(struct device *dev, resource_size_t offset, diff --git a/lib/devres.c b/lib/devres.c index 26c87c4..72c8909 100644 --- a/lib/devres.c +++ b/lib/devres.c @@ -2,7 +2,7 @@ #include linux/io.h #include linux/module.h -static void devm_ioremap_release(struct device *dev, void *res) +void devm_ioremap_release(struct device *dev, void *res) { iounmap(*(void __iomem **)res); } -- 1.5.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] [POWERPC] devres: Add devm_ioremap_flags()
From: Emil Medve [EMAIL PROTECTED] We provide an ioremap_flags so provide a coresphonding devm_ioremap_flags. Signed-off-by: Emil Medve [EMAIL PROTECTED] Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- Forgot to commit the actual implemtation in arch/powerpc/lib/devres.c Which tree should this go through, powerpc.git? - k arch/powerpc/lib/Makefile |1 + arch/powerpc/lib/devres.c | 33 + include/asm-powerpc/io.h |8 +++- include/linux/io.h|1 + lib/devres.c |2 +- 5 files changed, 43 insertions(+), 2 deletions(-) create mode 100644 arch/powerpc/lib/devres.c diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile index 4bb023f..f1d2cdc 100644 --- a/arch/powerpc/lib/Makefile +++ b/arch/powerpc/lib/Makefile @@ -23,3 +23,4 @@ obj-$(CONFIG_SMP) += locks.o endif obj-$(CONFIG_PPC_LIB_RHEAP) += rheap.o +obj-$(CONFIG_HAS_IOMEM)+= devres.o diff --git a/arch/powerpc/lib/devres.c b/arch/powerpc/lib/devres.c new file mode 100644 index 000..b73c64b --- /dev/null +++ b/arch/powerpc/lib/devres.c @@ -0,0 +1,33 @@ +#include linux/device.h /* devres_*(), devm_ioremap_release() */ +#include linux/io.h /* ioremap_flags() */ +#include linux/module.h /* EXPORT_SYMBOL() */ + +/** + * devm_ioremap_flags - Managed ioremap_flags() + * @dev: Generic device to remap IO address for + * @offset: BUS offset to map + * @size: Size of map + * @flags: Page flags + * + * Managed ioremap_flags(). Map is automatically unmapped on driver + * detach. + */ +void __iomem *devm_ioremap_flags(struct device *dev, resource_size_t offset, +size_t size, unsigned long flags) +{ + void __iomem **ptr, *addr; + + ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL); + if (!ptr) + return NULL; + + addr = ioremap_flags(offset, size, flags); + if (addr) { + *ptr = addr; + devres_add(dev, ptr); + } else + devres_free(ptr); + + return addr; +} +EXPORT_SYMBOL(devm_ioremap_flags); diff --git a/include/asm-powerpc/io.h b/include/asm-powerpc/io.h index afae069..3b8c334 100644 --- a/include/asm-powerpc/io.h +++ b/include/asm-powerpc/io.h @@ -2,7 +2,7 @@ #define _ASM_POWERPC_IO_H #ifdef __KERNEL__ -/* +/* * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version @@ -18,6 +18,9 @@ extern int check_legacy_ioport(unsigned long base_port); #define _PNPWRP0xa79 #define PNPBIOS_BASE 0xf000 +#include linux/device.h +#include linux/io.h + #include linux/compiler.h #include asm/page.h #include asm/byteorder.h @@ -744,6 +747,9 @@ static inline void * bus_to_virt(unsigned long address) #define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set) +void __iomem *devm_ioremap_flags(struct device *dev, resource_size_t offset, +size_t size, unsigned long flags); + #endif /* __KERNEL__ */ #endif /* _ASM_POWERPC_IO_H */ diff --git a/include/linux/io.h b/include/linux/io.h index 831f57c..7a390cf 100644 --- a/include/linux/io.h +++ b/include/linux/io.h @@ -58,6 +58,7 @@ static inline void devm_ioport_unmap(struct device *dev, void __iomem *addr) } #endif +void devm_ioremap_release(struct device *dev, void *res); void __iomem * devm_ioremap(struct device *dev, resource_size_t offset, unsigned long size); void __iomem * devm_ioremap_nocache(struct device *dev, resource_size_t offset, diff --git a/lib/devres.c b/lib/devres.c index 26c87c4..72c8909 100644 --- a/lib/devres.c +++ b/lib/devres.c @@ -2,7 +2,7 @@ #include linux/io.h #include linux/module.h -static void devm_ioremap_release(struct device *dev, void *res) +void devm_ioremap_release(struct device *dev, void *res) { iounmap(*(void __iomem **)res); } -- 1.5.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] [POWERPC] Xilinx: Fix compile warnings
For what it's worth: Acked-by: Stephen Neuendorffer [EMAIL PROTECTED] There's one or two other things I've been meaning to clean up, such as the section mismatch on hwicap_of_match, too. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-dev- [EMAIL PROTECTED] On Behalf Of Kumar Gala Sent: Wednesday, April 30, 2008 8:26 AM To: Josh Boyer Cc: linuxppc-dev@ozlabs.org Subject: [PATCH] [POWERPC] Xilinx: Fix compile warnings arch/powerpc/sysdev/xilinx_intc.c: In function ‘xilinx_intc_init’: arch/powerpc/sysdev/xilinx_intc.c:111: warning: format ‘%08X’ expects type ‘unsigned int’, but argument 2 has type ‘resource_size_t’ drivers/char/xilinx_hwicap/xilinx_hwicap.c: In function ‘hwicap_setup’: drivers/char/xilinx_hwicap/xilinx_hwicap.c:626: warning: cast to pointer from integer of different size drivers/char/xilinx_hwicap/xilinx_hwicap.c:646: warning: format ‘%x’ expects type ‘unsigned int’, but argument 6 has type ‘resource_size_t’ Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- arch/powerpc/sysdev/xilinx_intc.c |2 +- drivers/char/xilinx_hwicap/xilinx_hwicap.c |6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/sysdev/xilinx_intc.c b/arch/powerpc/sysdev/xilinx_intc.c index ba8eea2..b7aefd0 100644 --- a/arch/powerpc/sysdev/xilinx_intc.c +++ b/arch/powerpc/sysdev/xilinx_intc.c @@ -107,7 +107,7 @@ xilinx_intc_init(struct device_node *np) } regs = ioremap(res.start, 32); - printk(KERN_INFO Xilinx intc at 0x%08X mapped to 0x%p\n, + printk(KERN_INFO Xilinx intc at 0x%08LX mapped to 0x%p\n, res.start, regs); /* Setup interrupt controller */ diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.c b/drivers/char/xilinx_hwicap/xilinx_hwicap.c index dfe6907..3edf1fc 100644 --- a/drivers/char/xilinx_hwicap/xilinx_hwicap.c +++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.c @@ -623,8 +623,8 @@ static int __devinit hwicap_setup(struct device *dev, int id, if (!request_mem_region(drvdata-mem_start, drvdata-mem_size, DRIVER_NAME)) { - dev_err(dev, Couldn't lock memory region at %p\n, - (void *)regs_res-start); + dev_err(dev, Couldn't lock memory region at %Lx\n, + regs_res-start); retval = -EBUSY; goto failed1; } @@ -643,7 +643,7 @@ static int __devinit hwicap_setup(struct device *dev, int id, mutex_init(drvdata-sem); drvdata-is_open = 0; - dev_info(dev, ioremap %lx to %p with size %x\n, + dev_info(dev, ioremap %lx to %p with size %Lx\n, (unsigned long int)drvdata-mem_start, drvdata-base_address, drvdata-mem_size); -- 1.5.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v4] sysdev,mv64x60: MV64x60 device bus
For each mv64360 entry in the OpenFirmware database, add the registration of an of_bus to take care of devices connected to the MV64x60 asynchronous devices controller. This change makes it possible for those devices to be detected by drivers that support the of_platform without having a custom call for each of them in the board file. Signed-off-by: Remi Machet ([EMAIL PROTECTED]) --- Changes: v2: Use the compatible field to detect devices to register (on Dale Farnsworth suggestion). v3: Added __initdata to variable of_mv64x60_devices (thanks to Stephen Rothwell for pointing that out). v4: Re-wrote the patch description. arch/powerpc/sysdev/mv64x60_dev.c | 10 ++ 1 files changed, 10 insertions(+) diff --git a/arch/powerpc/sysdev/mv64x60_dev.c b/arch/powerpc/sysdev/mv64x60_dev.c index 41af122..c38695e 100644 --- a/arch/powerpc/sysdev/mv64x60_dev.c +++ b/arch/powerpc/sysdev/mv64x60_dev.c @@ -15,6 +15,7 @@ #include linux/console.h #include linux/mv643xx.h #include linux/platform_device.h +#include linux/of_platform.h #include asm/prom.h @@ -25,6 +26,11 @@ * PowerPC of_platform_bus_type. They support platform_bus_type instead. */ +static struct of_device_id __initdata of_mv64x60_devices[] = { + { .compatible = marvell,mv64306-devctrl, }, + {} +}; + /* * Create MPSC platform devices */ @@ -482,6 +488,10 @@ static int __init mv64x60_device_setup(void) of_node_put(np); } + /* Now add every node that is on the device bus (type is devicectrl */ + for_each_compatible_node(np, NULL, marvell,mv64360) + of_platform_bus_probe(np, of_mv64x60_devices, NULL); + return 0; } arch_initcall(mv64x60_device_setup); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/7] Implement arch disable/enable irq hooks.
On Tue, Apr 29, 2008 at 02:44:30PM +1000, Paul Mackerras wrote: 3. The style in all the assembly code is not to have spaces after commas separating instruction operands. I'll do that if that's what is prefered, but how did that come about as the style used? It's different from what we do in C, and adding the space helps readability in asm as well... 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. It works for me. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/6] [POWERPC] booting-without-of: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
Anton Vorontsov wrote: 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, [...] + [EMAIL PROTECTED],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; + + [EMAIL PROTECTED] { + ... + }; + }; + }; Where can I find the code for that binding? fsl_upm_nand.c from http://patchwork.ozlabs.org/linuxppc/patch?q=upmid=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 [EMAIL PROTECTED] 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. OK. 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. I have that. Are you sure about the e500 CPUs. I have not seen any MPC85xx board in U-Boot or Linux BSP using FSL UPM. Sometimes these magic sync instructions seem to be needed, e.g., in the MPC8548 manual I find: Also, an msync assembly instruction must be executed after each I2C register read/write access to guarantee in-order execution. Can somebody (from freescale?) sched some light on that issue? TIA. Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] [POWERPC] devres: Add devm_ioremap_flags()
On Wed, 30 Apr 2008 11:08:51 -0500 (CDT) Kumar Gala [EMAIL PROTECTED] wrote: From: Emil Medve [EMAIL PROTECTED] We provide an ioremap_flags so provide a coresphonding devm_ioremap_flags. Signed-off-by: Emil Medve [EMAIL PROTECTED] Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- Forgot to commit the actual implemtation in arch/powerpc/lib/devres.c Which tree should this go through, powerpc.git? I'd say so, yes. arch/powerpc/lib/Makefile |1 + arch/powerpc/lib/devres.c | 33 + include/asm-powerpc/io.h |8 +++- include/linux/io.h|1 + lib/devres.c |2 +- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] docbook: fix fatal rapidio yet again (and more to come)
On Wed, 30 Apr 2008 11:35:00 -0700 Andrew Morton wrote: On Tue, 29 Apr 2008 20:10:55 -0700 (PDT) Randy.Dunlap [EMAIL PROTECTED] wrote: From: Randy Dunlap [EMAIL PROTECTED] Don't refer to file that no longer exists: docproc: linux-2.6.25-git14/arch/powerpc/kernel/rio.c: No such file or directory Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- Documentation/DocBook/rapidio.tmpl |1 - 1 file changed, 1 deletion(-) --- linux-2.6.25-git14.orig/Documentation/DocBook/rapidio.tmpl +++ linux-2.6.25-git14/Documentation/DocBook/rapidio.tmpl @@ -133,7 +133,6 @@ !Idrivers/rapidio/rio-sysfs.c /sect1 sect1 id=PPC32_supporttitlePPC32 support/title -!Iarch/powerpc/kernel/rio.c !Earch/powerpc/sysdev/fsl_rio.c !Iarch/powerpc/sysdev/fsl_rio.c /sect1 grumble. This is a subset of rapidio-fix-docbook-references.patch, but I appear to be unable to interest anyone in merging/reviewing/accepting/anything-else that quite large set of patches. Guys, those patches were sent six weeks ago and it now looks like they will miss 2.6.26. This is pretty slack of us. Help? There's nothing there that can hurt. (famous last words) Just merge it. --- ~Randy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH] vmemmap fixes to use smaller pages
Benjamin Herrenschmidt wrote: This patch changes vmemmap to use a different region (region 0xf) of the address space whose page size can be dynamically configured at boot. The problem with the current approach of always using 16M pages is that it's not well suited to machines that have small amounts of memory such as small partitions on pseries, or PS3's. In fact, on the PS3, failure to allocate the 16M page backing vmmemmap tends to prevent hotplugging the HV's additional memory, thus limiting the available memory even more, from my experience down to something like 80M total, which makes it really not very useable. The logic used by my match to choose the vmemmap page size is: - If 16M pages are available and there's 1G or more RAM at boot, use that size. - Else if 64K pages are available, use that - Else use 4K pages I've tested on a POWER6 (16M pages) and on an iSeries POWER3 (4K pages) and it seems to work fine. However, when attempting to test on a PS3, it didn't boot. In fact, it doesn't boot without my patch with current upstream. Yes, this is a know problem I am working on, related to recent changes in bootmem. Errors with: 'sparse_early_usemap_alloc: allocation failed'. I tried booting 2.6.25 with a ps3_defconfig and that doesn't work neither (though at least when doing the later, I do get a black screen no sync, like of ps3fb failed monitor detection, while with current upstream, I just get the last kexec messages and nothing happens). This should work. You are the first to report a problem with 2.6.25. Could you double check your build, and if you still have trouble, put your vmlinux somewhere I can get it? Since the PS3 boot failures are impossible to debug unless your email is @sony* and you have the special magic tools, I'll let Geoff try the patch out. OK, I'll try it with the upstream kernel from last week and report within the next day or so. -Geoff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] docbook: fix fatal rapidio yet again (and more to come)
On Wed, 30 Apr 2008 14:01:12 -0500 Kumar Gala [EMAIL PROTECTED] wrote: On Apr 30, 2008, at 1:35 PM, Andrew Morton wrote: On Tue, 29 Apr 2008 20:10:55 -0700 (PDT) Randy.Dunlap [EMAIL PROTECTED] wrote: From: Randy Dunlap [EMAIL PROTECTED] Don't refer to file that no longer exists: docproc: linux-2.6.25-git14/arch/powerpc/kernel/rio.c: No such file or directory Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- Documentation/DocBook/rapidio.tmpl |1 - 1 file changed, 1 deletion(-) --- linux-2.6.25-git14.orig/Documentation/DocBook/rapidio.tmpl +++ linux-2.6.25-git14/Documentation/DocBook/rapidio.tmpl @@ -133,7 +133,6 @@ !Idrivers/rapidio/rio-sysfs.c /sect1 sect1 id=PPC32_supporttitlePPC32 support/title -!Iarch/powerpc/kernel/rio.c !Earch/powerpc/sysdev/fsl_rio.c !Iarch/powerpc/sysdev/fsl_rio.c /sect1 grumble. This is a subset of rapidio-fix-docbook-references.patch, but I appear to be unable to interest anyone in merging/reviewing/accepting/anything- else that quite large set of patches. Guys, those patches were sent six weeks ago and it now looks like they will miss 2.6.26. This is pretty slack of us. Help? Odd. I thought Paul had picked up a docbook RapidIO patch from you in the latest merge round. Well it's more than a patch. The six-week-old patch series is: rapidio-add-memory-mapping-driver-to-rapidio.patch rapidio-add-rapidio-space-allocation-bitmap-arithmetic.patch rapidio-add-fsl-rapidio-controller-memory-ops-functions.patch rapidio-add-the-rapidio-master-port-maintance-and-doorbell-window-to-space-resources.patch rapidio-add-rapidio-proc-fs-for-memory-mapping-debugging.patch rapidio-add-the-memory-mapping-support-in-rionet-driver.patch rapidio-fix-docbook-references.patch rapidio-fix-kernel-doc-problems.patch totalling: arch/powerpc/sysdev/fsl_rio.c | 13 + include/linux/rio.h | 10 drivers/net/Kconfig | 10 drivers/net/rionet.c| 324 ++ drivers/rapidio/Makefile|1 drivers/rapidio/rio.c | 10 drivers/rapidio/sallocator/Kconfig |9 drivers/rapidio/sallocator/Makefile | 12 + drivers/rapidio/sallocator/bitmap.c | 384 include/linux/rio.h | 10 include/linux/rio_drv.h | 41 +++ 16 files changed, 1425 insertions(+), 14 deletions(-) (seems that I forgot to cc Jeff on the rionet change too). Oh well. If nobody puts their hand up in the next 24 hours or so I'll just send it all in to Linus. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
drivers/net/fec_8xx config problem
I just noticed that the fec_8xx driver is not currently reachable via menuconfig because it depends on 8XX instead of 8xx. It looks like this change occurred in commit d1c0a65fb597697d1fbce4eadf42b84f70483edc, almost a year ago: diff --git a/drivers/net/fec_8xx/Kconfig b/drivers/net/fec_8xx/Kconfig index a84c232..afb34de 100644 --- a/drivers/net/fec_8xx/Kconfig+++ b/drivers/net/fec_8xx/Kconfig @@ -1,6 +1,6 @@ config FEC_8XX tristate Motorola 8xx FEC driver - depends on NET_ETHERNET 8xx + depends on 8XX select MII Since nobody has noticed this problem, I'm wondering if this driver is still in (infrequent) use, or if it's been superseded and should be removed, or if I'm just completely missing something with respect to the use of 8XX instead of 8xx. I'm happy to submit a patch to correct this, I'm just not sure what the right answer is. Thanks, Becky ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: drivers/net/fec_8xx config problem
On Apr 30, 2008, at 2:20 PM, Scott Wood wrote: On Wed, Apr 30, 2008 at 02:19:21PM -0500, Becky Bruce wrote: I just noticed that the fec_8xx driver is not currently reachable via menuconfig because it depends on 8XX instead of 8xx. [snip] Since nobody has noticed this problem, I'm wondering if this driver is still in (infrequent) use, or if it's been superseded and should be removed, or if I'm just completely missing something with respect to the use of 8XX instead of 8xx. It's been superseded by drivers/net/fs_enet. Is there any reason we haven't removed it? If not, I can push a patch to yank it. Cheers, B ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: drivers/net/fec_8xx config problem
On Wed, Apr 30, 2008 at 02:24:19PM -0500, Becky Bruce wrote: On Apr 30, 2008, at 2:20 PM, Scott Wood wrote: On Wed, Apr 30, 2008 at 02:19:21PM -0500, Becky Bruce wrote: I just noticed that the fec_8xx driver is not currently reachable via menuconfig because it depends on 8XX instead of 8xx. [snip] Since nobody has noticed this problem, I'm wondering if this driver is still in (infrequent) use, or if it's been superseded and should be removed, or if I'm just completely missing something with respect to the use of 8XX instead of 8xx. It's been superseded by drivers/net/fs_enet. Is there any reason we haven't removed it? To keep arch/ppc/8xx_io company? :-) If not, I can push a patch to yank it. I have no objection. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
patch devres-support-addresses-greater-than-an-unsigned-long-via-dev_ioremap.patch added to gregkh-2.6 tree
This is a note to let you know that I've just added the patch titled Subject: devres: support addresses greater than an unsigned long via dev_ioremap to my gregkh-2.6 tree. Its filename is devres-support-addresses-greater-than-an-unsigned-long-via-dev_ioremap.patch This tree can be found at http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/ From [EMAIL PROTECTED] Wed Apr 30 11:27:51 2008 From: Kumar Gala [EMAIL PROTECTED] Date: Tue, 29 Apr 2008 10:25:48 -0500 (CDT) Subject: devres: support addresses greater than an unsigned long via dev_ioremap To: Greg KH [EMAIL PROTECTED] Cc: Tejun Heo [EMAIL PROTECTED], Jeff Garzik [EMAIL PROTECTED], Andrew Morton [EMAIL PROTECTED], linuxppc-dev@ozlabs.org list linuxppc-dev@ozlabs.org, lkml Mailing List [EMAIL PROTECTED], Jesse Barnes [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Use a resource_size_t instead of unsigned long since some arch's are capable of having ioremap deal with addresses greater than the size of a unsigned long. Signed-off-by: Kumar Gala [EMAIL PROTECTED] Cc: Tejun Heo [EMAIL PROTECTED] Cc: Jeff Garzik [EMAIL PROTECTED] Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] --- include/linux/io.h |4 ++-- lib/devres.c |4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) --- a/include/linux/io.h +++ b/include/linux/io.h @@ -58,9 +58,9 @@ static inline void devm_ioport_unmap(str } #endif -void __iomem * devm_ioremap(struct device *dev, unsigned long offset, +void __iomem * devm_ioremap(struct device *dev, resource_size_t offset, unsigned long size); -void __iomem * devm_ioremap_nocache(struct device *dev, unsigned long offset, +void __iomem * devm_ioremap_nocache(struct device *dev, resource_size_t offset, unsigned long size); void devm_iounmap(struct device *dev, void __iomem *addr); int check_signature(const volatile void __iomem *io_addr, --- a/lib/devres.c +++ b/lib/devres.c @@ -20,7 +20,7 @@ static int devm_ioremap_match(struct dev * * Managed ioremap(). Map is automatically unmapped on driver detach. */ -void __iomem *devm_ioremap(struct device *dev, unsigned long offset, +void __iomem *devm_ioremap(struct device *dev, resource_size_t offset, unsigned long size) { void __iomem **ptr, *addr; @@ -49,7 +49,7 @@ EXPORT_SYMBOL(devm_ioremap); * Managed ioremap_nocache(). Map is automatically unmapped on driver * detach. */ -void __iomem *devm_ioremap_nocache(struct device *dev, unsigned long offset, +void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset, unsigned long size) { void __iomem **ptr, *addr; Patches currently in gregkh-2.6 which might be from [EMAIL PROTECTED] are driver-core/devres-support-addresses-greater-than-an-unsigned-long-via-dev_ioremap.patch ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2 4/6] [POWERPC] QE: implement support for the GPIO LIB API
This is needed to access QE GPIOs via Linux GPIO API. Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] --- Updated per Timur Tabi's comments. Documentation/powerpc/booting-without-of.txt | 27 + arch/powerpc/sysdev/qe_lib/Kconfig |9 ++ arch/powerpc/sysdev/qe_lib/Makefile |1 + arch/powerpc/sysdev/qe_lib/gpio.c| 146 ++ include/asm-powerpc/qe.h |3 + 5 files changed, 186 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/sysdev/qe_lib/gpio.c diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt index fc7a235..c1044ee 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/powerpc/booting-without-of.txt @@ -1738,6 +1738,33 @@ platforms are moved over to use the flattened-device-tree model. .. }; + Note that par_io nodes are obsolete, and should not be used for + the new device trees. Instead, each Par I/O bank should be represented + via its own gpio-controller node: + + Required properties: + - #gpio-cells : should be 2. + - compatible : should be fsl,chip-qe-pario-bank, + fsl,mpc8323-qe-pario-bank. + - reg : offset to the register set and its length. + - gpio-controller : node to identify gpio controllers. + + Example: + qe_pio_a: [EMAIL PROTECTED] { + #gpio-cells = 2; + compatible = fsl,mpc8360-qe-pario-bank, +fsl,mpc8323-qe-pario-bank; + reg = 0x1400 0x18; + gpio-controller; + }; + + qe_pio_e: [EMAIL PROTECTED] { + #gpio-cells = 2; + compatible = fsl,mpc8360-qe-pario-bank, +fsl,mpc8323-qe-pario-bank; + reg = 0x1460 0x18; + gpio-controller; + }; vi) Pin configuration nodes diff --git a/arch/powerpc/sysdev/qe_lib/Kconfig b/arch/powerpc/sysdev/qe_lib/Kconfig index 76ffbc4..4bb18f5 100644 --- a/arch/powerpc/sysdev/qe_lib/Kconfig +++ b/arch/powerpc/sysdev/qe_lib/Kconfig @@ -24,3 +24,12 @@ config QE_USB bool help QE USB Host Controller support + +config QE_GPIO + bool QE GPIO support + depends on QUICC_ENGINE + select GENERIC_GPIO + select HAVE_GPIO_LIB + help + Say Y here if you're going to use hardware that connects to the + QE GPIOs. diff --git a/arch/powerpc/sysdev/qe_lib/Makefile b/arch/powerpc/sysdev/qe_lib/Makefile index e9ff888..f1855c1 100644 --- a/arch/powerpc/sysdev/qe_lib/Makefile +++ b/arch/powerpc/sysdev/qe_lib/Makefile @@ -7,3 +7,4 @@ obj-$(CONFIG_UCC) += ucc.o obj-$(CONFIG_UCC_SLOW) += ucc_slow.o obj-$(CONFIG_UCC_FAST) += ucc_fast.o obj-$(CONFIG_QE_USB) += usb.o +obj-$(CONFIG_QE_GPIO) += gpio.o diff --git a/arch/powerpc/sysdev/qe_lib/gpio.c b/arch/powerpc/sysdev/qe_lib/gpio.c new file mode 100644 index 000..c712e24 --- /dev/null +++ b/arch/powerpc/sysdev/qe_lib/gpio.c @@ -0,0 +1,146 @@ +/* + * QUICC Engine GPIOs + * + * Copyright (c) MontaVista Software, Inc. 2008. + * + * Author: Anton Vorontsov [EMAIL PROTECTED] + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ + +#include linux/kernel.h +#include linux/spinlock.h +#include linux/io.h +#include linux/of.h +#include linux/of_gpio.h +#include linux/gpio.h +#include asm/qe.h + +struct qe_gpio_chip { + struct of_mm_gpio_chip mm_gc; + spinlock_t lock; + + /* shadowed data register to clear/set bits safely */ + u32 cpdata; +}; + +static inline struct qe_gpio_chip * +to_qe_gpio_chip(struct of_mm_gpio_chip *mm_gc) +{ + return container_of(mm_gc, struct qe_gpio_chip, mm_gc); +} + +static void qe_gpio_save_regs(struct of_mm_gpio_chip *mm_gc) +{ + struct qe_gpio_chip *qe_gc = to_qe_gpio_chip(mm_gc); + struct qe_pio_regs __iomem *regs = mm_gc-regs; + + qe_gc-cpdata = in_be32(regs-cpdata); +} + +static int qe_gpio_get(struct gpio_chip *gc, unsigned int gpio) +{ + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc); + struct qe_pio_regs __iomem *regs = mm_gc-regs; + u32 pin_mask = 1 (QE_PIO_PINS - 1 - gpio); + + return in_be32(regs-cpdata) pin_mask; +} + +static void qe_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val) +{ + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc); + struct qe_gpio_chip *qe_gc = to_qe_gpio_chip(mm_gc); + struct qe_pio_regs __iomem *regs = mm_gc-regs; + unsigned long flags; + u32 pin_mask = 1 (QE_PIO_PINS - 1 - gpio); + + spin_lock_irqsave(qe_gc-lock, flags); + + if (val) + qe_gc-cpdata |= pin_mask; + else +
Re: [PATCH v2 4/6] [POWERPC] QE: implement support for the GPIO LIB API
Anton Vorontsov wrote: + Example: + qe_pio_a: [EMAIL PROTECTED] { + #gpio-cells = 2; + compatible = fsl,mpc8360-qe-pario-bank, + fsl,mpc8323-qe-pario-bank; I know this is an example, but would we ever include both compatible strings in one DTS? Isn't the norm something like: fsl,mpc8360-qe-pario-bank, fsl,qe-pario-bank; I.e. specific version, then generic version? Otherwise, every time we introduce a new QE part, we'll have to update *every* QE-enabled device tree *and* the QE gpio driver. +static int qe_gpio_get(struct gpio_chip *gc, unsigned int gpio) +{ + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc); + struct qe_pio_regs __iomem *regs = mm_gc-regs; + u32 pin_mask = 1 (QE_PIO_PINS - 1 - gpio); + + return in_be32(regs-cpdata) pin_mask; +} Return value should be u32, not int. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] docbook: fix fatal rapidio yet again (and more to come)
On Apr 30, 2008, at 2:12 PM, Andrew Morton wrote: On Wed, 30 Apr 2008 14:01:12 -0500 Kumar Gala [EMAIL PROTECTED] wrote: On Apr 30, 2008, at 1:35 PM, Andrew Morton wrote: On Tue, 29 Apr 2008 20:10:55 -0700 (PDT) Randy.Dunlap [EMAIL PROTECTED] wrote: From: Randy Dunlap [EMAIL PROTECTED] Don't refer to file that no longer exists: docproc: linux-2.6.25-git14/arch/powerpc/kernel/rio.c: No such file or directory Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- Documentation/DocBook/rapidio.tmpl |1 - 1 file changed, 1 deletion(-) --- linux-2.6.25-git14.orig/Documentation/DocBook/rapidio.tmpl +++ linux-2.6.25-git14/Documentation/DocBook/rapidio.tmpl @@ -133,7 +133,6 @@ !Idrivers/rapidio/rio-sysfs.c /sect1 sect1 id=PPC32_supporttitlePPC32 support/title -!Iarch/powerpc/kernel/rio.c !Earch/powerpc/sysdev/fsl_rio.c !Iarch/powerpc/sysdev/fsl_rio.c /sect1 grumble. This is a subset of rapidio-fix-docbook-references.patch, but I appear to be unable to interest anyone in merging/reviewing/accepting/ anything- else that quite large set of patches. Guys, those patches were sent six weeks ago and it now looks like they will miss 2.6.26. This is pretty slack of us. Help? Odd. I thought Paul had picked up a docbook RapidIO patch from you in the latest merge round. Well it's more than a patch. The six-week-old patch series is: rapidio-add-memory-mapping-driver-to-rapidio.patch rapidio-add-rapidio-space-allocation-bitmap-arithmetic.patch rapidio-add-fsl-rapidio-controller-memory-ops-functions.patch rapidio-add-the-rapidio-master-port-maintance-and-doorbell-window-to- space-resources.patch rapidio-add-rapidio-proc-fs-for-memory-mapping-debugging.patch rapidio-add-the-memory-mapping-support-in-rionet-driver.patch rapidio-fix-docbook-references.patch rapidio-fix-kernel-doc-problems.patch totalling: arch/powerpc/sysdev/fsl_rio.c | 13 + include/linux/rio.h | 10 drivers/net/Kconfig | 10 drivers/net/rionet.c| 324 ++ drivers/rapidio/Makefile|1 drivers/rapidio/rio.c | 10 drivers/rapidio/sallocator/Kconfig |9 drivers/rapidio/sallocator/Makefile | 12 + drivers/rapidio/sallocator/bitmap.c | 384 ++ ++ include/linux/rio.h | 10 include/linux/rio_drv.h | 41 +++ 16 files changed, 1425 insertions(+), 14 deletions(-) (seems that I forgot to cc Jeff on the rionet change too). Oh well. If nobody puts their hand up in the next 24 hours or so I'll just send it all in to Linus. I'm raising my hand. The memory map driver needs further review. If the Docbook issues can be applied w/o the other patches I suggest we go forward with those. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[Cbe-oss-dev] [PATCH] Updated: Reworked Cell OProfile: SPU mutex lock fix
This is a reworked patch to fix the SPU data storage. Currently, the SPU escape sequences and program counter data is being added directly into the kernel buffer without holding the buffer_mutex lock. This patch changes how the data is stored. A new function, oprofile_add_value, is added into the oprofile driver to allow adding generic data to the per cpu buffers. This enables a series of calls to the oprofile_add_value to enter the needed SPU escape sequences and SPU program data into the kernel buffer via the per cpu buffers without any additional processing. The oprofile_add_value function is generic so it could be used by other architecures as well provided the needed postprocessing was added to opreport. Finally, this patch backs out the changes previously added to the oprofile generic code for handling the architecture specific ops.sync_start and ops.sync_stop that allowed the architecture to skip the per CPU buffer creation. Signed-off-by: Carl Love [EMAIL PROTECTED] Index: Cell_kernel_4_15_2008/arch/powerpc/oprofile/cell/pr_util.h === --- Cell_kernel_4_15_2008.orig/arch/powerpc/oprofile/cell/pr_util.h +++ Cell_kernel_4_15_2008/arch/powerpc/oprofile/cell/pr_util.h @@ -20,11 +20,6 @@ #include asm/cell-regs.h #include asm/spu.h -/* Defines used for sync_start */ -#define SKIP_GENERIC_SYNC 0 -#define SYNC_START_ERROR -1 -#define DO_GENERIC_SYNC 1 - struct spu_overlay_info { /* map of sections within an SPU overlay */ unsigned int vma; /* SPU virtual memory address from elf */ unsigned int size; /* size of section from elf */ @@ -85,7 +80,7 @@ void stop_spu_profiling(void); int spu_sync_start(void); /* remove the hooks */ -int spu_sync_stop(void); +void spu_sync_stop(void); /* Record SPU program counter samples to the oprofile event buffer. */ void spu_sync_buffer(int spu_num, unsigned int *samples, Index: Cell_kernel_4_15_2008/arch/powerpc/oprofile/cell/spu_task_sync.c === --- Cell_kernel_4_15_2008.orig/arch/powerpc/oprofile/cell/spu_task_sync.c +++ Cell_kernel_4_15_2008/arch/powerpc/oprofile/cell/spu_task_sync.c @@ -31,11 +31,12 @@ #define RELEASE_ALL -static DEFINE_SPINLOCK(buffer_lock); +static DEFINE_SPINLOCK(add_value_lock); static DEFINE_SPINLOCK(cache_lock); static int num_spu_nodes; int spu_prof_num_nodes; int last_guard_val[MAX_NUMNODES * 8]; +static int spu_ctx_sw_seen[MAX_NUMNODES * 8]; /* Container for caching information about an active SPU task. */ struct cached_info { @@ -289,6 +290,7 @@ static int process_context_switch(struct int retval; unsigned int offset = 0; unsigned long spu_cookie = 0, app_dcookie; + int cpu_buf; retval = prepare_cached_spu_info(spu, objectId); if (retval) @@ -303,17 +305,28 @@ static int process_context_switch(struct goto out; } - /* Record context info in event buffer */ - spin_lock_irqsave(buffer_lock, flags); - add_event_entry(ESCAPE_CODE); - add_event_entry(SPU_CTX_SWITCH_CODE); - add_event_entry(spu-number); - add_event_entry(spu-pid); - add_event_entry(spu-tgid); - add_event_entry(app_dcookie); - add_event_entry(spu_cookie); - add_event_entry(offset); - spin_unlock_irqrestore(buffer_lock, flags); + /* Record context info in event buffer. Note, there are 4x more +* SPUs then CPUs. Map the SPU events/data for a given SPU to +* the same CPU buffer. Need to ensure the cntxt switch data and +* samples stay in order. +*/ + cpu_buf = spu-number 2; + spin_lock_irqsave(add_value_lock, flags); + oprofile_add_value(ESCAPE_CODE, cpu_buf); + oprofile_add_value(SPU_CTX_SWITCH_CODE, cpu_buf); + oprofile_add_value(spu-number, cpu_buf); + oprofile_add_value(spu-pid, cpu_buf); + oprofile_add_value(spu-tgid, cpu_buf); + oprofile_add_value(app_dcookie, cpu_buf); + oprofile_add_value(spu_cookie, cpu_buf); + oprofile_add_value(offset, cpu_buf); + + /* Set flag to indicate SPU PC data can now be written out. If +* the SPU program counter data is seen before an SPU context +* record is seen, the postprocessing will fail. +*/ + spu_ctx_sw_seen[spu-number] = 1; + spin_unlock_irqrestore(add_value_lock, flags); smp_wmb(); /* insure spu event buffer updates are written */ /* don't want entries intermingled... */ out: @@ -333,7 +346,6 @@ static int spu_active_notify(struct noti unsigned long flags; struct spu *the_spu = data; - pr_debug(SPU event notification arrived\n); if (!val) { spin_lock_irqsave(cache_lock, flags); retval = release_cached_info(the_spu-number); @@ -363,38 +375,38 @@ static int
Re: [PATCH 1/7] Implement arch disable/enable irq hooks.
On Wed, Apr 30, 2008 at 11:01:47PM +0200, Segher Boessenkool wrote: 3. The style in all the assembly code is not to have spaces after commas separating instruction operands. I'll do that if that's what is prefered, but how did that come about as the style used? It's different from what we do in C, But this isn't C code, it's assembler code. Enh. It's a comma-delineated list in both cases. PowerPC assembler code (and most other assembler code) doesn't use spaces here usually. Looking at other arches, it seems pretty evenly split. and adding the space helps readability in asm as well... Many people disagree ;-) Compressionhelpsreadability? Anyway, it's better to keep a consistent style, whatever that style is, don't you agree? Not if it's GNU-style. :-) -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH] vmemmap fixes to use smaller pages
On Wed, 2008-04-30 at 12:06 -0700, Geoff Levand wrote: booting 2.6.25 with a ps3_defconfig and that doesn't work neither (though at least when doing the later, I do get a black screen no sync, like of ps3fb failed monitor detection, while with current upstream, I just get the last kexec messages and nothing happens). This should work. You are the first to report a problem with 2.6.25. Could you double check your build, and if you still have trouble, put your vmlinux somewhere I can get it? I'll dbl check today. It could be bad monitor detection... OK, I'll try it with the upstream kernel from last week and report within the next day or so. Thanks. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Set lower flag bits in regs-trap to indicate debug level exception
On Wed, 2008-04-30 at 05:44 -0500, Kumar Gala wrote: 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 [EMAIL PROTECTED] Ack. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] [POWERPC] devres: Add devm_ioremap_flags()
On Wed, 2008-04-30 at 11:08 -0500, Kumar Gala wrote: From: Emil Medve [EMAIL PROTECTED] We provide an ioremap_flags so provide a coresphonding devm_ioremap_flags. Signed-off-by: Emil Medve [EMAIL PROTECTED] Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- Forgot to commit the actual implemtation in arch/powerpc/lib/devres.c Which tree should this go through, powerpc.git? Let's call it ioremap_prot instead please. I'm about to change ioremap_flags to ioremap_prot anyways. Keep the flags/prot argument unsigned long for now (it can be argued it should be a pgprot but that hasn't been sorted out completely). Cheers, Ben. - k arch/powerpc/lib/Makefile |1 + arch/powerpc/lib/devres.c | 33 + include/asm-powerpc/io.h |8 +++- include/linux/io.h|1 + lib/devres.c |2 +- 5 files changed, 43 insertions(+), 2 deletions(-) create mode 100644 arch/powerpc/lib/devres.c diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile index 4bb023f..f1d2cdc 100644 --- a/arch/powerpc/lib/Makefile +++ b/arch/powerpc/lib/Makefile @@ -23,3 +23,4 @@ obj-$(CONFIG_SMP) += locks.o endif obj-$(CONFIG_PPC_LIB_RHEAP) += rheap.o +obj-$(CONFIG_HAS_IOMEM) += devres.o diff --git a/arch/powerpc/lib/devres.c b/arch/powerpc/lib/devres.c new file mode 100644 index 000..b73c64b --- /dev/null +++ b/arch/powerpc/lib/devres.c @@ -0,0 +1,33 @@ +#include linux/device.h/* devres_*(), devm_ioremap_release() */ +#include linux/io.h/* ioremap_flags() */ +#include linux/module.h/* EXPORT_SYMBOL() */ + +/** + * devm_ioremap_flags - Managed ioremap_flags() + * @dev: Generic device to remap IO address for + * @offset: BUS offset to map + * @size: Size of map + * @flags: Page flags + * + * Managed ioremap_flags(). Map is automatically unmapped on driver + * detach. + */ +void __iomem *devm_ioremap_flags(struct device *dev, resource_size_t offset, + size_t size, unsigned long flags) +{ + void __iomem **ptr, *addr; + + ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL); + if (!ptr) + return NULL; + + addr = ioremap_flags(offset, size, flags); + if (addr) { + *ptr = addr; + devres_add(dev, ptr); + } else + devres_free(ptr); + + return addr; +} +EXPORT_SYMBOL(devm_ioremap_flags); diff --git a/include/asm-powerpc/io.h b/include/asm-powerpc/io.h index afae069..3b8c334 100644 --- a/include/asm-powerpc/io.h +++ b/include/asm-powerpc/io.h @@ -2,7 +2,7 @@ #define _ASM_POWERPC_IO_H #ifdef __KERNEL__ -/* +/* * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version @@ -18,6 +18,9 @@ extern int check_legacy_ioport(unsigned long base_port); #define _PNPWRP 0xa79 #define PNPBIOS_BASE 0xf000 +#include linux/device.h +#include linux/io.h + #include linux/compiler.h #include asm/page.h #include asm/byteorder.h @@ -744,6 +747,9 @@ static inline void * bus_to_virt(unsigned long address) #define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set) +void __iomem *devm_ioremap_flags(struct device *dev, resource_size_t offset, + size_t size, unsigned long flags); + #endif /* __KERNEL__ */ #endif /* _ASM_POWERPC_IO_H */ diff --git a/include/linux/io.h b/include/linux/io.h index 831f57c..7a390cf 100644 --- a/include/linux/io.h +++ b/include/linux/io.h @@ -58,6 +58,7 @@ static inline void devm_ioport_unmap(struct device *dev, void __iomem *addr) } #endif +void devm_ioremap_release(struct device *dev, void *res); void __iomem * devm_ioremap(struct device *dev, resource_size_t offset, unsigned long size); void __iomem * devm_ioremap_nocache(struct device *dev, resource_size_t offset, diff --git a/lib/devres.c b/lib/devres.c index 26c87c4..72c8909 100644 --- a/lib/devres.c +++ b/lib/devres.c @@ -2,7 +2,7 @@ #include linux/io.h #include linux/module.h -static void devm_ioremap_release(struct device *dev, void *res) +void devm_ioremap_release(struct device *dev, void *res) { iounmap(*(void __iomem **)res); } ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Set lower flag bits in regs-trap to indicate debug level exception
On Apr 30, 2008, at 4:43 PM, Benjamin Herrenschmidt wrote: On Wed, 2008-04-30 at 05:44 -0500, Kumar Gala wrote: 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 [EMAIL PROTECTED] Ack. that was the easy one :) - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] [POWERPC] devres: Add devm_ioremap_flags()
On Apr 30, 2008, at 4:42 PM, Benjamin Herrenschmidt wrote: On Wed, 2008-04-30 at 11:08 -0500, Kumar Gala wrote: From: Emil Medve [EMAIL PROTECTED] We provide an ioremap_flags so provide a coresphonding devm_ioremap_flags. Signed-off-by: Emil Medve [EMAIL PROTECTED] Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- Forgot to commit the actual implemtation in arch/powerpc/lib/devres.c Which tree should this go through, powerpc.git? Let's call it ioremap_prot instead please. I'm about to change ioremap_flags to ioremap_prot anyways. Keep the flags/prot argument unsigned long for now (it can be argued it should be a pgprot but that hasn't been sorted out completely). No problem. I've always wondered why ioremap_* aren't better specified by generic code. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Rework EXC_LEVEL_EXCEPTION_PROLOG code
On Wed, 2008-04-30 at 04:27 -0500, Kumar Gala wrote: * 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) ^^ 11 ? * 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 [EMAIL PROTECTED] --- 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. Well, reschedule or signal, either way, you can't handle them on the way out. Maybe an option there is to set the flag in the normal kernel stack's thread info and trigger an interrupt asap via the PIT so things get handled ? 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 @@ slwir8,r8,2;\ addis r8,r8,[EMAIL PROTECTED];\ lwz r8,[EMAIL PROTECTED](r8); \ - addir8,r8,THREAD_SIZE; + addir8,r8,THREAD_SIZE-INT_FRAME_SIZE; #else #define BOOKE_LOAD_EXC_LEVEL_STACK(level)\ lis r8,[EMAIL PROTECTED]; \ lwz r8,[EMAIL PROTECTED](r8); \ - addir8,r8,THREAD_SIZE; + addir8,r8,THREAD_SIZE-INT_FRAME_SIZE; #endif Nothing specific to your patch, but those level##_STACK_TOP seem to be pretty badly named if you end up -adding- THREAD_SIZE to actually get to the stack's top. Do they really contain the stack top or do they in fact contain the stack base/bottom ? /* @@ -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 */\ + addir11,r11,THREAD_SIZE-INT_FRAME_SIZE; /* Alloc exception frm */\ So you do the above whether it will actually be needed or not right ? mfcrr10;/* 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 */\ - addir11,r11,THREAD_SIZE; \ -1: subir11,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; \ Are we concerned with performances here or not ? Because using the same reg all along isn't the best ... + /* 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); \
[PATCH v3] [POWERPC] devres: Add devm_ioremap_prot()
From: Emil Medve [EMAIL PROTECTED] We provide an ioremap_flags so provide a corresponding devm_ioremap_prot. The slight name difference is at Ben Herrenschmidt request as he plans on changing ioremap_flags to ioremap_prot in the future. Signed-off-by: Emil Medve [EMAIL PROTECTED] Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- Renamed at BenH's request to devm_ioremap_prot. arch/powerpc/lib/Makefile |1 + arch/powerpc/lib/devres.c | 33 + include/asm-powerpc/io.h |8 +++- include/linux/io.h|1 + lib/devres.c |2 +- 5 files changed, 43 insertions(+), 2 deletions(-) create mode 100644 arch/powerpc/lib/devres.c diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile index 4bb023f..f1d2cdc 100644 --- a/arch/powerpc/lib/Makefile +++ b/arch/powerpc/lib/Makefile @@ -23,3 +23,4 @@ obj-$(CONFIG_SMP) += locks.o endif obj-$(CONFIG_PPC_LIB_RHEAP) += rheap.o +obj-$(CONFIG_HAS_IOMEM)+= devres.o diff --git a/arch/powerpc/lib/devres.c b/arch/powerpc/lib/devres.c new file mode 100644 index 000..b290845 --- /dev/null +++ b/arch/powerpc/lib/devres.c @@ -0,0 +1,33 @@ +#include linux/device.h /* devres_*(), devm_ioremap_release() */ +#include linux/io.h /* ioremap_flags() */ +#include linux/module.h /* EXPORT_SYMBOL() */ + +/** + * devm_ioremap_prot - Managed ioremap_flags() + * @dev: Generic device to remap IO address for + * @offset: BUS offset to map + * @size: Size of map + * @flags: Page flags + * + * Managed ioremap_prot(). Map is automatically unmapped on driver + * detach. + */ +void __iomem *devm_ioremap_prot(struct device *dev, resource_size_t offset, +size_t size, unsigned long flags) +{ + void __iomem **ptr, *addr; + + ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL); + if (!ptr) + return NULL; + + addr = ioremap_flags(offset, size, flags); + if (addr) { + *ptr = addr; + devres_add(dev, ptr); + } else + devres_free(ptr); + + return addr; +} +EXPORT_SYMBOL(devm_ioremap_prot); diff --git a/include/asm-powerpc/io.h b/include/asm-powerpc/io.h index afae069..e0062d7 100644 --- a/include/asm-powerpc/io.h +++ b/include/asm-powerpc/io.h @@ -2,7 +2,7 @@ #define _ASM_POWERPC_IO_H #ifdef __KERNEL__ -/* +/* * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version @@ -18,6 +18,9 @@ extern int check_legacy_ioport(unsigned long base_port); #define _PNPWRP0xa79 #define PNPBIOS_BASE 0xf000 +#include linux/device.h +#include linux/io.h + #include linux/compiler.h #include asm/page.h #include asm/byteorder.h @@ -744,6 +747,9 @@ static inline void * bus_to_virt(unsigned long address) #define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set) +void __iomem *devm_ioremap_prot(struct device *dev, resource_size_t offset, + size_t size, unsigned long flags); + #endif /* __KERNEL__ */ #endif /* _ASM_POWERPC_IO_H */ diff --git a/include/linux/io.h b/include/linux/io.h index 831f57c..7a390cf 100644 --- a/include/linux/io.h +++ b/include/linux/io.h @@ -58,6 +58,7 @@ static inline void devm_ioport_unmap(struct device *dev, void __iomem *addr) } #endif +void devm_ioremap_release(struct device *dev, void *res); void __iomem * devm_ioremap(struct device *dev, resource_size_t offset, unsigned long size); void __iomem * devm_ioremap_nocache(struct device *dev, resource_size_t offset, diff --git a/lib/devres.c b/lib/devres.c index 26c87c4..72c8909 100644 --- a/lib/devres.c +++ b/lib/devres.c @@ -2,7 +2,7 @@ #include linux/io.h #include linux/module.h -static void devm_ioremap_release(struct device *dev, void *res) +void devm_ioremap_release(struct device *dev, void *res) { iounmap(*(void __iomem **)res); } -- 1.5.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro
On Wed, 2008-04-30 at 03:02 -0500, Kumar Gala wrote: got that. Does 40x/44x have anything similar we need to save/restore? MMUCR I'd say... look at what our tlbie does there... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro
On Apr 30, 2008, at 4:59 PM, Benjamin Herrenschmidt wrote: On Wed, 2008-04-30 at 03:02 -0500, Kumar Gala wrote: got that. Does 40x/44x have anything similar we need to save/ restore? MMUCR I'd say... look at what our tlbie does there... thanks. Will take a look. I just plan on overloading MMUCR with MAS0. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] docbook: fix fatal rapidio yet again (and more to come)
Andrew Morton writes: Odd. I thought Paul had picked up a docbook RapidIO patch from you in the latest merge round. Well it's more than a patch. The six-week-old patch series is: rapidio-add-memory-mapping-driver-to-rapidio.patch rapidio-add-rapidio-space-allocation-bitmap-arithmetic.patch rapidio-add-fsl-rapidio-controller-memory-ops-functions.patch rapidio-add-the-rapidio-master-port-maintance-and-doorbell-window-to-space-resources.patch rapidio-add-rapidio-proc-fs-for-memory-mapping-debugging.patch rapidio-add-the-memory-mapping-support-in-rionet-driver.patch rapidio-fix-docbook-references.patch rapidio-fix-kernel-doc-problems.patch What happened is that you (Andrew) sent them on to me pretty much unexamined. I took a look at them and dropped one of them because it created a new /proc file. I asked Kumar to look at them and he had issues with another three of the patches, and dropping those meant that all the following ones (including the fix-kernel-doc one) wouldn't apply, so I dropped them too. I applied the rest and sent them to Linus. (seems that I forgot to cc Jeff on the rionet change too). Yeah. I nearly dropped that one too. I probably should have. :) Oh well. If nobody puts their hand up in the next 24 hours or so I'll just send it all in to Linus. Please don't. At this stage I think the best thing is for Kumar to talk to Zhang Wei (they both work for Freescale, so that should be possible in theory :) and get him to rework the remaining patches as required for inclusion in 2.6.27. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [spi-devel-general] [PATCH] spi_mpc83xx: test below 0 on unsigned irq in mpc83xx_spi_probe()
On Wednesday 23 April 2008, Kumar Gala wrote: On Apr 23, 2008, at 3:19 PM, Roel Kluin wrote: mpc83xx_spi-irq is unsigned, so the test fails Signed-off-by: Roel Kluin [EMAIL PROTECTED] Any reason to not just make mpc83xx_spi-irq be int, following normal practice everywhere? If not, I'll roll that into the patch from Joakim Tjernlund... - Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Rework EXC_LEVEL_EXCEPTION_PROLOG code
On Apr 30, 2008, at 4:54 PM, Benjamin Herrenschmidt wrote: On Wed, 2008-04-30 at 04:27 -0500, Kumar Gala wrote: * 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) ^^ 11 ? r8 is correct for my example. My point is s/GPR11-INT_FRAME_SIZE/GPR11/ * 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 [EMAIL PROTECTED] --- 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. Well, reschedule or signal, either way, you can't handle them on the way out. Maybe an option there is to set the flag in the normal kernel stack's thread info and trigger an interrupt asap via the PIT so things get handled ? If we don't handle reschedule or signal will we actually not function properly? I assume reschedule isn't an issue, but could we lose a signal? 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 @@ slwir8,r8,2;\ addis r8,r8,[EMAIL PROTECTED];\ lwz r8,[EMAIL PROTECTED](r8); \ - addir8,r8,THREAD_SIZE; + addir8,r8,THREAD_SIZE-INT_FRAME_SIZE; #else #define BOOKE_LOAD_EXC_LEVEL_STACK(level) \ lis r8,[EMAIL PROTECTED]; \ lwz r8,[EMAIL PROTECTED](r8); \ - addir8,r8,THREAD_SIZE; + addir8,r8,THREAD_SIZE-INT_FRAME_SIZE; #endif Nothing specific to your patch, but those level##_STACK_TOP seem to be pretty badly named if you end up -adding- THREAD_SIZE to actually get to the stack's top. Do they really contain the stack top or do they in fact contain the stack base/bottom ? That might be stale from how the old code worked. I can never remember what we consider the top and bottom of the stack. (please remind me and I'll fixup the comments and variables). /* @@ -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 */\ + addir11,r11,THREAD_SIZE-INT_FRAME_SIZE; /* Alloc exception frm */\ So you do the above whether it will actually be needed or not right ? good point I can move this down. mfcrr10;/* 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 */\ - addir11,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;
Re: [PATCH] docbook: fix fatal rapidio yet again (and more to come)
On Apr 30, 2008, at 5:11 PM, Randy Dunlap wrote: On Thu, 1 May 2008 08:09:24 +1000 Paul Mackerras wrote: Andrew Morton writes: Odd. I thought Paul had picked up a docbook RapidIO patch from you in the latest merge round. Well it's more than a patch. The six-week-old patch series is: rapidio-add-memory-mapping-driver-to-rapidio.patch rapidio-add-rapidio-space-allocation-bitmap-arithmetic.patch rapidio-add-fsl-rapidio-controller-memory-ops-functions.patch rapidio-add-the-rapidio-master-port-maintance-and-doorbell-window- to-space-resources.patch rapidio-add-rapidio-proc-fs-for-memory-mapping-debugging.patch rapidio-add-the-memory-mapping-support-in-rionet-driver.patch rapidio-fix-docbook-references.patch rapidio-fix-kernel-doc-problems.patch What happened is that you (Andrew) sent them on to me pretty much unexamined. I took a look at them and dropped one of them because it created a new /proc file. I asked Kumar to look at them and he had issues with another three of the patches, and dropping those meant that all the following ones (including the fix-kernel-doc one) wouldn't apply, so I dropped them too. I applied the rest and sent them to Linus. (seems that I forgot to cc Jeff on the rionet change too). Yeah. I nearly dropped that one too. I probably should have. :) Oh well. If nobody puts their hand up in the next 24 hours or so I'll just send it all in to Linus. Please don't. At this stage I think the best thing is for Kumar to talk to Zhang Wei (they both work for Freescale, so that should be possible in theory :) and get him to rework the remaining patches as required for inclusion in 2.6.27. Just to be clear, the docbook changes shouldn't wait for 2.6.27. There's no need for that. Can the docbook be respun against linus's tree? -k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] docbook: fix fatal rapidio yet again (and more to come)
Kumar Gala wrote: On Apr 30, 2008, at 5:11 PM, Randy Dunlap wrote: On Thu, 1 May 2008 08:09:24 +1000 Paul Mackerras wrote: Andrew Morton writes: Odd. I thought Paul had picked up a docbook RapidIO patch from you in the latest merge round. Well it's more than a patch. The six-week-old patch series is: rapidio-add-memory-mapping-driver-to-rapidio.patch rapidio-add-rapidio-space-allocation-bitmap-arithmetic.patch rapidio-add-fsl-rapidio-controller-memory-ops-functions.patch rapidio-add-the-rapidio-master-port-maintance-and-doorbell-window-to-space-resources.patch rapidio-add-rapidio-proc-fs-for-memory-mapping-debugging.patch rapidio-add-the-memory-mapping-support-in-rionet-driver.patch rapidio-fix-docbook-references.patch rapidio-fix-kernel-doc-problems.patch What happened is that you (Andrew) sent them on to me pretty much unexamined. I took a look at them and dropped one of them because it created a new /proc file. I asked Kumar to look at them and he had issues with another three of the patches, and dropping those meant that all the following ones (including the fix-kernel-doc one) wouldn't apply, so I dropped them too. I applied the rest and sent them to Linus. (seems that I forgot to cc Jeff on the rionet change too). Yeah. I nearly dropped that one too. I probably should have. :) Oh well. If nobody puts their hand up in the next 24 hours or so I'll just send it all in to Linus. Please don't. At this stage I think the best thing is for Kumar to talk to Zhang Wei (they both work for Freescale, so that should be possible in theory :) and get him to rework the remaining patches as required for inclusion in 2.6.27. Just to be clear, the docbook changes shouldn't wait for 2.6.27. There's no need for that. Can the docbook be respun against linus's tree? Sure, I'll do that later, hopefully tonight. -- ~Randy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Rework EXC_LEVEL_EXCEPTION_PROLOG code
On Wed, 2008-04-30 at 17:13 -0500, Kumar Gala wrote: If we don't handle reschedule or signal will we actually not function properly? I assume reschedule isn't an issue, but could we lose a signal? Well, you can be in trouble if you lose TIF_SIGPENDING. You don't -have- to actually take the signal, it will then be done on the next return to userspace (next timer interrupt, next syscall, ...), but TIF_SIGPENDING must not be lost. Nothing specific to your patch, but those level##_STACK_TOP seem to be pretty badly named if you end up -adding- THREAD_SIZE to actually get to the stack's top. Do they really contain the stack top or do they in fact contain the stack base/bottom ? That might be stale from how the old code worked. I can never remember what we consider the top and bottom of the stack. (please remind me and I'll fixup the comments and variables). Well, top is the high address and bottom is the low address in my view of things :-) I thought about that. The only case its a bit of an issue is for CriticalInput. I don't see Watchdog, Debug, or MachineCheck as being performance critical. I can use r10 if I save and restored the CR or some other register. You can save CR first yeah and then interleave a bit using 2 registers (ie. 2 loads, 2 stores, or something like load 1, load 2, store 1, load 3, store 2, etc...) just leaving it to C code. I assume that preempt_count should be the same value on entry and exit. Do think we should set HARDIRQ_OFFSET for debug level exceptions? Well... I think all those things should run with EE disabled, and thus be considered as far as linux is concerned, as interrupts. So the C code should do irq_enter/exit. Where should I look for an example of how to convey that information to lockdep? The irqtrace stuff in the asm would do maybe unless transfer_to_handler does it already, I have to look at the code with all your patches applied... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 0/5] PS3 patches for 2.6.26
Paul, This is a small set of PS3 fixup patches for 2.6.26. [patch 1/5] POWERPC: Fix slb.c compile warnings [patch 2/5] PS3: Add time include to lpm [patch 3/5] PS3: Make ps3_virq_setup and ps3_virq_destroy static [patch 4/5] PS3: Remove unsupported wakeup sources [patch 5/5] PS3: Update ps3_defconfig -Geoff -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 4/5] PS3: Remove unsupported wakeup sources
Other OS wakeup is not supported from the IR controller, the bluetooth controller nor the RTC. Remove references to these in the PS3 sys-manager source. Signed-off-by: Geoff Levand [EMAIL PROTECTED] --- drivers/ps3/ps3-sys-manager.c |7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) --- a/drivers/ps3/ps3-sys-manager.c +++ b/drivers/ps3/ps3-sys-manager.c @@ -184,10 +184,7 @@ enum ps3_sys_manager_next_op { /** * enum ps3_sys_manager_wake_source - Next-op wakeup source (bit position mask). - * @PS3_SM_WAKE_DEFAULT: Disk insert, power button, eject button, IR - * controller, and bluetooth controller. - * @PS3_SM_WAKE_RTC: - * @PS3_SM_WAKE_RTC_ERROR: + * @PS3_SM_WAKE_DEFAULT: Disk insert, power button, eject button. * @PS3_SM_WAKE_W_O_L: Ether or wireless LAN. * @PS3_SM_WAKE_P_O_R: Power on reset. * @@ -200,8 +197,6 @@ enum ps3_sys_manager_next_op { enum ps3_sys_manager_wake_source { /* version 3 */ PS3_SM_WAKE_DEFAULT = 0, - PS3_SM_WAKE_RTC = 0x0040, - PS3_SM_WAKE_RTC_ERROR = 0x0080, PS3_SM_WAKE_W_O_L = 0x0400, PS3_SM_WAKE_P_O_R = 0x8000, }; -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 5/5] PS3: Update ps3_defconfig
Update ps3_defconfig. Signed-off-by: Geoff Levand [EMAIL PROTECTED] --- arch/powerpc/configs/ps3_defconfig | 132 +++-- 1 file changed, 84 insertions(+), 48 deletions(-) --- a/arch/powerpc/configs/ps3_defconfig +++ b/arch/powerpc/configs/ps3_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.25-rc6 -# Thu Mar 20 11:07:04 2008 +# Linux kernel version: 2.6.25 +# Mon Apr 28 12:39:10 2008 # CONFIG_PPC64=y @@ -30,6 +30,9 @@ CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_IRQ_PER_CPU=y +CONFIG_STACKTRACE_SUPPORT=y +CONFIG_TRACE_IRQFLAGS_SUPPORT=y +CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_ARCH_HAS_ILOG2_U64=y @@ -73,8 +76,6 @@ CONFIG_POSIX_MQUEUE=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set # CONFIG_GROUP_SCHED is not set -# CONFIG_USER_SCHED is not set -# CONFIG_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set @@ -161,7 +162,6 @@ CONFIG_PPC_MULTIPLATFORM=y # CONFIG_PPC_PMAC is not set # CONFIG_PPC_MAPLE is not set # CONFIG_PPC_PASEMI is not set -# CONFIG_PPC_CELLEB is not set CONFIG_PPC_PS3=y # @@ -181,6 +181,7 @@ CONFIG_PS3_LPM=m CONFIG_PPC_CELL=y # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PPC_IBM_CELL_BLADE is not set +# CONFIG_PPC_CELLEB is not set # # Cell Broadband Engine options @@ -205,9 +206,9 @@ CONFIG_SPU_BASE=y # # Kernel options # -# CONFIG_TICK_ONESHOT is not set +CONFIG_TICK_ONESHOT=y # CONFIG_NO_HZ is not set -# CONFIG_HIGH_RES_TIMERS is not set +CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_HZ_100 is not set CONFIG_HZ_250=y @@ -221,7 +222,6 @@ CONFIG_PREEMPT_NONE=y CONFIG_BINFMT_ELF=y CONFIG_COMPAT_BINFMT_ELF=y CONFIG_BINFMT_MISC=y -CONFIG_FORCE_MAX_ZONEORDER=13 # CONFIG_IOMMU_VMERGE is not set CONFIG_IOMMU_HELPER=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y @@ -255,6 +255,7 @@ CONFIG_BOUNCE=y CONFIG_ARCH_MEMORY_PROBE=y # CONFIG_PPC_HAS_HASH_64K is not set # CONFIG_PPC_64K_PAGES is not set +CONFIG_FORCE_MAX_ZONEORDER=13 # CONFIG_SCHED_SMT is not set CONFIG_PROC_DEVICETREE=y # CONFIG_CMDLINE_BOOL is not set @@ -272,7 +273,9 @@ CONFIG_GENERIC_ISA_DMA=y # CONFIG_PCI_SYSCALL is not set # CONFIG_ARCH_SUPPORTS_MSI is not set # CONFIG_PCCARD is not set +CONFIG_PAGE_OFFSET=0xc000 CONFIG_KERNEL_START=0xc000 +CONFIG_PHYSICAL_START=0x # # Networking @@ -292,7 +295,7 @@ CONFIG_XFRM=y # CONFIG_XFRM_STATISTICS is not set # CONFIG_NET_KEY is not set CONFIG_INET=y -# CONFIG_IP_MULTICAST is not set +CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set CONFIG_IP_FIB_HASH=y CONFIG_IP_PNP=y @@ -301,6 +304,7 @@ CONFIG_IP_PNP_DHCP=y # CONFIG_IP_PNP_RARP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set +# CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set # CONFIG_SYN_COOKIES is not set # CONFIG_INET_AH is not set @@ -332,8 +336,10 @@ CONFIG_INET6_XFRM_MODE_TUNNEL=y CONFIG_INET6_XFRM_MODE_BEET=y # CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set CONFIG_IPV6_SIT=y +CONFIG_IPV6_NDISC_NODETYPE=y # CONFIG_IPV6_TUNNEL is not set # CONFIG_IPV6_MULTIPLE_TABLES is not set +# CONFIG_IPV6_MROUTE is not set # CONFIG_NETWORK_SECMARK is not set # CONFIG_NETFILTER is not set # CONFIG_IP_DCCP is not set @@ -392,8 +398,6 @@ CONFIG_IEEE80211=m CONFIG_IEEE80211_CRYPT_WEP=m CONFIG_IEEE80211_CRYPT_CCMP=m CONFIG_IEEE80211_CRYPT_TKIP=m -CONFIG_IEEE80211_SOFTMAC=m -# CONFIG_IEEE80211_SOFTMAC_DEBUG is not set # CONFIG_RFKILL is not set # CONFIG_NET_9P is not set @@ -507,6 +511,7 @@ CONFIG_WLAN_80211=y # CONFIG_LIBERTAS is not set # CONFIG_USB_ZD1201 is not set # CONFIG_USB_NET_RNDIS_WLAN is not set +# CONFIG_IWLWIFI_LEDS is not set # CONFIG_HOSTAP is not set # @@ -578,6 +583,7 @@ CONFIG_INPUT_JOYSTICK=y # CONFIG_JOYSTICK_SPACEBALL is not set # CONFIG_JOYSTICK_STINGER is not set # CONFIG_JOYSTICK_TWIDJOY is not set +# CONFIG_JOYSTICK_ZHENHUA is not set # CONFIG_JOYSTICK_JOYDUMP is not set # CONFIG_JOYSTICK_XPAD is not set # CONFIG_INPUT_TABLET is not set @@ -641,6 +647,7 @@ CONFIG_SSB_POSSIBLE=y # Multifunction device drivers # # CONFIG_MFD_SM501 is not set +# CONFIG_HTC_PASIC3 is not set # # Multimedia devices @@ -761,10 +768,6 @@ CONFIG_SND_PS3_DEFAULT_START_DELAY=2000 # CONFIG_SND_SOC is not set # -# SoC Audio support for SuperH -# - -# # ALSA SoC audio for Freescale SOCs # @@ -849,6 +852,7 @@ CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_ALAUDA is not set # CONFIG_USB_STORAGE_ONETOUCH is not set # CONFIG_USB_STORAGE_KARMA is not set +# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set # CONFIG_USB_LIBUSUAL is not set # @@ -893,10 +897,6 @@ CONFIG_USB_MON=y # CONFIG_EDAC is not set # CONFIG_RTC_CLASS is not set # CONFIG_DMADEVICES is not set - -# -# Userspace I/O -# # CONFIG_UIO is not set
[patch 3/5] PS3: Make ps3_virq_setup and ps3_virq_destroy static
From: Geert Uytterhoeven [EMAIL PROTECTED] The routines ps3_virq_setup() and ps3_virq_destroy() are used in only one file, so make them static. Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED] Signed-off-by: Geoff Levand [EMAIL PROTECTED] --- arch/powerpc/platforms/ps3/interrupt.c |6 +++--- include/asm-powerpc/ps3.h |3 --- 2 files changed, 3 insertions(+), 6 deletions(-) --- a/arch/powerpc/platforms/ps3/interrupt.c +++ b/arch/powerpc/platforms/ps3/interrupt.c @@ -167,8 +167,8 @@ static struct irq_chip ps3_irq_chip = { * ps3_private data. */ -int ps3_virq_setup(enum ps3_cpu_binding cpu, unsigned long outlet, - unsigned int *virq) +static int ps3_virq_setup(enum ps3_cpu_binding cpu, unsigned long outlet, + unsigned int *virq) { int result; struct ps3_private *pd; @@ -217,7 +217,7 @@ fail_create: * Clears chip data and calls irq_dispose_mapping() for the virq. */ -int ps3_virq_destroy(unsigned int virq) +static int ps3_virq_destroy(unsigned int virq) { const struct ps3_private *pd = get_irq_chip_data(virq); --- a/include/asm-powerpc/ps3.h +++ b/include/asm-powerpc/ps3.h @@ -178,9 +178,6 @@ enum ps3_cpu_binding { PS3_BINDING_CPU_1 = 1, }; -int ps3_virq_setup(enum ps3_cpu_binding cpu, unsigned long outlet, - unsigned int *virq); -int ps3_virq_destroy(unsigned int virq); int ps3_irq_plug_setup(enum ps3_cpu_binding cpu, unsigned long outlet, unsigned int *virq); int ps3_irq_plug_destroy(unsigned int virq); -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 2.6.25-git] spi_mpc83xx much improved driver
On Wed, 30 Apr 2008 15:37:07 -0700 David Brownell [EMAIL PROTECTED] wrote: From: Joakim Tjernlund [EMAIL PROTECTED] Date: Fri, 11 Apr 2008 18:57:21 +0200 Subject: [PATCH] Much improved mpc83xx SPI driver. The current driver may cause glitches on SPI CLK line since one must disable the SPI controller before changing any HW settings. Fix this by implementing a local spi_transfer function that won't change speed and/or word size while CS is active. While doing that heavy lifting a few other issues were addressed too: - Make word size 16 and 32 work too. - Honor bits_per_word and speed_hz in spi transaction. - Optimize the common path. This also stops using the bitbang framework (except for a few constants). ... +static void mpc83xx_spi_work(struct work_struct *work) +{ + struct mpc83xx_spi *mpc83xx_spi = + container_of(work, struct mpc83xx_spi, work); + + spin_lock_irq(mpc83xx_spi-lock); irq-safe. ... + spin_lock(mpc83xx_spi-lock); not irq-safe. Deliberate? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 4/6] [POWERPC] QE: implement support for the GPIO LIB API
On Wed, Apr 30, 2008 at 02:42:03PM -0500, Timur Tabi wrote: Anton Vorontsov wrote: + Example: + qe_pio_a: [EMAIL PROTECTED] { + #gpio-cells = 2; + compatible = fsl,mpc8360-qe-pario-bank, +fsl,mpc8323-qe-pario-bank; I know this is an example, but would we ever include both compatible strings in one DTS? Isn't the norm something like: fsl,mpc8360-qe-pario-bank, fsl,qe-pario-bank; I.e. specific version, then generic version? Per Grant Likely's comments, fsl,qe-pario-bank considered as a made up stuff. MPC8323 is the first QE chip, so every next QE chips should be compatible. Though, for fsl,gtm we can't use this, since we really want generic name. Otherwise, every time we introduce a new QE part, we'll have to update *every* QE-enabled device tree *and* the QE gpio driver. Nope. If the the QE is compatible with the previous, just write fsl,newchip-qe-pario-bank, fsl,mpc8323-qe-pario-bank. Btw, the same we do for the 8349 compatible PCI. +static int qe_gpio_get(struct gpio_chip *gc, unsigned int gpio) +{ + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc); + struct qe_pio_regs __iomem *regs = mm_gc-regs; + u32 pin_mask = 1 (QE_PIO_PINS - 1 - gpio); + + return in_be32(regs-cpdata) pin_mask; +} Return value should be u32, not int. gpio.h disagree $ cat include/asm-generic/gpio.h | grep \*get int (*get)(struct gpio_chip *chip, -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 4/6] [POWERPC] QE: implement support for the GPIO LIB API
Anton Vorontsov wrote: Per Grant Likely's comments, fsl,qe-pario-bank considered as a made up stuff. MPC8323 is the first QE chip, so every next QE chips should be compatible. Ok. Return value should be u32, not int. gpio.h disagree $ cat include/asm-generic/gpio.h | grep \*get int (*get)(struct gpio_chip *chip, In that case, perhaps you should return this: return in_be32(regs-cpdata) pin_mask ? 1 : 0; -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 2.6.25-git] spi_mpc83xx much improved driver
On Wednesday 30 April 2008, Andrew Morton wrote: + spin_lock_irq(mpc83xx_spi-lock); irq-safe. ... + spin_lock(mpc83xx_spi-lock); not irq-safe. Deliberate? That latter one is inside an #if 0/#endif block, so it won't matter. The #if 0 block bothered me. Maybe Joakim can remove it. (By the way, I'd feel safer about this patch if there were an ack or two from more PPC folk...) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 4/6] [POWERPC] QE: implement support for the GPIO LIB API
On Wed, Apr 30, 2008 at 05:50:42PM -0500, Timur Tabi wrote: Anton Vorontsov wrote: Per Grant Likely's comments, fsl,qe-pario-bank considered as a made up stuff. MPC8323 is the first QE chip, so every next QE chips should be compatible. Ok. Return value should be u32, not int. gpio.h disagree $ cat include/asm-generic/gpio.h | grep \*get int (*get)(struct gpio_chip *chip, In that case, perhaps you should return this: return in_be32(regs-cpdata) pin_mask ? 1 : 0; What is the problem with returning (int)(u32 u32) value? You've asked to remove !! stuff and now purposing exactly the same... :-? -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] docbook: fix fatal rapidio yet again (and more to come)
On Thu, 1 May 2008 08:09:24 +1000 Paul Mackerras wrote: Andrew Morton writes: Odd. I thought Paul had picked up a docbook RapidIO patch from you in the latest merge round. Well it's more than a patch. The six-week-old patch series is: rapidio-add-memory-mapping-driver-to-rapidio.patch rapidio-add-rapidio-space-allocation-bitmap-arithmetic.patch rapidio-add-fsl-rapidio-controller-memory-ops-functions.patch rapidio-add-the-rapidio-master-port-maintance-and-doorbell-window-to-space-resources.patch rapidio-add-rapidio-proc-fs-for-memory-mapping-debugging.patch rapidio-add-the-memory-mapping-support-in-rionet-driver.patch rapidio-fix-docbook-references.patch rapidio-fix-kernel-doc-problems.patch What happened is that you (Andrew) sent them on to me pretty much unexamined. I took a look at them and dropped one of them because it created a new /proc file. I asked Kumar to look at them and he had issues with another three of the patches, and dropping those meant that all the following ones (including the fix-kernel-doc one) wouldn't apply, so I dropped them too. I applied the rest and sent them to Linus. (seems that I forgot to cc Jeff on the rionet change too). Yeah. I nearly dropped that one too. I probably should have. :) Oh well. If nobody puts their hand up in the next 24 hours or so I'll just send it all in to Linus. Please don't. At this stage I think the best thing is for Kumar to talk to Zhang Wei (they both work for Freescale, so that should be possible in theory :) and get him to rework the remaining patches as required for inclusion in 2.6.27. Just to be clear, the docbook changes shouldn't wait for 2.6.27. There's no need for that. --- ~Randy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/5] POWERPC: Fix slb.c compile warnings
On Wed, 2008-04-30 at 15:24 -0700, Geoff Levand wrote: Arrange for a syntax check to always be done on the powerpc/mm/slb.c DBG() macro by defining it to pr_debug() for non-debug builds. Also, fix these related compile warnings: slb.c:273: warning: format '%04x' expects type 'unsigned int', but argument 2 has type 'long unsigned int slb.c:274: warning: format '%04x' expects type 'unsigned int', but argument 2 has type 'long unsigned int' Signed-off-by: Geoff Levand [EMAIL PROTECTED] Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED] --- arch/powerpc/mm/slb.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/arch/powerpc/mm/slb.c +++ b/arch/powerpc/mm/slb.c @@ -30,7 +30,7 @@ #ifdef DEBUG #define DBG(fmt...) udbg_printf(fmt) #else -#define DBG(fmt...) +#define DBG pr_debug #endif extern void slb_allocate_realmode(unsigned long ea); @@ -279,8 +279,8 @@ void slb_initialize(void) patch_slb_encoding(slb_compare_rr_to_size, mmu_slb_size); - DBG(SLB: linear LLP = %04x\n, linear_llp); - DBG(SLB: io LLP = %04x\n, io_llp); + DBG(SLB: linear LLP = %04lx\n, linear_llp); + DBG(SLB: io LLP = %04lx\n, io_llp); } get_paca()-stab_rr = SLB_NUM_BOLTED; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
mucking with cputable ...
Hi, I'm trying to monkey with cputable. It is hanging after printing: Preparing BATs on the console (PowerMac 8600 with PowerLogix 750GX card, 2.6.24 YDL 4.0). I am guessing I am doing this PTRRELOC() thing wrong? Can someone explain what is going on here: *PTRRELOC(cur_cpu_spec) = the_cpu_spec; Up above both s and t needed reloccing? This is from identify_cpu(). Does this have something to do with data items in different sections (i.e. initdata)? I also welcome comments on where else the data I'm trying to graft into cputable might go (i.e. cpu_freq driver). Thanks! kevin --- cputable-old_c 2008-02-25 18:24:23.0 -0800 +++ cputable-new_c 2008-04-30 14:31:37.0 -0700 @@ -38,11 +38,13 @@ extern void __setup_cpu_604(unsigned long offset, struct cpu_spec* spec); extern void __setup_cpu_750(unsigned long offset, struct cpu_spec* spec); extern void __setup_cpu_750cx(unsigned long offset, struct cpu_spec* spec); extern void __setup_cpu_750fx(unsigned long offset, struct cpu_spec* spec); +extern void __setup_cpu_750gx(unsigned long offset, struct cpu_spec* spec); extern void __setup_cpu_7400(unsigned long offset, struct cpu_spec* spec); extern void __setup_cpu_7410(unsigned long offset, struct cpu_spec* spec); extern void __setup_cpu_745x(unsigned long offset, struct cpu_spec* spec); + #endif /* CONFIG_PPC32 */ #ifdef CONFIG_PPC64 extern void __setup_cpu_ppc970(unsigned long offset, struct cpu_spec* spec); extern void __setup_cpu_ppc970MP(unsigned long offset, struct cpu_spec* spec); @@ -70,8 +72,25 @@ PPC_FEATURE_HAS_ALTIVEC_COMP) #define COMMON_USER_BOOKE (PPC_FEATURE_32 | PPC_FEATURE_HAS_MMU | \ PPC_FEATURE_BOOKE) +#ifdef CONFIG_PPC32 +static struct ppc_misc_750fgx __initdata ppc_misc_750fx={ + .misc_cp=ppc_misc_cp_750fgx, + .min_ratio=2, /* min bus ratio */ + .max_ratio=20, /* max bus ratio */ + .min_core=40, /* min core frequency per spec */ + .max_core=80, /* max core frequency per spec */ +}; +static struct ppc_misc_750fgx __initdata ppc_misc_750gx={ + .misc_cp=ppc_misc_cp_750fgx, + .min_ratio=2, /* min bus ratio */ + .max_ratio=20, /* max bus ratio */ + .min_core=50, /* min core frequency per spec */ + .max_core=100, /* max core frequency per spec */ +}; +#endif /* CONFIG_PPC32 */ + static struct cpu_spec __initdata cpu_specs[] = { #ifdef CONFIG_PPC64 { /* Power3 */ .pvr_mask = 0x, @@ -590,8 +609,9 @@ .icache_bsize = 32, .dcache_bsize = 32, .num_pmcs = 4, .cpu_setup = __setup_cpu_750, + .misc = (void *) ppc_misc_750fx, .platform = ppc750, }, { /* 750FX rev 2.0 must disable HID0[DPM] */ .pvr_mask = 0x, @@ -602,8 +622,9 @@ .icache_bsize = 32, .dcache_bsize = 32, .num_pmcs = 4, .cpu_setup = __setup_cpu_750, + .misc = (void *) ppc_misc_750fx, .platform = ppc750, }, { /* 750FX (All revs except 2.0) */ .pvr_mask = 0x, @@ -614,20 +635,48 @@ .icache_bsize = 32, .dcache_bsize = 32, .num_pmcs = 4, .cpu_setup = __setup_cpu_750fx, + .misc = (void *) ppc_misc_750fx, .platform = ppc750, }, - { /* 750GX */ + { /* 750GX rev 1.x */ .pvr_mask = 0x, .pvr_value = 0x7002, .cpu_name = 750GX, .cpu_features = CPU_FTRS_750GX, .cpu_user_features = COMMON_USER | PPC_FEATURE_PPC_LE, .icache_bsize = 32, .dcache_bsize = 32, .num_pmcs = 4, - .cpu_setup = __setup_cpu_750fx, + .cpu_setup = __setup_cpu_750gx, + .misc = (void *) ppc_misc_750gx, + .platform = ppc750, + }, + { /* 750GX (rev 2.3, as used on PowerLogix 750GX upgrade card */ + .pvr_mask = 0x, + .pvr_value = 0x00080203, + .cpu_name = 750GX, + .cpu_features = CPU_FTRS_750GX, + .cpu_user_features =
Re: [PATCH 1/7] Implement arch disable/enable irq hooks.
Guennadi Liakhovetski writes: The patch (with the _TLF_SLEEPING fix you mentioned in a later email) works for me. Great, thanks. 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? I'll post it as a stand-alone patch with my S-o-b. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: drivers/net/fec_8xx config problem
On Wednesday 2008-04-30 21:23, Scott Wood wrote: On Apr 30, 2008, at 2:20 PM, Scott Wood wrote: On Wed, Apr 30, 2008 at 02:19:21PM -0500, Becky Bruce wrote: I just noticed that the fec_8xx driver is not currently reachable via menuconfig because it depends on 8XX instead of 8xx. [snip] Since nobody has noticed this problem, I'm wondering if this driver is still in (infrequent) use, or if it's been superseded and should be removed, or if I'm just completely missing something with respect to the use of 8XX instead of 8xx. Blame those developers who had the brilliant idea of using lowercase in kconfig symbols (these things emit cosmic particles en masse!) :-) arch/arm/mach-pxa/Kconfig:config PXA3xx ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 4/6] [POWERPC] QE: implement support for the GPIO LIB API
On Wed, Apr 30, 2008 at 06:03:45PM -0500, Timur Tabi wrote: Anton Vorontsov wrote: What is the problem with returning (int)(u32 u32) value? Technically, a signed int is smaller than an unsigned int, so a value of 0x8000 won't fit in an 'int'. They're of the same size. And because of that, we'll not lose information, so (int)(0x8000U) still != 0, it is just negative. You've asked to remove !! stuff and now purposing exactly the same... :-? The !! stuff was because the function was returning a boolean value, so non-zero == TRUE. I don't think the return value from 'get' is a technically a boolean, so I'm assuming that the spec says the return value should be 0 or 1, to reflect the value of that GPIO pin. No. The spec indeed says that 0 for low, non-0 for high. -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Rework EXC_LEVEL_EXCEPTION_PROLOG code
On Apr 30, 2008, at 5:22 PM, Benjamin Herrenschmidt wrote: On Wed, 2008-04-30 at 17:13 -0500, Kumar Gala wrote: If we don't handle reschedule or signal will we actually not function properly? I assume reschedule isn't an issue, but could we lose a signal? Well, you can be in trouble if you lose TIF_SIGPENDING. You don't - have- to actually take the signal, it will then be done on the next return to userspace (next timer interrupt, next syscall, ...), but TIF_SIGPENDING must not be lost. Interesting. It seems like causing a signal from an async interrupt from kernel space shouldn't be allowed. At worse we can store back the flags into the real thread_info. Nothing specific to your patch, but those level##_STACK_TOP seem to be pretty badly named if you end up -adding- THREAD_SIZE to actually get to the stack's top. Do they really contain the stack top or do they in fact contain the stack base/bottom ? That might be stale from how the old code worked. I can never remember what we consider the top and bottom of the stack. (please remind me and I'll fixup the comments and variables). Well, top is the high address and bottom is the low address in my view of things :-) yeah, so we are now pointing to stack bottom. will fix this up. I thought about that. The only case its a bit of an issue is for CriticalInput. I don't see Watchdog, Debug, or MachineCheck as being performance critical. I can use r10 if I save and restored the CR or some other register. You can save CR first yeah and then interleave a bit using 2 registers (ie. 2 loads, 2 stores, or something like load 1, load 2, store 1, load 3, store 2, etc...) Ok, will look at that. just leaving it to C code. I assume that preempt_count should be the same value on entry and exit. Do think we should set HARDIRQ_OFFSET for debug level exceptions? Well... I think all those things should run with EE disabled, and thus be considered as far as linux is concerned, as interrupts. So the C code should do irq_enter/exit. I agree we run all these interrupt levels with EE disabled. Not sure I follow what you mean by irq_enter/ext. Where should I look for an example of how to convey that information to lockdep? The irqtrace stuff in the asm would do maybe unless transfer_to_handler does it already, I have to look at the code with all your patches applied... ok. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] rapidio: fix current kernel-doc notation
From: Randy Dunlap [EMAIL PROTECTED] Fix current (-git16) missing docbook/kernel-doc notation in RapidIO files. Warning(linux-2.6.25-git16//include/linux/rio.h:187): No description found for parameter 'sys_size' Warning(linux-2.6.25-git16//include/linux/rio.h:187): No description found for parameter 'phy_type' Warning(linux-2.6.25-git16//arch/powerpc/sysdev/fsl_rio.c:188): No description found for parameter 'mport' Warning(linux-2.6.25-git16//arch/powerpc/sysdev/fsl_rio.c:224): No description found for parameter 'mport' Warning(linux-2.6.25-git16//arch/powerpc/sysdev/fsl_rio.c:245): No description found for parameter 'mport' Warning(linux-2.6.25-git16//arch/powerpc/sysdev/fsl_rio.c:270): No description found for parameter 'mport' Warning(linux-2.6.25-git16//arch/powerpc/sysdev/fsl_rio.c:311): No description found for parameter 'mport' Warning(linux-2.6.25-git16//arch/powerpc/sysdev/fsl_rio.c:996): No description found for parameter 'dev' Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- arch/powerpc/sysdev/fsl_rio.c |9 +++-- include/linux/rio.h |2 ++ 2 files changed, 9 insertions(+), 2 deletions(-) --- linux-2.6.25-git16.orig/include/linux/rio.h +++ linux-2.6.25-git16/include/linux/rio.h @@ -161,6 +161,8 @@ enum rio_phy_type { * @ops: configuration space functions * @id: Port ID, unique among all ports * @index: Port index, unique among all port interfaces of the same type + * @sys_size: RapidIO common transport system size + * @phy_type: RapidIO phy type * @name: Port name string * @priv: Master port private data */ --- linux-2.6.25-git16.orig/arch/powerpc/sysdev/fsl_rio.c +++ linux-2.6.25-git16/arch/powerpc/sysdev/fsl_rio.c @@ -176,6 +176,7 @@ struct rio_priv { /** * fsl_rio_doorbell_send - Send a MPC85xx doorbell message + * @mport: RapidIO master port info * @index: ID of RapidIO interface * @destid: Destination ID of target device * @data: 16-bit info field of RapidIO doorbell message @@ -211,6 +212,7 @@ static int fsl_rio_doorbell_send(struct /** * fsl_local_config_read - Generate a MPC85xx local config space read + * @mport: RapidIO master port info * @index: ID of RapdiIO interface * @offset: Offset into configuration space * @len: Length (in bytes) of the maintenance transaction @@ -232,6 +234,7 @@ static int fsl_local_config_read(struct /** * fsl_local_config_write - Generate a MPC85xx local config space write + * @mport: RapidIO master port info * @index: ID of RapdiIO interface * @offset: Offset into configuration space * @len: Length (in bytes) of the maintenance transaction @@ -254,6 +257,7 @@ static int fsl_local_config_write(struct /** * fsl_rio_config_read - Generate a MPC85xx read maintenance transaction + * @mport: RapidIO master port info * @index: ID of RapdiIO interface * @destid: Destination ID of transaction * @hopcount: Number of hops to target device @@ -295,6 +299,7 @@ fsl_rio_config_read(struct rio_mport *mp /** * fsl_rio_config_write - Generate a MPC85xx write maintenance transaction + * @mport: RapidIO master port info * @index: ID of RapdiIO interface * @destid: Destination ID of transaction * @hopcount: Number of hops to target device @@ -985,8 +990,8 @@ static inline void fsl_rio_info(struct d } /** - * fsl_rio_setup - Setup MPC85xx RapidIO interface - * @fsl_rio_setup - Setup Freescale PowerPC RapidIO interface + * fsl_rio_setup - Setup Freescale PowerPC RapidIO interface + * @dev: of_device pointer * * Initializes MPC85xx RapidIO hardware interface, configures * master port with system-specific info, and registers the ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Rework EXC_LEVEL_EXCEPTION_PROLOG code
On Wed, 2008-04-30 at 18:28 -0500, Kumar Gala wrote: Well, you can be in trouble if you lose TIF_SIGPENDING. You don't - have- to actually take the signal, it will then be done on the next return to userspace (next timer interrupt, next syscall, ...), but TIF_SIGPENDING must not be lost. Interesting. It seems like causing a signal from an async interrupt from kernel space shouldn't be allowed. At worse we can store back the flags into the real thread_info. Why shouldn't it be allowed ? We do store back flags in the real thread info when doing irqstacks... though I just noticed we don't do that for softirqs... paulus, isn't there a chance that we may lose a signal there ? I wouldn't expect softirq's to often send signals to current thread info (ie, they would use targetted flag sending which means the SIGPENDING flag will be set in the right thread_info obtained from the target task struct) but it still sounds safer to copy the flags back just in case... yeah, so we are now pointing to stack bottom. will fix this up. Call it base rather than bottom, sounds nicer :-) I agree we run all these interrupt levels with EE disabled. Not sure I follow what you mean by irq_enter/ext. That should do the right thing with preempt_count(), look at do_IRQ(). Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v4] sysdev,mv64x60: MV64x60 device bus
Hi Remi, On Wed, 30 Apr 2008 09:47:16 -0700 Remi Machet [EMAIL PROTECTED] wrote: For each mv64360 entry in the OpenFirmware database, add the registration of an of_bus to take care of devices connected to the MV64x60 asynchronous devices controller. This change makes it possible for those devices to be detected by drivers that support the of_platform without having a custom call for each of them in the board file. Signed-off-by: Remi Machet ([EMAIL PROTECTED]) You really should use '' and '' to surround your email address. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgp63V3GJNKpZ.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro
On Wed, 2008-04-30 at 18:45 -0500, Josh Boyer wrote: thanks. Will take a look. I just plan on overloading MMUCR with MAS0. Erg. Why? Please don't do that. This is common code and MAS0 doesn't make much sense on 4xx. It'll be confusing to anyone that isn't aware of this change. Nah, he meant using the slot for MAS0 in the exception frame structure as to not have to define two different structures I suppose... Can we come up with a generic #define that gets used instead? josh Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro
On Thu, 01 May 2008 09:53:22 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Wed, 2008-04-30 at 18:45 -0500, Josh Boyer wrote: thanks. Will take a look. I just plan on overloading MMUCR with MAS0. Erg. Why? Please don't do that. This is common code and MAS0 doesn't make much sense on 4xx. It'll be confusing to anyone that isn't aware of this change. Nah, he meant using the slot for MAS0 in the exception frame structure as to not have to define two different structures I suppose... Ah, ok. Sorry, still playing catch up on email. I thought we were talking about a #define. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v4] sysdev,mv64x60: MV64x60 device bus
Yes, I am sorry. I will post another patch in a few minutes ... Remi On Thu, 2008-05-01 at 09:54 +1000, Stephen Rothwell wrote: Hi Remi, On Wed, 30 Apr 2008 09:47:16 -0700 Remi Machet [EMAIL PROTECTED] wrote: For each mv64360 entry in the OpenFirmware database, add the registration of an of_bus to take care of devices connected to the MV64x60 asynchronous devices controller. This change makes it possible for those devices to be detected by drivers that support the of_platform without having a custom call for each of them in the board file. Signed-off-by: Remi Machet ([EMAIL PROTECTED]) You really should use '' and '' to surround your email address. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] devres: Add devm_ioremap_flags()
Kumar Gala wrote: From: Emil Medve [EMAIL PROTECTED] We provide an ioremap_flags so provide a coresphonding devm_ioremap_flags. Signed-off-by: Emil Medve [EMAIL PROTECTED] Signed-off-by: Kumar Gala [EMAIL PROTECTED] Acked-by: Tejun Heo [EMAIL PROTECTED] -- tejun ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v5] sysdev,mv64x60: MV64x60 device bus
For each mv64360 entry in the OpenFirmware database, add the registration of an of_bus to take care of devices connected to the MV64x60 asynchronous devices controller. This change makes it possible for those devices to be detected by drivers that support the of_platform without having a custom call for each of them in the board file. Signed-off-by: Remi Machet [EMAIL PROTECTED] --- Changes: v2: Use the compatible field to detect devices to register (on Dale Farnsworth suggestion). v3: Added __initdata to variable of_mv64x60_devices (thanks to Stephen Rothwell for pointing that out). v4: Re-wrote the patch description. v5: Changed the format of the email address arch/powerpc/sysdev/mv64x60_dev.c | 10 ++ 1 files changed, 10 insertions(+) diff --git a/arch/powerpc/sysdev/mv64x60_dev.c b/arch/powerpc/sysdev/mv64x60_dev.c index 41af122..c38695e 100644 --- a/arch/powerpc/sysdev/mv64x60_dev.c +++ b/arch/powerpc/sysdev/mv64x60_dev.c @@ -15,6 +15,7 @@ #include linux/console.h #include linux/mv643xx.h #include linux/platform_device.h +#include linux/of_platform.h #include asm/prom.h @@ -25,6 +26,11 @@ * PowerPC of_platform_bus_type. They support platform_bus_type instead. */ +static struct of_device_id __initdata of_mv64x60_devices[] = { + { .compatible = marvell,mv64306-devctrl, }, + {} +}; + /* * Create MPSC platform devices */ @@ -482,6 +488,10 @@ static int __init mv64x60_device_setup(void) of_node_put(np); } + /* Now add every node that is on the device bus */ + for_each_compatible_node(np, NULL, marvell,mv64360) + of_platform_bus_probe(np, of_mv64x60_devices, NULL); + return 0; } arch_initcall(mv64x60_device_setup); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro
On Wed, 2008-04-30 at 19:11 -0500, Josh Boyer wrote: Nah, he meant using the slot for MAS0 in the exception frame structure as to not have to define two different structures I suppose... Ah, ok. Sorry, still playing catch up on email. I thought we were talking about a #define. Heh, now that I think about it ... maybe :-) That would be bad indeed. Kumar ? Cheers Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] [POWERPC] devres: Add devm_ioremap_flags()
On Wed, 30 Apr 2008 11:08:51 -0500 (CDT) Kumar Gala [EMAIL PROTECTED] wrote: +++ b/arch/powerpc/lib/devres.c @@ -0,0 +1,33 @@ +#include linux/device.h/* devres_*(), devm_ioremap_release() */ +#include linux/io.h/* ioremap_flags() */ +#include linux/module.h/* EXPORT_SYMBOL() */ This file needs a copyright notice and license ... -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpYkxHu6jSfm.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] [POWERPC] devres: Add devm_ioremap_flags()
On Apr 30, 2008, at 8:18 PM, Stephen Rothwell wrote: On Wed, 30 Apr 2008 11:08:51 -0500 (CDT) Kumar Gala [EMAIL PROTECTED] wrote: +++ b/arch/powerpc/lib/devres.c @@ -0,0 +1,33 @@ +#include linux/device.h/* devres_*(), devm_ioremap_release() */ +#include linux/io.h/* ioremap_flags() */ +#include linux/module.h/* EXPORT_SYMBOL() */ This file needs a copyright notice and license ... agreed. will add. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro
On Apr 30, 2008, at 7:48 PM, Benjamin Herrenschmidt wrote: On Wed, 2008-04-30 at 19:11 -0500, Josh Boyer wrote: Nah, he meant using the slot for MAS0 in the exception frame structure as to not have to define two different structures I suppose... Ah, ok. Sorry, still playing catch up on email. I thought we were talking about a #define. Heh, now that I think about it ... maybe :-) That would be bad indeed. Kumar ? I'll alias the slot. Similiar to how we use _ESR - for dsisr Something like this will be added in asm-offset.c: DEFINE(MMUCR, STACK_INT_FRAME_SIZE+offsetof(struct exception_regs, mas0)); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 2/5] PS3: Add time include to lpm
On Wed, 30 Apr 2008 15:25:09 -0700 Geoff Levand [EMAIL PROTECTED] wrote: From: FUJITA Tomonori [EMAIL PROTECTED] Add an include asm/time.h statement for get_tb(). Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] Signed-off-by: Geoff Levand [EMAIL PROTECTED] --- drivers/ps3/ps3-lpm.c:192: error: implicit declaration of function 'get_tb' I could not recreate this error. asm/time.h seems to be included from linux/module.h: In file included from include2/asm/cputime.h:27, Seems that if VIRT_CPU_ACCOUNTING is disabled, asm/time.h is not included here. from /home/geoff/projects/cell/linux-2.6/include/linux/sched.h:67, from include2/asm/elf.h:6, from /home/geoff/projects/cell/linux-2.6/include/linux/elf.h:8, from /home/geoff/projects/cell/linux-2.6/include/linux/module.h:15, from /home/geoff/projects/cell/linux-2.6/drivers/ps3/ps3-lpm.c:24: include2/asm/time.h:134 drivers/ps3/ps3-lpm.c |1 + 1 file changed, 1 insertion(+) --- a/drivers/ps3/ps3-lpm.c +++ b/drivers/ps3/ps3-lpm.c @@ -22,6 +22,7 @@ #include linux/module.h #include linux/interrupt.h #include linux/uaccess.h +#include asm/time.h #include asm/ps3.h #include asm/lv1call.h #include asm/cell-pmu.h -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev