hverkuil: sailus: for cached MMAP buffers, do you think it would make sense to allow mixing cached and uncached buffers in one queue?
or rather, would it be justified in any way?
tfiga: I guess there are cases where some buffers are touched by the CPU and some not.
Whether the application can know that at the buffer queue time is another thing, but I guess in principle that use case exists.
tfiga: is there a reason why you would want it to be a queue property instead of a buffer property?
sailus: for that case I guess you could just ask for cached and use the no_cache_flush/invalidate flags at queue time
hverkuil: it's just dma_attrs currently is a queue property
similarly, we can't mix different memory types
so not mixing different allocation attributes could at least be consistent
from implementation complexity it doesn't really change too much
it's more about not overdesigning things
tfiga: Given those flags, do you think there are cases where uncached buffers are really needed?
Usually accessing those with CPU is extremely slow.
And cache flushing operations can be skipped with the flags.
tfiga: ah, ok, now I understand. Having this queue-specific seems reasonable to me.
sailus: big linear writes to write combine mappings are not so slow
and they don't trash cashes
caches*
they are also okay for things like bitstream
e.g. decoder input
on some platforms big burst reads from uncached buffers are also not that bad
there is also the usual compatibility claim :)
I think we need to keep the behavior of uncached mappings by default