lkml.org 
[lkml]   [2015]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2 20/28] ARCv2: barriers
    On Tue, Jun 23, 2015 at 10:03:25AM +0100, Vineet Gupta wrote:
    > On Tuesday 23 June 2015 02:19 PM, Will Deacon wrote:
    > >> +/*
    > >> > + * MMIO can also get buffered/optimized in micro-arch, so barriers needed
    > >> > + * Based on ARM model for the typical use case
    > >> > + *
    > >> > + * <writel_relaxed DMA buffer>
    > >> > + * <writel MMIO "go" reg>
    > >> > + * or:
    > >> > + * <readl MMIO "status" reg>
    > >> > + * <readl_relaxed DMA buffer>
    > > The writel_relaxed/readl_relaxed parts here would actually just be
    > > bog-standard loads and stores to an in-memory buffer. I was trying too hard
    > > to show the barrier semantics and accidentally turned the DMA buffers into
    > > __iomem regions.
    >
    > Not sure if I follow you completely :-)

    D'oh, sorry.

    > IMHO, It doesn't matter if we are dealing with a typical DMA buffer (cached) or a
    > buffer descriptor (typically uncached unless there's hardware IO-coh or some
    > such). Both the cases assume a vanilla ld/st to buffer (using relaxed API) with a
    > surrounding MMIO access.

    It's more that you should only pass __iomem pointers (i.e. stuff you got
    back from something like ioremap) to readl_relaxed/writel_relaxed and that's
    not typically how you would allocate your DMA buffer.

    > > If you fix the comment:
    >
    > Does this look better ?
    >
    > - * <writel_relaxed DMA buffer>
    > + * <writel_relaxed DMA buffer (cached or uncached)>

    I'd just replace 'writel_relaxed' with whatever your store instruction is
    (ST)?

    Will


    \
     
     \ /
      Last update: 2015-06-23 11:41    [W:5.974 / U:0.000 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site