On Thu, Oct 16, 2014 at 10:23:07AM -0700, Olav Haugan wrote:
> On 10/15/2014 2:16 AM, Thierry Reding wrote:
> >Perhaps make the return value ssize_t so that we can propagate errors?
> >
>
> I am fine with that. Joerg?
I am not so sure this is a good idea. On error the function should
return the s
On 10/15/2014 2:16 AM, Thierry Reding wrote:
On Mon, Oct 06, 2014 at 12:02:47PM -0700, Olav Haugan wrote:
On 9/25/2014 10:01 AM, Joerg Roedel wrote:
On Mon, Aug 11, 2014 at 03:45:50PM -0700, Olav Haugan wrote:
+static inline int iommu_map_sg(struct iommu_domain *domain, unsigned long iova,
+
On Mon, Oct 06, 2014 at 12:02:47PM -0700, Olav Haugan wrote:
> On 9/25/2014 10:01 AM, Joerg Roedel wrote:
> >On Mon, Aug 11, 2014 at 03:45:50PM -0700, Olav Haugan wrote:
> >>+static inline int iommu_map_sg(struct iommu_domain *domain, unsigned long
> >>iova,
> >>+ struct s
On 9/25/2014 10:01 AM, Joerg Roedel wrote:
On Mon, Aug 11, 2014 at 03:45:50PM -0700, Olav Haugan wrote:
+static inline int iommu_map_sg(struct iommu_domain *domain, unsigned long iova,
+ struct scatterlist *sg, unsigned int nents,
+ int p
On Mon, Aug 11, 2014 at 03:45:50PM -0700, Olav Haugan wrote:
> +static inline int iommu_map_sg(struct iommu_domain *domain, unsigned long
> iova,
> +struct scatterlist *sg, unsigned int nents,
> +int prot, unsigned long flags)
> +{
> + re
Hi Konrad,
On Wednesday 20 August 2014 09:02:50 Konrad Rzeszutek Wilk wrote:
> On Tue, Aug 19, 2014 at 10:52:46PM +0200, Laurent Pinchart wrote:
> > On Tuesday 19 August 2014 11:40:24 Olav Haugan wrote:
> > > On 8/19/2014 9:11 AM, Laurent Pinchart wrote:
> > > > On Tuesday 19 August 2014 13:59:54
On Tue, Aug 19, 2014 at 10:52:46PM +0200, Laurent Pinchart wrote:
> On Tuesday 19 August 2014 11:40:24 Olav Haugan wrote:
> > On 8/19/2014 9:11 AM, Laurent Pinchart wrote:
> > > On Tuesday 19 August 2014 13:59:54 Joerg Roedel wrote:
> > >> On Mon, Aug 18, 2014 at 03:47:56PM -0700, Olav Haugan wrote
On Tue, Aug 19, 2014 at 10:52:46PM +0200, Laurent Pinchart wrote:
> On Tuesday 19 August 2014 11:40:24 Olav Haugan wrote:
> > On 8/19/2014 9:11 AM, Laurent Pinchart wrote:
> > > On Tuesday 19 August 2014 13:59:54 Joerg Roedel wrote:
> > >> On Mon, Aug 18, 2014 at 03:47:56PM -0700, Olav Haugan wrote
On Tuesday 19 August 2014 11:40:24 Olav Haugan wrote:
> On 8/19/2014 9:11 AM, Laurent Pinchart wrote:
> > On Tuesday 19 August 2014 13:59:54 Joerg Roedel wrote:
> >> On Mon, Aug 18, 2014 at 03:47:56PM -0700, Olav Haugan wrote:
> >>> If the alignment is not correct then iommu_map() will return error
On 8/19/2014 9:11 AM, Laurent Pinchart wrote:
> On Tuesday 19 August 2014 13:59:54 Joerg Roedel wrote:
>> On Mon, Aug 18, 2014 at 03:47:56PM -0700, Olav Haugan wrote:
>>> If the alignment is not correct then iommu_map() will return error. Not
>>> sure what other option we have here (and why make it
On 8/19/2014 4:59 AM, Joerg Roedel wrote:
> On Mon, Aug 18, 2014 at 03:47:56PM -0700, Olav Haugan wrote:
>> If the alignment is not correct then iommu_map() will return error. Not
>> sure what other option we have here (and why make it different behavior
>> than iommu_map which just return error wh
On Tuesday 19 August 2014 13:59:54 Joerg Roedel wrote:
> On Mon, Aug 18, 2014 at 03:47:56PM -0700, Olav Haugan wrote:
> > If the alignment is not correct then iommu_map() will return error. Not
> > sure what other option we have here (and why make it different behavior
> > than iommu_map which just
On Mon, Aug 18, 2014 at 03:47:56PM -0700, Olav Haugan wrote:
> If the alignment is not correct then iommu_map() will return error. Not
> sure what other option we have here (and why make it different behavior
> than iommu_map which just return error when it is not aligned properly).
> I don't think
On 8/18/2014 2:55 PM, Joerg Roedel wrote:
> On Mon, Aug 11, 2014 at 03:45:50PM -0700, Olav Haugan wrote:
>> +int default_iommu_map_sg(struct iommu_domain *domain, unsigned long iova,
>> + struct scatterlist *sg, unsigned int nents,
>> + int prot, unsigned lon
On Mon, Aug 11, 2014 at 03:45:50PM -0700, Olav Haugan wrote:
> +int default_iommu_map_sg(struct iommu_domain *domain, unsigned long iova,
> + struct scatterlist *sg, unsigned int nents,
> + int prot, unsigned long flags)
> +{
> + int ret = 0;
> + un
On 8/18/2014 2:26 PM, j...@8bytes.org wrote:
> On Mon, Aug 18, 2014 at 01:48:46PM -0700, Olav Haugan wrote:
>> On 8/18/2014 11:32 AM, Rob Clark wrote:
>
>> No, I do not have other uses right now. But could imagine use cases like
>> "force mapping" flag etc.
>
> I think it is worth discussing to
On Mon, Aug 18, 2014 at 01:48:46PM -0700, Olav Haugan wrote:
> On 8/18/2014 11:32 AM, Rob Clark wrote:
> No, I do not have other uses right now. But could imagine use cases like
> "force mapping" flag etc.
I think it is worth discussing to add a flush() function to the
IOMMU-API. I sent a patch-
On 8/18/2014 11:32 AM, Rob Clark wrote:
> On Mon, Aug 18, 2014 at 10:07 AM, j...@8bytes.org wrote:
>> On Tue, Aug 12, 2014 at 09:56:11AM -0700, Olav Haugan wrote:
>>> On 8/12/2014 3:48 AM, Rob Clark wrote:
iirc, one plan for 'flags' was some sort of DONT_FLUSH_TLB flag for
drivers which
On Mon, Aug 18, 2014 at 10:07 AM, j...@8bytes.org wrote:
> On Tue, Aug 12, 2014 at 09:56:11AM -0700, Olav Haugan wrote:
>> On 8/12/2014 3:48 AM, Rob Clark wrote:
>> > iirc, one plan for 'flags' was some sort of DONT_FLUSH_TLB flag for
>> > drivers which wanted to map/unmap N buffers with a single
On Tue, Aug 12, 2014 at 09:56:11AM -0700, Olav Haugan wrote:
> On 8/12/2014 3:48 AM, Rob Clark wrote:
> > iirc, one plan for 'flags' was some sort of DONT_FLUSH_TLB flag for
> > drivers which wanted to map/unmap N buffers with a single flush at the
> > end. There might have been some other usages
Hi Laurent,
On 8/12/2014 9:55 AM, Laurent Pinchart wrote:
> Hi Olav,
>
> Thank you for the patch.
>
> On Monday 11 August 2014 15:45:50 Olav Haugan wrote:
>> Mapping and unmapping are more often than not in the critical path.
>> map_sg and unmap_sg allows IOMMU driver implementations to optimize
On 8/12/2014 3:48 AM, Rob Clark wrote:
> On Mon, Aug 11, 2014 at 9:51 PM, Hiroshi Doyu wrote:
>> Hi Olav,
>>
>> Olav Haugan writes:
>>
>>> @@ -93,6 +94,10 @@ enum iommu_attr {
>>> * @detach_dev: detach device from an iommu domain
>>> * @map: map a physically contiguous memory region to an iom
Hi Olav,
Thank you for the patch.
On Monday 11 August 2014 15:45:50 Olav Haugan wrote:
> Mapping and unmapping are more often than not in the critical path.
> map_sg and unmap_sg allows IOMMU driver implementations to optimize
> the process of mapping and unmapping buffers into the IOMMU page tab
On 8/11/2014 6:35 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Aug 11, 2014 at 03:45:50PM -0700, Olav Haugan wrote:
> .. snip..
>> +for_each_sg(sg, s, nents, i) {
>> +phys_addr_t phys = page_to_phys(sg_page(s));
>> +size_t page_len = s->offset + s->length;
>> +
>> +
On Mon, Aug 11, 2014 at 9:51 PM, Hiroshi Doyu wrote:
> Hi Olav,
>
> Olav Haugan writes:
>
>> @@ -93,6 +94,10 @@ enum iommu_attr {
>> * @detach_dev: detach device from an iommu domain
>> * @map: map a physically contiguous memory region to an iommu domain
>> * @unmap: unmap a physically cont
Hi Olav,
Olav Haugan writes:
> @@ -93,6 +94,10 @@ enum iommu_attr {
> * @detach_dev: detach device from an iommu domain
> * @map: map a physically contiguous memory region to an iommu domain
> * @unmap: unmap a physically contiguous memory region from an iommu domain
> + * @map_sg: map a s
On Mon, Aug 11, 2014 at 03:45:50PM -0700, Olav Haugan wrote:
> Mapping and unmapping are more often than not in the critical path.
> map_sg and unmap_sg allows IOMMU driver implementations to optimize
> the process of mapping and unmapping buffers into the IOMMU page tables.
>
> Instead of mapping
27 matches
Mail list logo
