On Fri, 28 Feb 2020 at 10:08, Sai Pavan Boddu <saip...@xilinx.com> wrote: > [Sai Pavan Boddu] Our idea is to create dma helper function which can also > pass the MemTxAttr i.e like > dma_memory_rw_attr (AddressSpace *as, dma_addr_t addr, > void *buf, dma_addr_t len, > DMADirection dir, > MemTxAttrs attr) > which needs to be used in sdhci, with "AddressSpace *as" pointing to smmu.
Yes, you want to be able to pass MemTxAttrs from devices using the dma APIs. (Or you could just call dma_barrier() yourself before directly using an address_space_* function.) Plumbing that through is straightforward. As an aside, we are enormously inconsistent about whether devices use dma_memory_* functions or just directly do address_space_* calls. I think the intention is that the dma_memory_* include necessary memory barriers, but it's not clear to me at least when the barriers are necessary or why we have this family of functions that some devices use and most just don't. > I see we don’t need QOM variant of MemTxAttr for this functionality, >but thought it would be good to use " object_add_link_property/ >object_set_link_property " to set the values from machine file's. >I would drop this idea, and look for other options to set the attributes. The attributes of a transaction are set by the thing generating the transactions (either the CPU, or the DMA device, whatever it is). Typically they're either fixed, or possibly configurable at a hardware level, or sometimes configurable by software. I don't think any of those scenarios are ones where you'd want the board model to be passing in a MemTxAttr at device creation time. thanks -- PMM
