[lkml]   [2010]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Re: USB mass storage and ARM cache coherency
    SORRY - one more message to apologise for the multiple reposts (and
    automatically appended legal disclaimer). I've been moved to Exchange
    2007 and trying to use Evolution + Exchange-MAPI. It looks like it went
    terribly wrong.


    On Wed, 2010-02-17 at 15:40 +0000, Catalin Marinas wrote:
    > On Wed, 2010-02-17 at 20:05 +1100, Benjamin Herrenschmidt wrote:
    > > On Tue, 2010-02-16 at 09:22 +0100, Oliver Neukum wrote:
    > > > This seems wrong to me. Buffers for control transfers may be
    > > > transfered
    > > > by DMA, so the caches must be flushed on architectures whose caches
    > > > are not coherent with respect to DMA.
    > > >=20
    > > > Would you care to elaborate on the exact nature of the bug you are
    > > > fixing?
    > >=20
    > > I missed part of this thread, so forgive me if I'm a bit off here, but
    > > if the problem is indeed I$/D$ cache coherency vs. PIO transfers, then
    > > this is a long solved issue on other archs such as ppc (and I _think_
    > > sparc).
    > The thread I started was indeed regarding I/D cache coherency and PIO.
    > But it diverged into DMA issues a few days ago (should have been a new
    > thread).
    > > The way we do it, at least on powerpc which is PIPT, is to keep track on
    > > a per-page basis, whether a given page is clean for execution using
    > > PG_arch1 bit. This bit is cleared when a new page is popped into the
    > > page cache, and we clear it from flush_dcache_page() iirc (you may want
    > > to dbl check I don't have the code at hand right now, or rather, I do
    > > but I'm to lazy to look right now :-)
    > We do the same on ARM. The problem with most (all) HCD drivers that do
    > PIO is that they copy the data to the transfer buffer but there is no
    > call in this driver to flush_dcache_page(). The upper mass storage or
    > filesystem layers don't call this function either, so there isn't
    > anything that would set the PG_arch1 bit.
    > --=20
    > Catalin
    > --
    > IMPORTANT NOTICE: The contents of this email and any attachments are
    > confidential and may also be privileged. If you are not the intended
    > recipient, please notify the sender immediately and do not disclose
    > the contents to any other person, use it for any purpose, or store or
    > copy the information in any medium. Thank you.
    > _______________________________________________
    > linux-arm-kernel mailing list

     \ /
      Last update: 2010-02-17 17:21    [W:0.025 / U:95.716 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site