Re: [PATCH 2/3] eSDHC: Fix errors when booting kernel with fsl esdhc
On Tue, Jul 5, 2011 at 9:49 AM, Roy Zang wrote: > From: Xu lei > > When esdhc module was enabled in p5020, there were following errors: > > mmc0: Timeout waiting for hardware interrupt. > mmc0: error -110 whilst initialising SD card > mmc0: Unexpected interrupt 0x0200. > mmc0: Timeout waiting for hardware interrupt. > mmc0: error -110 whilst initialising SD card > mmc0: Unexpected interrupt 0x0200. > > It is because ESDHC controller has different bit setting for PROCTL > register, when kernel sets Power Control Register by method for standard > SD Host Specification, it would overwritten FSL ESDHC PROCTL[DMAS]; > when it set Host Control Registers[DMAS], it sets PROCTL[EMODE] and > PROCTL[D3CD]. These operations will set bad bits for PROCTL Register > on FSL ESDHC Controller and cause errors, so this patch will make esdhc > driver access FSL PROCTL Register according to block guide instead of > standard SD Host Specification. > > For some FSL chips, such as MPC8536/P2020, PROCTL[VOLT_SEL] and PROCTL[DMAS] > bits are reserved and even if they are set to wrong bits there is no error. > But considering that all FSL ESDHC Controller register map is not fully > compliant to standard SD Host Specification, we put the patch to all of > FSL ESDHC Controllers. > > Signed-off-by: Lei Xu > Signed-off-by: Roy Zang > Signed-off-by: Kumar Gala > --- > drivers/mmc/host/sdhci-of-core.c | 3 ++ > drivers/mmc/host/sdhci.c | 62 ++--- > include/linux/mmc/sdhci.h | 6 ++- > 3 files changed, 57 insertions(+), 14 deletions(-) > > diff --git a/drivers/mmc/host/sdhci-of-core.c > b/drivers/mmc/host/sdhci-of-core.c > index 60e4186..fede43d 100644 > --- a/drivers/mmc/host/sdhci-of-core.c > +++ b/drivers/mmc/host/sdhci-of-core.c > @@ -179,6 +179,9 @@ static int __devinit sdhci_of_probe(struct > platform_device *ofdev) > if (sdhci_of_wp_inverted(np)) > host->quirks |= SDHCI_QUIRK_INVERTED_WRITE_PROTECT; > > + if (of_device_is_compatible(np, "fsl,esdhc")) > + host->quirks |= SDHCI_QUIRK_QORIQ_PROCTL_WEIRD; > + > clk = of_get_property(np, "clock-frequency", &size); > if (clk && size == sizeof(*clk) && *clk) > of_host->clock = be32_to_cpup(clk); > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c > index 58d5436..77174e5 100644 > --- a/drivers/mmc/host/sdhci.c > +++ b/drivers/mmc/host/sdhci.c > @@ -674,7 +674,7 @@ static void sdhci_set_transfer_irqs(struct sdhci_host > *host) > static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_command > *cmd) > { > u8 count; > - u8 ctrl; > + u32 ctrl; > struct mmc_data *data = cmd->data; > int ret; > > @@ -807,14 +807,28 @@ static void sdhci_prepare_data(struct sdhci_host *host, > struct mmc_command *cmd) > * is ADMA. > */ > if (host->version >= SDHCI_SPEC_200) { > - ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL); > - ctrl &= ~SDHCI_CTRL_DMA_MASK; > - if ((host->flags & SDHCI_REQ_USE_DMA) && > - (host->flags & SDHCI_USE_ADMA)) > - ctrl |= SDHCI_CTRL_ADMA32; > - else > - ctrl |= SDHCI_CTRL_SDMA; > - sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL); > + if (host->quirks & SDHCI_QUIRK_QORIQ_PROCTL_WEIRD) { > +#define ESDHCI_PROCTL_DMAS_MASK 0x0300 > +#define ESDHCI_PROCTL_ADMA32 0x0200 > +#define ESDHCI_PROCTL_SDMA 0x Breaks the code flow / readability. Can be moved to top of the file ? > + ctrl = sdhci_readl(host, SDHCI_HOST_CONTROL); > + ctrl &= ~ESDHCI_PROCTL_DMAS_MASK; > + if ((host->flags & SDHCI_REQ_USE_DMA) && > + (host->flags & SDHCI_USE_ADMA)) > + ctrl |= ESDHCI_PROCTL_ADMA32; > + else > + ctrl |= ESDHCI_PROCTL_SDMA; > + sdhci_writel(host, ctrl, SDHCI_HOST_CONTROL); > + } else { > + ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL); > + ctrl &= ~SDHCI_CTRL_DMA_MASK; > + if ((host->flags & SDHCI_REQ_USE_DMA) && > + (host->flags & SDHCI_USE_ADMA)) > + ctrl |= SDHCI_CTRL_ADMA32; > + else > + ctrl |= SDHCI_CTRL_SDMA; > + sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL); > + } > } > > if (!(host->flags & SDHCI_REQ_USE_DMA)) { > @@ -1138,19 +1152,32 @@ out: > static void sdhci_set_power(struct sdhci_host *host, unsigned short power) > { > u8 pwr = 0; > + u8 volt = 0; > > if (power != (unsigned short)-1) { > switch (1
Re: [PATCH 3/3] eSDHC: fix incorrect default value of the capabilities register on P4080
On Tue, Jul 05, 2011 at 12:19:03PM +0800, Roy Zang wrote: > P4080 eSDHC errata 12 describes incorrect default value of the > the host controller capabilities register. > > The default value of the VS18 and VS30 fields in the host controller > capabilities register (HOSTCAPBLT) are incorrect. The default of these bits > should be zero instead of one in the eSDHC logic. > > This patch adds the workaround for these errata. > > Signed-off-by: Roy Zang > --- > drivers/mmc/host/sdhci-of-core.c |3 +++ > drivers/mmc/host/sdhci.c |6 ++ > include/linux/mmc/sdhci.h|4 > 3 files changed, 13 insertions(+), 0 deletions(-) > > diff --git a/drivers/mmc/host/sdhci-of-core.c > b/drivers/mmc/host/sdhci-of-core.c > index fede43d..9bdd30d 100644 > --- a/drivers/mmc/host/sdhci-of-core.c > +++ b/drivers/mmc/host/sdhci-of-core.c > @@ -182,6 +182,9 @@ static int __devinit sdhci_of_probe(struct > platform_device *ofdev) > if (of_device_is_compatible(np, "fsl,esdhc")) > host->quirks |= SDHCI_QUIRK_QORIQ_PROCTL_WEIRD; > > + if (of_device_is_compatible(np, "fsl,p4080-esdhc")) > + host->quirks |= SDHCI_QUIRK_QORIQ_HOSTCAPBLT_ONLY_VS33; Should really use voltage-ranges, not quirks. http://www.spinics.net/lists/linux-mmc/msg02785.html Thanks, -- Anton Vorontsov Email: cbouatmai...@gmail.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/6] hw_breakpoints: Migrate breakpoint conditional build under new config
On Mon, Jul 04, 2011 at 11:14:16PM +0530, K.Prasad wrote: > On Mon, Jul 04, 2011 at 03:29:14PM +0200, Frederic Weisbecker wrote: > > On Mon, Jul 04, 2011 at 06:57:46PM +0530, K.Prasad wrote: > > > On Tue, May 24, 2011 at 11:52:23PM +0200, Frederic Weisbecker wrote: > > > > Migrate conditional hw_breakpoint code compilation under > > > > the new config to prepare for letting the user chose whether > > > > or not to build this feature > > > > > > > > > > Making the hardware breakpoint patches modular has always been a goal. > > > I've looked at the PowerPC parts of the code and they look harmless. > > > > > > Acked-by: K.Prasad > > > > Great! > > > > I'll push that soon, thanks guys for your acks! > > Meanwhile, I was testing hardware breakpoints through perf and found > that monitoring a given address fails when using 'perf record' (returns > -ENOSPC) while 'perf stat' and watchpoint through gdb works fine (see > logs below). > > Has this behaviour been reported for other perf counters? Nope I haven't anything like that. What I reported privately to you a few ago was actually due to a mistake of mine. Otherwise I haven't seen other problems. -ENOSPC is likely related to the breakpoint slot reservation, in kernel/events/hw_breakpoint.c ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: hvc_console change results in corrupt oops output
Benjamin Herrenschmidt wrote: > That is a fun conclusion considering that hvc has been written for the > pseries hypervisor which ... can return BUSY on writes :-) Go read the original thread. The problem is that tty writes and console writes are treated the same by the hvc client driver. If a client driver detects that the hypervisor is busy, it has the choice of either spinning or returning right away. Spinning is not acceptable for tty output, so all drivers return right away. hvc then drops the unwritten characters. According to Hendrik, this is still happening. > We just need to fix HVC properly. Where were you two years ago? I complained about the problem, and even posted a hackish "fix". The response I got was tepid -- some acknowledgement that the problem exists, but no real desire to fix it by anyone. So I had no choice but to abandon hvc. And frankly, I still don't understand why it exists. Since then, I wrote a very nice console/tty driver, and I have no plans to return to hvc even if the problem is fixed. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC] virtio: expose for non-virtualization users too
virtio has been so far used only in the context of virtualization, and the virtio Kconfig was sourced directly by the relevant arch Kconfigs when VIRTUALIZATION was selected. Now that we start using virtio for inter-processor communications, we need to source the virtio Kconfig outside of the virtualization scope too. Moreover, some architectures might use virtio for both virtualization and inter-processor communications, so directly sourcing virtio might yield unexpected results due to conflicting selections. The simple solution offered by this patch is to always source virtio's Kconfig in drivers/Kconfig, and remove it from the appropriate arch Kconfigs. Additionally, a virtio menu entry has been added so virtio drivers don't show up in the general drivers menu. This way anyone can use virtio, though it's arguably less accessible (and neat!) for virtualization users now. Note: some architectures (mips and sh) seem to have a VIRTUALIZATION menu merely for sourcing virtio's Kconfig, so that menu is removed too. Signed-off-by: Ohad Ben-Cohen --- The motivation behind this patch is: https://lkml.org/lkml/2011/6/21/47 If the general approach is agreed upon, we can either merge the patch independently, or add it to the AMP patch set. arch/ia64/kvm/Kconfig|1 - arch/mips/Kconfig| 16 arch/powerpc/kvm/Kconfig |1 - arch/s390/kvm/Kconfig|1 - arch/sh/Kconfig | 16 arch/tile/kvm/Kconfig|1 - arch/x86/kvm/Kconfig |1 - drivers/Kconfig |2 ++ drivers/virtio/Kconfig |3 +++ 9 files changed, 5 insertions(+), 37 deletions(-) diff --git a/arch/ia64/kvm/Kconfig b/arch/ia64/kvm/Kconfig index fa4d1e5..9806e55 100644 --- a/arch/ia64/kvm/Kconfig +++ b/arch/ia64/kvm/Kconfig @@ -49,6 +49,5 @@ config KVM_INTEL extensions. source drivers/vhost/Kconfig -source drivers/virtio/Kconfig endif # VIRTUALIZATION diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 653da62..a627a2c 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -2489,20 +2489,4 @@ source "security/Kconfig" source "crypto/Kconfig" -menuconfig VIRTUALIZATION - bool "Virtualization" - default n - ---help--- - Say Y here to get to see options for using your Linux host to run other - operating systems inside virtual machines (guests). - This option alone does not add any kernel code. - - If you say N, all options in this submenu will be skipped and disabled. - -if VIRTUALIZATION - -source drivers/virtio/Kconfig - -endif # VIRTUALIZATION - source "lib/Kconfig" diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig index b7baff7..105b691 100644 --- a/arch/powerpc/kvm/Kconfig +++ b/arch/powerpc/kvm/Kconfig @@ -99,6 +99,5 @@ config KVM_E500 If unsure, say N. source drivers/vhost/Kconfig -source drivers/virtio/Kconfig endif # VIRTUALIZATION diff --git a/arch/s390/kvm/Kconfig b/arch/s390/kvm/Kconfig index f66a1bd..a216341 100644 --- a/arch/s390/kvm/Kconfig +++ b/arch/s390/kvm/Kconfig @@ -37,6 +37,5 @@ config KVM # OK, it's a little counter-intuitive to do this, but it puts it neatly under # the virtualization menu. source drivers/vhost/Kconfig -source drivers/virtio/Kconfig endif # VIRTUALIZATION diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig index bbdeb48..748ff19 100644 --- a/arch/sh/Kconfig +++ b/arch/sh/Kconfig @@ -897,20 +897,4 @@ source "security/Kconfig" source "crypto/Kconfig" -menuconfig VIRTUALIZATION - bool "Virtualization" - default n - ---help--- - Say Y here to get to see options for using your Linux host to run other - operating systems inside virtual machines (guests). - This option alone does not add any kernel code. - - If you say N, all options in this submenu will be skipped and disabled. - -if VIRTUALIZATION - -source drivers/virtio/Kconfig - -endif # VIRTUALIZATION - source "lib/Kconfig" diff --git a/arch/tile/kvm/Kconfig b/arch/tile/kvm/Kconfig index b88f9c0..669fcdb 100644 --- a/arch/tile/kvm/Kconfig +++ b/arch/tile/kvm/Kconfig @@ -33,6 +33,5 @@ config KVM If unsure, say N. source drivers/vhost/Kconfig -source drivers/virtio/Kconfig endif # VIRTUALIZATION diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig index 50f6364..65cf823 100644 --- a/arch/x86/kvm/Kconfig +++ b/arch/x86/kvm/Kconfig @@ -76,6 +76,5 @@ config KVM_MMU_AUDIT # the virtualization menu. source drivers/vhost/Kconfig source drivers/lguest/Kconfig -source drivers/virtio/Kconfig endif # VIRTUALIZATION diff --git a/drivers/Kconfig b/drivers/Kconfig index 3bb154d..795218e 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -114,6 +114,8 @@ source "drivers/uio/Kconfig" source "drivers/vlynq/Kconfig" +source "drivers/virtio/Kconfig" + source "drivers/xen/Kconfig" source "drivers/staging/Kconfig" diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig index 3dd629
Analysing a kernel panic
Hello all, one of my drivers is causing a kernel panic and I _think_ it happens in the 1st call to the interrupt routine. What kind of information can I extract from the following ? Is it like a core dump that I can load with the executable in the debugger to know exactly what happened (I doubt it) ? Oops: Exception in kernel mode, sig: 4 [#1] Xilinx Virtex last sysfs file: Modules linked in: xad NIP: c0002328 LR: c0011de8 CTR: c001d77c REGS: c778de20 TRAP: 0700 Not tainted (2.6.34) MSR: 00021030 CR: 2444 XER: TASK = c6ce80a0[241] 'SoftNoy' THREAD: c778c000 GPR00: c778ded0 c6ce80a0 0026 c6dbe000 e146dcab GPR08: 02134be0 20e7 0001 20e6 100265d8 1007c600 GPR16: 100acd0c 100822e4 1009024d bfa39a48 c7452080 c05bf0e8 c05bf02c c0207d6c GPR24: c778c03c 0004 c6cc7040 c05c1b88 0001 0004 c6cc73c0 0026 NIP [c0002328] set_context+0x0/0x10 LR [c0011de8] switch_mmu_context+0x194/0x1b8 Call Trace: [c778ded0] [c001a810] pick_next_task_fair+0xec/0x130 (unreliable) [c778def0] [c0203514] schedule+0x300/0x394 [c778df40] [c000f63c] recheck+0x0/0x24 Instruction dump: <> Kernel stack overflow in process c6ce80a0, r1=c778c070 NIP: c000d270 LR: c000f3c8 CTR: c0017fd0 REGS: c778bfc0 TRAP: 0501 Tainted: G D (2.6.34) MSR: 00029030 CR: 2448 XER: TASK = c6ce80a0[241] 'SoftNoy' THREAD: c778c000 GPR00: 00029030 c778c070 c6ce80a0 c778c090 0800 32d8 0001 0001 GPR08: 32da 00021032 c000d110 06ce82a8 NIP [c000d270] program_check_exception+0x160/0x228 LR [c000f3c8] ret_from_except_full+0x0/0x4c Call Trace: Instruction dump: 38090004 901f0080 48d8 3ca3 7fe4fb78 80df0080 60a50001 3865 48a8 7ca6 60008000 7c000124 <77c00c04> 41a20068 4bffef89 2f83fff2 Kernel panic - not syncing: kernel stack overflow Call Trace: Rebooting in 180 seconds.. My driver is xad.ko, though /dev/xps-acqui-data. The user program is SoftNoy. The code for the ISR (note that this code works fine on the same driver for a slightly different piece of custom hardware): static irqreturn_t XadIsr(int irq, void *dev_id) { Xad.control_reg->fin_in = 0; Xad.interrupt_reg->ISR = 1; Xad.interrupt_IPIF_reg->ISR = 4; Xad.control_reg->flux_address[0] = BUFFER_PHY_BASE + BUF_SZ*(++Xad.Icnt % BUF_NB); Xad.control_reg->flux_address[1] = Xad.control_reg->flux_address[0] + BUF_SZ/2; if (Xad.Icntflux_start=255;// Arm the next interrupt else { // There aren't any buffers available for the next read. We'll do the start in the read routine Xad.Suspended=1; Xad.OverflowsSinceLastRead++; Xad.Overflow++; DBG_ADD_CHAR('*'); if (Verbose) printk(KERN_WARNING SD "%dth buffer overflow: %d-%d=%d>=%d\n" FL, Xad.Overflow, Xad.Icnt, Xad.Rcnt, Xad.Icnt-Xad.Rcnt, BUF_NB); } wake_up_interruptible(&Xad.wait); return IRQ_HANDLED; } -- Guillaume Dargaud http://www.gdargaud.net/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC] [PATCH] hvc_console: improve tty/console put_chars handling
Hi folks, On Tue, Jul 05, 2011 at 04:22:43PM +1000, Benjamin Herrenschmidt wrote: > On Tue, 2011-07-05 at 04:17 +, Tabi Timur-B04825 wrote: > > On Mon, Jul 4, 2011 at 9:24 AM, Hendrik Brueckner > > wrote: > > > > I started that thread. After much soul searching, we came to the > > conclusion that HVC is not compatible with hypervisors that return > > BUSY on writes. > > That is a fun conclusion considering that hvc has been written for the > pseries hypervisor which ... can return BUSY on writes :-) > > We just need to fix HVC properly. So I took initiative and looked again into this issue. Below you can find a patch that is based on Ben's -EAGAIN idea. The hvc console layer takes care of retrying depending on the backend's return code. However, the main issue is that from a backend perspective, there is no difference between tty and console output. Because consoles, especially the preferred console, behave different than a simple tty. Blocked write to a preferred console can stop the system. So with the patch below, the backend can now indirectly control the way console output is handled for it. I still have to think if this solution is ok or if it is better to introduce a new callback to console output only (and might provide a default implemenatation similar to the patch below). NOTE: I did not yet test this patch but will do.. I just want to share it early to get feedback from you. -->8- Currently, the hvc_console_print() function drops console output if the hvc backend's put_chars() returns 0. This patch changes this behavior to allow a retry through returning -EAGAIN. This change also affects the hvc_push() function. Both functions are changed to handle -EAGAIN and to retry the put_chars() operation. If a hvc backend returns -EAGAIN, the retry handling differs: - hvc_console_print() spins to write the complete console output. - hvc_push() behaves the same way as for returning 0. Now hvc backends can indirectly control the way how console output is handled through the hvc console layer. Signed-off-by: Hendrik Brueckner --- drivers/tty/hvc/hvc_console.c |8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) --- a/drivers/tty/hvc/hvc_console.c +++ b/drivers/tty/hvc/hvc_console.c @@ -163,8 +163,10 @@ static void hvc_console_print(struct con } else { r = cons_ops[index]->put_chars(vtermnos[index], c, i); if (r <= 0) { - /* throw away chars on error */ - i = 0; + /* throw away characters on error +* but spin in case of -EAGAIN */ + if (r != -EAGAIN) + i = 0; } else if (r > 0) { i -= r; if (i > 0) @@ -448,7 +450,7 @@ static int hvc_push(struct hvc_struct *h n = hp->ops->put_chars(hp->vtermno, hp->outbuf, hp->n_outbuf); if (n <= 0) { - if (n == 0) { + if (n == 0 || n == -EAGAIN) { hp->do_wakeup = 1; return 0; } ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] spi/fsl_spi: fix CPM spi driver
Hi Grant, is this patch in your eyes ok to be scheduled for the next linux merge window or is something missing? Or should it go through the powerpc tree and not through your spi tree? Please let me know your opinion. Best regards Holger Brunck On 06/20/2011 06:31 PM, Holger Brunck wrote: > This patch fixes the freescale spi driver for CPM. Without this > patch SPI on CPM failed because cpm_muram_alloc_fixed tries to > allocate muram in an preserved area. The error reported was: > > mpc8xxx_spi f0011a80.spi: can't allocate spi parameter ram > mpc8xxx_spi: probe of f0011a80.spi failed with error -12 > > Now the driver uses of_iomap to get access to this area > similar to i2c driver driver in the i2c-cpm.c which has a > similar device tree node. This is tested on a MPC8247 with CPM2. > > Signed-off-by: Holger Brunck > cc: Grant Likely > cc: spi-devel-gene...@lists.sourceforge.net > --- > This was the same problem reported and discussed on ppc-dev for CPM1: > http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-September/085739.html > > drivers/spi/spi_fsl_spi.c | 28 +++- > 1 files changed, 11 insertions(+), 17 deletions(-) > > diff --git a/drivers/spi/spi_fsl_spi.c b/drivers/spi/spi_fsl_spi.c > index 7963c9b..ca57edf 100644 > --- a/drivers/spi/spi_fsl_spi.c > +++ b/drivers/spi/spi_fsl_spi.c > @@ -684,7 +684,7 @@ static unsigned long fsl_spi_cpm_get_pram(struct > mpc8xxx_spi *mspi) > struct device_node *np = dev->of_node; > const u32 *iprop; > int size; > - unsigned long spi_base_ofs; > + void __iomem *spi_base; > unsigned long pram_ofs = -ENOMEM; > > /* Can't use of_address_to_resource(), QE muram isn't at 0. */ > @@ -702,33 +702,27 @@ static unsigned long fsl_spi_cpm_get_pram(struct > mpc8xxx_spi *mspi) > return pram_ofs; > } > > - /* CPM1 and CPM2 pram must be at a fixed addr. */ > - if (!iprop || size != sizeof(*iprop) * 4) > - return -ENOMEM; > - > - spi_base_ofs = cpm_muram_alloc_fixed(iprop[2], 2); > - if (IS_ERR_VALUE(spi_base_ofs)) > - return -ENOMEM; > + spi_base = of_iomap(np, 1); > + if (spi_base == NULL) > + return -EINVAL; > > if (mspi->flags & SPI_CPM2) { > pram_ofs = cpm_muram_alloc(SPI_PRAM_SIZE, 64); > - if (!IS_ERR_VALUE(pram_ofs)) { > - u16 __iomem *spi_base = cpm_muram_addr(spi_base_ofs); > - > - out_be16(spi_base, pram_ofs); > - } > + out_be16(spi_base, pram_ofs); > } else { > - struct spi_pram __iomem *pram = cpm_muram_addr(spi_base_ofs); > + struct spi_pram __iomem *pram = spi_base; > u16 rpbase = in_be16(&pram->rpbase); > > /* Microcode relocation patch applied? */ > if (rpbase) > pram_ofs = rpbase; > - else > - return spi_base_ofs; > + else { > + pram_ofs = cpm_muram_alloc(SPI_PRAM_SIZE, 64); > + out_be16(spi_base, pram_ofs); > + } > } > > - cpm_muram_free(spi_base_ofs); > + iounmap(spi_base); > return pram_ofs; > } > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: pci_pcie_cap invalid on AER/EEH enabled PPC?
On Tue, Jul 5, 2011 at 10:41 AM, Richard A Lary wrote: > On 7/1/2011 1:00 PM, Richard A Lary wrote: >> >> On 7/1/2011 12:02 PM, Jon Mason wrote: >>> >>> On Fri, Jul 1, 2011 at 1:30 PM, Richard A Lary >>> wrote: On 7/1/2011 8:24 AM, Jon Mason wrote: > > I recently sent out a number of patches to migrate drivers calling > `pci_find_capability(pdef, PCI_CAP_ID_EXP)` to pci_pcie_cap. This > function takes uses a PCI-E capability offset that was determined by > calling pci_find_capability during the PCI bus walking. In response > to one of the patches, James Smart posted: > > "The reason is due to an issue on PPC platforms whereby use of > "pdev->is_pcie" and pci_is_pcie() will erroneously fail under some > conditions, but explicit search for the capability struct via > pci_find_capability() is always successful. I expect this to be due > a shadowing of pci config space in the hal/platform that isn't > sufficiently built up. We detected this issue while testing AER/EEH, > and are functional only if the pci_find_capability() option is used." > > See http://marc.info/?l=linux-scsi&m=130946649427828&w=2 for the whole > post. > > Based on his description above pci_pcie_cap > andpci_find_capability(pdef, PCI_CAP_ID_EXP) should be functionally > equivalent. If this is not safe, then the PCI bus walking code is > most likely busted on EEH enabled PPC systems (and that is a BIG > problem). Can anyone confirm this is still an issue? Jon, I applied the following debug patch to lpfc driver in a 2.6.32 distro kernel ( I had this one handy, I can try with mainline later today ) --- drivers/scsi/lpfc/lpfc_init.c | 10 10 + 0 - 0 ! 1 file changed, 10 insertions(+) Index: b/drivers/scsi/lpfc/lpfc_init.c === --- a/drivers/scsi/lpfc/lpfc_init.c +++ b/drivers/scsi/lpfc/lpfc_init.c @@ -3958,6 +3958,16 @@ lpfc_enable_pci_dev(struct lpfc_hba *phb pci_try_set_mwi(pdev); pci_save_state(pdev); + printk(KERN_WARNING "pcicap: is_pcie=%x pci_cap=%x pcie_type=%x\n", + pdev->is_pcie, + pdev->pcie_cap, + pdev->pcie_type); + + if (pci_is_pcie(pdev)) + printk(KERN_WARNING "pcicap: true\n"); + else + printk(KERN_WARNING "pcicap: false\n"); + /* PCIe EEH recovery on powerpc platforms needs fundamental reset */ if (pci_find_capability(pdev, PCI_CAP_ID_EXP)) pdev->needs_freset = 1; This is output upon driver load on an IBM Power 7 model 8233-E8B server. dmesg | grep pcicap Linux version 2.6.32.42-pcicap-ppc64 (geeko@buildhost) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP Fri Jul 1 09:31:27 PDT 2011 pcicap: is_pcie=0 pci_cap=0 pcie_type=0 pcicap: false pcicap: is_pcie=0 pci_cap=0 pcie_type=0 pcicap: false pcicap: is_pcie=0 pci_cap=0 pcie_type=0 pcicap: false pcicap: is_pcie=0 pci_cap=0 pcie_type=0 pcicap: false It would appear that the pcie information is not set in pci_dev structure for this device at the time the driver is being initialized during boot. >>> >>> Thanks for trying this. Can you confirm that the other devices in the >>> system have this issue as well (or show that it is isolated to the lpr >>> device)? You can add printks in set_pcie_port_type() to verify what >>> is being set on bus walking and to see when it is being called with >>> respect to when it is being populated by firmware. >> >> Jon, >> >> I will give this suggestion a try and post results > > On Power PC platforms, set_pcie_port_type() is not called. On Power PC, > pci_dev structure is initialized by of_create_pci_dev(). However, the > structure member pcie_cap is NOT computed nor set in this function. Yes, it is. of_create_pci_dev() calls set_pcie_port_type() http://lxr.linux.no/linux+v2.6.39/arch/powerpc/kernel/pci_of_scan.c#L144 That function sets pdev->pcie_cap http://lxr.linux.no/linux+v2.6.39/drivers/pci/probe.c#L896 So, it should be set. It looks like there is a bug in of_create_pci_dev, as set_pcie_port_type is being called BEFORE the BARs are setup. If you move set_pcie_port_type prior to pci_device_add (perhaps even after), then I bet the issue is resolved. Thanks, Jon > The information used to populate pci_dev comes from the Power PC > device_tree passed to the OS by Open Firmware. > > Based upon standing Power PC design, we cannot support patches > which replace pci_find_capability(pdef, PCI_CAP_ID_EXP) with > pci_is_pcie(pdev) on Power PC platforms. > > -rich > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: pci_pcie_cap invalid on AER/EEH enabled PPC?
On 7/1/2011 1:00 PM, Richard A Lary wrote: On 7/1/2011 12:02 PM, Jon Mason wrote: On Fri, Jul 1, 2011 at 1:30 PM, Richard A Lary wrote: On 7/1/2011 8:24 AM, Jon Mason wrote: I recently sent out a number of patches to migrate drivers calling `pci_find_capability(pdef, PCI_CAP_ID_EXP)` to pci_pcie_cap. This function takes uses a PCI-E capability offset that was determined by calling pci_find_capability during the PCI bus walking. In response to one of the patches, James Smart posted: "The reason is due to an issue on PPC platforms whereby use of "pdev->is_pcie" and pci_is_pcie() will erroneously fail under some conditions, but explicit search for the capability struct via pci_find_capability() is always successful. I expect this to be due a shadowing of pci config space in the hal/platform that isn't sufficiently built up. We detected this issue while testing AER/EEH, and are functional only if the pci_find_capability() option is used." See http://marc.info/?l=linux-scsi&m=130946649427828&w=2 for the whole post. Based on his description above pci_pcie_cap andpci_find_capability(pdef, PCI_CAP_ID_EXP) should be functionally equivalent. If this is not safe, then the PCI bus walking code is most likely busted on EEH enabled PPC systems (and that is a BIG problem). Can anyone confirm this is still an issue? Jon, I applied the following debug patch to lpfc driver in a 2.6.32 distro kernel ( I had this one handy, I can try with mainline later today ) --- drivers/scsi/lpfc/lpfc_init.c | 10 10 + 0 - 0 ! 1 file changed, 10 insertions(+) Index: b/drivers/scsi/lpfc/lpfc_init.c === --- a/drivers/scsi/lpfc/lpfc_init.c +++ b/drivers/scsi/lpfc/lpfc_init.c @@ -3958,6 +3958,16 @@ lpfc_enable_pci_dev(struct lpfc_hba *phb pci_try_set_mwi(pdev); pci_save_state(pdev); + printk(KERN_WARNING "pcicap: is_pcie=%x pci_cap=%x pcie_type=%x\n", + pdev->is_pcie, + pdev->pcie_cap, + pdev->pcie_type); + + if (pci_is_pcie(pdev)) + printk(KERN_WARNING "pcicap: true\n"); + else + printk(KERN_WARNING "pcicap: false\n"); + /* PCIe EEH recovery on powerpc platforms needs fundamental reset */ if (pci_find_capability(pdev, PCI_CAP_ID_EXP)) pdev->needs_freset = 1; This is output upon driver load on an IBM Power 7 model 8233-E8B server. dmesg | grep pcicap Linux version 2.6.32.42-pcicap-ppc64 (geeko@buildhost) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP Fri Jul 1 09:31:27 PDT 2011 pcicap: is_pcie=0 pci_cap=0 pcie_type=0 pcicap: false pcicap: is_pcie=0 pci_cap=0 pcie_type=0 pcicap: false pcicap: is_pcie=0 pci_cap=0 pcie_type=0 pcicap: false pcicap: is_pcie=0 pci_cap=0 pcie_type=0 pcicap: false It would appear that the pcie information is not set in pci_dev structure for this device at the time the driver is being initialized during boot. Thanks for trying this. Can you confirm that the other devices in the system have this issue as well (or show that it is isolated to the lpr device)? You can add printks in set_pcie_port_type() to verify what is being set on bus walking and to see when it is being called with respect to when it is being populated by firmware. Jon, I will give this suggestion a try and post results On Power PC platforms, set_pcie_port_type() is not called. On Power PC, pci_dev structure is initialized by of_create_pci_dev(). However, the structure member pcie_cap is NOT computed nor set in this function. The information used to populate pci_dev comes from the Power PC device_tree passed to the OS by Open Firmware. Based upon standing Power PC design, we cannot support patches which replace pci_find_capability(pdef, PCI_CAP_ID_EXP) with pci_is_pcie(pdev) on Power PC platforms. -rich ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: pci_pcie_cap invalid on AER/EEH enabled PPC?
On 7/5/2011 9:18 AM, Jon Mason wrote: On Tue, Jul 5, 2011 at 10:41 AM, Richard A Lary wrote: On 7/1/2011 1:00 PM, Richard A Lary wrote: On 7/1/2011 12:02 PM, Jon Mason wrote: On Fri, Jul 1, 2011 at 1:30 PM, Richard A Lary wrote: On 7/1/2011 8:24 AM, Jon Mason wrote: I recently sent out a number of patches to migrate drivers calling `pci_find_capability(pdef, PCI_CAP_ID_EXP)` to pci_pcie_cap. This function takes uses a PCI-E capability offset that was determined by calling pci_find_capability during the PCI bus walking. In response to one of the patches, James Smart posted: "The reason is due to an issue on PPC platforms whereby use of "pdev->is_pcie" and pci_is_pcie() will erroneously fail under some conditions, but explicit search for the capability struct via pci_find_capability() is always successful. I expect this to be due a shadowing of pci config space in the hal/platform that isn't sufficiently built up. We detected this issue while testing AER/EEH, and are functional only if the pci_find_capability() option is used." See http://marc.info/?l=linux-scsi&m=130946649427828&w=2 for the whole post. Based on his description above pci_pcie_cap andpci_find_capability(pdef, PCI_CAP_ID_EXP) should be functionally equivalent. If this is not safe, then the PCI bus walking code is most likely busted on EEH enabled PPC systems (and that is a BIG problem). Can anyone confirm this is still an issue? Jon, I applied the following debug patch to lpfc driver in a 2.6.32 distro kernel ( I had this one handy, I can try with mainline later today ) --- drivers/scsi/lpfc/lpfc_init.c | 10 10 + 0 - 0 ! 1 file changed, 10 insertions(+) Index: b/drivers/scsi/lpfc/lpfc_init.c === --- a/drivers/scsi/lpfc/lpfc_init.c +++ b/drivers/scsi/lpfc/lpfc_init.c @@ -3958,6 +3958,16 @@ lpfc_enable_pci_dev(struct lpfc_hba *phb pci_try_set_mwi(pdev); pci_save_state(pdev); + printk(KERN_WARNING "pcicap: is_pcie=%x pci_cap=%x pcie_type=%x\n", + pdev->is_pcie, + pdev->pcie_cap, + pdev->pcie_type); + + if (pci_is_pcie(pdev)) + printk(KERN_WARNING "pcicap: true\n"); + else + printk(KERN_WARNING "pcicap: false\n"); + /* PCIe EEH recovery on powerpc platforms needs fundamental reset */ if (pci_find_capability(pdev, PCI_CAP_ID_EXP)) pdev->needs_freset = 1; This is output upon driver load on an IBM Power 7 model 8233-E8B server. dmesg | grep pcicap Linux version 2.6.32.42-pcicap-ppc64 (geeko@buildhost) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP Fri Jul 1 09:31:27 PDT 2011 pcicap: is_pcie=0 pci_cap=0 pcie_type=0 pcicap: false pcicap: is_pcie=0 pci_cap=0 pcie_type=0 pcicap: false pcicap: is_pcie=0 pci_cap=0 pcie_type=0 pcicap: false pcicap: is_pcie=0 pci_cap=0 pcie_type=0 pcicap: false It would appear that the pcie information is not set in pci_dev structure for this device at the time the driver is being initialized during boot. Thanks for trying this. Can you confirm that the other devices in the system have this issue as well (or show that it is isolated to the lpr device)? You can add printks in set_pcie_port_type() to verify what is being set on bus walking and to see when it is being called with respect to when it is being populated by firmware. Jon, I will give this suggestion a try and post results On Power PC platforms, set_pcie_port_type() is not called. On Power PC, pci_dev structure is initialized by of_create_pci_dev(). However, the structure member pcie_cap is NOT computed nor set in this function. Yes, it is. of_create_pci_dev() calls set_pcie_port_type() http://lxr.linux.no/linux+v2.6.39/arch/powerpc/kernel/pci_of_scan.c#L144 That function sets pdev->pcie_cap http://lxr.linux.no/linux+v2.6.39/drivers/pci/probe.c#L896 So, it should be set. It looks like there is a bug in of_create_pci_dev, as set_pcie_port_type is being called BEFORE the BARs are setup. If you move set_pcie_port_type prior to pci_device_add (perhaps even after), then I bet the issue is resolved. The claim above was based upon observation that with this patch applied to a 2.6.32 kernel, the printk output did not appear in dmesg upon boot. static void set_pcie_hotplug_bridge(struct pci_dev *pdev) @@ -774,6 +780,8 @@ int pci_setup_device(struct pci_dev *dev u8 hdr_type; struct pci_slot *slot; + printk(KERN_WARNING "pcicap: setup_device %p\n", dev); + if (pci_read_config_byte(dev, PCI_HEADER_TYPE, &hdr_type)) return -EIO; I can make no claim about my understanding of pci device initialization on Power PC, so I have added Anton Blanchard to the cc list. Perhaps Anton can explain why pcie_cap is always 0 on Power PC. -rich The information used to populate pci_dev comes from the Power PC device_tree passed to the OS by Open Firmware. Based upon standing Power PC design, we cannot support patches which replace pci_find_capability(pdef, PCI_CAP_ID_EXP) with pci_is_pcie(pdev) on Power PC p
Re: [PATCH] spi/fsl_spi: fix CPM spi driver
On Mon, Jun 20, 2011 at 06:31:57PM +0200, Holger Brunck wrote: > This patch fixes the freescale spi driver for CPM. Without this > patch SPI on CPM failed because cpm_muram_alloc_fixed tries to > allocate muram in an preserved area. The error reported was: > > mpc8xxx_spi f0011a80.spi: can't allocate spi parameter ram > mpc8xxx_spi: probe of f0011a80.spi failed with error -12 > > Now the driver uses of_iomap to get access to this area > similar to i2c driver driver in the i2c-cpm.c which has a > similar device tree node. This is tested on a MPC8247 with CPM2. > > Signed-off-by: Holger Brunck > cc: Grant Likely > cc: spi-devel-gene...@lists.sourceforge.net Applied, thanks. g. > --- > This was the same problem reported and discussed on ppc-dev for CPM1: > http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-September/085739.html > > drivers/spi/spi_fsl_spi.c | 28 +++- > 1 files changed, 11 insertions(+), 17 deletions(-) > > diff --git a/drivers/spi/spi_fsl_spi.c b/drivers/spi/spi_fsl_spi.c > index 7963c9b..ca57edf 100644 > --- a/drivers/spi/spi_fsl_spi.c > +++ b/drivers/spi/spi_fsl_spi.c > @@ -684,7 +684,7 @@ static unsigned long fsl_spi_cpm_get_pram(struct > mpc8xxx_spi *mspi) > struct device_node *np = dev->of_node; > const u32 *iprop; > int size; > - unsigned long spi_base_ofs; > + void __iomem *spi_base; > unsigned long pram_ofs = -ENOMEM; > > /* Can't use of_address_to_resource(), QE muram isn't at 0. */ > @@ -702,33 +702,27 @@ static unsigned long fsl_spi_cpm_get_pram(struct > mpc8xxx_spi *mspi) > return pram_ofs; > } > > - /* CPM1 and CPM2 pram must be at a fixed addr. */ > - if (!iprop || size != sizeof(*iprop) * 4) > - return -ENOMEM; > - > - spi_base_ofs = cpm_muram_alloc_fixed(iprop[2], 2); > - if (IS_ERR_VALUE(spi_base_ofs)) > - return -ENOMEM; > + spi_base = of_iomap(np, 1); > + if (spi_base == NULL) > + return -EINVAL; > > if (mspi->flags & SPI_CPM2) { > pram_ofs = cpm_muram_alloc(SPI_PRAM_SIZE, 64); > - if (!IS_ERR_VALUE(pram_ofs)) { > - u16 __iomem *spi_base = cpm_muram_addr(spi_base_ofs); > - > - out_be16(spi_base, pram_ofs); > - } > + out_be16(spi_base, pram_ofs); > } else { > - struct spi_pram __iomem *pram = cpm_muram_addr(spi_base_ofs); > + struct spi_pram __iomem *pram = spi_base; > u16 rpbase = in_be16(&pram->rpbase); > > /* Microcode relocation patch applied? */ > if (rpbase) > pram_ofs = rpbase; > - else > - return spi_base_ofs; > + else { > + pram_ofs = cpm_muram_alloc(SPI_PRAM_SIZE, 64); > + out_be16(spi_base, pram_ofs); > + } > } > > - cpm_muram_free(spi_base_ofs); > + iounmap(spi_base); > return pram_ofs; > } > > -- > 1.7.1 > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] spi/fsl_spi: fix CPM spi driver
On Tue, Jul 05, 2011 at 04:31:50PM +0200, Holger Brunck wrote: > Hi Grant, > is this patch in your eyes ok to be scheduled for the next linux merge window > or > is something missing? Or should it go through the powerpc tree and not through > your spi tree? No, I just hadn't gotten to it yet. Sometimes I need to be pinged. I've merged it. g. > > Please let me know your opinion. > > Best regards > Holger Brunck > > On 06/20/2011 06:31 PM, Holger Brunck wrote: > > This patch fixes the freescale spi driver for CPM. Without this > > patch SPI on CPM failed because cpm_muram_alloc_fixed tries to > > allocate muram in an preserved area. The error reported was: > > > > mpc8xxx_spi f0011a80.spi: can't allocate spi parameter ram > > mpc8xxx_spi: probe of f0011a80.spi failed with error -12 > > > > Now the driver uses of_iomap to get access to this area > > similar to i2c driver driver in the i2c-cpm.c which has a > > similar device tree node. This is tested on a MPC8247 with CPM2. > > > > Signed-off-by: Holger Brunck > > cc: Grant Likely > > cc: spi-devel-gene...@lists.sourceforge.net > > --- > > This was the same problem reported and discussed on ppc-dev for CPM1: > > http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-September/085739.html > > > > drivers/spi/spi_fsl_spi.c | 28 +++- > > 1 files changed, 11 insertions(+), 17 deletions(-) > > > > diff --git a/drivers/spi/spi_fsl_spi.c b/drivers/spi/spi_fsl_spi.c > > index 7963c9b..ca57edf 100644 > > --- a/drivers/spi/spi_fsl_spi.c > > +++ b/drivers/spi/spi_fsl_spi.c > > @@ -684,7 +684,7 @@ static unsigned long fsl_spi_cpm_get_pram(struct > > mpc8xxx_spi *mspi) > > struct device_node *np = dev->of_node; > > const u32 *iprop; > > int size; > > - unsigned long spi_base_ofs; > > + void __iomem *spi_base; > > unsigned long pram_ofs = -ENOMEM; > > > > /* Can't use of_address_to_resource(), QE muram isn't at 0. */ > > @@ -702,33 +702,27 @@ static unsigned long fsl_spi_cpm_get_pram(struct > > mpc8xxx_spi *mspi) > > return pram_ofs; > > } > > > > - /* CPM1 and CPM2 pram must be at a fixed addr. */ > > - if (!iprop || size != sizeof(*iprop) * 4) > > - return -ENOMEM; > > - > > - spi_base_ofs = cpm_muram_alloc_fixed(iprop[2], 2); > > - if (IS_ERR_VALUE(spi_base_ofs)) > > - return -ENOMEM; > > + spi_base = of_iomap(np, 1); > > + if (spi_base == NULL) > > + return -EINVAL; > > > > if (mspi->flags & SPI_CPM2) { > > pram_ofs = cpm_muram_alloc(SPI_PRAM_SIZE, 64); > > - if (!IS_ERR_VALUE(pram_ofs)) { > > - u16 __iomem *spi_base = cpm_muram_addr(spi_base_ofs); > > - > > - out_be16(spi_base, pram_ofs); > > - } > > + out_be16(spi_base, pram_ofs); > > } else { > > - struct spi_pram __iomem *pram = cpm_muram_addr(spi_base_ofs); > > + struct spi_pram __iomem *pram = spi_base; > > u16 rpbase = in_be16(&pram->rpbase); > > > > /* Microcode relocation patch applied? */ > > if (rpbase) > > pram_ofs = rpbase; > > - else > > - return spi_base_ofs; > > + else { > > + pram_ofs = cpm_muram_alloc(SPI_PRAM_SIZE, 64); > > + out_be16(spi_base, pram_ofs); > > + } > > } > > > > - cpm_muram_free(spi_base_ofs); > > + iounmap(spi_base); > > return pram_ofs; > > } > > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: NAND BBT corruption on MPC83xx
On Fri, Jun 17, 2011 at 5:34 PM, Scott Wood wrote: > > It seems that the generic code always passes -1 with PAGEPROG, and only > provides the actual page address on SEQIN. > > I don't think the ECC readback is needed, and the fact that it looks like > it has always been broken would seem to confirm that. It's broken in > other ways, too -- it assumes a particular ECC layout. Let's get rid of it. > > As for the corruption, could it be degradation from repeated reads of that > one page? > I modified nanddump to do repeated reads, and compare the data obtained from the first iteration with that obtained later (to detect bit-flips). I tried 3 different variations: - one which reads the first page (2k) of the last block - one which reads the second page (2k) of the last block - one which reads the entire last block (128k), just for comparison As I understand it, read-disturb would primarily come into play when the second page is read, since it's adjacent to the first page (please correct me if I'm wrong there). Anyway, all 3 of these tests were run for at least 50 million read cycles, with no bit-flips detected. So I'm somewhat doubtful that this is the cause of the BBT corruption I've been seeing. Separately, I set up 2 test devices to run while I was away last week. One of them contained 2 patches: - Mike Hench's patch which eliminates this block of code in fsl_elbc_nand.c - Adam Thomson's patch (http://lists.infradead.org/pipermail/linux-mtd/2011-June/036427.html) which initializes oob_poi correctly Upon my return, the device with these patches saw no problems at all, and had no additional bad blocks. The device without these patches had some 200+ blocks which had been newly marked as bad in the BBT over the course of 10 days. After rebooting, this latter device then failed to boot, as shown here: http://mcreech.com/work/bbt-ecc-error4.txt I'm currently running another test to verify which of the two patches actually fixed this problem (which might take a few days), but it seems like removing that block of code in fsl_elbc_nand.c is a good idea. -- Matthew L. Creech ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] mtd: eLBC NAND: remove bogus ECC read-back
From: Mike Hench The eLBC NAND driver currently follows up each program/write operation with a read-back of the page, in order to [ostensibly] fill in ECC data for the caller. However, the page address used for this read is always -1, so the read will never work correctly. Remove this useless (and potentially problematic) block of code. Signed-off-by: Matthew L. Creech --- drivers/mtd/nand/fsl_elbc_nand.c | 17 - 1 files changed, 0 insertions(+), 17 deletions(-) diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c index 0bb254c..050a2fc 100644 --- a/drivers/mtd/nand/fsl_elbc_nand.c +++ b/drivers/mtd/nand/fsl_elbc_nand.c @@ -455,23 +455,6 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command, fsl_elbc_run_command(mtd); - /* Read back the page in order to fill in the ECC for the -* caller. Is this really needed? -*/ - if (full_page && elbc_fcm_ctrl->oob_poi) { - out_be32(&lbc->fbcr, 3); - set_addr(mtd, 6, page_addr, 1); - - elbc_fcm_ctrl->read_bytes = mtd->writesize + 9; - - fsl_elbc_do_read(chip, 1); - fsl_elbc_run_command(mtd); - - memcpy_fromio(elbc_fcm_ctrl->oob_poi + 6, - &elbc_fcm_ctrl->addr[elbc_fcm_ctrl->index], 3); - elbc_fcm_ctrl->index += 3; - } - elbc_fcm_ctrl->oob_poi = NULL; return; } -- 1.6.3.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mtd: eLBC NAND: remove bogus ECC read-back
On Tue, 5 Jul 2011 15:59:57 -0400 "Matthew L. Creech" wrote: > From: Mike Hench > > The eLBC NAND driver currently follows up each program/write operation with a > read-back of the page, in order to [ostensibly] fill in ECC data for the > caller. However, the page address used for this read is always -1, so the read > will never work correctly. Remove this useless (and potentially problematic) > block of code. > > Signed-off-by: Matthew L. Creech > --- > drivers/mtd/nand/fsl_elbc_nand.c | 17 - > 1 files changed, 0 insertions(+), 17 deletions(-) > > diff --git a/drivers/mtd/nand/fsl_elbc_nand.c > b/drivers/mtd/nand/fsl_elbc_nand.c > index 0bb254c..050a2fc 100644 > --- a/drivers/mtd/nand/fsl_elbc_nand.c > +++ b/drivers/mtd/nand/fsl_elbc_nand.c > @@ -455,23 +455,6 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, > unsigned int command, > > fsl_elbc_run_command(mtd); > > - /* Read back the page in order to fill in the ECC for the > - * caller. Is this really needed? > - */ > - if (full_page && elbc_fcm_ctrl->oob_poi) { > - out_be32(&lbc->fbcr, 3); > - set_addr(mtd, 6, page_addr, 1); > - > - elbc_fcm_ctrl->read_bytes = mtd->writesize + 9; > - > - fsl_elbc_do_read(chip, 1); > - fsl_elbc_run_command(mtd); > - > - memcpy_fromio(elbc_fcm_ctrl->oob_poi + 6, > - &elbc_fcm_ctrl->addr[elbc_fcm_ctrl->index], 3); > - elbc_fcm_ctrl->index += 3; > - } > - > elbc_fcm_ctrl->oob_poi = NULL; > return; > } All references to elbc_fcm_ctrl->oob_poi (not chip->oob_poi) can be removed now. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: pci_pcie_cap invalid on AER/EEH enabled PPC?
On 7/5/2011 10:22 AM, Richard A Lary wrote: On 7/5/2011 9:18 AM, Jon Mason wrote: On Tue, Jul 5, 2011 at 10:41 AM, Richard A Lary wrote: On 7/1/2011 1:00 PM, Richard A Lary wrote: On 7/1/2011 12:02 PM, Jon Mason wrote: On Fri, Jul 1, 2011 at 1:30 PM, Richard A Lary wrote: On 7/1/2011 8:24 AM, Jon Mason wrote: I recently sent out a number of patches to migrate drivers calling `pci_find_capability(pdef, PCI_CAP_ID_EXP)` to pci_pcie_cap. This function takes uses a PCI-E capability offset that was determined by calling pci_find_capability during the PCI bus walking. In response to one of the patches, James Smart posted: "The reason is due to an issue on PPC platforms whereby use of "pdev->is_pcie" and pci_is_pcie() will erroneously fail under some conditions, but explicit search for the capability struct via pci_find_capability() is always successful. I expect this to be due a shadowing of pci config space in the hal/platform that isn't sufficiently built up. We detected this issue while testing AER/EEH, and are functional only if the pci_find_capability() option is used." See http://marc.info/?l=linux-scsi&m=130946649427828&w=2 for the whole post. Based on his description above pci_pcie_cap andpci_find_capability(pdef, PCI_CAP_ID_EXP) should be functionally equivalent. If this is not safe, then the PCI bus walking code is most likely busted on EEH enabled PPC systems (and that is a BIG problem). Can anyone confirm this is still an issue? Jon, I applied the following debug patch to lpfc driver in a 2.6.32 distro kernel ( I had this one handy, I can try with mainline later today ) --- drivers/scsi/lpfc/lpfc_init.c | 10 10 + 0 - 0 ! 1 file changed, 10 insertions(+) Index: b/drivers/scsi/lpfc/lpfc_init.c === --- a/drivers/scsi/lpfc/lpfc_init.c +++ b/drivers/scsi/lpfc/lpfc_init.c @@ -3958,6 +3958,16 @@ lpfc_enable_pci_dev(struct lpfc_hba *phb pci_try_set_mwi(pdev); pci_save_state(pdev); + printk(KERN_WARNING "pcicap: is_pcie=%x pci_cap=%x pcie_type=%x\n", + pdev->is_pcie, + pdev->pcie_cap, + pdev->pcie_type); + + if (pci_is_pcie(pdev)) + printk(KERN_WARNING "pcicap: true\n"); + else + printk(KERN_WARNING "pcicap: false\n"); + /* PCIe EEH recovery on powerpc platforms needs fundamental reset */ if (pci_find_capability(pdev, PCI_CAP_ID_EXP)) pdev->needs_freset = 1; This is output upon driver load on an IBM Power 7 model 8233-E8B server. dmesg | grep pcicap Linux version 2.6.32.42-pcicap-ppc64 (geeko@buildhost) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP Fri Jul 1 09:31:27 PDT 2011 pcicap: is_pcie=0 pci_cap=0 pcie_type=0 pcicap: false pcicap: is_pcie=0 pci_cap=0 pcie_type=0 pcicap: false pcicap: is_pcie=0 pci_cap=0 pcie_type=0 pcicap: false pcicap: is_pcie=0 pci_cap=0 pcie_type=0 pcicap: false It would appear that the pcie information is not set in pci_dev structure for this device at the time the driver is being initialized during boot. Thanks for trying this. Can you confirm that the other devices in the system have this issue as well (or show that it is isolated to the lpr device)? You can add printks in set_pcie_port_type() to verify what is being set on bus walking and to see when it is being called with respect to when it is being populated by firmware. Jon, I will give this suggestion a try and post results On Power PC platforms, set_pcie_port_type() is not called. On Power PC, pci_dev structure is initialized by of_create_pci_dev(). However, the structure member pcie_cap is NOT computed nor set in this function. Yes, it is. of_create_pci_dev() calls set_pcie_port_type() http://lxr.linux.no/linux+v2.6.39/arch/powerpc/kernel/pci_of_scan.c#L144 That function sets pdev->pcie_cap http://lxr.linux.no/linux+v2.6.39/drivers/pci/probe.c#L896 So, it should be set. It looks like there is a bug in of_create_pci_dev, as set_pcie_port_type is being called BEFORE the BARs are setup. If you move set_pcie_port_type prior to pci_device_add (perhaps even after), then I bet the issue is resolved. The claim above was based upon observation that with this patch applied to a 2.6.32 kernel, the printk output did not appear in dmesg upon boot. static void set_pcie_hotplug_bridge(struct pci_dev *pdev) @@ -774,6 +780,8 @@ int pci_setup_device(struct pci_dev *dev u8 hdr_type; struct pci_slot *slot; + printk(KERN_WARNING "pcicap: setup_device %p\n", dev); + if (pci_read_config_byte(dev, PCI_HEADER_TYPE, &hdr_type)) return -EIO; I can make no claim about my understanding of pci device initialization on Power PC, so I have added Anton Blanchard to the cc list. Perhaps Anton can explain why pcie_cap is always 0 on Power PC. I pulled down 3.0-rc6 kernel, I will build and test the pci_is_pcie(pdev) patch in lpfc driver now that set_pcie_port_type() is called from of_create_pci_dev(). -rich The information used to populate pci_dev comes from the Power PC device_tree passed to the OS by Open Firmware. B
[PATCH v2] mtd: eLBC NAND: remove elbc_fcm_ctrl->oob_poi
From: Mike Hench The eLBC NAND driver currently follows up each program/write operation with a read-back of the page, in order to [ostensibly] fill in ECC data for the caller. However, the page address used for this read is always -1, so the read will never work correctly. Remove this useless (and potentially problematic) block of code. v2: elbc_fcm_ctrl->oob_poi is removed entirely, since this code block was the only place it was actually used. Signed-off-by: Matthew L. Creech --- drivers/mtd/nand/fsl_elbc_nand.c | 25 - 1 files changed, 0 insertions(+), 25 deletions(-) diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c index 0bb254c..5e4fbf5 100644 --- a/drivers/mtd/nand/fsl_elbc_nand.c +++ b/drivers/mtd/nand/fsl_elbc_nand.c @@ -75,7 +75,6 @@ struct fsl_elbc_fcm_ctrl { unsigned int use_mdr;/* Non zero if the MDR is to be set */ unsigned int oob;/* Non zero if operating on OOB data */ unsigned int counter;/* counter for the initializations */ - char *oob_poi; /* Place to write ECC after read back*/ }; /* These map to the positions used by the FCM hardware ECC generator */ @@ -454,25 +453,6 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command, } fsl_elbc_run_command(mtd); - - /* Read back the page in order to fill in the ECC for the -* caller. Is this really needed? -*/ - if (full_page && elbc_fcm_ctrl->oob_poi) { - out_be32(&lbc->fbcr, 3); - set_addr(mtd, 6, page_addr, 1); - - elbc_fcm_ctrl->read_bytes = mtd->writesize + 9; - - fsl_elbc_do_read(chip, 1); - fsl_elbc_run_command(mtd); - - memcpy_fromio(elbc_fcm_ctrl->oob_poi + 6, - &elbc_fcm_ctrl->addr[elbc_fcm_ctrl->index], 3); - elbc_fcm_ctrl->index += 3; - } - - elbc_fcm_ctrl->oob_poi = NULL; return; } @@ -752,13 +732,8 @@ static void fsl_elbc_write_page(struct mtd_info *mtd, struct nand_chip *chip, const uint8_t *buf) { - struct fsl_elbc_mtd *priv = chip->priv; - struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = priv->ctrl->nand; - fsl_elbc_write_buf(mtd, buf, mtd->writesize); fsl_elbc_write_buf(mtd, chip->oob_poi, mtd->oobsize); - - elbc_fcm_ctrl->oob_poi = chip->oob_poi; } static int fsl_elbc_chip_init(struct fsl_elbc_mtd *priv) -- 1.6.3.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] virtio: expose for non-virtualization users too
On 07/05/2011 07:06 AM, Ohad Ben-Cohen wrote: > virtio has been so far used only in the context of virtualization, > and the virtio Kconfig was sourced directly by the relevant arch > Kconfigs when VIRTUALIZATION was selected. > > Now that we start using virtio for inter-processor communications, > we need to source the virtio Kconfig outside of the virtualization > scope too. > Seems reasonable to me. -hpa ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] mtd: eLBC NAND: remove elbc_fcm_ctrl->oob_poi
On Tue, 5 Jul 2011 18:35:02 -0400 "Matthew L. Creech" wrote: > From: Mike Hench > > The eLBC NAND driver currently follows up each program/write operation with a > read-back of the page, in order to [ostensibly] fill in ECC data for the > caller. However, the page address used for this read is always -1, so the read > will never work correctly. Remove this useless (and potentially problematic) > block of code. > > v2: elbc_fcm_ctrl->oob_poi is removed entirely, since this code block was the > only place it was actually used. Just noticed, full_page can come out as well. Otherwise, ACK -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] mtd: eLBC NAND: remove elbc_fcm_ctrl->oob_poi
On Tue, Jul 5, 2011 at 7:01 PM, Scott Wood wrote: > > Just noticed, full_page can come out as well. > > Otherwise, ACK > Oh right, didn't notice that - thanks. -- Matthew L. Creech ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3] mtd: eLBC NAND: remove elbc_fcm_ctrl->oob_poi
From: Mike Hench The eLBC NAND driver currently follows up each program/write operation with a read-back of the page, in order to [ostensibly] fill in ECC data for the caller. However, the page address used for this read is always -1, so the read will never work correctly. Remove this useless (and potentially problematic) block of code. v2: elbc_fcm_ctrl->oob_poi is removed entirely, since this code block was the only place it was actually used. v3: local 'full_page' variable is no longer used either. Signed-off-by: Matthew L. Creech --- drivers/mtd/nand/fsl_elbc_nand.c | 33 ++--- 1 files changed, 2 insertions(+), 31 deletions(-) diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c index 0bb254c..b4d310f 100644 --- a/drivers/mtd/nand/fsl_elbc_nand.c +++ b/drivers/mtd/nand/fsl_elbc_nand.c @@ -75,7 +75,6 @@ struct fsl_elbc_fcm_ctrl { unsigned int use_mdr;/* Non zero if the MDR is to be set */ unsigned int oob;/* Non zero if operating on OOB data */ unsigned int counter;/* counter for the initializations */ - char *oob_poi; /* Place to write ECC after read back*/ }; /* These map to the positions used by the FCM hardware ECC generator */ @@ -435,7 +434,6 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command, /* PAGEPROG reuses all of the setup from SEQIN and adds the length */ case NAND_CMD_PAGEPROG: { - int full_page; dev_vdbg(priv->dev, "fsl_elbc_cmdfunc: NAND_CMD_PAGEPROG " "writing %d bytes.\n", elbc_fcm_ctrl->index); @@ -445,34 +443,12 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command, * write so the HW generates the ECC. */ if (elbc_fcm_ctrl->oob || elbc_fcm_ctrl->column != 0 || - elbc_fcm_ctrl->index != mtd->writesize + mtd->oobsize) { + elbc_fcm_ctrl->index != mtd->writesize + mtd->oobsize) out_be32(&lbc->fbcr, elbc_fcm_ctrl->index); - full_page = 0; - } else { + else out_be32(&lbc->fbcr, 0); - full_page = 1; - } fsl_elbc_run_command(mtd); - - /* Read back the page in order to fill in the ECC for the -* caller. Is this really needed? -*/ - if (full_page && elbc_fcm_ctrl->oob_poi) { - out_be32(&lbc->fbcr, 3); - set_addr(mtd, 6, page_addr, 1); - - elbc_fcm_ctrl->read_bytes = mtd->writesize + 9; - - fsl_elbc_do_read(chip, 1); - fsl_elbc_run_command(mtd); - - memcpy_fromio(elbc_fcm_ctrl->oob_poi + 6, - &elbc_fcm_ctrl->addr[elbc_fcm_ctrl->index], 3); - elbc_fcm_ctrl->index += 3; - } - - elbc_fcm_ctrl->oob_poi = NULL; return; } @@ -752,13 +728,8 @@ static void fsl_elbc_write_page(struct mtd_info *mtd, struct nand_chip *chip, const uint8_t *buf) { - struct fsl_elbc_mtd *priv = chip->priv; - struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = priv->ctrl->nand; - fsl_elbc_write_buf(mtd, buf, mtd->writesize); fsl_elbc_write_buf(mtd, chip->oob_poi, mtd->oobsize); - - elbc_fcm_ctrl->oob_poi = chip->oob_poi; } static int fsl_elbc_chip_init(struct fsl_elbc_mtd *priv) -- 1.6.3.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: pci_pcie_cap invalid on AER/EEH enabled PPC?
On 7/5/2011 1:34 PM, Richard A Lary wrote: On 7/5/2011 10:22 AM, Richard A Lary wrote: On 7/5/2011 9:18 AM, Jon Mason wrote: On Tue, Jul 5, 2011 at 10:41 AM, Richard A Lary wrote: On 7/1/2011 1:00 PM, Richard A Lary wrote: On 7/1/2011 12:02 PM, Jon Mason wrote: On Fri, Jul 1, 2011 at 1:30 PM, Richard A Lary wrote: On 7/1/2011 8:24 AM, Jon Mason wrote: I recently sent out a number of patches to migrate drivers calling `pci_find_capability(pdef, PCI_CAP_ID_EXP)` to pci_pcie_cap. This function takes uses a PCI-E capability offset that was determined by calling pci_find_capability during the PCI bus walking. In response to one of the patches, James Smart posted: "The reason is due to an issue on PPC platforms whereby use of "pdev->is_pcie" and pci_is_pcie() will erroneously fail under some conditions, but explicit search for the capability struct via pci_find_capability() is always successful. I expect this to be due a shadowing of pci config space in the hal/platform that isn't sufficiently built up. We detected this issue while testing AER/EEH, and are functional only if the pci_find_capability() option is used." See http://marc.info/?l=linux-scsi&m=130946649427828&w=2 for the whole post. Based on his description above pci_pcie_cap andpci_find_capability(pdef, PCI_CAP_ID_EXP) should be functionally equivalent. If this is not safe, then the PCI bus walking code is most likely busted on EEH enabled PPC systems (and that is a BIG problem). Can anyone confirm this is still an issue? Jon, I applied the following debug patch to lpfc driver in a 2.6.32 distro kernel ( I had this one handy, I can try with mainline later today ) --- drivers/scsi/lpfc/lpfc_init.c | 10 10 + 0 - 0 ! 1 file changed, 10 insertions(+) Index: b/drivers/scsi/lpfc/lpfc_init.c === --- a/drivers/scsi/lpfc/lpfc_init.c +++ b/drivers/scsi/lpfc/lpfc_init.c @@ -3958,6 +3958,16 @@ lpfc_enable_pci_dev(struct lpfc_hba *phb pci_try_set_mwi(pdev); pci_save_state(pdev); + printk(KERN_WARNING "pcicap: is_pcie=%x pci_cap=%x pcie_type=%x\n", + pdev->is_pcie, + pdev->pcie_cap, + pdev->pcie_type); + + if (pci_is_pcie(pdev)) + printk(KERN_WARNING "pcicap: true\n"); + else + printk(KERN_WARNING "pcicap: false\n"); + /* PCIe EEH recovery on powerpc platforms needs fundamental reset */ if (pci_find_capability(pdev, PCI_CAP_ID_EXP)) pdev->needs_freset = 1; This is output upon driver load on an IBM Power 7 model 8233-E8B server. dmesg | grep pcicap Linux version 2.6.32.42-pcicap-ppc64 (geeko@buildhost) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP Fri Jul 1 09:31:27 PDT 2011 pcicap: is_pcie=0 pci_cap=0 pcie_type=0 pcicap: false pcicap: is_pcie=0 pci_cap=0 pcie_type=0 pcicap: false pcicap: is_pcie=0 pci_cap=0 pcie_type=0 pcicap: false pcicap: is_pcie=0 pci_cap=0 pcie_type=0 pcicap: false It would appear that the pcie information is not set in pci_dev structure for this device at the time the driver is being initialized during boot. Thanks for trying this. Can you confirm that the other devices in the system have this issue as well (or show that it is isolated to the lpr device)? You can add printks in set_pcie_port_type() to verify what is being set on bus walking and to see when it is being called with respect to when it is being populated by firmware. Jon, I will give this suggestion a try and post results On Power PC platforms, set_pcie_port_type() is not called. On Power PC, pci_dev structure is initialized by of_create_pci_dev(). However, the structure member pcie_cap is NOT computed nor set in this function. Yes, it is. of_create_pci_dev() calls set_pcie_port_type() http://lxr.linux.no/linux+v2.6.39/arch/powerpc/kernel/pci_of_scan.c#L144 That function sets pdev->pcie_cap http://lxr.linux.no/linux+v2.6.39/drivers/pci/probe.c#L896 So, it should be set. It looks like there is a bug in of_create_pci_dev, as set_pcie_port_type is being called BEFORE the BARs are setup. If you move set_pcie_port_type prior to pci_device_add (perhaps even after), then I bet the issue is resolved. The claim above was based upon observation that with this patch applied to a 2.6.32 kernel, the printk output did not appear in dmesg upon boot. static void set_pcie_hotplug_bridge(struct pci_dev *pdev) @@ -774,6 +780,8 @@ int pci_setup_device(struct pci_dev *dev u8 hdr_type; struct pci_slot *slot; + printk(KERN_WARNING "pcicap: setup_device %p\n", dev); + if (pci_read_config_byte(dev, PCI_HEADER_TYPE, &hdr_type)) return -EIO; I can make no claim about my understanding of pci device initialization on Power PC, so I have added Anton Blanchard to the cc list. Perhaps Anton can explain why pcie_cap is always 0 on Power PC. I pulled down 3.0-rc6 kernel, I will build and test the pci_is_pcie(pdev) patch in lpfc driver now that set_pcie_port_type() is called from of_create_pci_dev(). Jon, I applied the debug patches mentioned above along with the lpfc patch ht
Re: pci_pcie_cap invalid on AER/EEH enabled PPC?
> On Power PC platforms, set_pcie_port_type() is not called. On Power PC, > pci_dev structure is initialized by of_create_pci_dev(). However, the > structure member pcie_cap is NOT computed nor set in this function. Just a quick correction here, please don't say "On Power PC platforms" such generic statements that only apply to IBM pSeries platforms running under pHyp :-) There's plenty of other platforms supported in arch/powerpc that have very different characteristics and use more "generic" code to build their PCI layout. > The information used to populate pci_dev comes from the Power PC > device_tree passed to the OS by Open Firmware. > > Based upon standing Power PC design, we cannot support patches > which replace pci_find_capability(pdef, PCI_CAP_ID_EXP) with > pci_is_pcie(pdev) on Power PC platforms. No, that isn't correct. We can (and should) fix our arch code to do the right thing. There is no reason why those two wouldn't be equivalent. If we are missing a call to set_pcie_port_type() then we should add it, however if I look at our upstream code, pci_of_scan.c seems to be calling that, so it could be a missing backport ? Can you try with an upstream kernel ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: pci_pcie_cap invalid on AER/EEH enabled PPC?
On Tue, 2011-07-05 at 17:14 -0700, Richard A Lary wrote: > I applied the debug patches mentioned above along with the lpfc patch > http://marc.info/?l=linux-scsi&m=130919648513685&w=2 > to linux 3.0-rc6 kernel. > > The debug patches show that pci_dev members "is_pcie, pci_cap and pcie_type" > are > now all being set to correct values now that 'of_create_pci_dev()' calls > 'set_pcie_port_type()'. I was not able to determine when this patch went in. git is good for that :-) bb209c8287d2d55ec4a67e3933346e0a3ee0da76: Author: Benjamin Herrenschmidt 2010-01-27 04:10:03 Committer: Benjamin Herrenschmidt 2010-01-29 16:51:10 Parent: 4406c56d0a4da7a37b9180abeaece6cd00bcc874 (Merge branch 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6) Child: 26b4a0ca46985ae9586c194f7859f3838b1230f8 (powerpc/pci: Add missing hookup to pci_slot) Branches: many (38) Follows: v2.6.33-rc5 Precedes: v2.6.33-rc7 powerpc/pci: Add calls to set_pcie_port_type() and set_pcie_hotplug_bridge() We are missing these when building the pci_dev from scratch off the Open Firmware device-tree Signed-off-by: Benjamin Herrenschmidt Acked-by: Jesse Barnes We should probably backport it to .32-stable. Any volunteer ? You might also want to consider for backport: 26b4a0ca46985ae9586c194f7859f3838b1230f8 and 94afc008e1e6fbadfac0b75fcf193b6d7074b2f1 > My tests show that lpfc driver now recovers from injected PCIe bus errors > using test the 'if (pci_is_pcie(pdev))' for PCIe adapter type. > > I did not apply the test patch which changed the location of > set_pcie_port_type(dev) in of_create_pci_dev(). I can apply and test > this change if you think it is necessary? No I think we call it in the right place, which mirrors pci_setup_device(), that is before the early quirk. > Based upon these results, I will ACK the change to the lpfc driver for > "[PATCH 03/19] lpfc: remove unnecessary read of PCI_CAP_ID_EXP". > I suspect that other drivers which are modified to use 'if > (pci_is_pcie(pdev))' > will work on Power PC as well, but I did not test any drivers other than lpfc. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] sm501: When registering the GPIO, turn on the GPIO unit's power
When attempting to use GPIO via the sm501 unit on the TQM5200 board, GPIO operations would only function if during the same boot u-boot's "fkt led" command had initialized the sm501. Comparing the sm501's registers with and without running the "fkt led" command turned up one significant difference: u-boot had enabled the GPIO power gate. Changing the Linux sm501 driver to enable the GPIO power gate allows GPIO to work without first initializing it with u-boot. Signed-off-by: Josh Triplett --- drivers/mfd/sm501.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/mfd/sm501.c b/drivers/mfd/sm501.c index df3702c..d7a0ab9 100644 --- a/drivers/mfd/sm501.c +++ b/drivers/mfd/sm501.c @@ -1089,6 +1089,7 @@ static int __devinit sm501_register_gpio(struct sm501_devdata *sm) goto err_low_chip; } + sm501_unit_power(sm->dev, SM501_GATE_GPIO, 1); gpio->registered = 1; return 0; @@ -1118,6 +1119,8 @@ static void sm501_gpio_remove(struct sm501_devdata *sm) if (!sm->gpio.registered) return; + sm501_unit_power(sm->dev, SM501_GATE_GPIO, 0); + ret = gpiochip_remove(&gpio->low.gpio); if (ret) dev_err(sm->dev, "cannot remove low chip, cannot tidy up\n"); -- 1.7.5.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] mtd/nand : don't free the global data fsl_lbc_ctrl_dev->nand in fsl_elbc_chip_remove()
On Tue, 2011-06-28 at 09:50 +0800, b35...@freescale.com wrote: > From: Liu Shuo > > The global data fsl_lbc_ctrl_dev->nand don't have to be freed in > fsl_elbc_chip_remove(). The right place to do that is in > fsl_elbc_nand_remove() > if elbc_fcm_ctrl->counter is zero. > > Signed-off-by: Liu Shuo Changed the subject to something shorted and pushed to l2-mtd-2.6.git, thanks. -- Best Regards, Artem Bityutskiy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev