Hi Marek,
On 10/17/2015 07:03 AM, Marek Vasut wrote:
I would suggest the "cache alignment check and skip" be removed from cache flush ops, and say out the DMA buffer allocation rule loudly in README, and enforce it by guardianship.
What exactly do you envision by this "guardianship" ?
I mean the reviews of custodians.
Please allow me to restate the reasons,
- The cache flush ops are commonly used. Please refer to the "Cache and
TLB Flushing Under Linux" doc, linux/Documentation/cachetlb.txt. Violating the defined interface is much worse than violating coding style. It will certainly impact the portability of u-boot. And might introduce more bug than resolve.
I agree with this one.
- We all agree that enforcing DMA buffer allocation to cache aligned is
the only real solution. Adding such "check and skip" to cache flush ops cannot prevent the flush or solve the problem.
We should probably check-scream-skip here.
- Though the flush size of block device are usually aligned, the size
of packet are not. Asking the packet drivers to adjust the flush size does not make sense. It is the job of cache flush ops. The debug probe should not override the original purpose. It should be spelled for common understanding.
The socket buffer(s) should be aligned, so network packets should be fine.
While the start of socket buffer might be aligned, the size of the transfer might not for the send ops. It is depended on the net/tcp/ip packets size.
For example, with tftp, there is a lot of unaligned end of packets.
tftp d1000000 u-boot-dtb.bin
flush unaligned d7ff7020-d7ff704e [repeat ..]
So, such an alarm may be false. And such a skip can be bug.
In fact, for my own projects, I have changed the memory allocation to always cache aligned. And I rarely worry about it ever after.
I look at the net.c of u-boot. There are packets buffer allocated on BSS and stack. I would suggest avoid such programming, and use aligned memory allocation stead.
Best regards, Thomas