Re: Implementing IOMMU support for SDHCI

[Peter Maydell]

On Fri, 28 Feb 2020 at 10:08, Sai Pavan Boddu <address@hidden> 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