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
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: 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: 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-cool 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
[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
