Re: [PATCH] arch/microblaze: Added sync method support for DMA andmade refinements

[Michal Simek]

Eli Billauer wrote:
> Michal Simek wrote:
>
> > DMA_TO_DEVICE is fine - data has to be flushed.
> >
> > For DMA_FROM_DEVICE you expect that allocated space will contains data 
> > from device.
> > Which means if you flush them, they will be rewritten by DMA in the 
> > next step.
> > Which means that IMHO you can invalidate them which is faster than 
> > flushing.
> The flushing is only necessary when a certain memory region is written 
> to, not flushed, and then allocated for DMA from device. This is not 
> what drivers usually do, but it's nevertheless legal to do so. Maybe it 
> can also happen as a result of memory being freed but not flushed, and 
> then allocated as a DMA buffer. So this flushing prevents, at most, an 
> extremely rare problem. I don't expect to see something go wrong right 
> away in the lack of this flush.

I prefer to fix the real problems. If you can't see any real problem,
please do not fix theoretical one. I am open to accept your comments
that it is safer to use flush. Look at my second email and add it to 3rd patch.

> In light of this, I can't see why flushing would be slower than 
> invalidation, if the cache lines aren't expected to be dirty except for 
> very rare conditions.

If they are not dirty, flushing/invalidation time should be the same.
But if they are, invalidation is faster.


> As for invalidation of a dirty cache line: Looking at the Microblaze 
> reference manual's description of the wdc instruction, I'm under the 
> impression that each cache line has two flags: Valid and Dirty, as they 
> appear in the pseudocode. I'm not on the clear about what happens if a 
> dirty cache line is invalidated. It would make sense to clear both 
> flags. It also makes sense to write the data back to the RAM in this 
> case. But I really don't know what's actually implemented.

AFAIK if a dirty cache line is invalidated data is just removed from flash
and there is not and you do invalidation - CPU using cache lines(on BE) and writing
data to memory. There could be a lot of stall cycles.

Thanks,
Michal




--
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/