On Tuesday, October 13, 2015 at 02:17:53 AM, Thomas Chou wrote:
Hi Marek,
Hi!
On 10/12/2015 09:46 PM, Marek Vasut wrote:
On Monday, October 12, 2015 at 02:55:03 PM, Thomas Chou wrote:
Hi Marek,
Hi Thomas,
On 10/12/2015 06:32 PM, Marek Vasut wrote:
Wouldn't invalidate_dcache_range() be enough here ? You don't care about the data in the newly allocated area at this point I guess -- either you fill them in and then flush, for DMA from CPU to device OR you receive data from device to CPU and then you invalidate this buffer again.
No. We cannot use invalidate cache here. This is related to cache design of nios2, kind of direct mapped cache.
Can you please expand on this ?
This is rather hardware depended.
Please refer to page 7 about cache implementation on the "Nios II Core Implementation Detail" manual,
https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ hb/nios2/n2cpu_nii51015.pdf
And page 227, 8-44 about initd and initda instructions on the "Nios II Classic Processor Reference Guide",
https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ hb/nios2/n2cpu_nii5v1.pdf
The initda instruction might do the job.
I'd say that's the instruction we need, yep.
But nios2 cpu with 4 bytes dcache line size does not support this instruction. So we don't implement the invalidate_dcache_range/all() in u-boot yet.
Where did you find this information ?
Of course, we can add the invalidate cache ops if we can drop the support of nios2 cpu with 4 bytes dcache line size.
btw. I was thinking about this whole cache situation. Please don't get me wrong, my intention is not to put way more work unto you and/or grind you about minor details. I hope it doesn't look that way to you.
No worries. It is just that I had very little free time last night to give more details. You are welcome.
Thanks!
Best regards, Marek Vasut