Re: Is adding offset to dma address is valid operation?

[Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>]

On 26/03/18 13:31, Harsh Jain wrote:
> 
> 
> On 26-03-2018 17:15, Robin Murphy wrote:
>> Hi Harsh,
>> 
>> On 26/03/18 10:55, Harsh Jain wrote:
>>> Hi,
>>> 
>>> Can we add  offset to dma address received from IOMMU in
>>> scatter/Gather list before sending it to H/W.
>>> 
>>> Address to HW = sg_dma_address(sg) + offset, where 0 < offset <
>>> sg_dma_len(sg).
>> 
>> sg_dma_address() should already account for sg->offset (i.e. the
>> start of the buffer within the page. If there's a DMA API
>> implementation failing to respect that then that's a bug.
>> 
>>> I need this operation to make sure our H/W does not receives
>>> entry of size greater than 2K.
>> 
>> If however it's just that you want to fragment a single SG entry
>> into multiple commaneds/descriptors/etc. internally to your driver,
>> then I can't see that being an issue as long as you don't visibly
>> modify the scatterlist itself. If there's a genuine length and/or
>> alignment limitation in the hardware, though, it would be better to
>> set up dev->dma_parms appropriately to describe them, such that the
>> subsystem responsible for generating the scatterlist respects the
>> appropriate constraints in the first place (and if it doesn't, then
>> that's another bug to fix).
> Can dma_parms  handle 2K size limit ? Because dma_map_sg() returns <=
> passed nents. But in my case nents will increase.

The point is that dma_map_sg() should still never increase nents, 
because the guy *creating* the scatterlist is also expected to respect 
dma_parms where it exists, such that nents would be appropriate to start 
with. That said, it does look like there are some places (e.g. the block 
layer) which may not cope properly with limits less than PAGE_SIZE, so I 
guess the reliability of dma_parms might depend on how much you want to 
go spelunking in core code :/

Robin.