On Tue, Mar 21, 2017 at 4:19 PM, David Daney <ddaney@xxxxxxxxxxxxxxxxxx> wrote:
> On 03/21/2017 01:58 AM, Arnd Bergmann wrote:
>>
>> On Mon, Mar 20, 2017 at 9:45 PM, David Daney <ddaney@xxxxxxxxxxxxxxxxxx>
>> wrote:
>>>
>>> On 03/17/2017 07:13 AM, Ulf Hansson wrote:
>>>>
>>>> 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.
>>
>>
>> The proper solution might be to create an architecture independent
>> interface
>> for it, what it is that the function does. Can you explain what the
>> purpose
>> of locking/unlocking the cache line for MMC is? Is this something that
>> could be done more generally in the dma_map_ops implementation?
>
>
> It is a 1-off erratum workaround that is only needed on fewer than five
> models/revisions of a mips64 based SoC family. As such, creating a general
> purpose, architecture independent, framework is clearly not the proper
> approach.
If this is just for maintaining coherency of the DMA operation inbetween,
then there is already a generic API for that, which the driver calls.
Adding the workaround into octeon_dma_map_sg() would be a way
to abstract the platform erratum from the driver.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
