Re: [PATCH v2 1/2] powerpc/8xx: Fix NR_IRQ bugs and refactor 8xx interrupt controller
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 2012/04/24 05:13:15: On Mon, 2012-04-23 at 16:30 -0600, Grant Likely wrote: The mpc8xx driver uses a reference to NR_IRQS that is buggy. It uses NR_IRQs for the array size of the ppc_cached_irq_mask bitmap, but NR_IRQs could be smaller than the number of hardware irqs that ppc_cached_irq_mask tracks. Joakim, any chance you can test this ASAP ? :-) Sorry, but no. We have not moved our 8xx boards to 3.x as it in maintenance and takes too much space. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/2] powerpc/8xx: Fix NR_IRQ bugs and refactor 8xx interrupt controller
On Tue, 2012-04-24 at 09:41 +0200, Joakim Tjernlund wrote: Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 2012/04/24 05:13:15: On Mon, 2012-04-23 at 16:30 -0600, Grant Likely wrote: The mpc8xx driver uses a reference to NR_IRQS that is buggy. It uses NR_IRQs for the array size of the ppc_cached_irq_mask bitmap, but NR_IRQs could be smaller than the number of hardware irqs that ppc_cached_irq_mask tracks. Joakim, any chance you can test this ASAP ? :-) Sorry, but no. We have not moved our 8xx boards to 3.x as it in maintenance and takes too much space. Ah ok... Anybody else on the list who still has some 8xx gear ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Mon, 2012-04-23 at 18:45 +0200, Gerhard Pircher wrote: Von: Michel Dänzer mic...@daenzer.net On Fre, 2012-04-20 at 18:14 +0200, Gerhard Pircher wrote: Von: Michel Dänzer mic...@daenzer.net On Fre, 2012-04-20 at 13:15 +0200, Gerhard Pircher wrote: What I didn't understand yet is how this uncacheable memory is allocated (well, I never took the time to look at this again). The functions in ttm_page_alloc.c seem to allocate normal cacheable memory and try to set the page flags with set_pages_array_uc(), which is more or less a no-op on powerpc. ttm_page_alloc_dma.c on the other side is only used with SWIOTLB!? [...] Could it be that the memory is finally mapped uncacheable by radeon_bo_kmap()/ ttm_bo_kmap()/..some other TTM functions../vmap()? Yeah, AFAICT, basically ttm_io_prot() defines the mapping attributes, and vmap() is used to enforce them for kernel mappings. Okay, that sounds like the approach used by arch/powerpc/mm/dma- noncoherent.c in my (green) ears. What about the PCIGART mode? Is the driver free to use cached memory in this mode? Yes, it assumes PCI(e) GART to be CPU cache coherent. Okay. I guess it should be possible to modify it so that it makes use of uncacheable memory - just for testing!? Sure. Just set man-available_caching and man-default_caching as in the AGP case in radeon_init_mem_type(). PCIGART was working somehow on my platform up to the ~2.6.39 kernel, i.e. I could login to GNOME and open a program until the machine locked-up. :-) But it's worse with newer kernels? BTW: I see that the uninorth driver defines needs_scratch_page. What is this actually good for? It causes the code in drivers/char/agp/backend.c to allocate a scratch page (bridge-scratch_page) which the driver can use for unused GART entries. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
Original-Nachricht Datum: Tue, 24 Apr 2012 16:15:00 +0200 Von: Michel Dänzer mic...@daenzer.net An: Gerhard Pircher gerhard_pirc...@gmx.net CC: linuxppc-dev@lists.ozlabs.org Betreff: Re: PowerPC radeon KMS - is it possible? On Mon, 2012-04-23 at 18:45 +0200, Gerhard Pircher wrote: Von: Michel Dänzer mic...@daenzer.net On Fre, 2012-04-20 at 18:14 +0200, Gerhard Pircher wrote: Von: Michel Dänzer mic...@daenzer.net [...] Could it be that the memory is finally mapped uncacheable by radeon_bo_kmap()/ttm_bo_kmap()/..some other TTM functions../vmap()? Yeah, AFAICT, basically ttm_io_prot() defines the mapping attributes, and vmap() is used to enforce them for kernel mappings. Okay, that sounds like the approach used by arch/powerpc/mm/dma- noncoherent.c in my (green) ears. What about the PCIGART mode? Is the driver free to use cached memory in this mode? Yes, it assumes PCI(e) GART to be CPU cache coherent. Okay. I guess it should be possible to modify it so that it makes use of uncacheable memory - just for testing!? Sure. Just set man-available_caching and man-default_caching as in the AGP case in radeon_init_mem_type(). Thanks for the info! I'll play around with it. PCIGART was working somehow on my platform up to the ~2.6.39 kernel, i.e. I could login to GNOME and open a program until the machine locked-up. :-) But it's worse with newer kernels? Yes, it's worse. But that's surely the fault of the buggy northbridge. I believe the bridge doesn't like some of the code that the driver uses to avoid ordering issues. But I still have to find out where the lockups exactly happen. BTW: I see that the uninorth driver defines needs_scratch_page. What is this actually good for? It causes the code in drivers/char/agp/backend.c to allocate a scratch page (bridge-scratch_page) which the driver can use for unused GART entries. Okay, so it would make sense to set this for my platform's AGP bridge, which doesn't seem to support a GATT entry valid bit. Gerhard -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [EDAC ABI v13 24/25] edac: change the mem allocation scheme to make Documentation/kobject.txt happy
On Thu, 2012-04-19 at 10:14 -0300, Mauro Carvalho Chehab wrote: diff --git a/drivers/edac/edac_mc.c b/drivers/edac/edac_mc.c [] @@ -296,7 +296,7 @@ struct mem_ctl_info *edac_mc_alloc(unsigned edac_index, /* * Alocate and fill the csrow/channels structs */ - mci-csrows = kzalloc(sizeof(*mci-csrows) * tot_csrows, GFP_KERNEL); + mci-csrows = kcalloc(sizeof(*mci-csrows), tot_csrows, GFP_KERNEL); trivia: the first 2 args to kcalloc should be swapped. static inline void *kcalloc(size_t n, size_t size, gfp_t flags) kcalloc(tot_csrows, sizeof(*mci-csrows), GFP_KERNEL); [] @@ -307,7 +307,7 @@ struct mem_ctl_info *edac_mc_alloc(unsigned edac_index, csr-csrow_idx = row; csr-mci = mci; csr-nr_channels = tot_cschannels; - csr-channels = kzalloc(sizeof(*csr-channels) * tot_cschannels, + csr-channels = kcalloc(sizeof(*csr-channels), tot_cschannels, and here. [] @@ -323,7 +323,7 @@ struct mem_ctl_info *edac_mc_alloc(unsigned edac_index, /* * Allocate and fill the dimm structs */ - mci-dimms = kzalloc(sizeof(*mci-dimms) * tot_dimms, GFP_KERNEL); + mci-dimms = kcalloc(sizeof(*mci-dimms), tot_dimms, GFP_KERNEL); and here too. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH EDACv16 1/2] edac: Change internal representation to work with layers
Change the EDAC internal representation to work with non-csrow based memory controllers. There are lots of those memory controllers nowadays, and more are coming. So, the EDAC internal representation needs to be changed, in order to work with those memory controllers, while preserving backward compatibility with the old ones. The edac core were written with the idea that memory controllers are able to directly access csrows, and that the channels are used inside a csrows select. This is not true for FB-DIMM and RAMBUS memory controllers. Also, some recent advanced memory controllers don't present a per-csrows view. Instead, they view memories as DIMM's, instead of ranks, accessed via csrow/channel. So, change the allocation and error report routines to allow them to work with all types of architectures. This will allow the removal of several hacks on FB-DIMM and RAMBUS memory controllers on the next patches. Also, several tests were done on different platforms using different x86 drivers. TODO: a multi-rank DIMM's are currently represented by multiple DIMM entries at struct dimm_info. That means that changing a label for one rank won't change the same label for the other ranks at the same dimm. Such bug is there since the beginning of the EDAC, so it is not a big deal. However, on several drivers, it is possible to fix this issue, but it should be a per-driver fix, as the csrow = DIMM arrangement may not be equal for all. So, don't try to fix it here yet. PS.: I tried to make this patch as short as possible, preceding it with several other patches that simplified the logic here. Yet, as the internal API changes, all drivers need changes. The changes are generally bigger on the drivers for FB-DIMM's. FIXME: while the FB-DIMMs are not converted to use the new design, uncorrected errors will show just one channel. In the past, all changes were on a big patch with about 150K. As it needed to be split, in order to be accepted by the EDAC ML at vger, we've opted to have this small drawback. As an advantage, it is now easier to review the patch series. Cc: Aristeu Rozanski aroza...@redhat.com Cc: Doug Thompson nor...@yahoo.com Cc: Borislav Petkov borislav.pet...@amd.com Cc: Mark Gross mark.gr...@intel.com Cc: Jason Uhlenkott juhle...@akamai.com Cc: Tim Small t...@buttersideup.com Cc: Ranganathan Desikan r...@jetztechnologies.com Cc: Arvind R. arvin...@gmail.com Cc: Olof Johansson o...@lixom.net Cc: Egor Martovetsky e...@pasemi.com Cc: Chris Metcalf cmetc...@tilera.com Cc: Michal Marek mma...@suse.cz Cc: Jiri Kosina jkos...@suse.cz Cc: Joe Perches j...@perches.com Cc: Dmitry Eremin-Solenikov dbarysh...@gmail.com Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Hitoshi Mitake h.mit...@gmail.com Cc: Andrew Morton a...@linux-foundation.org Cc: Niklas Söderlund niklas.soderl...@ericsson.com Cc: Shaohui Xie shaohui@freescale.com Cc: Josh Boyer jwbo...@gmail.com Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- v16: Only context changes drivers/edac/edac_core.h | 92 ++- drivers/edac/edac_mc.c | 682 -- include/linux/edac.h | 40 ++- 3 files changed, 526 insertions(+), 288 deletions(-) diff --git a/drivers/edac/edac_core.h b/drivers/edac/edac_core.h index e48ab31..7201bb1 100644 --- a/drivers/edac/edac_core.h +++ b/drivers/edac/edac_core.h @@ -447,8 +447,13 @@ static inline void pci_write_bits32(struct pci_dev *pdev, int offset, #endif /* CONFIG_PCI */ -extern struct mem_ctl_info *edac_mc_alloc(unsigned sz_pvt, unsigned nr_csrows, - unsigned nr_chans, int edac_index); +struct mem_ctl_info *edac_mc_alloc(unsigned sz_pvt, unsigned nr_csrows, + unsigned nr_chans, int edac_index); +struct mem_ctl_info *new_edac_mc_alloc(unsigned edac_index, + unsigned n_layers, + struct edac_mc_layer *layers, + bool rev_order, + unsigned sz_pvt); extern int edac_mc_add_mc(struct mem_ctl_info *mci); extern void edac_mc_free(struct mem_ctl_info *mci); extern struct mem_ctl_info *edac_mc_find(int idx); @@ -467,24 +472,80 @@ extern int edac_mc_find_csrow_by_page(struct mem_ctl_info *mci, * reporting logic and function interface - reduces conditional * statement clutter and extra function arguments. */ -extern void edac_mc_handle_ce(struct mem_ctl_info *mci, + +void edac_mc_handle_error(const enum hw_event_mc_err_type type, + struct mem_ctl_info *mci, + const unsigned long page_frame_number, + const unsigned long offset_in_page, + const unsigned long syndrome, + const int layer0, + const int layer1, + const int
Re: [PATCH v2 1/2] powerpc/8xx: Fix NR_IRQ bugs and refactor 8xx interrupt controller
On 04/24/2012 06:22 AM, Benjamin Herrenschmidt wrote: On Tue, 2012-04-24 at 09:41 +0200, Joakim Tjernlund wrote: Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 2012/04/24 05:13:15: On Mon, 2012-04-23 at 16:30 -0600, Grant Likely wrote: The mpc8xx driver uses a reference to NR_IRQS that is buggy. It uses NR_IRQs for the array size of the ppc_cached_irq_mask bitmap, but NR_IRQs could be smaller than the number of hardware irqs that ppc_cached_irq_mask tracks. Joakim, any chance you can test this ASAP ? :-) Sorry, but no. We have not moved our 8xx boards to 3.x as it in maintenance and takes too much space. Ah ok... Anybody else on the list who still has some 8xx gear ? Boots OK on ep88xc. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Regression in 32-bit ppc kernel
Hi, Somewhere between v3.2 and v3.3, the kernel in my Powerbook G4 started issuing the following traceback on bootup: [ 40.264006] irq 23: nobody cared (try booting with the irqpoll option) [ 40.264031] Call Trace: [ 40.264070] [dfff3f00] [c000984c] show_stack+0x7c/0x194 (unreliable) [ 40.264102] [dfff3f40] [c00a6840] __report_bad_irq+0x44/0xf4 [ 40.264119] [dfff3f60] [c00a6adc] note_interrupt+0x1ec/0x2ac [ 40.264135] [dfff3f80] [c00a48a8] handle_irq_event_percpu+0x250/0x2b8 [ 40.264152] [dfff3fd0] [c00a4944] handle_irq_event+0x34/0x54 [ 40.264169] [dfff3fe0] [c00a7514] handle_fasteoi_irq+0xb4/0x124 [ 40.264192] [dfff3ff0] [c000f5bc] call_handle_irq+0x18/0x28 [ 40.264208] [dec85ce0] [c000719c] do_IRQ+0x114/0x1cc [ 40.264226] [dec85d10] [c0015868] ret_from_except+0x0/0x1c [ 40.264254] --- Exception: 501 at find_vma+0x10/0x80 [ 40.264259] LR = do_page_fault+0x26c/0x6ac [ 40.264272] [dec85dd0] [c03f0128] do_page_fault+0x25c/0x6ac (unreliable) [ 40.264289] [dec85f40] [c00155e4] handle_page_fault+0xc/0x80 [ 40.264327] --- Exception: 301 at 0x4800a174 The problem still exists in v3.4-rc3. I am currently doing a bisection of this problem, but it will take a long time to complete. Note: IRQ 23 is not active in v3.2. Thanks, Larry ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Regression in 32-bit ppc kernel
On Tue, 2012-04-24 at 17:58 -0500, Larry Finger wrote: Hi, Somewhere between v3.2 and v3.3, the kernel in my Powerbook G4 started issuing the following traceback on bootup: Does it continue working afterward or not at all ? Are you using the old IDE driver or the newer libata based pata_macio ? Cheers, Ben. [ 40.264006] irq 23: nobody cared (try booting with the irqpoll option) [ 40.264031] Call Trace: [ 40.264070] [dfff3f00] [c000984c] show_stack+0x7c/0x194 (unreliable) [ 40.264102] [dfff3f40] [c00a6840] __report_bad_irq+0x44/0xf4 [ 40.264119] [dfff3f60] [c00a6adc] note_interrupt+0x1ec/0x2ac [ 40.264135] [dfff3f80] [c00a48a8] handle_irq_event_percpu+0x250/0x2b8 [ 40.264152] [dfff3fd0] [c00a4944] handle_irq_event+0x34/0x54 [ 40.264169] [dfff3fe0] [c00a7514] handle_fasteoi_irq+0xb4/0x124 [ 40.264192] [dfff3ff0] [c000f5bc] call_handle_irq+0x18/0x28 [ 40.264208] [dec85ce0] [c000719c] do_IRQ+0x114/0x1cc [ 40.264226] [dec85d10] [c0015868] ret_from_except+0x0/0x1c [ 40.264254] --- Exception: 501 at find_vma+0x10/0x80 [ 40.264259] LR = do_page_fault+0x26c/0x6ac [ 40.264272] [dec85dd0] [c03f0128] do_page_fault+0x25c/0x6ac (unreliable) [ 40.264289] [dec85f40] [c00155e4] handle_page_fault+0xc/0x80 [ 40.264327] --- Exception: 301 at 0x4800a174 The problem still exists in v3.4-rc3. I am currently doing a bisection of this problem, but it will take a long time to complete. Note: IRQ 23 is not active in v3.2. Thanks, Larry ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
3.4-rc3 compile failed on IBM Power6
# gcc --version gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3) Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. platform: pSeries model: IBM,9117-MMA machine: CHRP IBM,9117-MMA # make O=../build/3.4-rc4/ GEN /usr/src/kernels/build/3.4-rc4/Makefile HOSTLD scripts/kconfig/conf scripts/kconfig/conf --silentoldconfig Kconfig Using /usr/src/kernels/linux as source for kernel GEN /usr/src/kernels/build/3.4-rc4/Makefile WRAParch/powerpc/include/generated/asm/rwsem.h CHK include/linux/version.h UPD include/linux/version.h CHK include/generated/utsrelease.h UPD include/generated/utsrelease.h CC kernel/bounds.s GEN include/generated/bounds.h CC arch/powerpc/kernel/asm-offsets.s GEN include/generated/asm-offsets.h CALL/usr/src/kernels/linux/scripts/checksyscalls.sh HOSTCC scripts/dtc/checks.o HOSTCC scripts/dtc/data.o SHIPPED scripts/dtc/dtc-lexer.lex.c SHIPPED scripts/dtc/dtc-parser.tab.h HOSTCC scripts/dtc/dtc-lexer.lex.o SHIPPED scripts/dtc/dtc-parser.tab.c HOSTCC scripts/dtc/dtc-parser.tab.o HOSTCC scripts/dtc/dtc.o HOSTCC scripts/dtc/flattree.o HOSTCC scripts/dtc/fstree.o HOSTCC scripts/dtc/livetree.o HOSTCC scripts/dtc/srcpos.o HOSTCC scripts/dtc/treesource.o HOSTCC scripts/dtc/util.o HOSTLD scripts/dtc/dtc HOSTCC scripts/genksyms/genksyms.o SHIPPED scripts/genksyms/lex.lex.c SHIPPED scripts/genksyms/keywords.hash.c SHIPPED scripts/genksyms/parse.tab.h HOSTCC scripts/genksyms/lex.lex.o SHIPPED scripts/genksyms/parse.tab.c HOSTCC scripts/genksyms/parse.tab.o HOSTLD scripts/genksyms/genksyms CC scripts/mod/empty.o HOSTCC scripts/mod/mk_elfconfig MKELF scripts/mod/elfconfig.h HOSTCC scripts/mod/file2alias.o HOSTCC scripts/mod/modpost.o HOSTCC scripts/mod/sumversion.o HOSTLD scripts/mod/modpost HOSTCC scripts/selinux/genheaders/genheaders HOSTCC scripts/selinux/mdp/mdp HOSTCC scripts/kallsyms HOSTCC scripts/pnmtologo HOSTCC scripts/conmakehash HOSTCC scripts/bin2c CC init/main.o CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o CC init/do_mounts.o CC init/do_mounts_rd.o CC init/do_mounts_initrd.o CC init/do_mounts_md.o LD init/mounts.o CC init/initramfs.o LD init/built-in.o HOSTCC usr/gen_init_cpio GEN usr/initramfs_data.cpio AS usr/initramfs_data.o LD usr/built-in.o CC arch/powerpc/kernel/cputable.o CC arch/powerpc/kernel/ptrace.o CC arch/powerpc/kernel/syscalls.o CC arch/powerpc/kernel/irq.o CC arch/powerpc/kernel/align.o CC arch/powerpc/kernel/signal_32.o CC arch/powerpc/kernel/pmc.o CC arch/powerpc/kernel/vdso.o CC arch/powerpc/kernel/init_task.o CC arch/powerpc/kernel/process.o CPP arch/powerpc/kernel/systbl_chk.i CALL/usr/src/kernels/linux/arch/powerpc/kernel/systbl_chk.sh AS arch/powerpc/kernel/systbl.o CC arch/powerpc/kernel/idle.o CC arch/powerpc/kernel/signal.o CC arch/powerpc/kernel/sysfs.o CC arch/powerpc/kernel/cacheinfo.o CC arch/powerpc/kernel/time.o CC arch/powerpc/kernel/prom.o CC arch/powerpc/kernel/traps.o CC arch/powerpc/kernel/setup-common.o CC arch/powerpc/kernel/udbg.o AS arch/powerpc/kernel/misc.o CC arch/powerpc/kernel/io.o CC arch/powerpc/kernel/dma.o AS arch/powerpc/kernel/misc_64.o LDS arch/powerpc/kernel/vdso32/vdso32.lds VDSO32A arch/powerpc/kernel/vdso32/sigtramp.o VDSO32A arch/powerpc/kernel/vdso32/gettimeofday.o VDSO32A arch/powerpc/kernel/vdso32/datapage.o VDSO32A arch/powerpc/kernel/vdso32/cacheflush.o VDSO32A arch/powerpc/kernel/vdso32/note.o VDSO32L arch/powerpc/kernel/vdso32/vdso32.so.dbg OBJCOPY arch/powerpc/kernel/vdso32/vdso32.so AS arch/powerpc/kernel/vdso32/vdso32_wrapper.o LD arch/powerpc/kernel/vdso32/built-in.o LDS arch/powerpc/kernel/vdso64/vdso64.lds VDSO64A arch/powerpc/kernel/vdso64/sigtramp.o VDSO64A arch/powerpc/kernel/vdso64/gettimeofday.o VDSO64A arch/powerpc/kernel/vdso64/datapage.o VDSO64A arch/powerpc/kernel/vdso64/cacheflush.o VDSO64A arch/powerpc/kernel/vdso64/note.o VDSO64L arch/powerpc/kernel/vdso64/vdso64.so.dbg OBJCOPY arch/powerpc/kernel/vdso64/vdso64.so AS arch/powerpc/kernel/vdso64/vdso64_wrapper.o LD arch/powerpc/kernel/vdso64/built-in.o CC arch/powerpc/kernel/setup_64.o CC arch/powerpc/kernel/sys_ppc32.o CC arch/powerpc/kernel/signal_64.o CC arch/powerpc/kernel/ptrace32.o CC arch/powerpc/kernel/paca.o CC arch/powerpc/kernel/nvram_64.o CC arch/powerpc/kernel/firmware.o CC
Re: 3.4-rc3 compile failed on IBM Power6
Hi Ryan, Thanks for the report! On 25.04.2012 [08:22:19 +0800], Ryan Wang wrote: # gcc --version gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3) Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. platform: pSeries model: IBM,9117-MMA machine: CHRP IBM,9117-MMA snip CC arch/powerpc/platforms/pseries/iommu.o /usr/src/kernels/linux/arch/powerpc/platforms/pseries/iommu.c: In function ?query_ddw?: /usr/src/kernels/linux/arch/powerpc/platforms/pseries/iommu.c:823: error: implicit declaration of function ?pci_dev_to_eeh_dev? /usr/src/kernels/linux/arch/powerpc/platforms/pseries/iommu.c:823: warning: assignment makes pointer from integer without a cast /usr/src/kernels/linux/arch/powerpc/platforms/pseries/iommu.c:824: error: dereferencing pointer to incomplete type /usr/src/kernels/linux/arch/powerpc/platforms/pseries/iommu.c:825: error: dereferencing pointer to incomplete type /usr/src/kernels/linux/arch/powerpc/platforms/pseries/iommu.c:826: error: dereferencing pointer to incomplete type /usr/src/kernels/linux/arch/powerpc/platforms/pseries/iommu.c:827: error: dereferencing pointer to incomplete type /usr/src/kernels/linux/arch/powerpc/platforms/pseries/iommu.c: In function ?create_ddw?: /usr/src/kernels/linux/arch/powerpc/platforms/pseries/iommu.c:852: warning: assignment makes pointer from integer without a cast /usr/src/kernels/linux/arch/powerpc/platforms/pseries/iommu.c:853: error: dereferencing pointer to incomplete type /usr/src/kernels/linux/arch/powerpc/platforms/pseries/iommu.c:854: error: dereferencing pointer to incomplete type /usr/src/kernels/linux/arch/powerpc/platforms/pseries/iommu.c:855: error: dereferencing pointer to incomplete type /usr/src/kernels/linux/arch/powerpc/platforms/pseries/iommu.c:856: error: dereferencing pointer to incomplete type make[3]: *** [arch/powerpc/platforms/pseries/iommu.o] Error 1 make[2]: *** [arch/powerpc/platforms/pseries] Error 2 make[1]: *** [arch/powerpc/platforms] Error 2 make: *** [sub-make] Error 2 Do you have CONFIG_EEH set in your .config? I'm guessing not, and that causes pci.h to not define pci_dev_to_eeh_dev(). Gavin, I think this is broken by your 39baadbf36cee3ede5fdb8a34006d9109e5e2570. Probably need a wrapper for pci_dev_to_eeh_dev() when !CONFIG_EEH? Actually, looking at it more, eeh_dev, which is protected by CONFIG_EEH in arch/powerpc/include/asm/eeh.h won't be defined in such situations and is the type of the return from pci_dev_to_eeh_dev(). So that's going to be broken completely if !CONFIG_EEH as above. So maybe the callers should be EEH-unaware (as they were before) and the callee becomes of the EEH variety (at compile-time) if CONFIG_EEH is set? Thanks, Nish -- Nishanth Aravamudan n...@us.ibm.com IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] drivers/ps3: Fix checkpatch warnings in ps3av.c
From: Valentin Ilie valentin.i...@gmail.com
Signed-off-by: Valentin Ilie valentin.i...@gmail.com
Cc: Geert Uytterhoeven ge...@linux-m68k.org
Signed-off-by: Geoff Levand ge...@infradead.org
---
Hi Geert,
Here's what I queued for v3.5, let me know if you have any concerns.
-Geoff
drivers/ps3/ps3av.c | 24 +---
1 file changed, 9 insertions(+), 15 deletions(-)
diff --git a/drivers/ps3/ps3av.c b/drivers/ps3/ps3av.c
index a409fa0..93d0a8b 100644
--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -338,7 +338,7 @@ int ps3av_do_pkt(u32 cid, u16 send_len, size_t usr_buf_size,
mutex_unlock(ps3av-mutex);
return 0;
- err:
+err:
mutex_unlock(ps3av-mutex);
printk(KERN_ERR %s: failed cid:%x res:%d\n, __func__, cid, res);
return res;
@@ -477,7 +477,6 @@ int ps3av_set_audio_mode(u32 ch, u32 fs, u32 word_bits, u32
format, u32 source)
return 0;
}
-
EXPORT_SYMBOL_GPL(ps3av_set_audio_mode);
static int ps3av_set_videomode(void)
@@ -501,7 +500,7 @@ static void ps3av_set_videomode_packet(u32 id)
video_mode = video_mode_table[id PS3AV_MODE_MASK];
- avb_param.num_of_video_pkt = PS3AV_AVB_NUM_VIDEO; /* num of head
*/
+ avb_param.num_of_video_pkt = PS3AV_AVB_NUM_VIDEO; /* num of head */
avb_param.num_of_audio_pkt = 0;
avb_param.num_of_av_video_pkt = ps3av-av_hw_conf.num_of_hdmi +
ps3av-av_hw_conf.num_of_avmulti;
@@ -521,7 +520,7 @@ static void ps3av_set_videomode_packet(u32 id)
#ifndef PS3AV_HDMI_YUV
if (ps3av-av_port[i] == PS3AV_CMD_AVPORT_HDMI_0 ||
ps3av-av_port[i] == PS3AV_CMD_AVPORT_HDMI_1)
- av_video_cs = RGB8; /* use RGB for HDMI */
+ av_video_cs = RGB8; /* use RGB for HDMI */
#endif
len += ps3av_cmd_set_av_video_cs(avb_param.buf[len],
ps3av-av_port[i],
@@ -590,8 +589,8 @@ static void ps3avd(struct work_struct *work)
#define SHIFT_VESA 8
static const struct {
- unsigned mask : 19;
- unsigned id : 4;
+ unsigned mask:19;
+ unsigned id:4;
} ps3av_preferred_modes[] = {
{ PS3AV_RESBIT_WUXGA SHIFT_VESA, PS3AV_MODE_WUXGA },
{ PS3AV_RESBIT_1920x1080P SHIFT_60, PS3AV_MODE_1080P60 },
@@ -667,7 +666,8 @@ static enum ps3av_mode_num ps3av_hdmi_get_id(struct
ps3av_info_monitor *info)
return id;
}
-static void ps3av_monitor_info_dump(const struct ps3av_pkt_av_get_monitor_info
*monitor_info)
+static void ps3av_monitor_info_dump(
+ const struct ps3av_pkt_av_get_monitor_info *monitor_info)
{
const struct ps3av_info_monitor *info = monitor_info-info;
const struct ps3av_info_audio *audio = info-audio;
@@ -717,8 +717,8 @@ static void ps3av_monitor_info_dump(const struct
ps3av_pkt_av_get_monitor_info *
/* audio block */
for (i = 0; i info-num_of_audio_block; i++) {
- pr_debug(audio[%d] type: %02x max_ch: %02x fs: %02x sbit:
-%02x\n,
+ pr_debug(
+ audio[%d] type: %02x max_ch: %02x fs: %02x sbit:
%02x\n,
i, audio-type, audio-max_num_of_ch, audio-fs,
audio-sbit);
audio++;
@@ -870,21 +870,18 @@ int ps3av_set_video_mode(int id)
return 0;
}
-
EXPORT_SYMBOL_GPL(ps3av_set_video_mode);
int ps3av_get_auto_mode(void)
{
return ps3av_auto_videomode(ps3av-av_hw_conf);
}
-
EXPORT_SYMBOL_GPL(ps3av_get_auto_mode);
int ps3av_get_mode(void)
{
return ps3av ? ps3av-ps3av_mode : 0;
}
-
EXPORT_SYMBOL_GPL(ps3av_get_mode);
/* get resolution by video_mode */
@@ -902,7 +899,6 @@ int ps3av_video_mode2res(u32 id, u32 *xres, u32 *yres)
*yres = video_mode_table[id].y;
return 0;
}
-
EXPORT_SYMBOL_GPL(ps3av_video_mode2res);
/* mute */
@@ -911,7 +907,6 @@ int ps3av_video_mute(int mute)
return ps3av_set_av_video_mute(mute ? PS3AV_CMD_MUTE_ON
: PS3AV_CMD_MUTE_OFF);
}
-
EXPORT_SYMBOL_GPL(ps3av_video_mute);
/* mute analog output only */
@@ -935,7 +930,6 @@ int ps3av_audio_mute(int mute)
return ps3av_set_audio_mute(mute ? PS3AV_CMD_MUTE_ON
: PS3AV_CMD_MUTE_OFF);
}
-
EXPORT_SYMBOL_GPL(ps3av_audio_mute);
static int __devinit ps3av_probe(struct ps3_system_bus_device *dev)
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 3.4-rc3 compile failed on IBM Power6
Hi Nish, # gcc --version gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3) Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. platform: pSeries model: IBM,9117-MMA machine: CHRP IBM,9117-MMA snip CC arch/powerpc/platforms/pseries/iommu.o /usr/src/kernels/linux/arch/powerpc/platforms/pseries/iommu.c: In function ?query_ddw?: /usr/src/kernels/linux/arch/powerpc/platforms/pseries/iommu.c:823: error: implicit declaration of function ?pci_dev_to_eeh_dev? /usr/src/kernels/linux/arch/powerpc/platforms/pseries/iommu.c:823: warning: assignment makes pointer from integer without a cast /usr/src/kernels/linux/arch/powerpc/platforms/pseries/iommu.c:824: error: dereferencing pointer to incomplete type /usr/src/kernels/linux/arch/powerpc/platforms/pseries/iommu.c:825: error: dereferencing pointer to incomplete type /usr/src/kernels/linux/arch/powerpc/platforms/pseries/iommu.c:826: error: dereferencing pointer to incomplete type /usr/src/kernels/linux/arch/powerpc/platforms/pseries/iommu.c:827: error: dereferencing pointer to incomplete type /usr/src/kernels/linux/arch/powerpc/platforms/pseries/iommu.c: In function ?create_ddw?: /usr/src/kernels/linux/arch/powerpc/platforms/pseries/iommu.c:852: warning: assignment makes pointer from integer without a cast /usr/src/kernels/linux/arch/powerpc/platforms/pseries/iommu.c:853: error: dereferencing pointer to incomplete type /usr/src/kernels/linux/arch/powerpc/platforms/pseries/iommu.c:854: error: dereferencing pointer to incomplete type /usr/src/kernels/linux/arch/powerpc/platforms/pseries/iommu.c:855: error: dereferencing pointer to incomplete type /usr/src/kernels/linux/arch/powerpc/platforms/pseries/iommu.c:856: error: dereferencing pointer to incomplete type make[3]: *** [arch/powerpc/platforms/pseries/iommu.o] Error 1 make[2]: *** [arch/powerpc/platforms/pseries] Error 2 make[1]: *** [arch/powerpc/platforms] Error 2 make: *** [sub-make] Error 2 Do you have CONFIG_EEH set in your .config? I'm guessing not, and that causes pci.h to not define pci_dev_to_eeh_dev(). Gavin, I think this is broken by your 39baadbf36cee3ede5fdb8a34006d9109e5e2570. Probably need a wrapper for pci_dev_to_eeh_dev() when !CONFIG_EEH? Actually, looking at it more, eeh_dev, which is protected by CONFIG_EEH in arch/powerpc/include/asm/eeh.h won't be defined in such situations and is the type of the return from pci_dev_to_eeh_dev(). So that's going to be broken completely if !CONFIG_EEH as above. I think it's because iommu.c depends on CONFIG_EEH heavily anyway with or without the fix 39baadbf36cee3ede5fdb8a34006d9109e5e2570. That means without CONFIG_EEH, iommu.c won't work properly even it can be compiled successfully :-) The story behind is that the PCI device is expected to be PE sensitive. While setting up its DMA (through IOMMU), the number of the PE to which the PCI device belongs to is passed to the related RTAS call. So the PE number of the PCI device is expected if possible. As I knew, the PE number of the PCI device is -ONLY- figured out by EEH. So maybe the callers should be EEH-unaware (as they were before) and the callee becomes of the EEH variety (at compile-time) if CONFIG_EEH is set? In order to make iommu.c irrelative to CONFIG_EEH, we might figure out the PE number of the PCI device during PCI probe time. Here're some rough thoughts about the rework. - Introduce additional field int pe_num to struct dev_archdata. That would be traced like: (struct pci_dev)-(struct device dev) -(struct dev_archdata archdata). - During the PCI probe time (maybe pci_fixup_early), we can figure out the PE number. Then we can retrieve the PE number of PCI device from int pe_num and needn't care CONFIG_EEH has been turned on or off. I'm not sure Ben has any comments on the idea? Thanks, Gavin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Regression in 32-bit ppc kernel
On 04/24/2012 06:53 PM, Benjamin Herrenschmidt wrote: On Tue, 2012-04-24 at 17:58 -0500, Larry Finger wrote: Hi, Somewhere between v3.2 and v3.3, the kernel in my Powerbook G4 started issuing the following traceback on bootup: Does it continue working afterward or not at all ? Are you using the old IDE driver or the newer libata based pata_macio ? Yes, it finishes the boot, and appears to work correctly. If a device is missing, I do not know what it is. I think I am using the old IDE driver. Larry ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 3.4-rc3 compile failed on IBM Power6
On Wed, 2012-04-25 at 09:50 +0800, Gavin Shan wrote: In order to make iommu.c irrelative to CONFIG_EEH, we might figure out the PE number of the PCI device during PCI probe time. Here're some rough thoughts about the rework. - Introduce additional field int pe_num to struct dev_archdata. That would be traced like: (struct pci_dev)-(struct device dev) -(struct dev_archdata archdata). - During the PCI probe time (maybe pci_fixup_early), we can figure out the PE number. Then we can retrieve the PE number of PCI device from int pe_num and needn't care CONFIG_EEH has been turned on or off. I'm not sure Ben has any comments on the idea? Just select EEH from pseries Kconfig, no point in keeping that a user visible option. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Regression in 32-bit ppc kernel
On Tue, 2012-04-24 at 21:37 -0500, Larry Finger wrote: Somewhere between v3.2 and v3.3, the kernel in my Powerbook G4 started issuing the following traceback on bootup: Does it continue working afterward or not at all ? Are you using the old IDE driver or the newer libata based pata_macio ? Yes, it finishes the boot, and appears to work correctly. If a device is missing, I do not know what it is. I think I am using the old IDE driver. Interesting. Does it make a difference if you switch to pata_macio ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] ppc/pseries: rivet CONFIG_EEH for pSeries platform
Recently, Ryan Wang tried to compile PPC pSeries platform without CONFIG_EEH and eventually run into errors. Nishanth Aravamudan helped to narrow down the root cause. Actually, the pSeries platform depends on CONFIG_EEH heavily and that won't work properly without EEH support. According to Ben's suggestion, the patch make CONFIG_EEH invisible and keep it as always selected on pSeries platform. Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com --- arch/powerpc/platforms/pseries/Kconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig index aadbe4f..178a5f3 100644 --- a/arch/powerpc/platforms/pseries/Kconfig +++ b/arch/powerpc/platforms/pseries/Kconfig @@ -30,9 +30,9 @@ config PPC_SPLPAR two or more partitions. config EEH - bool PCI Extended Error Handling (EEH) if EXPERT + bool depends on PPC_PSERIES PCI - default y if !EXPERT + default y config PSERIES_MSI bool -- 1.7.5.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][2/3][RFC] TDM Framework
On Sat, 2012-03-10 at 18:27 +0530, Poonam Aggrwal wrote: From: Sandeep Singh sand...@freescale.com TDM Framework is an attempt to provide a platform independent layer which can offer a standard interface for TDM access to different client modules. Beneath, the framework layer can house different types of TDM drivers to handle various TDM devices, the hardware intricacies of the devices being completely taken care by TDM drivers. Neither the changeset comment, the code, not the Documentation file (which are non-existent, at least in this patch, though mentioned), define what TDM actually is :-) Cheers, Ben. This framework layer will allow any type of TDM device to hook with it. For example Freescale controller as on MPC8315, UCC based TDM controller, or any other controller. The main functions of this Framework are: - provides interface to TDM clients to access TDM functionalities. - provides standard interface for TDM drivers to hook with the framework. - handles various data handling stuff and buffer management. In future this Framework will be extended to provide Interface for Line control devices also. For example SLIC, E1/T1 Framers etc. Limitations/Future Work --- 1. Presently the framework supports only Single Port channelised mode. 2. Also the configurability options are limited which will be extended later on. 3. Only kernel mode TDM clients are supported currently. Support for User mode clients will be added later. Signed-off-by: Sandeep Singh sand...@freescale.com Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com --- A couple of todos' are left in the patch, we are working on it and will be addressed in the updated patch set. drivers/Kconfig |1 + drivers/Makefile|1 + drivers/tdm/Kconfig | 25 + drivers/tdm/tdm-core.c | 1146 +++ include/linux/mod_devicetable.h | 11 + include/linux/tdm.h | 347 6 files changed, 1531 insertions(+), 0 deletions(-) create mode 100644 drivers/tdm/Kconfig create mode 100644 drivers/tdm/tdm-core.c create mode 100644 include/linux/tdm.h diff --git a/drivers/Kconfig b/drivers/Kconfig index ad6c1eb..25f7f5b 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -130,4 +130,5 @@ source drivers/virt/Kconfig source drivers/net/dpa/NetCommSw/Kconfig +source drivers/tdm/Kconfig endmenu diff --git a/drivers/Makefile b/drivers/Makefile index cd546eb..362b5ed 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -102,6 +102,7 @@ obj-$(CONFIG_INFINIBAND) += infiniband/ obj-$(CONFIG_SGI_SN) += sn/ obj-y+= firmware/ obj-$(CONFIG_CRYPTO) += crypto/ +obj-$(CONFIG_TDM)+= tdm/ obj-$(CONFIG_SUPERH) += sh/ obj-$(CONFIG_ARCH_SHMOBILE) += sh/ ifndef CONFIG_ARCH_USES_GETTIMEOFFSET diff --git a/drivers/tdm/Kconfig b/drivers/tdm/Kconfig new file mode 100644 index 000..8db2b05 --- /dev/null +++ b/drivers/tdm/Kconfig @@ -0,0 +1,25 @@ +# +# TDM subsystem configuration +# + +menuconfig TDM + tristate TDM support + ---help--- + More information is contained in the directory file:Documentation/tdm/, + especially in the file called summary there. + If you want TDM support, you should say Y here and also to the + specific driver for your bus adapter(s) below. + + This TDM support can also be built as a module. If so, the module + will be called tdm-core. + +if TDM + +config TDM_DEBUG_CORE + bool TDM Core debugging messages + help + Say Y here if you want the TDM core to produce a bunch of debug + messages to the system log. Select this if you are having a + problem with TDM support and want to see more of what is going on. + +endif # TDM diff --git a/drivers/tdm/tdm-core.c b/drivers/tdm/tdm-core.c new file mode 100644 index 000..cdda260 --- /dev/null +++ b/drivers/tdm/tdm-core.c @@ -0,0 +1,1146 @@ +/* driver/tdm/tdm-core.c + * + * Copyright (C) 2012 Freescale Semiconductor, Inc, All rights reserved. + * + * TDM core is the interface between TDM clients and TDM devices. + * It is also intended to serve as an interface for line controld + * devices later on. + * + * Author:Hemant Agrawal hem...@freescale.com + * Rajesh Gumasta rajesh.guma...@freescale.com + * + * Modified by Sandeep Kr Singh sand...@freescale.com + * Poonam Aggarwal poonam.aggar...@freescale.com + * 1. Added framework based initialization of device. + * 2. All the init/run time configuration is now done by framework. + * 3. Added channel level operations. + * + * 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
Re: 3.4-rc3 compile failed on IBM Power6
In order to make iommu.c irrelative to CONFIG_EEH, we might figure out the PE number of the PCI device during PCI probe time. Here're some rough thoughts about the rework. - Introduce additional field int pe_num to struct dev_archdata. That would be traced like: (struct pci_dev)-(struct device dev) -(struct dev_archdata archdata). - During the PCI probe time (maybe pci_fixup_early), we can figure out the PE number. Then we can retrieve the PE number of PCI device from int pe_num and needn't care CONFIG_EEH has been turned on or off. I'm not sure Ben has any comments on the idea? Just select EEH from pseries Kconfig, no point in keeping that a user visible option. Thanks for the suggestion, Ben :-) I've sent one trivial patch against it. Cheers, Ben. Thanks, Gavin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
