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

[David Daney <ddaney@caviumnetworks.com>]

On 03/17/2017 07:13 AM, Ulf Hansson wrote:
> On 10 March 2017 at 14:25, Jan Glauber <jglauber@cavium.com> 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