From: alexey <alexey.skidanov@intel.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] staging: android: ion: Add implementation of dma_buf_vmap and dma_buf_vunmap
Date: Wed, 31 Jan 2018 01:44:47 +0200 [thread overview]
Message-ID: <f69020cc-b2e4-5369-1345-f7bd7619266c@intel.com> (raw)
In-Reply-To: <20180130221501.GA6717@kroah.com>
On 01/31/2018 12:15 AM, Greg KH wrote:
> On Tue, Jan 30, 2018 at 10:39:13PM +0200, Alexey Skidanov wrote:
>> dma_buf_vmap and dma_buf_vunmap allow drivers to access buffers, created by ion.
> But why would anyone ever want to do that? What is wrong with the
> existing interfaces that drivers use to access buffers created by ion?
Any driver, sharing the buffers, created by ion, through dma-buf, may
get back the
sgtable describing the buffer for device DMA and may call dma_buf_vmap
to get back
the kernel virtual address of the buffer to get access to it. Currently,
the second
option is missing. Actually, the buffer already mapped by ion
implementation.
> What code uses this new interface?
This is not the new interface. this is the missing implementation of the
last two ops:
struct dma_buf_ops {
int (* attach) (struct dma_buf *, struct device *, struct
dma_buf_attachment *);
void (* detach) (struct dma_buf *, struct dma_buf_attachment *);
struct sg_table * (* map_dma_buf) (struct dma_buf_attachment *, enum
dma_data_direction);
void (* unmap_dma_buf) (struct dma_buf_attachment *,struct sg_table
*, enum dma_data_direction);
void (* release) (struct dma_buf *);
int (* begin_cpu_access) (struct dma_buf *, enum dma_data_direction);
int (* end_cpu_access) (struct dma_buf *, enum dma_data_direction);
void *(* map_atomic) (struct dma_buf *, unsigned long);
void (* unmap_atomic) (struct dma_buf *, unsigned long, void *);
void *(* map) (struct dma_buf *, unsigned long);
void (* unmap) (struct dma_buf *, unsigned long, void *);
int (* mmap) (struct dma_buf *, struct vm_area_struct *vma);
void *(* vmap) (struct dma_buf *);
void (* vunmap) (struct dma_buf *, void *vaddr);
};
>
> We need a bit more information please.
>
> thanks,
>
> greg k-h
Thanks,
Alexey
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
next prev parent reply other threads:[~2018-01-30 23:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-30 20:39 Alexey Skidanov
2018-01-30 20:47 ` Dan Carpenter
2018-01-30 22:15 ` Greg KH
2018-01-30 23:44 ` alexey [this message]
2018-01-31 7:58 ` Dan Carpenter
2018-01-31 8:38 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f69020cc-b2e4-5369-1345-f7bd7619266c@intel.com \
--to=alexey.skidanov@intel.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®