Re: [PATCH v12 4/9] mmc: cavium: Work-around hardware bug on cn6xxx and cnf7xxx

[David Daney]

On 03/17/2017 07:13 AM, Ulf Hansson wrote:
> On 10 March 2017 at 14:25, Jan Glauber <jglauber@xxxxxxxxxx> wrote:
> > Prevent data corruption on cn6xxx and cnf7xxx.
> > Due to an imperfection in the design of the MMC bus hardware,
> > the 2nd to last cache block of a DMA read must be locked into the L2
> > cache.
[...]
> > +/**
> > + * Unlock a memory region in the L2 cache
> > + *
> > + * @start - start address to unlock
> > + * @len - length to unlock in bytes
> > + */
> > +void l2c_unlock_mem_region(u64 start, u64 len)
> > +{
> > +       u64 end;
> > +
> > +       /* Round start/end to cache line boundaries */
> > +       end = ALIGN(start + len - 1, CVMX_CACHE_LINE_SIZE);
> > +       start = ALIGN(start, CVMX_CACHE_LINE_SIZE);
> > +
> > +       while (start <= end) {
> > +               l2c_unlock_line(start);
> > +               start += CVMX_CACHE_LINE_SIZE;
> > +       }
> > +}
> > +EXPORT_SYMBOL_GPL(l2c_unlock_mem_region);
>
> It seems like we should be able to implement these functions in the
> octeon mmc driver, instead of having to export some SoC specific APIs.
> You only need to figure out how to find the correct CACHE_LINE_SIZE,
> but that should be possible to fix.

It doesn't matter which source file the code lives in.  If you are happy 
having it in drivers/mmc/host/cavium-pltfm-octeon.c (or whatever we end 
up calling the file), it could be put there.

CVMX_CACHE_LINE_SIZE == 128.  It will never change.


> My point is really that we should avoid exporting SoC specific APIs
> which shall be called from drivers. This is old fashion.

Some people find it objectionable to see 1-off architecture specific 
in-line asm in a driver file, but I agree that putting it as close to 
the user as possible makes sense.

David Daney