[U-Boot] DMA bounce buffer in FAT code

[Jean-Jacques Hiblot]

On 11/01/2017 01:33, Benoît Thébaudeau wrote:
> Dear Jean-Jacques,
>
> On Tue, Jan 10, 2017 at 12:35 PM, Jean-Jacques Hiblot <jjhiblot at ti.com> wrote:
>> commits 8133f43d and cc63b25e introduced buffer bouncing at the level of the
>> FAT fs driver. I came across those because of printf() saying that the
>> buffer is not aligned when I save my env in file on a FAT partition. Those
>> messages are annoying because they lead to think that there's a problem when
>> saving the environment. We could move them to debug() or at least indicate
>> that's only a warning.
> That would be fine. I would have a small preference for debug() here.
>
>> However I think that removing the bounce buffer mechanism altogether is
>> better option. The alignment constraint doesn't belong at this level and
>> indeed there are controllers that do not require it at all (those not using
>> DMA for once). It could be moved to the block level and activated only if
>> the driver for the controller needs it. Or it could be left to the driver of
>> the controller do implement it.
> Indeed. This was my first idea at the time of these commits, but it
> required too many changes as this was before the introduction of DM.
> The best way to go nowadays is probably to move the bounce buffer
> mechanism to the block driver, using it if and only if the underlying
> storage driver has flagged somewhere that it needs it. Doing it at a
> lower level would require to duplicate this mechanism, which would not
> be great. Note that this mechanism may also be present in other FS
> drivers.
I checked the code of other fs and couldn't find bounce buffering there.
However I found a common implementation of bounce buffering in 
comon/bouncebuf.c. It also takes care of the cache handling for the DMA.
Users of the API are device drivers, not higher level code (FS or 
block). IMHO it's the best way to go, because doing it at the block 
level may hurt the performances of platforms that do not require it.
I'd suggest that bounce buffering is removed from FAT and the proper fix 
added in the driver that misses it.

In the case of fsl_esdhc.c, I think the problem comes from the cache 
handling when the buffer is not aligned. It can be fixed by using bounce 
buffers or it can be fixed by allowing cache operations to perform even 
when unaligned addresses are used. I'll post a separate email to 
describe this.

Jean-Jacques


>
>> I'm willing to prepare the patches for the modifications if you think they
>> make sense.
> Thanks.
>
> Best regards,
> Benoît