Re: [PATCH] Fix DMA nodes in the MPC8610 HPCD device tree
On May 31, 2008, at 12:27 AM, Paul Mackerras wrote: Timur Tabi writes: The node for DMA2 in the MPC8610 HPCD device tree has the wrong compatible properties. This breaks the DMA driver and the sound driver. Signed-off-by: Timur Tabi [EMAIL PROTECTED] --- I have no idea how I let this bug slip in, but this is a must-fix for 2.6.26. Kumar, do you have anything else for 2.6.26 at the moment? If not, and this patch is OK with you, I'll put it in along with Olof's two patches and send them to Linus. Does anyone else have any pending fixes for 2.6.26? I don't. I want/need to do defconfig updates but that can wait if you plan on getting this out over the weekend. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v4] [POWERPC] Move to runtime allocated exception stacks
On May 31, 2008, at 12:04 AM, Paul Mackerras wrote: Kumar Gala writes: For the additonal exception levels (critical, debug, machine check) on 40x/book-e we were using static allocations of the stack in the associated head.S. Move to a runtime allocation to make the code a bit easier to read as we mimic how we handle IRQ stacks. Its also a bit easier to setup the stack with a dummy thread_info in C code. Looks fine, with just one very minor comment: - addir11,r11,THREAD_SIZE; \ -1: subi r11,r11,INT_FRAME_SIZE; /* Allocate an exception frame */\ +1: addir11,r11,THREAD_SIZE; \ + subir11,r11,INT_FRAME_SIZE; /* Allocate an exception frame */\ You could make that a single addi r11,r11,THREAD_SIZE-INT_FRAME_SIZE now. I remember noticing that and thinking I should go back in fix. Will look at doing that and add the patches to my powerpc-next tree. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Linus, Please pull from the 'merge' branch of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge to get four more bug-fixes for powerpc (including Ben's patch adding memory clobbers to the asm for I/O accessors) and a pasemi defconfig update. Thanks, Paul. arch/powerpc/boot/dts/mpc8610_hpcd.dts | 10 +- arch/powerpc/configs/pasemi_defconfig | 172 +--- arch/ppc/kernel/ppc_ksyms.c|2 drivers/pcmcia/electra_cf.c|1 include/asm-powerpc/io.h | 12 +- 5 files changed, 126 insertions(+), 71 deletions(-) Benjamin Herrenschmidt (1): [POWERPC] Add memory clobber to MMIO accessors Olof Johansson (2): electra_cf: Add MODULE_DEVICE_TABLE() [POWERPC] pasemi: update pasemi_defconfig, enable electra_cf Timur Tabi (1): [POWERPC] Fix DMA nodes in the MPC8610 HPCD device tree Tony Breeds (1): [POWERPC] Export empty_zero_page and copy_page in arch/ppc ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MMIO and gcc re-ordering issue
On Thu, May 29, 2008 at 10:47:18AM -0400, Jes Sorensen wrote: Thats not going to solve the problem on Altix. On Altix the issue is that there can be multiple paths through the NUMA fabric from cpuX to PCI bridge Y. Consider this uber-cooltm ascii art - NR is my abbrevation for NUMA router: --- --- |cpu X| |cpu Y| --- --- | \ /| |\/ | |/\ | | / \| - -- |NR 1| |NR 2| -- -- \ / \ / --- | PCI | --- The problem is that your two writel's, despite being both issued on cpu X, due to the spin lock, in your example, can end up with the first one going through NR 1 and the second one going through NR 2. If there's contention on NR 1, the write going via NR 2 may hit the PCI bridge prior to the one going via NR 1. We don't actually have that problem on the Altix. All writes issued by CPU X will be ordered with respect to each other. But writes by CPU X and CPU Y will not be, unless an mmiowb() is done by the original CPU before the second CPU writes. I.e. CPU X writel CPU X writel CPU X mmiowb CPU Y writel ... Note that this implies some sort of locking. Also note that if in the above, CPU Y did the mmiowb, that would not work. jeremy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MMIO and gcc re-ordering issue
On Fri, May 30, 2008 at 10:21:00AM -0700, Jesse Barnes wrote: On Friday, May 30, 2008 2:36 am Jes Sorensen wrote: James Bottomley wrote: The only way to guarantee ordering in the above setup, is to either make writel() fully ordered or adding the mmiowb()'s inbetween the two writel's. On Altix you have to go and read from the PCI brige to ensure all writes to it have been flushed, which is also what mmiowb() is doing. If writel() was to guarantee this ordering, it would make every writel() call extremely expensive :-( So if a read from the bridge achieves the same effect, can't we just put one after the writes within the spinlock (an unrelaxed one). That way A relaxed readX would be sufficient. It's the next lowest cost way (after mmiowb) of ensuring write ordering between CPUs. Regular readX is the most expensive method (well, we could probably come up with something worse, but we'd have to work at it :). this whole sequence will look like a well understood PCI posting flush rather than have to muck around with little understood (at least by most driver writers) io barriers? Hmmm, I think mmiowb() does some sort of status read from the bridge, I am not sure if it's enough to just do a regular readl(). I'm adding Jeremy to the list, he should know for sure. I think a read from the target host bridge is enough. What mmiowb() does though is to read a *local* host bridge register, which contains a count of the number of PIO ops still in flight on their way to their target bridge. When it reaches 0, all PIOs have arrived at the target host bridge (they still may be bufferd), so ordering is guaranteed. Note that is the main advantage over a read. There is no round trip across the NUMA fabric. jeremy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver
Hi. On Fri, May 30, 2008 at 05:19:30PM -0500, Kim Phillips ([EMAIL PROTECTED]) wrote: ok, I see what you are saying now; if a channel gets done during talitos_done processing, it'll trigger an interrupt and reset priv-status, leaving the tasklet in the dark as to which channel has done status, depending on how many channel dones it has already processed. I think the only solution here is to call flush_channel on each channel, regardless of the bits in the interrupt status - I'll send out a patch shortly. Out of curiosity, what is number of channels? I had simialar issue with HIFN crypto driver and limited number of descriptor to 80 iirc, since with that number HIFN traversal did not show perfromance degradataion on Ghz x86. callback, during that time cached status and priv itself (and tail like in two simultaneous flushes) could change (or not?) I think you're talking about a different 'status' here; flush_channel's local 'status' doesn't resemble priv-status bits in any way, it looks at the descriptor header writeback bits for done status, on a per descriptor basis. It forwards this descriptor done vs. error status to the callback. priv itself won't change; it's uniquely associated to the device. I meant descriptor hdr value accessed via it - can it be checked in tasklet under the lock and in submit path without? Can they correlate somehow? -- Evgeniy Polyakov ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix DMA nodes in the MPC8610 HPCD device tree
On Sat, 31 May 2008 15:27:30 +1000 Paul Mackerras [EMAIL PROTECTED] wrote: Does anyone else have any pending fixes for 2.6.26? I don't. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
