Inclusion of 85xx cache-sram patch series
Any plans to include this patch series at http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/078693.html into your 'next' branch or there are some outstanding issues with this. Thanks, Vivek ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Problem with mini-PCI-E slot on P2020RDB
From: linuxppc-dev-bounces+vivek.mahajan=freescale@lists.ozlabs. org [mailto:linuxppc-dev-bounces+vivek.mahajan=freescale@lists .ozlabs.org] On Behalf Of Felix Radensky Sent: Thursday, December 17, 2009 12:52 PM I just noticed a MSI enable bit in drivers/net/wireless/ath/ath9k/reg.h as under, may be we need to trun this on:- reg.h:1013:#define AR_PCIE_MSI 0x4094 reg.h:1014:#define AR_PCIE_MSI_ENABLE 0x0001 According to ath9k developers adding MSI support to the driver is not trivial. They've tried once, it didn't work and they gave up. Any chance I can use mini-PCI-E slot without MSI ? So, even after enabling the above bit, there were no MSI interrupts from this card. If we look at some of the GbE or SATA drivers, adding MSI is not that hard. ath9k can be an exception. I reported this issue to the p2020 board designer; but unfortunately he is out until 1/4/10. It could be a missing pull-up issue at IRQ0 or some thing else, I don't know. Thanks. Felix. Thanks, Vivek ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Problem with mini-PCI-E slot on P2020RDB
From: Felix Radensky [mailto:fe...@embedded-sol.com] Sent: Thursday, December 17, 2009 2:26 PM Yes, I've enabled that bit, but didn't get any interrupt. Thanks for trying. Thanks a lot. If I understand you correctly, the only way I can get ath9k driver to work on this board using legacy interrupts is to wait for a hardware fix. Right ? Correct Felix. Thanks, Vivek ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Problem with mini-PCI-E slot on P2020RDB
From: Felix Radensky [mailto:fe...@embedded-sol.com] Sent: Wednesday, December 16, 2009 2:56 PM To: Mahajan Vivek-B08308 Cc: linuxppc-...@ozlabs.org; Aggrwal Poonam-B10812; Kumar Gala Subject: Re: Problem with mini-PCI-E slot on P2020RDB Hi, Looks like INTA is not being routed to IRQ0 properly for this PCIe ctlr. Try changing the interrupt-map prop for the ctlr at 0xffe0a000 to the following, temporarily:- interrupt-map = /* IDSEL 0x0 */ 0x0 0x0 0x1 mpic 0x1 0x1 0x0 0x0 0x2 mpic 0x2 0x1 0x0 0x0 0x3 mpic 0x3 0x1 0x0 0x0 0x4 mpic 0x0 0x1 Thanks for your help. With this change nobody cared message disappears, but interrupts are not coming at all. Is it a SoC problem or a board problem ? As per the p2020rm, PCIe legacy INTA is shared with IRQ0 for this ctlr, which is the exactly the case with other SoC's p2020ds, mpc8536ds, mpc8572ds. To me it seems like a board issue and it needs to be followed up. I plugged in ralink rt2860 pcie wirless card in the mini-pcie slot of p2020rdb, which ran fine becaused it used MSI by default. How hard is it to enable MSI in the atheros wireless driver. Thanks. Felix. Thanks, Vivek ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Problem with mini-PCI-E slot on P2020RDB
From: Felix Radensky [mailto:fe...@embedded-sol.com] Sent: Wednesday, December 16, 2009 5:30 PM As per the p2020rm, PCIe legacy INTA is shared with IRQ0 for this ctlr, which is the exactly the case with other SoC's p2020ds, mpc8536ds, mpc8572ds. To me it seems like a board issue and it needs to be followed up. I plugged in ralink rt2860 pcie wirless card in the mini-pcie slot of p2020rdb, which ran fine becaused it used MSI by default. How hard is it to enable MSI in the atheros wireless driver. I've enabled MSI in ath9k driver, by simply adding pci_enable_msi() and pci_disable_msi() at relevant places. The MSI interrupt is allocated. irq: irq 0 on host /s...@ffe0/m...@41600 mapped to virtual irq 18 phy0: Atheros AR9280 MAC/BB Rev:2 AR5133 RF Rev:d0: mem=0xf216, irq=18 cat /proc/interrupts CPU0 18: 0 FSL-MSI Edge ath9k lspci -v shows that MSI was enabled on device But I don't get any interrupts. I've posted a question to ath9k list, maybe folks there will have some ideas. I just noticed a MSI enable bit in drivers/net/wireless/ath/ath9k/reg.h as under, may be we need to trun this on:- reg.h:1013:#define AR_PCIE_MSI 0x4094 reg.h:1014:#define AR_PCIE_MSI_ENABLE 0x0001 Thanks. Felix. Thanks, Vivek ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Problem with mini-PCI-E slot on P2020RDB
-Original Message- From: linuxppc-dev-bounces+vivek.mahajan=freescale@lists.ozlabs. org [mailto:linuxppc-dev-bounces+vivek.mahajan=freescale@lists .ozlabs.org] On Behalf Of Felix Radensky Sent: Wednesday, December 16, 2009 2:56 AM To: linuxppc-...@ozlabs.org; Aggrwal Poonam-B10812; Kumar Gala Subject: Problem with mini-PCI-E slot on P2020RDB Hi, I'm trying to use mini-PCI-E WLAN card on P2020RDB running 2.6.32, but so far without success. ath9k driver identifies the device, I can run ifconfig, iwconfig and hostapd on wlan0, but device is not getting any interrupts, so I suspect the interrupt configuration is wrong. Atheros ath9k driver reports: phy0: Atheros AR9280 MAC/BB Rev:2 AR5133 RF Rev:d0: mem=0xf106, irq=16 The mapping for irq 16 is: irq: irq 1 on host /s...@ffe0/p...@4 mapped to virtual irq 16 According to /proc/interrupts: CPU0 16: 0 OpenPIC Edge ath9k The same problem happens if Atheros card is plugged (with adapter) into regular PCI-E slot. It seems that p2020rdb device tree is missing interrupt-map-mask and interrupt-map properties in PCI-E nodes. I've tried running kernel from latest FSL BSP for this board (based on 2.6.32-rc3). The device tree has the interrupt-map-mask and interrupt-map properties, and interrupt mapping is different: irq: irq 0 on host /s...@ffe0/p...@4 mapped to virtual irq 16 In /proc/interrups I see CPU0 16: 11 OpenPIC Level ath9k However, when ath9k driver is loaded I get this: irq 16: nobody cared (try booting with the irqpoll option) Call Trace: [efbefa40] [c00074b0] show_stack+0x4c/0x16c (unreliable) [efbefa70] [c0073970] __report_bad_irq+0x38/0xd0 [efbefa90] [c0073bd4] note_interrupt+0x1cc/0x22c [efbefac0] [c00747d0] handle_fasteoi_irq+0xf4/0x128 [efbefae0] [c0004eb8] do_IRQ+0xc8/0xf4 [efbefb00] [c001081c] ret_from_except+0x0/0x18 [efbefbc0] [] (null) [efbefc10] [c0004d24] do_softirq+0x60/0x64 [efbefc20] [c0044670] irq_exit+0x88/0xa8 [efbefc30] [c0004ebc] do_IRQ+0xcc/0xf4 [efbefc50] [c001081c] ret_from_except+0x0/0x18 [efbefd10] [c00730b4] __setup_irq+0x320/0x39c [efbefd30] [c0073214] request_threaded_irq+0xe4/0x148 [efbefd60] [f2244218] ath_pci_probe+0x1b0/0x3a4 [ath9k] [efbefda0] [c01c386c] local_pci_probe+0x24/0x34 [efbefdb0] [c01c3bc0] pci_device_probe+0x84/0xa8 [efbefde0] [c01e86b8] driver_probe_device+0xa8/0x1a8 [efbefe00] [c01e8874] __driver_attach+0xbc/0xc0 [efbefe20] [c01e7d88] bus_for_each_dev+0x70/0xac [efbefe50] [c01e84d8] driver_attach+0x24/0x34 [efbefe60] [c01e7504] bus_add_driver+0xb8/0x278 [efbefe90] [c01e8bec] driver_register+0x84/0x178 [efbefeb0] [c01c3e6c] __pci_register_driver+0x54/0xe4 [efbefed0] [f2244434] ath_pci_init+0x28/0x38 [ath9k] [efbefee0] [f215702c] ath9k_init+0x2c/0x100 [ath9k] [efbefef0] [c0001d34] do_one_initcall+0x3c/0x1e8 [efbeff20] [c006f9f0] sys_init_module+0xf8/0x220 [efbeff40] [c00101c4] ret_from_syscall+0x0/0x3c handlers: [f223badc] (ath_isr+0x0/0x1b4 [ath9k]) Disabling IRQ #16 Looks like INTA is not being routed to IRQ0 properly for this PCIe ctlr. Try changing the interrupt-map prop for the ctlr at 0xffe0a000 to the following, temporarily:- interrupt-map = /* IDSEL 0x0 */ 0x0 0x0 0x1 mpic 0x1 0x1 0x0 0x0 0x2 mpic 0x2 0x1 0x0 0x0 0x3 mpic 0x3 0x1 0x0 0x0 0x4 mpic 0x0 0x1 ; Atheros card plugged into regular PCI-E slot works OK in FSL BSP. Any help in resolving this is much appreciated. Thanks. Felix. Thanks, Vivek ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v3 3/3] powerpc/fsl: 85xx: add cache-sram support
From: Wood Scott-B07421 Sent: Friday, November 20, 2009 11:09 PM Cache-sram does not have any device tree entry since it is not a hardware as such. Putting it under chosen can be another option. I think, Scott (cc'ed) was of the opinion that since 32b base address support is missing; so there is no point in moving this address to the command line and .config should be okay for now for it. I don't know what you mean by 32b base address support is missing. I have no objection to putting it on the command line. It was a typo, it should be missing 36b address support. Since the kernel did not run under different environment (i.e 32b / 36b base address); so it was decided that .config may be okay for this. -Scott Thanks, Vivek ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v3 3/3] powerpc/fsl: 85xx: add cache-sram support
From: Gala Kumar-B11780 Sent: Thursday, November 19, 2009 7:51 PM + * Cache SRAM handling for QorIQ platform should say PQ3 some QorIQ platforms Ok +config FSL_85XX_CACHE_SRAM_BASE + hex + depends on FSL_85XX_CACHE_SRAM + default 0xfff0 + I really don't like setting the physical address this way, can we not do this via the device tree? Cache-sram does not have any device tree entry since it is not a hardware as such. Putting it under chosen can be another option. I think, Scott (cc'ed) was of the opinion that since 32b base address support is missing; so there is no point in moving this address to the command line and .config should be okay for now for it. + * QorIQ based Cache Controller Memory Mapped Registers PQ3 or some QorIQ Ok + * Simple memory allocator abstraction for QorIQ (P1/P2) based Cache-SRAM PQ3 or some QorIQ Ok + + if (!param || (strict_strtoul(param, 0, val) 0)) + return -EINVAL; + we should use memparse() Ok Thanks, Vivek ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/1] ata/sata_sil24: MSI support, disabled by default
From: Jeff Garzik [mailto:j...@garzik.org] Sent: Tuesday, November 17, 2009 1:12 PM In this case msi is supposed to be passed via insmod and not via kernel cmdline. If the driver is built-in the kernel, then force sata_sil24_msi = 1 in the driver to enable it. First, the original patch was just fine, and it was applied. You should have received email confirmation of this already. Yes, I did. Second, all module options are available on the kernel command line, when a module is built into the kernel. You supply a module name prefix to each module option, on the kernel command line. Correct, sata_sil24.msi enables it. Jeff Thanks, Vivek ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/1] ata/sata_sil24: MSI support, disabled by default
From: Grant Grundler [mailto:grund...@google.com] Sent: Monday, November 16, 2009 11:08 PM +static int sata_sil24_msi; /* Disable MSI */ +module_param_named(msi, sata_sil24_msi, bool, S_IRUGO); +MODULE_PARM_DESC(msi, Enable MSI (Default: false)); Vivek, Do we even still need the parameter? I'm thinking either MSI works with a chipset or it doesn't. The kernel has globals to know which state is true. Sometimes even in a platform, some PCIe endpoints do very well with MSI while others may have to resort to legacy ints. Should we let the endpoints make the final call. If the parameter is needed, when this driver is compiled into the kernel, how is msi parameter specified? I think the parameter needs to be documented and fit in with other msi parameters. See nomsi in Documentation/kernel-parameters.txt. In this case msi is supposed to be passed via insmod and not via kernel cmdline. If the driver is built-in the kernel, then force sata_sil24_msi = 1 in the driver to enable it. If you want to keep this module parameter, can I suggest calling the exported parameter sata_sil24_msi? Will do it in the subsequent patch. pci_intx() isn't documented in MSI-HOWTO.txt - because it's already called: pci_msi_enable() - pci_msi_enable_block() - msi_capability_init() - pci_intx_for_msi(dev, 0) - pci_intx(pdev, 0); (thanks to willy (Mathew Wilcox) for pointing me at msi_capability_init() - I overlooked it) Please add Reviewed-by: Grant Grundler grund...@google.com once the variable name is changed and the pci_intx() call is removed. Will take care in the upcoming patch cheers, grant Thanks, Vivek ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v3 2/3] powerpc/fsl: 85xx: document cache-sram
Wolfgang Denk Sent: Wednesday, October 21, 2009 11:20 PM * How to enable it from a low level driver * How to set its size ... +The size of the above cache SRAM memory window is passed via the +kernel command line as cache-sram-size= Would it not make more sense to configure this property through the device tree? Since this parameter needs to be passed run time to the kernel and it was not preconfigured by u-boot; so it landed in the cmdline instead of the device tree. Best regards, Wolfgang Denk Thanks, Vivek ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 4/4] powerpc/fsl: 85xx: add cache-sram support
From: Gala Kumar-B11780 Sent: Friday, September 25, 2009 12:08 AM + mbar(1); why isn't eieio() sufficient here? When I initially added / tested cache SRAM for P2020RDB, its RM talked about using mbar() though mbar(1) is identical to eieio() opcode-wise. Also as cache-sram works only for 85xx derivatives, so I picked mbar() instead of eieio. Thanks, Vivek ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
2.6.31: powerpc build errors with include/linux/perf_counter.h
Hello Markus, Apparently this http://git.kernel.org/?p=linux/kernel/git/benh/powerpc.git;a=commitdiff; h=5622f295b53fb60dbf9bed3e2c89d182490a8b7f breaks the powerpc build as under when built from http://git.kernel.org/?p=linux/kernel/git/benh/powerpc.git;a=summary with latest commit ebc79c4f8da0f92efa968e0328f32334a2ce80cf cc1: warnings being treated as errors In file included from arch/powerpc/kernel/irq.c:56: include/linux/perf_counter.h: In function 'perf_output_begin': include/linux/perf_counter.h:854: warning: no return statement in function returning non-void include/linux/perf_counter.h: At top level: include/linux/perf_counter.h:863: warning: 'struct perf_sample_data' declared inside parameter list include/linux/perf_counter.h:863: warning: its scope is only this definition or declaration, which is probably not what include/linux/perf_counter.h:868: warning: 'struct perf_sample_data' declared inside parameter list make[1]: *** [arch/powerpc/kernel/irq.o] Error 1 make: *** [arch/powerpc/kernel] Error 2 Thanks, Vivek ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
