Re: DMA-API attr - DMA_ATTR_NO_KERNEL_MAPPING

Re: DMA-API attr - DMA_ATTR_NO_KERNEL_MAPPING

[Christoph Hellwig]

On Wed, Jun 26, 2019 at 10:12:45PM +0530, Pankaj Suryawanshi wrote:
> [CC: linux kernel and Vlastimil Babka]

The right list is the list for the DMA mapping subsystem, which is
iommu@lists.linux-foundation.org.  I've also added that.

> > I am writing driver in which I used DMA_ATTR_NO_KERNEL_MAPPING attribute
> > for cma allocation using dma_alloc_attr(), as per kernel docs
> > https://www.kernel.org/doc/Documentation/DMA-attributes.txt  buffers
> > allocated with this attribute can be only passed to user space by calling
> > dma_mmap_attrs().
> >
> > how can I mapped in kernel space (after dma_alloc_attr with
> > DMA_ATTR_NO_KERNEL_MAPPING ) ?

You can't.  And that is the whole point of that API.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: DMA-API attr - DMA_ATTR_NO_KERNEL_MAPPING

[Pankaj Suryawanshi]

On Wed, Jun 26, 2019 at 11:21 PM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Wed, Jun 26, 2019 at 10:12:45PM +0530, Pankaj Suryawanshi wrote:
> > [CC: linux kernel and Vlastimil Babka]
>
> The right list is the list for the DMA mapping subsystem, which is
> iommu@lists.linux-foundation.org.  I've also added that.
>
> > > I am writing driver in which I used DMA_ATTR_NO_KERNEL_MAPPING attribute
> > > for cma allocation using dma_alloc_attr(), as per kernel docs
> > > https://www.kernel.org/doc/Documentation/DMA-attributes.txt  buffers
> > > allocated with this attribute can be only passed to user space by calling
> > > dma_mmap_attrs().
> > >
> > > how can I mapped in kernel space (after dma_alloc_attr with
> > > DMA_ATTR_NO_KERNEL_MAPPING ) ?
>
> You can't.  And that is the whole point of that API.

1. We can again mapped in kernel space using dma_remap() api , because
when we are using  DMA_ATTR_NO_KERNEL_MAPPING for dma_alloc_attr it
returns the page as virtual address(in case of CMA) so we can mapped
it again using dma_remap().

2. We can mapped in kernel space using vmap() as used for ion-cma
https://github.com/torvalds/linux/tree/master/drivers/staging/android/ion
 as used in function ion_heap_map_kernel().

Please let me know if i am missing anything.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: DMA-API attr - DMA_ATTR_NO_KERNEL_MAPPING

[Robin Murphy]

On 28/06/2019 17:29, Pankaj Suryawanshi wrote:
> On Wed, Jun 26, 2019 at 11:21 PM Christoph Hellwig <hch@infradead.org> wrote:
>>
>> On Wed, Jun 26, 2019 at 10:12:45PM +0530, Pankaj Suryawanshi wrote:
>>> [CC: linux kernel and Vlastimil Babka]
>>
>> The right list is the list for the DMA mapping subsystem, which is
>> iommu@lists.linux-foundation.org.  I've also added that.
>>
>>>> I am writing driver in which I used DMA_ATTR_NO_KERNEL_MAPPING attribute
>>>> for cma allocation using dma_alloc_attr(), as per kernel docs
>>>> https://www.kernel.org/doc/Documentation/DMA-attributes.txt  buffers
>>>> allocated with this attribute can be only passed to user space by calling
>>>> dma_mmap_attrs().
>>>>
>>>> how can I mapped in kernel space (after dma_alloc_attr with
>>>> DMA_ATTR_NO_KERNEL_MAPPING ) ?
>>
>> You can't.  And that is the whole point of that API.
> 
> 1. We can again mapped in kernel space using dma_remap() api , because
> when we are using  DMA_ATTR_NO_KERNEL_MAPPING for dma_alloc_attr it
> returns the page as virtual address(in case of CMA) so we can mapped
> it again using dma_remap().

No, you really can't. A caller of dma_alloc_attrs(..., 
DMA_ATTR_NO_KERNEL_MAPPING) cannot make any assumptions about the void* 
it returns, other than that it must be handed back to dma_free_attrs() 
later. The implementation is free to ignore the flag and give back a 
virtual mapping anyway. Any driver which depends on how one particular 
implementation on one particular platform happens to behave today is, 
essentially, wrong.

> 2. We can mapped in kernel space using vmap() as used for ion-cma
> https://github.com/torvalds/linux/tree/master/drivers/staging/android/ion
>   as used in function ion_heap_map_kernel().
> 
> Please let me know if i am missing anything.

If you want a kernel mapping, *don't* explicitly request not to have a 
kernel mapping in the first place. It's that simple.

Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: DMA-API attr - DMA_ATTR_NO_KERNEL_MAPPING

[Pankaj Suryawanshi]

[-- Attachment #1.1: Type: text/plain, Size: 5717 bytes --]

On Mon, Jul 1, 2019 at 7:39 PM Robin Murphy <robin.murphy@arm.com> wrote:

> On 28/06/2019 17:29, Pankaj Suryawanshi wrote:
> > On Wed, Jun 26, 2019 at 11:21 PM Christoph Hellwig <hch@infradead.org>
> wrote:
> >>
> >> On Wed, Jun 26, 2019 at 10:12:45PM +0530, Pankaj Suryawanshi wrote:
> >>> [CC: linux kernel and Vlastimil Babka]
> >>
> >> The right list is the list for the DMA mapping subsystem, which is
> >> iommu@lists.linux-foundation.org.  I've also added that.
> >>
> >>>> I am writing driver in which I used DMA_ATTR_NO_KERNEL_MAPPING
> attribute
> >>>> for cma allocation using dma_alloc_attr(), as per kernel docs
> >>>> https://www.kernel.org/doc/Documentation/DMA-attributes.txt  buffers
> >>>> allocated with this attribute can be only passed to user space by
> calling
> >>>> dma_mmap_attrs().
> >>>>
> >>>> how can I mapped in kernel space (after dma_alloc_attr with
> >>>> DMA_ATTR_NO_KERNEL_MAPPING ) ?
> >>
> >> You can't.  And that is the whole point of that API.
> >
> > 1. We can again mapped in kernel space using dma_remap() api , because
> > when we are using  DMA_ATTR_NO_KERNEL_MAPPING for dma_alloc_attr it
> > returns the page as virtual address(in case of CMA) so we can mapped
> > it again using dma_remap().
>
> No, you really can't. A caller of dma_alloc_attrs(...,
> DMA_ATTR_NO_KERNEL_MAPPING) cannot make any assumptions about the void*
> it returns, other than that it must be handed back to dma_free_attrs()
> later. The implementation is free to ignore the flag and give back a
> virtual mapping anyway. Any driver which depends on how one particular
> implementation on one particular platform happens to behave today is,
> essentially, wrong.
>

Here is the example that i have tried in my driver.
///////////////code
snippet/////////////////////////////////////////////////////////////////////////

For CMA allocation using DMA API with DMA_ATTR_NO_KERNEL_MAPPING  :-

if(strcmp("video",info->name) == 0)
        {
        printk("Testing CMA Alloc %s\n", info->name);
        info->dma_virt = dma_alloc_attrs(pmap_device, info->size, &phys,
GFP_KERNEL,
                        DMA_ATTR_WRITE_COMBINE | DMA_ATTR_FORCE_CONTIGUOUS
| DMA_ATTR_NO_KERNEL_MAPPING);
        if (!info->dma_virt) {
                pr_err("\x1b[31m" "pmap: cma: failed to alloc %s"
"\x1b[0m\n",
                                info->name);
                return 0;
        }
                __dma_remap(info->dma_virt, info->size, PAGE_KERNEL); //
pgprot we will take from attr
                virt = page_address(info->dma_virt);
        }

For CMA free using DMA api with DMA_ATTR_NO_KERNEL_MAPPING:-

if(strcmp("video",info->name) == 0)
        {
        printk("Testing CMA Release\n");
        __dma_remap(info->dma_virt, info->size, PAGE_KERNEL);
        dma_free_attrs(pmap_device, info->size, info->dma_virt, phys,
                        DMA_ATTR_WRITE_COMBINE | DMA_ATTR_FORCE_CONTIGUOUS
| DMA_ATTR_NO_KERNEL_MAPPING);
        }

Flow of Function calls :-

1. static void *__dma_alloc() // .want_vaddr = ((attrs &
DMA_ATTR_NO_KERNEL_MAPPING) == 0)

2.cma_allocator :-
                            i.  static void *cma_allocator_alloc ()
                            ii. static void *__alloc_from_contiguous()  //
file name :- ./arch/arm/mm/dma-mapping.c
                                                                     if
(!want_vaddr)

                                                                      goto
out; // condition true for DMA_ATTR_NO_KERNEL_MAPPING

                                                                     if
(PageHighMem(page)) {
                                                                     ptr =
__dma_alloc_remap(page, size, GFP_KERNEL, prot, caller);
                                                                     if
(!ptr) {


dma_release_from_contiguous(dev, page, count);

                                                          return NULL;
                                                                      }
                                                                     } else
{

__dma_remap(page, size, prot);
                                                                    ptr =
page_address(page);
                                                                     }

                                                                   out:

                                                                  *ret_page
= page; // return  page
                                                                   return
ptr;  // nothing in ptr
                                                                  }
                            iii. struct page *dma_alloc_from_contiguous()
                            iv. cma_alloc()
3. dma_alloc () // returns
return args.want_vaddr ? addr : page; // returns page which is return by
alloc_from_contiguous().

What wrong with this if we already know page is returning dma_alloc_attr().
we can use dma_remap in our driver and free as freed in static void
__free_from_contiguous ().
Please let me know if i missing anything.

> 2. We can mapped in kernel space using vmap() as used for ion-cma
> >
> https://github.com/torvalds/linux/tree/master/drivers/staging/android/ion
> >   as used in function ion_heap_map_kernel().
> >
> > Please let me know if i am missing anything.
>
> If you want a kernel mapping, *don't* explicitly request not to have a
> kernel mapping in the first place. It's that simple.
>

Do you mean do not use dma-api ? because if i used dma-api it will give you
mapped virtual address.
or i have to use directly cma_alloc() in my driver. // if i used this
approach i need to reserved more vmalloc area.

Any help would be appreciated.

>
> Robin.
>

[-- Attachment #1.2: Type: text/html, Size: 11073 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: DMA-API attr - DMA_ATTR_NO_KERNEL_MAPPING

[Pankaj Suryawanshi]

[-- Attachment #1.1: Type: text/plain, Size: 5844 bytes --]

[CC: pankaj.suryawanshi@einfochips.com]

On Mon, Jul 1, 2019 at 11:17 PM Pankaj Suryawanshi <
pankajssuryawanshi@gmail.com> wrote:
>
>
>
>
> On Mon, Jul 1, 2019 at 7:39 PM Robin Murphy <robin.murphy@arm.com> wrote:
>>
>> On 28/06/2019 17:29, Pankaj Suryawanshi wrote:
>> > On Wed, Jun 26, 2019 at 11:21 PM Christoph Hellwig <hch@infradead.org>
wrote:
>> >>
>> >> On Wed, Jun 26, 2019 at 10:12:45PM +0530, Pankaj Suryawanshi wrote:
>> >>> [CC: linux kernel and Vlastimil Babka]
>> >>
>> >> The right list is the list for the DMA mapping subsystem, which is
>> >> iommu@lists.linux-foundation.org.  I've also added that.
>> >>
>> >>>> I am writing driver in which I used DMA_ATTR_NO_KERNEL_MAPPING
attribute
>> >>>> for cma allocation using dma_alloc_attr(), as per kernel docs
>> >>>> https://www.kernel.org/doc/Documentation/DMA-attributes.txt  buffers
>> >>>> allocated with this attribute can be only passed to user space by
calling
>> >>>> dma_mmap_attrs().
>> >>>>
>> >>>> how can I mapped in kernel space (after dma_alloc_attr with
>> >>>> DMA_ATTR_NO_KERNEL_MAPPING ) ?
>> >>
>> >> You can't.  And that is the whole point of that API.
>> >
>> > 1. We can again mapped in kernel space using dma_remap() api , because
>> > when we are using  DMA_ATTR_NO_KERNEL_MAPPING for dma_alloc_attr it
>> > returns the page as virtual address(in case of CMA) so we can mapped
>> > it again using dma_remap().
>>
>> No, you really can't. A caller of dma_alloc_attrs(...,
>> DMA_ATTR_NO_KERNEL_MAPPING) cannot make any assumptions about the void*
>> it returns, other than that it must be handed back to dma_free_attrs()
>> later. The implementation is free to ignore the flag and give back a
>> virtual mapping anyway. Any driver which depends on how one particular
>> implementation on one particular platform happens to behave today is,
>> essentially, wrong.
>
>
> Here is the example that i have tried in my driver.
> ///////////////code
snippet/////////////////////////////////////////////////////////////////////////
>
> For CMA allocation using DMA API with DMA_ATTR_NO_KERNEL_MAPPING  :-
>
> if(strcmp("video",info->name) == 0)
>         {
>         printk("Testing CMA Alloc %s\n", info->name);
>         info->dma_virt = dma_alloc_attrs(pmap_device, info->size, &phys,
GFP_KERNEL,
>                         DMA_ATTR_WRITE_COMBINE |
DMA_ATTR_FORCE_CONTIGUOUS | DMA_ATTR_NO_KERNEL_MAPPING);
>         if (!info->dma_virt) {
>                 pr_err("\x1b[31m" "pmap: cma: failed to alloc %s"
"\x1b[0m\n",
>                                 info->name);
>                 return 0;
>         }
>                 __dma_remap(info->dma_virt, info->size, PAGE_KERNEL); //
pgprot we will take from attr
>                 virt = page_address(info->dma_virt);
>         }
>
> For CMA free using DMA api with DMA_ATTR_NO_KERNEL_MAPPING:-
>
> if(strcmp("video",info->name) == 0)
>         {
>         printk("Testing CMA Release\n");
>         __dma_remap(info->dma_virt, info->size, PAGE_KERNEL);
>         dma_free_attrs(pmap_device, info->size, info->dma_virt, phys,
>                         DMA_ATTR_WRITE_COMBINE |
DMA_ATTR_FORCE_CONTIGUOUS | DMA_ATTR_NO_KERNEL_MAPPING);
>         }
>
> Flow of Function calls :-
>
> 1. static void *__dma_alloc() // .want_vaddr = ((attrs &
DMA_ATTR_NO_KERNEL_MAPPING) == 0)
>
> 2.cma_allocator :-
>                             i.  static void *cma_allocator_alloc ()
>                             ii. static void *__alloc_from_contiguous()
 // file name :- ./arch/arm/mm/dma-mapping.c
>                                                                      if
(!want_vaddr)
>
          goto out; // condition true for DMA_ATTR_NO_KERNEL_MAPPING
>
>                                                                      if
(PageHighMem(page)) {
>                                                                      ptr
= __dma_alloc_remap(page, size, GFP_KERNEL, prot, caller);
>                                                                      if
(!ptr) {
>
      dma_release_from_contiguous(dev, page, count);
>
      return NULL;
>                                                                       }
>                                                                      }
else {
>
 __dma_remap(page, size, prot);
>                                                                     ptr =
page_address(page);
>                                                                      }
>
>                                                                    out:

>
*ret_page = page; // return  page
>                                                                    return
ptr;  // nothing in ptr
>                                                                   }
>                             iii. struct page *dma_alloc_from_contiguous()
>                             iv. cma_alloc()
> 3. dma_alloc () // returns
> return args.want_vaddr ? addr : page; // returns page which is return by
alloc_from_contiguous().
>
> What wrong with this if we already know page is returning
dma_alloc_attr().
> we can use dma_remap in our driver and free as freed in static void
__free_from_contiguous ().
> Please let me know if i missing anything.
>
>> > 2. We can mapped in kernel space using vmap() as used for ion-cma
>> >
https://github.com/torvalds/linux/tree/master/drivers/staging/android/ion
>> >   as used in function ion_heap_map_kernel().
>> >
>> > Please let me know if i am missing anything.
>>
>> If you want a kernel mapping, *don't* explicitly request not to have a
>> kernel mapping in the first place. It's that simple.
>
>
> Do you mean do not use dma-api ? because if i used dma-api it will give
you mapped virtual address.
> or i have to use directly cma_alloc() in my driver. // if i used this
approach i need to reserved more vmalloc area.
>
> Any help would be appreciated.
>>
>>
>> Robin.

[-- Attachment #1.2: Type: text/html, Size: 8644 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: DMA-API attr - DMA_ATTR_NO_KERNEL_MAPPING

[Robin Murphy]

On 01/07/2019 18:47, Pankaj Suryawanshi wrote:
>> If you want a kernel mapping, *don't* explicitly request not to have a
>> kernel mapping in the first place. It's that simple.
>>
> 
> Do you mean do not use dma-api ? because if i used dma-api it will give you
> mapped virtual address.
> or i have to use directly cma_alloc() in my driver. // if i used this
> approach i need to reserved more vmalloc area.

No, I mean just call dma_alloc_attrs() normally *without* adding the 
DMA_ATTR_NO_KERNEL_MAPPING flag. That flag means "I never ever want to 
make CPU accesses to this buffer from the kernel" - that is clearly not 
the case for your code, so it is utterly nonsensical to still pass the 
flag but try to hack around it later.

Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: DMA-API attr - DMA_ATTR_NO_KERNEL_MAPPING

[Pankaj Suryawanshi]

On Mon, Jul 1, 2019 at 11:24 PM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 01/07/2019 18:47, Pankaj Suryawanshi wrote:
> >> If you want a kernel mapping, *don't* explicitly request not to have a
> >> kernel mapping in the first place. It's that simple.
> >>
> >
> > Do you mean do not use dma-api ? because if i used dma-api it will give you
> > mapped virtual address.
> > or i have to use directly cma_alloc() in my driver. // if i used this
> > approach i need to reserved more vmalloc area.
>
> No, I mean just call dma_alloc_attrs() normally *without* adding the
> DMA_ATTR_NO_KERNEL_MAPPING flag. That flag means "I never ever want to
> make CPU accesses to this buffer from the kernel" - that is clearly not
> the case for your code, so it is utterly nonsensical to still pass the
> flag but try to hack around it later.


Actually my use case is that i want virtual mapping only when i will
play video as my vpu/gpu driver is design like that.
and  i am using 32-bit so virtual memory is splitted as 3G/1G so dont
have enough memory for all the time to mapped with kernel space.

Lets say i am allocating 400MB for driver but i want only 30MB for
virtual mapping (not everytime) that is the case.
>
>
> Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: DMA-API attr - DMA_ATTR_NO_KERNEL_MAPPING

[Pankaj Suryawanshi]

On Mon, Jul 1, 2019 at 11:17 PM Pankaj Suryawanshi
<pankajssuryawanshi@gmail.com> wrote:
>
>
>
>
> On Mon, Jul 1, 2019 at 7:39 PM Robin Murphy <robin.murphy@arm.com> wrote:
>>
>> On 28/06/2019 17:29, Pankaj Suryawanshi wrote:
>> > On Wed, Jun 26, 2019 at 11:21 PM Christoph Hellwig <hch@infradead.org> wrote:
>> >>
>> >> On Wed, Jun 26, 2019 at 10:12:45PM +0530, Pankaj Suryawanshi wrote:
>> >>> [CC: linux kernel and Vlastimil Babka]
>> >>
>> >> The right list is the list for the DMA mapping subsystem, which is
>> >> iommu@lists.linux-foundation.org.  I've also added that.
>> >>
>> >>>> I am writing driver in which I used DMA_ATTR_NO_KERNEL_MAPPING attribute
>> >>>> for cma allocation using dma_alloc_attr(), as per kernel docs
>> >>>> https://www.kernel.org/doc/Documentation/DMA-attributes.txt  buffers
>> >>>> allocated with this attribute can be only passed to user space by calling
>> >>>> dma_mmap_attrs().
>> >>>>
>> >>>> how can I mapped in kernel space (after dma_alloc_attr with
>> >>>> DMA_ATTR_NO_KERNEL_MAPPING ) ?
>> >>
>> >> You can't.  And that is the whole point of that API.
>> >
>> > 1. We can again mapped in kernel space using dma_remap() api , because
>> > when we are using  DMA_ATTR_NO_KERNEL_MAPPING for dma_alloc_attr it
>> > returns the page as virtual address(in case of CMA) so we can mapped
>> > it again using dma_remap().
>>
>> No, you really can't. A caller of dma_alloc_attrs(...,
>> DMA_ATTR_NO_KERNEL_MAPPING) cannot make any assumptions about the void*
>> it returns, other than that it must be handed back to dma_free_attrs()
>> later. The implementation is free to ignore the flag and give back a
>> virtual mapping anyway. Any driver which depends on how one particular
>> implementation on one particular platform happens to behave today is,
>> essentially, wrong.
>
>
> Here is the example that i have tried in my driver.
> ///////////////code snippet/////////////////////////////////////////////////////////////////////////
>
> For CMA allocation using DMA API with DMA_ATTR_NO_KERNEL_MAPPING  :-
>
> if(strcmp("video",info->name) == 0)
>         {
>         printk("Testing CMA Alloc %s\n", info->name);
>         info->dma_virt = dma_alloc_attrs(pmap_device, info->size, &phys, GFP_KERNEL,
>                         DMA_ATTR_WRITE_COMBINE | DMA_ATTR_FORCE_CONTIGUOUS | DMA_ATTR_NO_KERNEL_MAPPING);
>         if (!info->dma_virt) {
>                 pr_err("\x1b[31m" "pmap: cma: failed to alloc %s" "\x1b[0m\n",
>                                 info->name);
>                 return 0;
>         }
>                 __dma_remap(info->dma_virt, info->size, PAGE_KERNEL); // /*TO DO pgprot we will be taken from attr */  // we will use this only when virtual mapping is required.
>                 virt = page_address(info->dma_virt); // will use this virtual when kernel mapping needed.
>         }
>
> For CMA free using DMA api with DMA_ATTR_NO_KERNEL_MAPPING:-
>
> if(strcmp("video",info->name) == 0)
>         {
>         printk("Testing CMA Release\n");
>         __dma_remap(info->dma_virt, info->size, PAGE_KERNEL);
>         dma_free_attrs(pmap_device, info->size, info->dma_virt, phys,
>                         DMA_ATTR_WRITE_COMBINE | DMA_ATTR_FORCE_CONTIGUOUS | DMA_ATTR_NO_KERNEL_MAPPING);
>         }
>
> Flow of Function calls :-
>
> 1. static void *__dma_alloc() // .want_vaddr = ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) == 0)
>
> 2.cma_allocator :-
>                             i.  static void *cma_allocator_alloc ()
>                             ii. static void *__alloc_from_contiguous()  // file name :- ./arch/arm/mm/dma-mapping.c
>                                                                      if (!want_vaddr)
>                                                                                     goto out; // condition true for DMA_ATTR_NO_KERNEL_MAPPING
>
>                                                                      if (PageHighMem(page)) {
>                                                                      ptr = __dma_alloc_remap(page, size, GFP_KERNEL, prot, caller);
>                                                                      if (!ptr) {
>                                                                                 dma_release_from_contiguous(dev, page, count);
>                                                                                 return NULL;
>                                                                       }
>                                                                      } else {
>                                                                      __dma_remap(page, size, prot);
>                                                                     ptr = page_address(page);
>                                                                      }
>
>                                                                    out:
>                                                                   *ret_page = page; // return  page
>                                                                    return ptr;  // nothing in ptr
>                                                                   }
>                             iii. struct page *dma_alloc_from_contiguous()
>                             iv. cma_alloc()
> 3. dma_alloc () // returns
> return args.want_vaddr ? addr : page; // returns page which is return by alloc_from_contiguous().
>
> What wrong with this if we already know page is returning dma_alloc_attr().
> we can use dma_remap in our driver and free as freed in static void __free_from_contiguous ().
> Please let me know if i missing anything.
>
>> > 2. We can mapped in kernel space using vmap() as used for ion-cma
>> > https://github.com/torvalds/linux/tree/master/drivers/staging/android/ion
>> >   as used in function ion_heap_map_kernel().
>> >
>> > Please let me know if i am missing anything.
>>
>> If you want a kernel mapping, *don't* explicitly request not to have a
>> kernel mapping in the first place. It's that simple.
>
>
> Do you mean do not use dma-api ? because if i used dma-api it will give you mapped virtual address.
> or i have to use directly cma_alloc() in my driver. // if i used this approach i need to reserved more vmalloc area.
>
> Any help would be appreciated.
>>
>>
>> Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu