[PATCH] drm/i2c/ch7006: Convert to dev_pm_ops
The I2C specific suspend and resume functions have been deprecated and
printing a warning on boot for over a year, dev_pm_ops should be used
instead so convert to that.
Also remove the suspend function since all it does is log.
Signed-off-by: Mark Brown
---
drivers/gpu/drm/i2c/ch7006_drv.c | 16 +++-
1 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c b/drivers/gpu/drm/i2c/ch7006_drv.c
index d3f2e87..ca4435d 100644
--- a/drivers/gpu/drm/i2c/ch7006_drv.c
+++ b/drivers/gpu/drm/i2c/ch7006_drv.c
@@ -427,15 +427,10 @@ static int ch7006_remove(struct i2c_client *client)
return 0;
}
-static int ch7006_suspend(struct i2c_client *client, pm_message_t mesg)
+static int ch7006_resume(struct device *dev)
{
- ch7006_dbg(client, "\n");
-
- return 0;
-}
+ struct i2c_client *client = to_i2c_device(dev);
-static int ch7006_resume(struct i2c_client *client)
-{
ch7006_dbg(client, "\n");
ch7006_write(client, 0x3d, 0x0);
@@ -499,15 +494,18 @@ static struct i2c_device_id ch7006_ids[] = {
};
MODULE_DEVICE_TABLE(i2c, ch7006_ids);
+static const struct dev_pm_ops ch7006_pm_ops = {
+ .resume = ch7006_resume,
+};
+
static struct drm_i2c_encoder_driver ch7006_driver = {
.i2c_driver = {
.probe = ch7006_probe,
.remove = ch7006_remove,
- .suspend = ch7006_suspend,
- .resume = ch7006_resume,
.driver = {
.name = "ch7006",
+ .pm = ch7006_pm_ops,
},
.id_table = ch7006_ids,
--
1.7.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [RFCv2 PATCH 4/9] v4l: add buffer exporting via dmabuf
On 03/22/2012 07:37 PM, Laurent Pinchart wrote:
Hi Subash,
On Thursday 22 March 2012 19:27:01 Subash Patel wrote:
On 03/22/2012 04:46 PM, Laurent Pinchart wrote:
On Tuesday 13 March 2012 11:17:02 Tomasz Stanislawski wrote:
[snip]
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index bb6844e..e71c787 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -680,6 +680,25 @@ struct v4l2_buffer {
#define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE0x0800
#define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000
+/**
+ * struct v4l2_exportbuffer - export of video buffer as DMABUF file
descriptor
+ *
+ * @fd:file descriptor associated with DMABUF (set by driver)
+ * @mem_offset:for non-multiplanar buffers with memory ==
V4L2_MEMORY_MMAP;
I don't think we will ever support exporting anything else than
V4L2_MEMORY_MMAP buffers. What will happen for multiplanar buffers ?
+ * offset from the start of the device memory for this plane,
+ * (or a "cookie" that should be passed to mmap() as offset)
+ *
Shouldn't the mem_offset field always be set to the mmap cookie value ?
I'm a bit confused by the "or" part, it seems to have been copied from
the v4l2_buffer documentation directly. We should clarify that.
+ * Contains data used for exporting a video buffer as DMABUF file
+ * descriptor. Uses the same 'cookie' as mmap() syscall. All reserved
fields
+ * must be set to zero.
+ */
+struct v4l2_exportbuffer {
+ __u32 fd;
+ __u32 reserved0;
Why is there a reserved field here ?
+1 to Laurent. Any particular need for reserved0 and reserved[13] below?
I think one void user pointer is sufficient even for future need.
I'd rather have more than one void user pointer, just in case. A couple of
bytes won't be expensive,
Just an off-topic note. When I learnt to hit keyboard for programming(in
linux for embedded), I had strict guidelines not to declare variables as
I like, as memory and computing was very precious then. A decade later,
people no more think its expensive to keep 14*3 bytes*(who knows how
many dma_buf objects) in the system.
Just a side note, thats all :)
and they will save lots of hassle in the future if
we need to add a couple of fields. I was just wondering why there was a
reserved field between fd and mem_offset.
+ __u32 mem_offset;
+ __u32 reserved[13];
+};
+
Also, what is the reason for returning the fd through this structure? To
keep it aligned with other v4l2 calls? I liked(or now hate making change
in the app) how it was being returned through the ioctl in your last patch.
Probably to be consistent with the V4L2 API, yes. It won't make a big
difference for applications, I would favor consistency in this case.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [RFCv2 PATCH 2/9 - 4/4] v4l: vb2-dma-contig: update and code refactoring
Hi Laurent,
On 03/22/2012 08:12 PM, Laurent Pinchart wrote:
Hi Tomasz,
On Thursday 22 March 2012 14:36:33 Tomasz Stanislawski wrote:
Hi Laurent,
Thank you very much for your comments and question.
They were very useful.
You're welcome.
Please refer to the comments below.
On 03/22/2012 11:50 AM, Laurent Pinchart wrote:
On Thursday 22 March 2012 11:02:23 Laurent Pinchart wrote:
From: Tomasz Stanislawski
This patch combines updates and fixes to dma-contig allocator.
Moreover the allocator code was refactored.
The most important changes are:
- functions were reordered
- move compression of scatterlist to separete function
- add support for multichunk but contiguous scatterlists
- simplified implementation of vb2-dma-contig context structure
- let mmap method to use dma_mmap_writecombine
- add support for scatterlist in userptr mode
[snip]
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c index c898e6f..9965465
100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
[snip]
static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
{
struct device *dev = alloc_ctx;
struct vb2_dc_buf *buf;
+ int ret;
+ int
n_pages;http://165.213.219.115/cgi-bin/gitweb.cgi?p=mirror/linux-3.0-mid
as;a=shortlog;h=refs/heads/exynos-3.0-dev + struct page **pages = NULL;
buf = kzalloc(sizeof *buf, GFP_KERNEL);
if (!buf)
return ERR_PTR(-ENOMEM);
- buf->vaddr = dma_alloc_coherent(dev, size,&buf->dma_addr,
GFP_KERNEL);
+ buf->dev = dev;
+ buf->size = size;
+ buf->vaddr = dma_alloc_coherent(buf->dev, buf->size,&buf->dma_addr,
+ GFP_KERNEL);
+
+ ret = -ENOMEM;
if (!buf->vaddr) {
- dev_err(dev, "dma_alloc_coherent of size %ld failed\n", size);
- kfree(buf);
- return ERR_PTR(-ENOMEM);
+ dev_err(dev, "dma_alloc_coherent of size %ld failed\n",
+ size);
+ goto fail_buf;
}
- buf->dev = dev;
- buf->size = size;
+ WARN_ON((unsigned long)buf->vaddr& ~PAGE_MASK);
+ WARN_ON(buf->dma_addr& ~PAGE_MASK);
+
+ n_pages = PAGE_ALIGN(size)>> PAGE_SHIFT;
+
+ pages = kmalloc(n_pages * sizeof pages[0], GFP_KERNEL);
+ if (!pages) {
+ printk(KERN_ERR "failed to alloc page table\n");
+ goto fail_dma;
+ }
+
+ ret = dma_get_pages(dev, buf->vaddr, buf->dma_addr, pages, n_pages);
As the only purpose of this is to retrieve a list of pages that will be
used to create a single-entry sgt, wouldn't it be possible to shortcut
the code and get the physical address of the buffer directly ?
The physical address should not be used since they are meaningless in a
context of different devices. It seams that only the list of pages is
more-or-less portable between different drivers.
The pages are physically contiguous. The physical address of the first page is
thus all you need.
struct page and physical addresses can be used interchangeably in this case if
I'm not mistaken. If you want to go with pages, you could use the first page
only instead of the physical buffer address.
The physical address is already present in buf->dma_addr, but it is only
valid if the device has no MMU. Notice that vb2-dma-contig possess no
knowledge if MMU is present for a given device.
That's why buf->dma_addr can't be considered as a physical address. It's only
useful in the device context.
The sg list is not going to be single-entry if the device is provided with
its own MMU.
There's something I don't get then. vb2-dma-contig deals with physically
contiguous buffers. The buffer is backed by physically contiguous pages, so
the sg list should have a single entry.
I think at present, vb2-dma-contig is abused for any kind of memory
allocation (continuous or not). Wouldnt it be good to have a proper
working setup for videobuf2-dma-sg instead? Driver which chooses to use
continuous, shall assign vb2_queue->mem_ops = vb2_dma_contig_memops. The
devices which know they have a MMU backing can assign the same to
vb2_dma_sg_memops. But as of now, we try to use vb2_dma_contig_memops
for all kind of operation. I have also done this mistake, and wish I
repaired it and posted it before :(
+ if (ret< 0) {
+ printk(KERN_ERR "failed to get buffer pages from DMA API\n");
+ goto fail_pages;
+ }
+ if (ret != n_pages) {
+ ret = -EFAULT;
+ printk(KERN_ERR "failed to get all pages from DMA API\n");
+ goto fail_pages;
+ }
+
+ buf->sgt_base = vb2_dc_pages_to_sgt(pages, n_pages, 0, 0);
+ if (IS_ERR(buf->sgt_base)) {
+ ret = PTR_ERR(buf->sgt_base);
+ printk(KERN_ERR "failed to prepare sg table\n");
+ goto fail_pages;
+
Re: [Linaro-mm-sig] [RFCv2 PATCH 4/9] v4l: add buffer exporting via dmabuf
Hi Thomasz,
On 03/22/2012 04:46 PM, Laurent Pinchart wrote:
Hi Tomasz,
Thanks for the patch.
On Tuesday 13 March 2012 11:17:02 Tomasz Stanislawski wrote:
This patch adds extension to V4L2 api. It allow to export a mmap buffer as
file descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset
used by mmap and return a file descriptor on success.
I know code is more fun to write than documentation, but
Documentation/DocBook/media/v4l will be sad if this patch is merged as-is ;-)
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
drivers/media/video/v4l2-compat-ioctl32.c |1 +
drivers/media/video/v4l2-ioctl.c | 11 +++
include/linux/videodev2.h | 20
include/media/v4l2-ioctl.h|2 ++
4 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
b/drivers/media/video/v4l2-compat-ioctl32.c index e6f67aa..fd157cb 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -954,6 +954,7 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int
cmd, unsigned long arg) case VIDIOC_S_FBUF32:
case VIDIOC_OVERLAY32:
case VIDIOC_QBUF32:
+ case VIDIOC_EXPBUF:
case VIDIOC_DQBUF32:
case VIDIOC_STREAMON32:
case VIDIOC_STREAMOFF32:
diff --git a/drivers/media/video/v4l2-ioctl.c
b/drivers/media/video/v4l2-ioctl.c index 74cab51..a125016 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -207,6 +207,7 @@ static const char *v4l2_ioctls[] = {
[_IOC_NR(VIDIOC_S_FBUF)] = "VIDIOC_S_FBUF",
[_IOC_NR(VIDIOC_OVERLAY)] = "VIDIOC_OVERLAY",
[_IOC_NR(VIDIOC_QBUF)] = "VIDIOC_QBUF",
+ [_IOC_NR(VIDIOC_EXPBUF)] = "VIDIOC_EXPBUF",
[_IOC_NR(VIDIOC_DQBUF)]= "VIDIOC_DQBUF",
[_IOC_NR(VIDIOC_STREAMON)] = "VIDIOC_STREAMON",
[_IOC_NR(VIDIOC_STREAMOFF)]= "VIDIOC_STREAMOFF",
@@ -938,6 +939,16 @@ static long __video_do_ioctl(struct file *file,
dbgbuf(cmd, vfd, p);
break;
}
+ case VIDIOC_EXPBUF:
+ {
+ struct v4l2_exportbuffer *p = arg;
+
+ if (!ops->vidioc_expbuf)
+ break;
+
+ ret = ops->vidioc_expbuf(file, fh, p);
You can pass arg to ops->vidioc_expbuf() directly, there's no need to create a
struct v4l2_exportbuffer *p variable.
+ break;
+ }
case VIDIOC_DQBUF:
{
struct v4l2_buffer *p = arg;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index bb6844e..e71c787 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -680,6 +680,25 @@ struct v4l2_buffer {
#define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE 0x0800
#define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000
+/**
+ * struct v4l2_exportbuffer - export of video buffer as DMABUF file
descriptor
+ *
+ * @fd:file descriptor associated with DMABUF (set by driver)
+ * @mem_offset:for non-multiplanar buffers with memory ==
V4L2_MEMORY_MMAP;
I don't think we will ever support exporting anything else than
V4L2_MEMORY_MMAP buffers. What will happen for multiplanar buffers ?
+ * offset from the start of the device memory for this plane,
+ * (or a "cookie" that should be passed to mmap() as offset)
+ *
Shouldn't the mem_offset field always be set to the mmap cookie value ? I'm a
bit confused by the "or" part, it seems to have been copied from the
v4l2_buffer documentation directly. We should clarify that.
+ * Contains data used for exporting a video buffer as DMABUF file
+ * descriptor. Uses the same 'cookie' as mmap() syscall. All reserved
fields
+ * must be set to zero.
+ */
+struct v4l2_exportbuffer {
+ __u32 fd;
+ __u32 reserved0;
Why is there a reserved field here ?
+1 to Laurent. Any particular need for reserved0 and reserved[13] below?
I think one void user pointer is sufficient even for future need.
+ __u32 mem_offset;
+ __u32 reserved[13];
+};
+
Also, what is the reason for returning the fd through this structure? To
keep it aligned with other v4l2 calls? I liked(or now hate making change
in the app) how it was being returned through the ioctl in your last patch.
/*
*O V E R L A Y P R E V I E W
*/
@@ -2303,6 +2322,7 @@ struct v4l2_create_buffers {
#define VIDIOC_S_FBUF _IOW('V', 11, struct v4l2_framebuffer)
#define VIDIOC_OVERLAY _IOW('V', 14, int)
#define VIDIOC_QBUF _IOWR('V', 15, struct v4l2_buffer)
+#define VIDIOC_EXPBUF _IOWR('V', 16, struct v4l2_exportbuffer)
#define VIDIOC_DQBUF _IOWR('V', 17, struct v4l2_buffer)
#define VIDIOC_STREAMON_IOW('V', 18,
Re: [Linaro-mm-sig] [RFCv2 PATCH 2/9] v4l: vb2-dma-contig: update and code refactoring
Hello Thomasz, Marek,
I found an issue with below patch. Please read below.
On 03/13/2012 03:47 PM, Tomasz Stanislawski wrote:
This patch combines updates and fixes to dma-contig allocator.
Moreover the allocator code was refactored.
The most important changes are:
- functions were reordered
- move compression of scatterlist to separete function
- add support for multichunk but contiguous scatterlists
- simplified implementation of vb2-dma-contig context structure
- let mmap method to use dma_mmap_writecombine
- add support for scatterlist in userptr mode
Signed-off-by: Marek Szyprowski
[mmap method]
Signed-off-by: Andrzej Pietrasiewicz
[scatterlist in userptr mode]
Signed-off-by: Kamil Debski
[bugfixing]
Signed-off-by: Tomasz Stanislawski
[core refactoring, helper functions]
Signed-off-by: Kyungmin Park
---
drivers/media/video/videobuf2-dma-contig.c | 495 +++-
1 files changed, 414 insertions(+), 81 deletions(-)
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c
index f17ad98..c1dc043 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -10,173 +10,506 @@
* the Free Software Foundation.
*/
+#include
+#include
#include
+#include
+#include
#include
-#include
#include
#include
-struct vb2_dc_conf {
- struct device *dev;
-};
-
struct vb2_dc_buf {
- struct vb2_dc_conf *conf;
+ struct device *dev;
void*vaddr;
- dma_addr_t dma_addr;
unsigned long size;
- struct vm_area_struct *vma;
- atomic_trefcount;
+ dma_addr_t dma_addr;
+ struct sg_table *dma_sgt;
+ enum dma_data_direction dma_dir;
+
+ /* MMAP related */
struct vb2_vmarea_handler handler;
+ atomic_trefcount;
+ struct sg_table *sgt_base;
+
+ /* USERPTR related */
+ struct vm_area_struct *vma;
};
-static void vb2_dma_contig_put(void *buf_priv);
+/*/
+/*scatterlist table functions*/
+/*/
-static void *vb2_dma_contig_alloc(void *alloc_ctx, unsigned long size)
+static struct sg_table *vb2_dc_pages_to_sgt(struct page **pages,
+ unsigned long n_pages, size_t offset, size_t offset2)
{
- struct vb2_dc_conf *conf = alloc_ctx;
- struct vb2_dc_buf *buf;
+ struct sg_table *sgt;
+ int i, j; /* loop counters */
+ int cur_page, chunks;
+ int ret;
+ struct scatterlist *s;
- buf = kzalloc(sizeof *buf, GFP_KERNEL);
- if (!buf)
+ sgt = kzalloc(sizeof *sgt, GFP_KERNEL);
+ if (!sgt)
return ERR_PTR(-ENOMEM);
- buf->vaddr = dma_alloc_coherent(conf->dev, size,&buf->dma_addr,
- GFP_KERNEL);
- if (!buf->vaddr) {
- dev_err(conf->dev, "dma_alloc_coherent of size %ld failed\n",
- size);
- kfree(buf);
+ /* compute number of chunks */
+ chunks = 1;
+ for (i = 1; i< n_pages; ++i)
+ if (pages[i] != pages[i - 1] + 1)
+ ++chunks;
+
+ ret = sg_alloc_table(sgt, chunks, GFP_KERNEL);
+ if (ret) {
+ kfree(sgt);
return ERR_PTR(-ENOMEM);
}
- buf->conf = conf;
- buf->size = size;
-
- buf->handler.refcount =&buf->refcount;
- buf->handler.put = vb2_dma_contig_put;
- buf->handler.arg = buf;
+ /* merging chunks and putting them into the scatterlist */
+ cur_page = 0;
+ for_each_sg(sgt->sgl, s, sgt->orig_nents, i) {
+ size_t size = PAGE_SIZE;
+
+ for (j = cur_page + 1; j< n_pages; ++j) {
+ if (pages[j] != pages[j - 1] + 1)
+ break;
+ size += PAGE_SIZE;
+ }
+
+ /* cut offset if chunk starts at the first page */
+ if (cur_page == 0)
+ size -= offset;
+ /* cut offset2 if chunk ends at the last page */
+ if (j == n_pages)
+ size -= offset2;
+
+ sg_set_page(s, pages[cur_page], size, offset);
+ offset = 0;
+ cur_page = j;
+ }
- atomic_inc(&buf->refcount);
+ return sgt;
+}
- return buf;
+static void vb2_dc_release_sgtable(struct sg_table *sgt)
+{
+ sg_free_table(sgt);
+ kfree(sgt);
}
-static void vb2_dma_contig_put(void *buf_priv)
+static void vb2_dc_put_sgtable(struct sg_table *sgt, int dirty)
{
- struct vb2_dc_buf *buf = buf_priv;
+
radeon + DVI->mDP converter + mDP display blank screen issue since 3.0
Hi!
Since Linux 3.0, a system with a Radeon HD 5450 (1002:68f9) connected
to a 27" Apple LED cinema display via an Atlona AT-DP400 Dual Link DVI
to Mini DisplayPort converter has started to stop giving screen
output on switching from text mode to graphical framebuffer during
system startup.
I finally had some time to look at this, and it seems to have stopped
working after this commit:
commit df271bec805b42527d864777ed035fcbb42e76c0
Author: Alex Deucher
Date: Fri May 20 04:34:15 2011 -0400
drm/radeon/kms: properly handle bpc >8 in atom command tables
Signed-off-by: Alex Deucher
Signed-off-by: Dave Airlie
...and with the patch below (i.e. reverting part of the commit above)
applied to 3.3 I get screen output again.
Even though the monitor seems to have an 8 bit panel, it reports 10
bits per channel in its EDID:
[...]
Manufacturer: APP Model 9226 Serial Number 41959462
Made week 38 of 2010
EDID version: 1.4
Digital display
10 bits per primary color channel
DisplayPort interface
Maximum image size: 60 cm x 34 cm
[...]
The (active, dual link) DVI->mDP converter spec sheet says it supports
24 bit color, and I'm guessing that it can't deal with 30. Is the
converter at fault here for passing through the EDID unchanged?
Also, what would be the right way to handle this, a kernel command
line or module option to limit color depth or something like that?
("Buy a video card with DP output." is a valid answer, I suppose.)
I have no clue at all about graphics, and I have no idea whatsoever
what I'm doing here, but I just wanted to post this somewhere for
Google to find in case someone else runs into this!
thanks,
Lennert
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 742f17f..77a6a04 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -513,11 +513,9 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
struct radeon_device *rdev = dev->dev_private;
struct drm_encoder *encoder = NULL;
struct radeon_encoder *radeon_encoder = NULL;
- struct drm_connector *connector = NULL;
u32 adjusted_clock = mode->clock;
int encoder_mode = 0;
u32 dp_clock = mode->clock;
- int bpc = 8;
bool is_duallink = false;
/* reset the pll flags */
@@ -549,13 +547,11 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
if (encoder->crtc == crtc) {
radeon_encoder = to_radeon_encoder(encoder);
- connector = radeon_get_connector_for_encoder(encoder);
- if (connector && connector->display_info.bpc)
- bpc = connector->display_info.bpc;
encoder_mode = atombios_get_encoder_mode(encoder);
is_duallink = radeon_dig_monitor_is_duallink(encoder,
mode->clock);
if ((radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT
| ATOM_DEVICE_DFP_SUPPORT)) ||
(radeon_encoder_get_dp_bridge_encoder_id(encoder)
!= ENCODER_OBJECT_ID_NONE)) {
+ struct drm_connector *connector =
radeon_get_connector_for_encoder(encoder);
if (connector) {
struct radeon_connector
*radeon_connector = to_radeon_connector(connector);
struct radeon_connector_atom_dig
*dig_connector =
@@ -645,7 +641,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
if (encoder_mode ==
ATOM_ENCODER_MODE_HDMI)
/* deep color support */
args.v3.sInput.usPixelClock =
-
cpu_to_le16((mode->clock * bpc / 8) / 10);
+ cpu_to_le16(mode->clock
/ 10);
if (dig->coherent_mode)
args.v3.sInput.ucDispPllConfig
|=
DISPPLL_CONFIG_COHERENT_MODE;
@@ -753,7 +749,6 @@ static void atombios_crtc_program_pll(struct drm_crtc *crtc,
u32 fb_div,
u32 frac_fb_div,
u32 post_div,
- int bpc,
bool ss_enabled,
struct radeon_atom_ss *ss)
{
@@ -817,15 +812,6 @@ static void atombios_crtc_program_pll(struct drm_crtc
*crtc,
args.v5.ucMiscInfo = 0;
[PATCH] drm/i915: no-lvds quirk on MSI DC500
Hi again,
Could anyone have a look at this ?
On Tue, Mar 13, 2012 at 3:16 PM, Anisse Astier wrote:
>
> Any opinion on this quirk ?
>
> On Wed, ?7 Mar 2012 18:36:35 +0100, Anisse Astier wrote
> :
>
> > This hardware doesn't have an LVDS, it's a desktop box. Fix incorrect
> > LVDS detection.
> >
> > Cc: stable at kernel.org
> > Signed-off-by: Anisse Astier
> > ---
> > ?drivers/gpu/drm/i915/intel_lvds.c | ? ?8
> > ?1 files changed, 8 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_lvds.c
> > b/drivers/gpu/drm/i915/intel_lvds.c
> > index b103c3b..2dee11e 100644
> > --- a/drivers/gpu/drm/i915/intel_lvds.c
> > +++ b/drivers/gpu/drm/i915/intel_lvds.c
> > @@ -739,6 +739,14 @@ static const struct dmi_system_id intel_no_lvds[] =
> > {
> > ? ? ? ? ? ? ? ? ? ? ? DMI_MATCH(DMI_BOARD_NAME, "AT5NM10T-I"),
> > ? ? ? ? ? ? ? },
> > ? ? ? },
> > + ? ? {
> > + ? ? ? ? ? ? .callback = intel_no_lvds_dmi_callback,
> > + ? ? ? ? ? ? .ident = "MSI Wind Box DC500",
> > + ? ? ? ? ? ? .matches = {
> > + ? ? ? ? ? ? ? ? ? ? DMI_MATCH(DMI_BOARD_VENDOR, "MICRO-STAR
> > INTERNATIONAL CO., LTD"),
> > + ? ? ? ? ? ? ? ? ? ? DMI_MATCH(DMI_BOARD_NAME, "MS-7469"),
> > + ? ? ? ? ? ? },
> > + ? ? },
> >
> > ? ? ? { } ? ? /* terminating entry */
> > ?};
[PATCH] exynos: add module name.
exynos drm driver have been added to mainline so this patch adds
module name for exynos to modetest and vbltest.
this patch is based on commit id below:
c50cc24690938db53cd91ae9ff2fa0958693f80d
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
tests/modetest/modetest.c |2 +-
tests/vbltest/vbltest.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 229ab8a..884e6e4 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -721,7 +721,7 @@ int main(int argc, char **argv)
int c;
int encoders = 0, connectors = 0, crtcs = 0, framebuffers = 0;
int test_vsync = 0;
- char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx" };
+ char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", "exynos" };
char *modeset = NULL;
int i, count = 0;
struct connector con_args[2];
diff --git a/tests/vbltest/vbltest.c b/tests/vbltest/vbltest.c
index 903ca0f..4fccd59 100644
--- a/tests/vbltest/vbltest.c
+++ b/tests/vbltest/vbltest.c
@@ -103,7 +103,7 @@ static void usage(char *name)
int main(int argc, char **argv)
{
int i, c, fd, ret;
- char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx" };
+ char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", "exynos" };
drmVBlank vbl;
drmEventContext evctx;
struct vbl_info handler_info;
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: no-lvds quirk on MSI DC500
On Wed, 7 Mar 2012 18:36:35 +0100, Anisse Astier wrote: > This hardware doesn't have an LVDS, it's a desktop box. Fix incorrect > LVDS detection. > > Cc: stable at kernel.org > Signed-off-by: Anisse Astier Acked-by: Chris Wilson *sigh* -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH] drm: Add locking to resume_force_mode to prevent multiple
On Thu, 22 Mar 2012 18:25:55 -0400, Sean Paul wrote: > Add a mutex to protect resume_force_mode from being called multiple > times. This fixes a bug observed on SNB where two wake sources call > resume_force_mode and the FDI training fails as a result. The user > facing result of this is complete screen corruption. Looks like a bug in i915_drv.c for calling that function without holding the mode_config.lock -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH v2] drm/i915: Run DDC buses at 50 kbps
On Wed, Mar 21, 2012 at 02:29:47PM +0100, Jean Delvare wrote: > A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C > devices can typically operate faster than this, 50 kbps should be fine > for all devices (and compliant devices can always stretch the clock if > needed.) > > FWIW, the vast majority of framebuffer drivers set udelay to 10 > already. So set it to 10 in DRM drivers too, this will make EDID block > reads faster. We might even lower the udelay value later if no problem > is reported. > > Signed-off-by: Jean Delvare > Acked-by: Eugeni Dodonov > Cc: Dave Airlie > Cc: Keith Packard Fyi this already got merged int Dave's tree (the unsplit version) as: commit 1849ecb22fb3b5d57b65e7369a3957adf9f26f39 Author: Jean Delvare Date: Sat Jan 28 11:07:09 2012 +0100 drm/kms: Make i2c buses faster Cheers, Daniel > --- > Changes since v1: > * Split per driver to make merging easier. > * Make the subject line more accurate. > > drivers/gpu/drm/i915/intel_i2c.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- linux-3.4-rc0.orig/drivers/gpu/drm/i915/intel_i2c.c 2012-03-21 > 13:43:33.750915151 +0100 > +++ linux-3.4-rc0/drivers/gpu/drm/i915/intel_i2c.c2012-03-21 > 13:44:05.923915628 +0100 > @@ -37,7 +37,7 @@ > > /* Intel GPIO access functions */ > > -#define I2C_RISEFALL_TIME 20 > +#define I2C_RISEFALL_TIME 10 > > static inline struct intel_gmbus * > to_intel_gmbus(struct i2c_adapter *i2c) > > -- > Jean Delvare > Suse L3 > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[Linaro-mm-sig] [RFCv2 PATCH 4/9] v4l: add buffer exporting via dmabuf
On 03/22/2012 07:37 PM, Laurent Pinchart wrote:
> Hi Subash,
>
> On Thursday 22 March 2012 19:27:01 Subash Patel wrote:
>> On 03/22/2012 04:46 PM, Laurent Pinchart wrote:
>>> On Tuesday 13 March 2012 11:17:02 Tomasz Stanislawski wrote:
>
> [snip]
>
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index bb6844e..e71c787 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -680,6 +680,25 @@ struct v4l2_buffer {
#define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE 0x0800
#define V4L2_BUF_FLAG_NO_CACHE_CLEAN0x1000
+/**
+ * struct v4l2_exportbuffer - export of video buffer as DMABUF file
descriptor
+ *
+ * @fd: file descriptor associated with DMABUF (set by driver)
+ * @mem_offset: for non-multiplanar buffers with memory ==
V4L2_MEMORY_MMAP;
>>>
>>> I don't think we will ever support exporting anything else than
>>> V4L2_MEMORY_MMAP buffers. What will happen for multiplanar buffers ?
>>>
+ *offset from the start of the device memory for this
plane,
+ *(or a "cookie" that should be passed to mmap() as
offset)
+ *
>>>
>>> Shouldn't the mem_offset field always be set to the mmap cookie value ?
>>> I'm a bit confused by the "or" part, it seems to have been copied from
>>> the v4l2_buffer documentation directly. We should clarify that.
>>>
+ * Contains data used for exporting a video buffer as DMABUF file
+ * descriptor. Uses the same 'cookie' as mmap() syscall. All reserved
fields
+ * must be set to zero.
+ */
+struct v4l2_exportbuffer {
+ __u32 fd;
+ __u32 reserved0;
>>>
>>> Why is there a reserved field here ?
>>
>> +1 to Laurent. Any particular need for reserved0 and reserved[13] below?
>> I think one void user pointer is sufficient even for future need.
>
> I'd rather have more than one void user pointer, just in case. A couple of
> bytes won't be expensive,
Just an off-topic note. When I learnt to hit keyboard for programming(in
linux for embedded), I had strict guidelines not to declare variables as
I like, as memory and computing was very precious then. A decade later,
people no more think its expensive to keep 14*3 bytes*(who knows how
many dma_buf objects) in the system.
Just a side note, thats all :)
and they will save lots of hassle in the future if
> we need to add a couple of fields. I was just wondering why there was a
> reserved field between fd and mem_offset.
>
+ __u32 mem_offset;
+ __u32 reserved[13];
+};
+
>>
>> Also, what is the reason for returning the fd through this structure? To
>> keep it aligned with other v4l2 calls? I liked(or now hate making change
>> in the app) how it was being returned through the ioctl in your last patch.
>
> Probably to be consistent with the V4L2 API, yes. It won't make a big
> difference for applications, I would favor consistency in this case.
>
[Linaro-mm-sig] [RFCv2 PATCH 2/9 - 4/4] v4l: vb2-dma-contig: update and code refactoring
Hi Laurent,
On 03/22/2012 08:12 PM, Laurent Pinchart wrote:
> Hi Tomasz,
>
> On Thursday 22 March 2012 14:36:33 Tomasz Stanislawski wrote:
>> Hi Laurent,
>> Thank you very much for your comments and question.
>> They were very useful.
>
> You're welcome.
>
>> Please refer to the comments below.
>>
>> On 03/22/2012 11:50 AM, Laurent Pinchart wrote:
>>> On Thursday 22 March 2012 11:02:23 Laurent Pinchart wrote:
From: Tomasz Stanislawski
This patch combines updates and fixes to dma-contig allocator.
Moreover the allocator code was refactored.
The most important changes are:
- functions were reordered
- move compression of scatterlist to separete function
- add support for multichunk but contiguous scatterlists
- simplified implementation of vb2-dma-contig context structure
- let mmap method to use dma_mmap_writecombine
- add support for scatterlist in userptr mode
>
> [snip]
>
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c index c898e6f..9965465
100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
>
> [snip]
>
static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
{
struct device *dev = alloc_ctx;
struct vb2_dc_buf *buf;
+ int ret;
+ int
n_pages;http://165.213.219.115/cgi-bin/gitweb.cgi?p=mirror/linux-3.0-mid
as;a=shortlog;h=refs/heads/exynos-3.0-dev +struct page **pages =
NULL;
buf = kzalloc(sizeof *buf, GFP_KERNEL);
if (!buf)
return ERR_PTR(-ENOMEM);
- buf->vaddr = dma_alloc_coherent(dev, size,&buf->dma_addr,
> GFP_KERNEL);
+ buf->dev = dev;
+ buf->size = size;
+ buf->vaddr = dma_alloc_coherent(buf->dev, buf->size,&buf->dma_addr,
+ GFP_KERNEL);
+
+ ret = -ENOMEM;
if (!buf->vaddr) {
- dev_err(dev, "dma_alloc_coherent of size %ld failed\n", size);
- kfree(buf);
- return ERR_PTR(-ENOMEM);
+ dev_err(dev, "dma_alloc_coherent of size %ld failed\n",
+ size);
+ goto fail_buf;
}
- buf->dev = dev;
- buf->size = size;
+ WARN_ON((unsigned long)buf->vaddr& ~PAGE_MASK);
+ WARN_ON(buf->dma_addr& ~PAGE_MASK);
+
+ n_pages = PAGE_ALIGN(size)>> PAGE_SHIFT;
+
+ pages = kmalloc(n_pages * sizeof pages[0], GFP_KERNEL);
+ if (!pages) {
+ printk(KERN_ERR "failed to alloc page table\n");
+ goto fail_dma;
+ }
+
+ ret = dma_get_pages(dev, buf->vaddr, buf->dma_addr, pages, n_pages);
>>>
>>> As the only purpose of this is to retrieve a list of pages that will be
>>> used to create a single-entry sgt, wouldn't it be possible to shortcut
>>> the code and get the physical address of the buffer directly ?
>>
>> The physical address should not be used since they are meaningless in a
>> context of different devices. It seams that only the list of pages is
>> more-or-less portable between different drivers.
>
> The pages are physically contiguous. The physical address of the first page is
> thus all you need.
>
> struct page and physical addresses can be used interchangeably in this case if
> I'm not mistaken. If you want to go with pages, you could use the first page
> only instead of the physical buffer address.
>
>> The physical address is already present in buf->dma_addr, but it is only
>> valid if the device has no MMU. Notice that vb2-dma-contig possess no
>> knowledge if MMU is present for a given device.
>
> That's why buf->dma_addr can't be considered as a physical address. It's only
> useful in the device context.
>
>> The sg list is not going to be single-entry if the device is provided with
>> its own MMU.
>
> There's something I don't get then. vb2-dma-contig deals with physically
> contiguous buffers. The buffer is backed by physically contiguous pages, so
> the sg list should have a single entry.
>
I think at present, vb2-dma-contig is abused for any kind of memory
allocation (continuous or not). Wouldnt it be good to have a proper
working setup for videobuf2-dma-sg instead? Driver which chooses to use
continuous, shall assign vb2_queue->mem_ops = vb2_dma_contig_memops. The
devices which know they have a MMU backing can assign the same to
vb2_dma_sg_memops. But as of now, we try to use vb2_dma_contig_memops
for all kind of operation. I have also done this mistake, and wish I
repaired it and posted it before :(
+ if (ret< 0) {
+ printk(KERN_ERR "failed to get buffer pages from DMA API\n");
+ goto fail_pages;
+ }
+ if (ret != n_pages) {
+ ret = -EFAULT;
+ printk(KERN_ERR "failed to get all pages from DMA API\n");
+ goto fail_pages;
+ }
+
[PATCH] drm/i2c/ch7006: Convert to dev_pm_ops
The I2C specific suspend and resume functions have been deprecated and
printing a warning on boot for over a year, dev_pm_ops should be used
instead so convert to that.
Also remove the suspend function since all it does is log.
Signed-off-by: Mark Brown
---
drivers/gpu/drm/i2c/ch7006_drv.c | 16 +++-
1 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c b/drivers/gpu/drm/i2c/ch7006_drv.c
index d3f2e87..ca4435d 100644
--- a/drivers/gpu/drm/i2c/ch7006_drv.c
+++ b/drivers/gpu/drm/i2c/ch7006_drv.c
@@ -427,15 +427,10 @@ static int ch7006_remove(struct i2c_client *client)
return 0;
}
-static int ch7006_suspend(struct i2c_client *client, pm_message_t mesg)
+static int ch7006_resume(struct device *dev)
{
- ch7006_dbg(client, "\n");
-
- return 0;
-}
+ struct i2c_client *client = to_i2c_device(dev);
-static int ch7006_resume(struct i2c_client *client)
-{
ch7006_dbg(client, "\n");
ch7006_write(client, 0x3d, 0x0);
@@ -499,15 +494,18 @@ static struct i2c_device_id ch7006_ids[] = {
};
MODULE_DEVICE_TABLE(i2c, ch7006_ids);
+static const struct dev_pm_ops ch7006_pm_ops = {
+ .resume = ch7006_resume,
+};
+
static struct drm_i2c_encoder_driver ch7006_driver = {
.i2c_driver = {
.probe = ch7006_probe,
.remove = ch7006_remove,
- .suspend = ch7006_suspend,
- .resume = ch7006_resume,
.driver = {
.name = "ch7006",
+ .pm = ch7006_pm_ops,
},
.id_table = ch7006_ids,
--
1.7.9.1
[Linaro-mm-sig] [RFCv2 PATCH 4/9] v4l: add buffer exporting via dmabuf
Hi Thomasz,
On 03/22/2012 04:46 PM, Laurent Pinchart wrote:
> Hi Tomasz,
>
> Thanks for the patch.
>
> On Tuesday 13 March 2012 11:17:02 Tomasz Stanislawski wrote:
>> This patch adds extension to V4L2 api. It allow to export a mmap buffer as
>> file descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset
>> used by mmap and return a file descriptor on success.
>
> I know code is more fun to write than documentation, but
> Documentation/DocBook/media/v4l will be sad if this patch is merged as-is ;-)
>
>> Signed-off-by: Tomasz Stanislawski
>> Signed-off-by: Kyungmin Park
>> ---
>> drivers/media/video/v4l2-compat-ioctl32.c |1 +
>> drivers/media/video/v4l2-ioctl.c | 11 +++
>> include/linux/videodev2.h | 20
>> include/media/v4l2-ioctl.h|2 ++
>> 4 files changed, 34 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
>> b/drivers/media/video/v4l2-compat-ioctl32.c index e6f67aa..fd157cb 100644
>> --- a/drivers/media/video/v4l2-compat-ioctl32.c
>> +++ b/drivers/media/video/v4l2-compat-ioctl32.c
>> @@ -954,6 +954,7 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int
>> cmd, unsigned long arg) case VIDIOC_S_FBUF32:
>> case VIDIOC_OVERLAY32:
>> case VIDIOC_QBUF32:
>> +case VIDIOC_EXPBUF:
>> case VIDIOC_DQBUF32:
>> case VIDIOC_STREAMON32:
>> case VIDIOC_STREAMOFF32:
>> diff --git a/drivers/media/video/v4l2-ioctl.c
>> b/drivers/media/video/v4l2-ioctl.c index 74cab51..a125016 100644
>> --- a/drivers/media/video/v4l2-ioctl.c
>> +++ b/drivers/media/video/v4l2-ioctl.c
>> @@ -207,6 +207,7 @@ static const char *v4l2_ioctls[] = {
>> [_IOC_NR(VIDIOC_S_FBUF)] = "VIDIOC_S_FBUF",
>> [_IOC_NR(VIDIOC_OVERLAY)] = "VIDIOC_OVERLAY",
>> [_IOC_NR(VIDIOC_QBUF)] = "VIDIOC_QBUF",
>> +[_IOC_NR(VIDIOC_EXPBUF)] = "VIDIOC_EXPBUF",
>> [_IOC_NR(VIDIOC_DQBUF)]= "VIDIOC_DQBUF",
>> [_IOC_NR(VIDIOC_STREAMON)] = "VIDIOC_STREAMON",
>> [_IOC_NR(VIDIOC_STREAMOFF)]= "VIDIOC_STREAMOFF",
>> @@ -938,6 +939,16 @@ static long __video_do_ioctl(struct file *file,
>> dbgbuf(cmd, vfd, p);
>> break;
>> }
>> +case VIDIOC_EXPBUF:
>> +{
>> +struct v4l2_exportbuffer *p = arg;
>> +
>> +if (!ops->vidioc_expbuf)
>> +break;
>> +
>> +ret = ops->vidioc_expbuf(file, fh, p);
>
> You can pass arg to ops->vidioc_expbuf() directly, there's no need to create a
> struct v4l2_exportbuffer *p variable.
>
>> +break;
>> +}
>> case VIDIOC_DQBUF:
>> {
>> struct v4l2_buffer *p = arg;
>> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
>> index bb6844e..e71c787 100644
>> --- a/include/linux/videodev2.h
>> +++ b/include/linux/videodev2.h
>> @@ -680,6 +680,25 @@ struct v4l2_buffer {
>> #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE 0x0800
>> #define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000
>>
>> +/**
>> + * struct v4l2_exportbuffer - export of video buffer as DMABUF file
>> descriptor
>> + *
>> + * @fd: file descriptor associated with DMABUF (set by driver)
>> + * @mem_offset: for non-multiplanar buffers with memory ==
>> V4L2_MEMORY_MMAP;
>
> I don't think we will ever support exporting anything else than
> V4L2_MEMORY_MMAP buffers. What will happen for multiplanar buffers ?
>
>> + * offset from the start of the device memory for this plane,
>> + * (or a "cookie" that should be passed to mmap() as offset)
>> + *
>
> Shouldn't the mem_offset field always be set to the mmap cookie value ? I'm a
> bit confused by the "or" part, it seems to have been copied from the
> v4l2_buffer documentation directly. We should clarify that.
>
>> + * Contains data used for exporting a video buffer as DMABUF file
>> + * descriptor. Uses the same 'cookie' as mmap() syscall. All reserved
>> fields
>> + * must be set to zero.
>> + */
>> +struct v4l2_exportbuffer {
>> +__u32 fd;
>> +__u32 reserved0;
>
> Why is there a reserved field here ?
+1 to Laurent. Any particular need for reserved0 and reserved[13] below?
I think one void user pointer is sufficient even for future need.
>
>> +__u32 mem_offset;
>> +__u32 reserved[13];
>> +};
>> +
Also, what is the reason for returning the fd through this structure? To
keep it aligned with other v4l2 calls? I liked(or now hate making change
in the app) how it was being returned through the ioctl in your last patch.
>> /*
>>* O V E R L A Y P R E V I E W
>>*/
>> @@ -2303,6 +2322,7 @@ struct v4l2_create_buffers {
>> #define VIDIOC_S_FBUF _IOW('V', 11, struct v4l2_framebuffer)
>> #define VIDIOC_OVERLAY _IOW('V', 14, int)
>> #define VIDIOC_QBUF_IOWR('V', 15, struct v4l2_buffer)
>> +
[Linaro-mm-sig] [RFCv2 PATCH 2/9] v4l: vb2-dma-contig: update and code refactoring
Hello Thomasz, Marek,
I found an issue with below patch. Please read below.
On 03/13/2012 03:47 PM, Tomasz Stanislawski wrote:
> This patch combines updates and fixes to dma-contig allocator.
> Moreover the allocator code was refactored.
> The most important changes are:
> - functions were reordered
> - move compression of scatterlist to separete function
> - add support for multichunk but contiguous scatterlists
> - simplified implementation of vb2-dma-contig context structure
> - let mmap method to use dma_mmap_writecombine
> - add support for scatterlist in userptr mode
>
> Signed-off-by: Marek Szyprowski
> [mmap method]
> Signed-off-by: Andrzej Pietrasiewicz
> [scatterlist in userptr mode]
> Signed-off-by: Kamil Debski
> [bugfixing]
> Signed-off-by: Tomasz Stanislawski
> [core refactoring, helper functions]
> Signed-off-by: Kyungmin Park
> ---
> drivers/media/video/videobuf2-dma-contig.c | 495
> +++-
> 1 files changed, 414 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/media/video/videobuf2-dma-contig.c
> b/drivers/media/video/videobuf2-dma-contig.c
> index f17ad98..c1dc043 100644
> --- a/drivers/media/video/videobuf2-dma-contig.c
> +++ b/drivers/media/video/videobuf2-dma-contig.c
> @@ -10,173 +10,506 @@
>* the Free Software Foundation.
>*/
>
> +#include
> +#include
> #include
> +#include
> +#include
> #include
> -#include
>
> #include
> #include
>
> -struct vb2_dc_conf {
> - struct device *dev;
> -};
> -
> struct vb2_dc_buf {
> - struct vb2_dc_conf *conf;
> + struct device *dev;
> void*vaddr;
> - dma_addr_t dma_addr;
> unsigned long size;
> - struct vm_area_struct *vma;
> - atomic_trefcount;
> + dma_addr_t dma_addr;
> + struct sg_table *dma_sgt;
> + enum dma_data_direction dma_dir;
> +
> + /* MMAP related */
> struct vb2_vmarea_handler handler;
> + atomic_trefcount;
> + struct sg_table *sgt_base;
> +
> + /* USERPTR related */
> + struct vm_area_struct *vma;
> };
>
> -static void vb2_dma_contig_put(void *buf_priv);
> +/*/
> +/*scatterlist table functions*/
> +/*/
>
> -static void *vb2_dma_contig_alloc(void *alloc_ctx, unsigned long size)
> +static struct sg_table *vb2_dc_pages_to_sgt(struct page **pages,
> + unsigned long n_pages, size_t offset, size_t offset2)
> {
> - struct vb2_dc_conf *conf = alloc_ctx;
> - struct vb2_dc_buf *buf;
> + struct sg_table *sgt;
> + int i, j; /* loop counters */
> + int cur_page, chunks;
> + int ret;
> + struct scatterlist *s;
>
> - buf = kzalloc(sizeof *buf, GFP_KERNEL);
> - if (!buf)
> + sgt = kzalloc(sizeof *sgt, GFP_KERNEL);
> + if (!sgt)
> return ERR_PTR(-ENOMEM);
>
> - buf->vaddr = dma_alloc_coherent(conf->dev, size,&buf->dma_addr,
> - GFP_KERNEL);
> - if (!buf->vaddr) {
> - dev_err(conf->dev, "dma_alloc_coherent of size %ld failed\n",
> - size);
> - kfree(buf);
> + /* compute number of chunks */
> + chunks = 1;
> + for (i = 1; i< n_pages; ++i)
> + if (pages[i] != pages[i - 1] + 1)
> + ++chunks;
> +
> + ret = sg_alloc_table(sgt, chunks, GFP_KERNEL);
> + if (ret) {
> + kfree(sgt);
> return ERR_PTR(-ENOMEM);
> }
>
> - buf->conf = conf;
> - buf->size = size;
> -
> - buf->handler.refcount =&buf->refcount;
> - buf->handler.put = vb2_dma_contig_put;
> - buf->handler.arg = buf;
> + /* merging chunks and putting them into the scatterlist */
> + cur_page = 0;
> + for_each_sg(sgt->sgl, s, sgt->orig_nents, i) {
> + size_t size = PAGE_SIZE;
> +
> + for (j = cur_page + 1; j< n_pages; ++j) {
> + if (pages[j] != pages[j - 1] + 1)
> + break;
> + size += PAGE_SIZE;
> + }
> +
> + /* cut offset if chunk starts at the first page */
> + if (cur_page == 0)
> + size -= offset;
> + /* cut offset2 if chunk ends at the last page */
> + if (j == n_pages)
> + size -= offset2;
> +
> + sg_set_page(s, pages[cur_page], size, offset);
> + offset = 0;
> + cur_page = j;
> + }
>
> - atomic_inc(&buf->refcount);
> + return sgt;
> +}
>
> - return buf;
> +static void vb2_dc_release_sgtable(struct sg_table *sgt)
> +{
> + sg_free_table(sgt);
> + kfree(sgt);
> }
>
> -static void vb2_dma_contig_put
Re: [PATCH] drm/i2c/ch7006: Convert to dev_pm_ops
Mark Brown writes:
> The I2C specific suspend and resume functions have been deprecated and
> printing a warning on boot for over a year, dev_pm_ops should be used
> instead so convert to that.
>
> Also remove the suspend function since all it does is log.
>
> Signed-off-by: Mark Brown
> ---
> drivers/gpu/drm/i2c/ch7006_drv.c | 16 +++-
> 1 files changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c
> b/drivers/gpu/drm/i2c/ch7006_drv.c
> index d3f2e87..ca4435d 100644
> --- a/drivers/gpu/drm/i2c/ch7006_drv.c
> +++ b/drivers/gpu/drm/i2c/ch7006_drv.c
> @@ -427,15 +427,10 @@ static int ch7006_remove(struct i2c_client *client)
> return 0;
> }
>
> -static int ch7006_suspend(struct i2c_client *client, pm_message_t mesg)
> +static int ch7006_resume(struct device *dev)
> {
> - ch7006_dbg(client, "\n");
> -
> - return 0;
> -}
> + struct i2c_client *client = to_i2c_device(dev);
>
> -static int ch7006_resume(struct i2c_client *client)
> -{
> ch7006_dbg(client, "\n");
>
> ch7006_write(client, 0x3d, 0x0);
> @@ -499,15 +494,18 @@ static struct i2c_device_id ch7006_ids[] = {
> };
> MODULE_DEVICE_TABLE(i2c, ch7006_ids);
>
> +static const struct dev_pm_ops ch7006_pm_ops = {
> + .resume = ch7006_resume,
> +};
> +
> static struct drm_i2c_encoder_driver ch7006_driver = {
> .i2c_driver = {
> .probe = ch7006_probe,
> .remove = ch7006_remove,
> - .suspend = ch7006_suspend,
> - .resume = ch7006_resume,
>
> .driver = {
> .name = "ch7006",
> + .pm = ch7006_pm_ops,
> },
>
> .id_table = ch7006_ids,
Thanks for fixing this,
Reviewed-by: Francisco Jerez
pgpqYbaUbei8x.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Add locking to resume_force_mode to prevent multiple
Add a mutex to protect resume_force_mode from being called multiple
times. This fixes a bug observed on SNB where two wake sources call
resume_force_mode and the FDI training fails as a result. The user
facing result of this is complete screen corruption.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_crtc_helper.c |8
drivers/gpu/drm/drm_stub.c|1 +
include/drm/drmP.h|1 +
3 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 8111889..de7e492 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -882,6 +882,13 @@ int drm_helper_resume_force_mode(struct drm_device *dev)
struct drm_crtc_helper_funcs *crtc_funcs;
int ret;
+ /* Make sure we're not already resuming, this can really screw
+* things up! */
+ if (mutex_trylock(&dev->resume_mutex) == 0) {
+ DRM_DEBUG("Already in resume_force_mode\n");
+ return 0;
+ }
+
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
if (!crtc->enabled)
@@ -914,6 +921,7 @@ int drm_helper_resume_force_mode(struct drm_device *dev)
}
/* disable the unused connectors while restoring the modesetting */
drm_helper_disable_unused_functions(dev);
+ mutex_unlock(&dev->resume_mutex);
return 0;
}
EXPORT_SYMBOL(drm_helper_resume_force_mode);
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index aa454f8..f35bed5 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -273,6 +273,7 @@ int drm_fill_in_dev(struct drm_device *dev,
spin_lock_init(&dev->count_lock);
spin_lock_init(&dev->event_lock);
mutex_init(&dev->struct_mutex);
+ mutex_init(&dev->resume_mutex);
mutex_init(&dev->ctxlist_mutex);
if (drm_ht_create(&dev->map_hash, 12)) {
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 574bd1c..75395a8 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1034,6 +1034,7 @@ struct drm_device {
/*@{ */
spinlock_t count_lock; /**< For inuse, drm_device::open_count,
drm_device::buf_use */
struct mutex struct_mutex; /**< For others */
+ struct mutex resume_mutex; /**< For drm_helper_resume_force_mode */
/*@} */
/** \name Usage Counters */
--
1.7.7.3
[Linaro-mm-sig] [RFCv2 PATCH 2/9 - 4/4] v4l: vb2-dma-contig: update and code refactoring
On 03/22/2012 03:52 PM, Subash Patel wrote: > Hi Laurent, > > On 03/22/2012 08:12 PM, Laurent Pinchart wrote: >> Hi Tomasz, >> >> On Thursday 22 March 2012 14:36:33 Tomasz Stanislawski wrote: >>> Hi Laurent, >>> Thank you very much for your comments and question. >>> They were very useful. >> >> You're welcome. >> >>> Please refer to the comments below. >>> >>> On 03/22/2012 11:50 AM, Laurent Pinchart wrote: On Thursday 22 March 2012 11:02:23 Laurent Pinchart wrote: > From: Tomasz Stanislawski > [snip] >>> The physical address is already present in buf->dma_addr, but it is only >>> valid if the device has no MMU. Notice that vb2-dma-contig possess no >>> knowledge if MMU is present for a given device. >> >> That's why buf->dma_addr can't be considered as a physical address. It's only >> useful in the device context. >> >>> The sg list is not going to be single-entry if the device is provided with >>> its own MMU. >> >> There's something I don't get then. vb2-dma-contig deals with physically >> contiguous buffers. The buffer is backed by physically contiguous pages, so >> the sg list should have a single entry. >> > I think at present, vb2-dma-contig is abused for any kind of memory > allocation (continuous or not). Wouldnt it be good to have a > proper working setup for videobuf2-dma-sg instead? Driver which chooses to > use continuous, shall assign vb2_queue->mem_ops = > vb2_dma_contig_memops. The devices which know they have a MMU backing can > assign the same to vb2_dma_sg_memops. But as of now, > we try to use vb2_dma_contig_memops for all kind of operation. I have also > done this mistake, and wish I repaired it and posted > it before :( > Hi Subash, At first, I do not think that vb2-dma-contig is abused for any kind of allocation. It is used only for DMA coherent contiguous mapping what is very close to vb2-dma-contig's original purpose. One thing has to be said loudly: "The driver does not need to and should not know if IOMMU is present or not." The DMA framework must know if device uses IOMMU or not. Reason: the memory is allocated, free, flushed, mapped only by DMA framework. Usage of vb2-dma-contig or vb2-dma-sg depends only on the way how the memory is configured into the device. Most of embedded devices use only buffer's start address and buffer size (often indirectly specified by width/height and format). It mean that device needs a buffer that is contiguous for its DMA engine. In such a case, the driver should ALWAYS use vb2-dma-contig. The DMA framework hidden deep in dma_alloc_coherent internals will deal with IOMMU configuration. I hope you find this information useful. Regards, Tomasz Stanislawski
[Bug 37696] [RADEON:KMS:PLL] frequent colored lines appear on screen
https://bugs.freedesktop.org/show_bug.cgi?id=37696 --- Comment #2 from Joshua Roys 2012-03-22 17:08:25 PDT --- They are still visible with 3.3.0. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Linaro-mm-sig] [RFCv2 PATCH 2/9 - 4/4] v4l: vb2-dma-contig: update and code refactoring
Hi Laurent,
On 03/22/2012 03:42 PM, Laurent Pinchart wrote:
> Hi Tomasz,
>
> On Thursday 22 March 2012 14:36:33 Tomasz Stanislawski wrote:
>> Hi Laurent,
>> Thank you very much for your comments and question.
>> They were very useful.
>
> You're welcome.
>
>> Please refer to the comments below.
>>
>> On 03/22/2012 11:50 AM, Laurent Pinchart wrote:
>>> On Thursday 22 March 2012 11:02:23 Laurent Pinchart wrote:
From: Tomasz Stanislawski
This patch combines updates and fixes to dma-contig allocator.
Moreover the allocator code was refactored.
The most important changes are:
- functions were reordered
- move compression of scatterlist to separete function
- add support for multichunk but contiguous scatterlists
- simplified implementation of vb2-dma-contig context structure
- let mmap method to use dma_mmap_writecombine
- add support for scatterlist in userptr mode
>
> [snip]
>
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c index c898e6f..9965465
100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
>
> [snip]
>
static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
{
struct device *dev = alloc_ctx;
struct vb2_dc_buf *buf;
+ int ret;
+ int
n_pages;
buf = kzalloc(sizeof *buf, GFP_KERNEL);
if (!buf)
return ERR_PTR(-ENOMEM);
- buf->vaddr = dma_alloc_coherent(dev, size, &buf->dma_addr,
> GFP_KERNEL);
+ buf->dev = dev;
+ buf->size = size;
+ buf->vaddr = dma_alloc_coherent(buf->dev, buf->size, &buf->dma_addr,
+ GFP_KERNEL);
+
+ ret = -ENOMEM;
if (!buf->vaddr) {
- dev_err(dev, "dma_alloc_coherent of size %ld failed\n", size);
- kfree(buf);
- return ERR_PTR(-ENOMEM);
+ dev_err(dev, "dma_alloc_coherent of size %ld failed\n",
+ size);
+ goto fail_buf;
}
- buf->dev = dev;
- buf->size = size;
+ WARN_ON((unsigned long)buf->vaddr & ~PAGE_MASK);
+ WARN_ON(buf->dma_addr & ~PAGE_MASK);
+
+ n_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
+
+ pages = kmalloc(n_pages * sizeof pages[0], GFP_KERNEL);
+ if (!pages) {
+ printk(KERN_ERR "failed to alloc page table\n");
+ goto fail_dma;
+ }
+
+ ret = dma_get_pages(dev, buf->vaddr, buf->dma_addr, pages, n_pages);
>>>
>>> As the only purpose of this is to retrieve a list of pages that will be
>>> used to create a single-entry sgt, wouldn't it be possible to shortcut
>>> the code and get the physical address of the buffer directly ?
>>
>> The physical address should not be used since they are meaningless in a
>> context of different devices. It seams that only the list of pages is
>> more-or-less portable between different drivers.
>
> The pages are physically contiguous. The physical address of the first page
> is
> thus all you need.
No. DMA-CONTIG buffers do not have to be physically contiguous. Please refer
below.
>
> struct page and physical addresses can be used interchangeably in this case
> if
> I'm not mistaken. If you want to go with pages, you could use the first page
> only instead of the physical buffer address.
>
Ok. There are bus addresses, physical addresses, DMA addresses and PFNs.
As I understand PFNs and 'struct page' can be interchanged, at least in one
direction.
The PFNs are used to create a bus address, I mean addresses that are recognized
by
a RAM chip. So a list of PFNs seams to be the most portable way of describing
the memory, isn't it?
>> The physical address is already present in buf->dma_addr, but it is only
>> valid if the device has no MMU. Notice that vb2-dma-contig possess no
>> knowledge if MMU is present for a given device.
>
> That's why buf->dma_addr can't be considered as a physical address. It's only
> useful in the device context.
>
ok
>> The sg list is not going to be single-entry if the device is provided with
>> its own MMU.
>
> There's something I don't get then. vb2-dma-contig deals with physically
> contiguous buffers. The buffer is backed by physically contiguous pages, so
> the sg list should have a single entry.
>
As I understand dma-contig deal with DMA contiguous buffers, it means buffers
that are contiguous from device point of view. Therefore those buffers do NOT
have to be physically contiguous if the device has its own IOMMU.
+ if (ret < 0) {
+ printk(KERN_ERR "failed to get buffer pages from DMA API\n");
+ goto fail_pages;
+ }
+ if (ret != n_pages) {
+ ret = -EFAULT;
+ printk(KERN_ERR "failed to get all pages from DMA API\n");
+ goto fail_pages;
+
[Linaro-mm-sig] [RFCv2 PATCH 4/9] v4l: add buffer exporting via dmabuf
Hi Subash,
On Thursday 22 March 2012 20:29:57 Subash Patel wrote:
> On 03/22/2012 07:37 PM, Laurent Pinchart wrote:
> > On Thursday 22 March 2012 19:27:01 Subash Patel wrote:
> >> On 03/22/2012 04:46 PM, Laurent Pinchart wrote:
> >>> On Tuesday 13 March 2012 11:17:02 Tomasz Stanislawski wrote:
> > [snip]
> >
> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> index bb6844e..e71c787 100644
> --- a/include/linux/videodev2.h
> +++ b/include/linux/videodev2.h
> @@ -680,6 +680,25 @@ struct v4l2_buffer {
>
> #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE 0x0800
> #define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000
>
> +/**
> + * struct v4l2_exportbuffer - export of video buffer as DMABUF file
> descriptor
> + *
> + * @fd: file descriptor associated with DMABUF (set by driver)
> + * @mem_offset: for non-multiplanar buffers with memory ==
> V4L2_MEMORY_MMAP;
> >>>
> >>> I don't think we will ever support exporting anything else than
> >>> V4L2_MEMORY_MMAP buffers. What will happen for multiplanar buffers ?
> >>>
> + * offset from the start of the device memory for this
> plane,
> + * (or a "cookie" that should be passed to mmap() as
> offset)
> + *
> >>>
> >>> Shouldn't the mem_offset field always be set to the mmap cookie value ?
> >>> I'm a bit confused by the "or" part, it seems to have been copied from
> >>> the v4l2_buffer documentation directly. We should clarify that.
> >>>
> + * Contains data used for exporting a video buffer as DMABUF file
> + * descriptor. Uses the same 'cookie' as mmap() syscall. All reserved
> fields
> + * must be set to zero.
> + */
> +struct v4l2_exportbuffer {
> +__u32 fd;
> +__u32 reserved0;
> >>>
> >>> Why is there a reserved field here ?
> >>
> >> +1 to Laurent. Any particular need for reserved0 and reserved[13] below?
> >> I think one void user pointer is sufficient even for future need.
> >
> > I'd rather have more than one void user pointer, just in case. A couple of
> > bytes won't be expensive,
>
> Just an off-topic note. When I learnt to hit keyboard for programming(in
> linux for embedded), I had strict guidelines not to declare variables as
> I like, as memory and computing was very precious then.
Somewhere on my TODO list is a Kalman filter implementation for a
microcontroller with 512 bytes of RAM. I know what you mean :-)
> A decade later, people no more think its expensive to keep 14*3 bytes*(who
> knows how many dma_buf objects) in the system.
> Just a side note, thats all :)
For objects that will exist in many instances, saving memory is important (you
would need to be really convincing to add a single bit to struct page for
instance), but struct v4l2_exportbuffer is only used to hold parameters for an
ioctl. That's temporary memory, so I think we can spare a couple of extra
bytes if it can help with ABI stability.
> > and they will save lots of hassle in the future if
> > we need to add a couple of fields. I was just wondering why there was a
> > reserved field between fd and mem_offset.
> >
> +__u32 mem_offset;
> +__u32 reserved[13];
> +};
> +
> >>
> >> Also, what is the reason for returning the fd through this structure? To
> >> keep it aligned with other v4l2 calls? I liked(or now hate making change
> >> in the app) how it was being returned through the ioctl in your last
> >> patch.
> >
> > Probably to be consistent with the V4L2 API, yes. It won't make a big
> > difference for applications, I would favor consistency in this case.
--
Regards,
Laurent Pinchart
Re: [PATCH] drm/i915: no-lvds quirk on MSI DC500
On Wed, 7 Mar 2012 18:36:35 +0100, Anisse Astier wrote: > This hardware doesn't have an LVDS, it's a desktop box. Fix incorrect > LVDS detection. > > Cc: sta...@kernel.org > Signed-off-by: Anisse Astier Acked-by: Chris Wilson *sigh* -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Add locking to resume_force_mode to prevent multiple
On Thu, 22 Mar 2012 18:25:55 -0400, Sean Paul wrote: > Add a mutex to protect resume_force_mode from being called multiple > times. This fixes a bug observed on SNB where two wake sources call > resume_force_mode and the FDI training fails as a result. The user > facing result of this is complete screen corruption. Looks like a bug in i915_drv.c for calling that function without holding the mode_config.lock -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Linaro-mm-sig] [RFCv2 PATCH 4/9] v4l: add buffer exporting via dmabuf
On Thursday 22 March 2012 15:26:08 Daniel Vetter wrote:
> On Thu, Mar 22, 2012 at 03:07:18PM +0100, Laurent Pinchart wrote:
> > > >> + * Contains data used for exporting a video buffer as DMABUF file
> > > >> + * descriptor. Uses the same 'cookie' as mmap() syscall. All
> > > >> reserved
> > > >> fields
> > > >> + * must be set to zero.
> > > >> + */
> > > >> +struct v4l2_exportbuffer {
> > > >> + __u32 fd;
> > > >> + __u32 reserved0;
> > > >
> > > > Why is there a reserved field here ?
> > >
> > > +1 to Laurent. Any particular need for reserved0 and reserved[13] below?
> > > I think one void user pointer is sufficient even for future need.
> >
> > I'd rather have more than one void user pointer, just in case. A couple of
> > bytes won't be expensive, and they will save lots of hassle in the future
> > if we need to add a couple of fields. I was just wondering why there was
> > a reserved field between fd and mem_offset.
>
> Quick comment from a random bystander: __u32 is not big enough for a void*
> pointer from userspace ...
That's why I'm happy with 14 reserved __u32. That should be enough for
userspace pointers in the foreseable future :-)
--
Regards,
Laurent Pinchart
[Linaro-mm-sig] [RFCv2 PATCH 2/9 - 4/4] v4l: vb2-dma-contig: update and code refactoring
Hi Tomasz,
On Thursday 22 March 2012 14:36:33 Tomasz Stanislawski wrote:
> Hi Laurent,
> Thank you very much for your comments and question.
> They were very useful.
You're welcome.
> Please refer to the comments below.
>
> On 03/22/2012 11:50 AM, Laurent Pinchart wrote:
> > On Thursday 22 March 2012 11:02:23 Laurent Pinchart wrote:
> >> From: Tomasz Stanislawski
> >>
> >> This patch combines updates and fixes to dma-contig allocator.
> >> Moreover the allocator code was refactored.
> >> The most important changes are:
> >> - functions were reordered
> >> - move compression of scatterlist to separete function
> >> - add support for multichunk but contiguous scatterlists
> >> - simplified implementation of vb2-dma-contig context structure
> >> - let mmap method to use dma_mmap_writecombine
> >> - add support for scatterlist in userptr mode
[snip]
> >> diff --git a/drivers/media/video/videobuf2-dma-contig.c
> >> b/drivers/media/video/videobuf2-dma-contig.c index c898e6f..9965465
> >> 100644
> >> --- a/drivers/media/video/videobuf2-dma-contig.c
> >> +++ b/drivers/media/video/videobuf2-dma-contig.c
[snip]
> >> static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
> >> {
> >>
> >>struct device *dev = alloc_ctx;
> >>struct vb2_dc_buf *buf;
> >>
> >> + int ret;
> >> + int
> >> n_pages;http://165.213.219.115/cgi-bin/gitweb.cgi?p=mirror/linux-3.0-mid
> >> as;a=shortlog;h=refs/heads/exynos-3.0-dev +struct page **pages =
> >> NULL;
> >>
> >>buf = kzalloc(sizeof *buf, GFP_KERNEL);
> >>if (!buf)
> >>
> >>return ERR_PTR(-ENOMEM);
> >>
> >> - buf->vaddr = dma_alloc_coherent(dev, size, &buf->dma_addr,
GFP_KERNEL);
> >> + buf->dev = dev;
> >> + buf->size = size;
> >> + buf->vaddr = dma_alloc_coherent(buf->dev, buf->size, &buf->dma_addr,
> >> + GFP_KERNEL);
> >> +
> >> + ret = -ENOMEM;
> >>
> >>if (!buf->vaddr) {
> >>
> >> - dev_err(dev, "dma_alloc_coherent of size %ld failed\n", size);
> >> - kfree(buf);
> >> - return ERR_PTR(-ENOMEM);
> >> + dev_err(dev, "dma_alloc_coherent of size %ld failed\n",
> >> + size);
> >> + goto fail_buf;
> >>
> >>}
> >>
> >> - buf->dev = dev;
> >> - buf->size = size;
> >> + WARN_ON((unsigned long)buf->vaddr & ~PAGE_MASK);
> >> + WARN_ON(buf->dma_addr & ~PAGE_MASK);
> >> +
> >> + n_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
> >> +
> >> + pages = kmalloc(n_pages * sizeof pages[0], GFP_KERNEL);
> >> + if (!pages) {
> >> + printk(KERN_ERR "failed to alloc page table\n");
> >> + goto fail_dma;
> >> + }
> >> +
> >> + ret = dma_get_pages(dev, buf->vaddr, buf->dma_addr, pages, n_pages);
> >
> > As the only purpose of this is to retrieve a list of pages that will be
> > used to create a single-entry sgt, wouldn't it be possible to shortcut
> > the code and get the physical address of the buffer directly ?
>
> The physical address should not be used since they are meaningless in a
> context of different devices. It seams that only the list of pages is
> more-or-less portable between different drivers.
The pages are physically contiguous. The physical address of the first page is
thus all you need.
struct page and physical addresses can be used interchangeably in this case if
I'm not mistaken. If you want to go with pages, you could use the first page
only instead of the physical buffer address.
> The physical address is already present in buf->dma_addr, but it is only
> valid if the device has no MMU. Notice that vb2-dma-contig possess no
> knowledge if MMU is present for a given device.
That's why buf->dma_addr can't be considered as a physical address. It's only
useful in the device context.
> The sg list is not going to be single-entry if the device is provided with
> its own MMU.
There's something I don't get then. vb2-dma-contig deals with physically
contiguous buffers. The buffer is backed by physically contiguous pages, so
the sg list should have a single entry.
> >> + if (ret < 0) {
> >> + printk(KERN_ERR "failed to get buffer pages from DMA API\n");
> >> + goto fail_pages;
> >> + }
> >> + if (ret != n_pages) {
> >> + ret = -EFAULT;
> >> + printk(KERN_ERR "failed to get all pages from DMA API\n");
> >> + goto fail_pages;
> >> + }
> >> +
> >> + buf->sgt_base = vb2_dc_pages_to_sgt(pages, n_pages, 0, 0);
> >> + if (IS_ERR(buf->sgt_base)) {
> >> + ret = PTR_ERR(buf->sgt_base);
> >> + printk(KERN_ERR "failed to prepare sg table\n");
> >> + goto fail_pages;
> >> + }
> >
> > buf->sgt_base isn't used in this patch. I would move the buf->sgt_base
> > creation code to the patch that uses it then, or to its own patch just
> > before the patch that uses it.
>
> Good point. The sgt_base is used by exporter only. Thanks for noticing it.
>
> >> +
> >> + /* pages are no longer needed */
> >> + kfree(pages);
> >>
> >>buf->handler.re
[PATCH] drm: Add locking to resume_force_mode to prevent multiple
Add a mutex to protect resume_force_mode from being called multiple
times. This fixes a bug observed on SNB where two wake sources call
resume_force_mode and the FDI training fails as a result. The user
facing result of this is complete screen corruption.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_crtc_helper.c |8
drivers/gpu/drm/drm_stub.c|1 +
include/drm/drmP.h|1 +
3 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 8111889..de7e492 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -882,6 +882,13 @@ int drm_helper_resume_force_mode(struct drm_device *dev)
struct drm_crtc_helper_funcs *crtc_funcs;
int ret;
+ /* Make sure we're not already resuming, this can really screw
+* things up! */
+ if (mutex_trylock(&dev->resume_mutex) == 0) {
+ DRM_DEBUG("Already in resume_force_mode\n");
+ return 0;
+ }
+
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
if (!crtc->enabled)
@@ -914,6 +921,7 @@ int drm_helper_resume_force_mode(struct drm_device *dev)
}
/* disable the unused connectors while restoring the modesetting */
drm_helper_disable_unused_functions(dev);
+ mutex_unlock(&dev->resume_mutex);
return 0;
}
EXPORT_SYMBOL(drm_helper_resume_force_mode);
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index aa454f8..f35bed5 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -273,6 +273,7 @@ int drm_fill_in_dev(struct drm_device *dev,
spin_lock_init(&dev->count_lock);
spin_lock_init(&dev->event_lock);
mutex_init(&dev->struct_mutex);
+ mutex_init(&dev->resume_mutex);
mutex_init(&dev->ctxlist_mutex);
if (drm_ht_create(&dev->map_hash, 12)) {
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 574bd1c..75395a8 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1034,6 +1034,7 @@ struct drm_device {
/*@{ */
spinlock_t count_lock; /**< For inuse, drm_device::open_count,
drm_device::buf_use */
struct mutex struct_mutex; /**< For others */
+ struct mutex resume_mutex; /**< For drm_helper_resume_force_mode */
/*@} */
/** \name Usage Counters */
--
1.7.7.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Linaro-mm-sig] [RFCv2 PATCH 4/9] v4l: add buffer exporting via dmabuf
On Thu, Mar 22, 2012 at 03:07:18PM +0100, Laurent Pinchart wrote:
> > >> + * Contains data used for exporting a video buffer as DMABUF file
> > >> + * descriptor. Uses the same 'cookie' as mmap() syscall. All reserved
> > >> fields
> > >> + * must be set to zero.
> > >> + */
> > >> +struct v4l2_exportbuffer {
> > >> +__u32 fd;
> > >> +__u32 reserved0;
> > >
> > > Why is there a reserved field here ?
> >
> > +1 to Laurent. Any particular need for reserved0 and reserved[13] below?
> > I think one void user pointer is sufficient even for future need.
>
> I'd rather have more than one void user pointer, just in case. A couple of
> bytes won't be expensive, and they will save lots of hassle in the future if
> we need to add a couple of fields. I was just wondering why there was a
> reserved field between fd and mem_offset.
Quick comment from a random bystander: __u32 is not big enough for a void*
pointer from userspace ...
-Daniel
--
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48
Re: [PATCH] drm/i915: no-lvds quirk on MSI DC500
Hi again,
Could anyone have a look at this ?
On Tue, Mar 13, 2012 at 3:16 PM, Anisse Astier wrote:
>
> Any opinion on this quirk ?
>
> On Wed, Â 7 Mar 2012 18:36:35 +0100, Anisse Astier wrote
> :
>
> > This hardware doesn't have an LVDS, it's a desktop box. Fix incorrect
> > LVDS detection.
> >
> > Cc: sta...@kernel.org
> > Signed-off-by: Anisse Astier
> > ---
> > Â drivers/gpu/drm/i915/intel_lvds.c | Â Â 8
> > Â 1 files changed, 8 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_lvds.c
> > b/drivers/gpu/drm/i915/intel_lvds.c
> > index b103c3b..2dee11e 100644
> > --- a/drivers/gpu/drm/i915/intel_lvds.c
> > +++ b/drivers/gpu/drm/i915/intel_lvds.c
> > @@ -739,6 +739,14 @@ static const struct dmi_system_id intel_no_lvds[] =
> > {
> > Â Â Â Â Â Â Â Â Â Â Â DMI_MATCH(DMI_BOARD_NAME, "AT5NM10T-I"),
> > Â Â Â Â Â Â Â },
> > Â Â Â },
> > + Â Â {
> > + Â Â Â Â Â Â .callback = intel_no_lvds_dmi_callback,
> > + Â Â Â Â Â Â .ident = "MSI Wind Box DC500",
> > + Â Â Â Â Â Â .matches = {
> > + Â Â Â Â Â Â Â Â Â Â DMI_MATCH(DMI_BOARD_VENDOR, "MICRO-STAR
> > INTERNATIONAL CO., LTD"),
> > + Â Â Â Â Â Â Â Â Â Â DMI_MATCH(DMI_BOARD_NAME, "MS-7469"),
> > + Â Â Â Â Â Â },
> > + Â Â },
> >
> > Â Â Â { } Â Â /* terminating entry */
> > Â };
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Linaro-mm-sig] [RFCv2 PATCH 4/9] v4l: add buffer exporting via dmabuf
Hi Subash,
On Thursday 22 March 2012 19:27:01 Subash Patel wrote:
> On 03/22/2012 04:46 PM, Laurent Pinchart wrote:
> > On Tuesday 13 March 2012 11:17:02 Tomasz Stanislawski wrote:
[snip]
> >> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> >> index bb6844e..e71c787 100644
> >> --- a/include/linux/videodev2.h
> >> +++ b/include/linux/videodev2.h
> >> @@ -680,6 +680,25 @@ struct v4l2_buffer {
> >>
> >> #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE0x0800
> >> #define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000
> >>
> >> +/**
> >> + * struct v4l2_exportbuffer - export of video buffer as DMABUF file
> >> descriptor
> >> + *
> >> + * @fd: file descriptor associated with DMABUF (set by driver)
> >> + * @mem_offset: for non-multiplanar buffers with memory ==
> >> V4L2_MEMORY_MMAP;
> >
> > I don't think we will ever support exporting anything else than
> > V4L2_MEMORY_MMAP buffers. What will happen for multiplanar buffers ?
> >
> >> + *offset from the start of the device memory for this
> >> plane,
> >> + *(or a "cookie" that should be passed to mmap() as
> >> offset)
> >> + *
> >
> > Shouldn't the mem_offset field always be set to the mmap cookie value ?
> > I'm a bit confused by the "or" part, it seems to have been copied from
> > the v4l2_buffer documentation directly. We should clarify that.
> >
> >> + * Contains data used for exporting a video buffer as DMABUF file
> >> + * descriptor. Uses the same 'cookie' as mmap() syscall. All reserved
> >> fields
> >> + * must be set to zero.
> >> + */
> >> +struct v4l2_exportbuffer {
> >> + __u32 fd;
> >> + __u32 reserved0;
> >
> > Why is there a reserved field here ?
>
> +1 to Laurent. Any particular need for reserved0 and reserved[13] below?
> I think one void user pointer is sufficient even for future need.
I'd rather have more than one void user pointer, just in case. A couple of
bytes won't be expensive, and they will save lots of hassle in the future if
we need to add a couple of fields. I was just wondering why there was a
reserved field between fd and mem_offset.
> >> + __u32 mem_offset;
> >> + __u32 reserved[13];
> >> +};
> >> +
>
> Also, what is the reason for returning the fd through this structure? To
> keep it aligned with other v4l2 calls? I liked(or now hate making change
> in the app) how it was being returned through the ioctl in your last patch.
Probably to be consistent with the V4L2 API, yes. It won't make a big
difference for applications, I would favor consistency in this case.
--
Regards,
Laurent Pinchart
[git pull] drm nouveau destaging + Kelper modesetting support
Hi Linus, This pull request is unexpected and not something I had mentioned previously. so NVIDIA announced new Kepler GPUs this morning, and Ben has killed himself getting modesetting support for them together to have on launch day. Most of the code to support the new chips has already gone in, however this pull contains a few more pieces along with the final enables so the driver binds to the new Kepler cards. Its quite amazing that nouveau can support a GPU on its launch day even if its just unaccelerated modesetting, and I'd like to have support in the next kernel. In order to sweeten the deal, Ben has also requested nouveau destage and become ABI stable, the only change is the version number bump which he prepared userspace for quite a long time ago. The driver hasn't broken ABI since that one big break that caused a lot of fuss. It's also quite a small set of code, and not likely to break anything. Dave. The following changes since commit 5466c7b1683a23dbbcfb7ee4a71c4f23886001c7: drm/i915: use DDC_ADDR instead of hard-coding it (2012-03-21 10:20:38 +) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-nouveau-destage Ben Skeggs (14): drm/nouveau/ttm: always do buffer moves on kernel channel drm/nouveau: remove subchannel names from places where it doesn't matter drm/nouveau: move fence sequence check to start of loop drm/nvc0-/disp: reimplement flip completion method as fifo method drm/nouveau: remove m2mf creation on userspace channels drm/nouveau: inform userspace of new kernel subchannel requirements drm/nouveau: oops, increase channel dispc_vma to 4 drm/nvd0/disp: ignore clock set if no pclk drm/nouveau: bump version to 1.0.0 drm/nouveau: move out of staging drivers drm/nouveau: add bios connector type for dms59 drm/nve0: initial modesetting support for kepler chipsets drm/nve0/disp: nvidia randomly decided to move the dithering method drm/nouveau/dp: support version 4.0 of DP table Dave Airlie (1): Merge branch 'drm-nouveau-next' of git://git.freedesktop.org/git/nouveau/linux-2.6 into drm-next drivers/gpu/drm/Kconfig |2 + drivers/gpu/drm/nouveau/nouveau_bios.c |3 +- drivers/gpu/drm/nouveau/nouveau_bios.h |2 + drivers/gpu/drm/nouveau/nouveau_bo.c| 11 +-- drivers/gpu/drm/nouveau/nouveau_channel.c | 34 +++--- drivers/gpu/drm/nouveau/nouveau_connector.c | 13 +-- drivers/gpu/drm/nouveau/nouveau_display.c | 14 ++- drivers/gpu/drm/nouveau/nouveau_dma.c | 61 +--- drivers/gpu/drm/nouveau/nouveau_dma.h |4 +- drivers/gpu/drm/nouveau/nouveau_dp.c| 11 ++ drivers/gpu/drm/nouveau/nouveau_drv.h | 40 +--- drivers/gpu/drm/nouveau/nouveau_fence.c | 35 +++--- drivers/gpu/drm/nouveau/nouveau_gem.c | 10 +-- drivers/gpu/drm/nouveau/nouveau_state.c | 152 +++ drivers/gpu/drm/nouveau/nv50_display.c | 12 +- drivers/gpu/drm/nouveau/nvc0_fifo.c | 36 ++- drivers/gpu/drm/nouveau/nvc0_graph.c|9 -- drivers/gpu/drm/nouveau/nvd0_display.c | 23 - drivers/staging/Kconfig |2 - 19 files changed, 288 insertions(+), 186 deletions(-)
[git pull] drm - radeon southern islands / trinity support
Hi Linus, This applies after my drm-next pull request sent yesterday. It is support from AMD for their newest GPU and APUs. The products called RadeonHD 7xxx, and the Trinity APU series. This did come in a bit late, due to some over-complicated AMD internal review process, which from the outside seems unnecessary once the company has decided it wants to support open source. However as I said previously I'd rather not put the people who've got this hw for 3 months now being forced to use fglrx on it if there is open code. Its pretty well self contained and just plugs into the driver in various places. The following changes since commit da0df92b57311aa1b26a2a90599ed16e1e968b90: drm: allow loading an EDID as firmware to override broken monitor (2012-03-20 10:09:28 +) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-radeon-sitn-support Alex Deucher (46): drm/radeon/kms: Upstream ObjectID.h updates drm/radeon/kms: upstream atombios.h updates drm/radeon/kms: upstream power table updates drm/radeon/kms: add SI chip families drm/radeon/kms: add initial DCE6 display watermark support drm/radeon/kms: fix up atom HPD gpio parsing for DCE6 drm/radeon/kms/atom: DCE6 no longer has crtcmemreq bits drm/radeon/kms/atom: add support for crtc power gating drm/radeon/kms: DCE6 disp eng pll updates drm/radeon/kms/atom: add support for DCE6.x dig transmitters drm/radeon/kms: DP aux updates for DCE6 drm/radeon/kms: update comments about dig encoders/transmitters drm/radeon/kms/atom: add support for SI SetVoltage table drm/radeon/kms: update power table parsing for SI drm/radeon/kms: add support for internal thermal sensor on SI drm/radeon/kms: add gpu init support for SI drm/radeon/kms: Add support for SI GPU reset drm/radeon/kms: add support for MC/VM setup on SI drm/radeon/kms: add support for the CONST IB to the CS ioctl drm/radeon/kms: add VM CS checker for SI drm/radeon/kms: Only VM CS ioctl is supported on SI (v2) drm/radeon/kms: add ucode loading for SI drm/radeon/kms: add support for MC ucode loading on SI drm/radeon/kms: add support for CP setup on SI drm/radeon/kms: add IB and fence dispatch functions for SI drm/radeon/kms: Add support for RLC init on SI drm/radeon/kms: add support for interrupts on SI drm/radeon/kms: fill in startup/shutdown callbacks for SI drm/radeon/kms: add support for compute rings in CS ioctl on SI drm/radeon/kms: add radeon_asic struct for SI drm/radeon/kms: Add SI pci ids drm/radeon/kms: add trinity (TN) chip family drm/radeon/kms: no support for internal thermal sensor on TN yet drm/radeon/kms: DCE6.1 watermark updates for TN drm/radeon/kms: DCE6.1 disp eng pll updates drm/radeon/kms: Adjust pll picker for DCE6.1 drm/radeon/kms: disable PPLL0 on DCE6.1 when not in use drm/radeon/kms/DCE6.1: ss is not supported on the internal pplls drm/radeon/kms: Add checks for TN in the DP bridge code drm/radeon/kms: cayman gpu init updates for trinity drm/radeon/kms: Update evergreen functions for trinity drm/radeon/kms/vm: set vram base offset properly for TN drm/radeon/kms: add support for ucode loading on trinity (v2) drm/radeon/kms: add radeon_asic struct for trinity drm/radeon/kms: add trinity pci ids drm/radeon/kms: update duallink checks for DCE6 Michel D?nzer (1): drm/radeon: Update radeon_info_ioctl for SI. (v2) Tom Stellard (1): drm/radeon/kms: add info query for max pipes drivers/gpu/drm/radeon/Makefile |2 +- drivers/gpu/drm/radeon/ObjectID.h |5 + drivers/gpu/drm/radeon/atombios.h | 1109 +++- drivers/gpu/drm/radeon/atombios_crtc.c | 100 +- drivers/gpu/drm/radeon/atombios_dp.c|6 +- drivers/gpu/drm/radeon/atombios_encoders.c | 71 +- drivers/gpu/drm/radeon/evergreen.c | 25 +- drivers/gpu/drm/radeon/evergreen_blit_kms.c |2 +- drivers/gpu/drm/radeon/ni.c | 141 +- drivers/gpu/drm/radeon/nid.h|1 + drivers/gpu/drm/radeon/r600.c | 25 +- drivers/gpu/drm/radeon/r600d.h |4 + drivers/gpu/drm/radeon/radeon.h | 55 +- drivers/gpu/drm/radeon/radeon_asic.c| 208 ++ drivers/gpu/drm/radeon/radeon_asic.h| 25 + drivers/gpu/drm/radeon/radeon_atombios.c| 78 +- drivers/gpu/drm/radeon/radeon_connectors.c |2 +- drivers/gpu/drm/radeon/radeon_cs.c | 63 +- drivers/gpu/drm/radeon/radeon_device.c |6 +- drivers/gpu/drm/radeon/radeon_display.c |2 +- drivers/gpu/drm/radeon/radeon_drv.c |3 +- drivers/gpu/drm/radeon/radeon_encoders.c|6 +- drivers/gpu/drm/radeon/radeon_family.h |4 + drivers/gpu/drm/radeon/radeon_kms.c
[Linaro-mm-sig] [RFCv2 PATCH 2/9 - 4/4] v4l: vb2-dma-contig: update and code refactoring
Hi Laurent,
Thank you very much for your comments and question.
They were very useful.
Please refer to the comments below.
On 03/22/2012 11:50 AM, Laurent Pinchart wrote:
> Hi Tomasz,
>
> Thanks for the patch.
>
> On Thursday 22 March 2012 11:02:23 Laurent Pinchart wrote:
>> From: Tomasz Stanislawski
>>
>> This patch combines updates and fixes to dma-contig allocator.
>> Moreover the allocator code was refactored.
>> The most important changes are:
>> - functions were reordered
>> - move compression of scatterlist to separete function
>> - add support for multichunk but contiguous scatterlists
>> - simplified implementation of vb2-dma-contig context structure
>> - let mmap method to use dma_mmap_writecombine
>> - add support for scatterlist in userptr mode
>>
>> Signed-off-by: Marek Szyprowski
>> [mmap method]
>> Signed-off-by: Andrzej Pietrasiewicz
>> [scatterlist in userptr mode]
>> Signed-off-by: Kamil Debski
>> [bugfixing]
>> Signed-off-by: Tomasz Stanislawski
>> [core refactoring, helper functions]
>> Signed-off-by: Kyungmin Park
>> ---
>> drivers/media/video/videobuf2-dma-contig.c | 400
>> +--- 1 files changed, 365 insertions(+), 35
>> deletions(-)
>>
>> diff --git a/drivers/media/video/videobuf2-dma-contig.c
>> b/drivers/media/video/videobuf2-dma-contig.c index c898e6f..9965465 100644
>> --- a/drivers/media/video/videobuf2-dma-contig.c
>> +++ b/drivers/media/video/videobuf2-dma-contig.c
>> @@ -10,9 +10,12 @@
>> * the Free Software Foundation.
>> */
>>
>> +#include
>> +#include
>> #include
>> +#include
>> +#include
>> #include
>> -#include
>>
>> #include
>> #include
>> @@ -22,16 +25,115 @@ struct vb2_dc_buf {
>> void*vaddr;
>> unsigned long size;
>> dma_addr_t dma_addr;
>> +struct sg_table *dma_sgt;
>> +enum dma_data_direction dma_dir;
>>
>> /* MMAP related */
>> struct vb2_vmarea_handler handler;
>> atomic_trefcount;
>> +struct sg_table *sgt_base;
>>
>> /* USERPTR related */
>> struct vm_area_struct *vma;
>> };
>>
>> /*/
>> +/*scatterlist table functions*/
>> +/*/
>> +
>> +static struct sg_table *vb2_dc_pages_to_sgt(struct page **pages,
>> +unsigned long n_pages, size_t offset, size_t offset2)
>> +{
>> +struct sg_table *sgt;
>> +int i, j; /* loop counters */
>> +int cur_page, chunks;
>> +int ret;
>> +struct scatterlist *s;
>> +
>> +sgt = kzalloc(sizeof *sgt, GFP_KERNEL);
>> +if (!sgt)
>> +return ERR_PTR(-ENOMEM);
>> +
>> +/* compute number of chunks */
>> +chunks = 1;
>> +for (i = 1; i < n_pages; ++i)
>> +if (pages[i] != pages[i - 1] + 1)
>> +++chunks;
>> +
>> +ret = sg_alloc_table(sgt, chunks, GFP_KERNEL);
>> +if (ret) {
>> +kfree(sgt);
>> +return ERR_PTR(-ENOMEM);
>> +}
>> +
>> +/* merging chunks and putting them into the scatterlist */
>> +cur_page = 0;
>> +for_each_sg(sgt->sgl, s, sgt->orig_nents, i) {
>> +size_t size = PAGE_SIZE;
>> +
>> +for (j = cur_page + 1; j < n_pages; ++j) {
>> +if (pages[j] != pages[j - 1] + 1)
>> +break;
>> +size += PAGE_SIZE;
>> +}
>> +
>> +/* cut offset if chunk starts at the first page */
>> +if (cur_page == 0)
>> +size -= offset;
>> +/* cut offset2 if chunk ends at the last page */
>> +if (j == n_pages)
>> +size -= offset2;
>> +
>> +sg_set_page(s, pages[cur_page], size, offset);
>> +offset = 0;
>> +cur_page = j;
>> +}
>> +
>> +return sgt;
>> +}
>> +
>> +static void vb2_dc_release_sgtable(struct sg_table *sgt)
>> +{
>> +sg_free_table(sgt);
>> +kfree(sgt);
>> +}
>> +
>> +static void vb2_dc_put_sgtable(struct sg_table *sgt, int dirty)
>> +{
>> +struct scatterlist *s;
>> +int i, j;
>> +
>> +for_each_sg(sgt->sgl, s, sgt->nents, i) {
>> +struct page *page = sg_page(s);
>> +int n_pages = PAGE_ALIGN(s->offset + s->length) >> PAGE_SHIFT;
>> +
>> +for (j = 0; j < n_pages; ++j, ++page) {
>> +if (dirty)
>> +set_page_dirty_lock(page);
>> +put_page(page);
>> +}
>> +}
>> +
>> +vb2_dc_release_sgtable(sgt);
>> +}
>> +
>> +static unsigned long vb2_dc_get_contiguous_size(struct sg_table *sgt)
>> +{
>> +struct scatterlist *s;
>> +dma_addr_t expected = sg_dma_address(sgt->sgl);
>> +int i;
>> +unsigned long size = 0;
>> +
>> +for_each_sg(sgt->sgl, s, sgt->nents, i) {
>> +if (sg_dm
Re: [PATCH v2] drm/i915: Run DDC buses at 50 kbps
On Wed, Mar 21, 2012 at 02:29:47PM +0100, Jean Delvare wrote: > A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C > devices can typically operate faster than this, 50 kbps should be fine > for all devices (and compliant devices can always stretch the clock if > needed.) > > FWIW, the vast majority of framebuffer drivers set udelay to 10 > already. So set it to 10 in DRM drivers too, this will make EDID block > reads faster. We might even lower the udelay value later if no problem > is reported. > > Signed-off-by: Jean Delvare > Acked-by: Eugeni Dodonov > Cc: Dave Airlie > Cc: Keith Packard Fyi this already got merged int Dave's tree (the unsplit version) as: commit 1849ecb22fb3b5d57b65e7369a3957adf9f26f39 Author: Jean Delvare Date: Sat Jan 28 11:07:09 2012 +0100 drm/kms: Make i2c buses faster Cheers, Daniel > --- > Changes since v1: > * Split per driver to make merging easier. > * Make the subject line more accurate. > > drivers/gpu/drm/i915/intel_i2c.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- linux-3.4-rc0.orig/drivers/gpu/drm/i915/intel_i2c.c 2012-03-21 > 13:43:33.750915151 +0100 > +++ linux-3.4-rc0/drivers/gpu/drm/i915/intel_i2c.c2012-03-21 > 13:44:05.923915628 +0100 > @@ -37,7 +37,7 @@ > > /* Intel GPIO access functions */ > > -#define I2C_RISEFALL_TIME 20 > +#define I2C_RISEFALL_TIME 10 > > static inline struct intel_gmbus * > to_intel_gmbus(struct i2c_adapter *i2c) > > -- > Jean Delvare > Suse L3 > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
radeon + DVI->mDP converter + mDP display blank screen issue since 3.0
Hi!
Since Linux 3.0, a system with a Radeon HD 5450 (1002:68f9) connected
to a 27" Apple LED cinema display via an Atlona AT-DP400 Dual Link DVI
to Mini DisplayPort converter has started to stop giving screen
output on switching from text mode to graphical framebuffer during
system startup.
I finally had some time to look at this, and it seems to have stopped
working after this commit:
commit df271bec805b42527d864777ed035fcbb42e76c0
Author: Alex Deucher
Date: Fri May 20 04:34:15 2011 -0400
drm/radeon/kms: properly handle bpc >8 in atom command tables
Signed-off-by: Alex Deucher
Signed-off-by: Dave Airlie
...and with the patch below (i.e. reverting part of the commit above)
applied to 3.3 I get screen output again.
Even though the monitor seems to have an 8 bit panel, it reports 10
bits per channel in its EDID:
[...]
Manufacturer: APP Model 9226 Serial Number 41959462
Made week 38 of 2010
EDID version: 1.4
Digital display
10 bits per primary color channel
DisplayPort interface
Maximum image size: 60 cm x 34 cm
[...]
The (active, dual link) DVI->mDP converter spec sheet says it supports
24 bit color, and I'm guessing that it can't deal with 30. Is the
converter at fault here for passing through the EDID unchanged?
Also, what would be the right way to handle this, a kernel command
line or module option to limit color depth or something like that?
("Buy a video card with DP output." is a valid answer, I suppose.)
I have no clue at all about graphics, and I have no idea whatsoever
what I'm doing here, but I just wanted to post this somewhere for
Google to find in case someone else runs into this!
thanks,
Lennert
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 742f17f..77a6a04 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -513,11 +513,9 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
struct radeon_device *rdev = dev->dev_private;
struct drm_encoder *encoder = NULL;
struct radeon_encoder *radeon_encoder = NULL;
- struct drm_connector *connector = NULL;
u32 adjusted_clock = mode->clock;
int encoder_mode = 0;
u32 dp_clock = mode->clock;
- int bpc = 8;
bool is_duallink = false;
/* reset the pll flags */
@@ -549,13 +547,11 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
if (encoder->crtc == crtc) {
radeon_encoder = to_radeon_encoder(encoder);
- connector = radeon_get_connector_for_encoder(encoder);
- if (connector && connector->display_info.bpc)
- bpc = connector->display_info.bpc;
encoder_mode = atombios_get_encoder_mode(encoder);
is_duallink = radeon_dig_monitor_is_duallink(encoder,
mode->clock);
if ((radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT
| ATOM_DEVICE_DFP_SUPPORT)) ||
(radeon_encoder_get_dp_bridge_encoder_id(encoder)
!= ENCODER_OBJECT_ID_NONE)) {
+ struct drm_connector *connector =
radeon_get_connector_for_encoder(encoder);
if (connector) {
struct radeon_connector
*radeon_connector = to_radeon_connector(connector);
struct radeon_connector_atom_dig
*dig_connector =
@@ -645,7 +641,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
if (encoder_mode ==
ATOM_ENCODER_MODE_HDMI)
/* deep color support */
args.v3.sInput.usPixelClock =
-
cpu_to_le16((mode->clock * bpc / 8) / 10);
+ cpu_to_le16(mode->clock
/ 10);
if (dig->coherent_mode)
args.v3.sInput.ucDispPllConfig
|=
DISPPLL_CONFIG_COHERENT_MODE;
@@ -753,7 +749,6 @@ static void atombios_crtc_program_pll(struct drm_crtc *crtc,
u32 fb_div,
u32 frac_fb_div,
u32 post_div,
- int bpc,
bool ss_enabled,
struct radeon_atom_ss *ss)
{
@@ -817,15 +812,6 @@ static void atombios_crtc_program_pll(struct drm_crtc
*crtc,
args.v5.ucMiscInfo = 0; /* HDMI dept
[RFCv2 PATCH 7/9] v4l: vb2-dma-contig: change map/unmap behaviour
On Thu, Mar 22, 2012 at 13:15, Laurent Pinchart wrote: > On Tuesday 13 March 2012 11:17:05 Tomasz Stanislawski wrote: >> The DMABUF documentation says that the map_dma_buf callback should return >> scatterlist that is mapped into a caller's address space. In practice, >> almost none of existing implementations of DMABUF exporter does it. ?This >> patch breaks the DMABUF specification in order to allow exchange DMABUF >> buffers between other APIs like DRM. > > Then it's time to fix the spec, and squash 6/9 and 7/9 together (I started > reviewing 6/9 and the implementation puzzled me until I saw the "fixes" in > 7/9). Nope. The drm proof of concept stuff that just grabbed the struct pages pointers from the sg_table has always just been a gross hack to get things of the ground. With proper kernel cpu access and mmap support we can ditch these, and Dave Airlie has already started with that: http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-dmabuf2 Furthermore the kernel cpu access helpers are designed to just plug into the corresponding ttm helpers. It'll be slightly more messy for drm/i915 and udl because they don't use ttm. And the afaik the proof of concept stuff from Rob Clark very much depends upon handing out addresses in the targets device address space. And there are other scenarios that just require this, besides that it makes imo more sense from an api design pov. Yours, Daniel -- Daniel Vetter daniel.vetter at ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch
Re: [git pull] drm main pull for 3.4-rc1
On Wed, Mar 21, 2012 at 3:47 AM, Dave Airlie wrote: > > (oh and any warnings you see in i915 are gcc's fault from what anyone can > see). Christ those are annoying. Has anybody contacted the gcc people about this? Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm main pull for 3.4-rc1
On Wed, Mar 21, 2012 at 3:47 AM, Dave Airlie wrote: > > (oh and any warnings you see in i915 are gcc's fault from what anyone can > see). Christ those are annoying. Has anybody contacted the gcc people about this? Linus
[RFCv2 PATCH 7/9] v4l: vb2-dma-contig: change map/unmap behaviour
Hi Tomasz,
Thanks for the patch.
On Tuesday 13 March 2012 11:17:05 Tomasz Stanislawski wrote:
> The DMABUF documentation says that the map_dma_buf callback should return
> scatterlist that is mapped into a caller's address space. In practice,
> almost none of existing implementations of DMABUF exporter does it. This
> patch breaks the DMABUF specification in order to allow exchange DMABUF
> buffers between other APIs like DRM.
Then it's time to fix the spec, and squash 6/9 and 7/9 together (I started
reviewing 6/9 and the implementation puzzled me until I saw the "fixes" in
7/9).
We need to agree on a behaviour for the mapping API. I've thought from the
beginning that mapping the buffer to the importer's device address space
should be the responsibility of the importer, not the exporter. If we move to
that approach, we should probably rename the map and unmap functions as they
won't deal with mappings anymore. I recall that pin/unpin were proposed at
some point (possible during a meeting at the ELC).
One possible issue with handling mappings in the importer is that the exporter
won't be able to implement any mapping/unmapping hack that might be needed. As
the DMA SG API doesn't seem to support VM_PFNMAP memory (see the explanation
in my reply to 2/9), we will be left without a solution if an exporter uses
memory not backed with struct page.
> Signed-off-by: Tomasz Stanislawski
> Signed-off-by: Kyungmin Park
> ---
> drivers/media/video/videobuf2-dma-contig.c | 64
> 1 files changed, 27 insertions(+), 37
> deletions(-)
>
> diff --git a/drivers/media/video/videobuf2-dma-contig.c
> b/drivers/media/video/videobuf2-dma-contig.c index d95b23a..32bb16b 100644
> --- a/drivers/media/video/videobuf2-dma-contig.c
> +++ b/drivers/media/video/videobuf2-dma-contig.c
> @@ -315,11 +315,6 @@ static int vb2_dc_mmap(void *buf_priv, struct
> vm_area_struct *vma) /* DMABUF ops for exporters */
> /*/
>
> -struct vb2_dc_attachment {
> - struct sg_table sgt;
> - enum dma_data_direction dir;
> -};
> -
> static int vb2_dc_dmabuf_ops_attach(struct dma_buf *dbuf, struct device
> *dev, struct dma_buf_attachment *dbuf_attach)
> {
> @@ -330,17 +325,13 @@ static int vb2_dc_dmabuf_ops_attach(struct dma_buf
> *dbuf, struct device *dev, static void vb2_dc_dmabuf_ops_detach(struct
> dma_buf *dbuf,
> struct dma_buf_attachment *db_attach)
> {
> - struct vb2_dc_attachment *attach = db_attach->priv;
> - struct sg_table *sgt;
> + struct sg_table *sgt = db_attach->priv;
>
> - if (!attach)
> + if (!sgt)
> return;
>
> - sgt = &attach->sgt;
> -
> - dma_unmap_sg(db_attach->dev, sgt->sgl, sgt->nents, attach->dir);
> sg_free_table(sgt);
> - kfree(attach);
> + kfree(sgt);
> db_attach->priv = NULL;
> }
>
> @@ -349,26 +340,22 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
> {
> struct dma_buf *dbuf = db_attach->dmabuf;
> struct vb2_dc_buf *buf = dbuf->priv;
> - struct vb2_dc_attachment *attach = db_attach->priv;
> - struct sg_table *sgt;
> + struct sg_table *sgt = db_attach->priv;
> struct scatterlist *rd, *wr;
> int i, ret;
>
> /* return previously mapped sg table */
> - if (attach)
> - return &attach->sgt;
> + if (sgt)
> + return sgt;
>
> - attach = kzalloc(sizeof *attach, GFP_KERNEL);
> - if (!attach)
> + sgt = kzalloc(sizeof *sgt, GFP_KERNEL);
> + if (!sgt)
> return ERR_PTR(-ENOMEM);
>
> - sgt = &attach->sgt;
> - attach->dir = dir;
> -
> /* copying the buf->base_sgt to attachment */
> ret = sg_alloc_table(sgt, buf->sgt_base->orig_nents, GFP_KERNEL);
> if (ret) {
> - kfree(attach);
> + kfree(sgt);
> return ERR_PTR(-ENOMEM);
> }
>
> @@ -380,16 +367,7 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
> wr = sg_next(wr);
> }
>
> - /* mapping new sglist to the client */
> - ret = dma_map_sg(db_attach->dev, sgt->sgl, sgt->orig_nents, dir);
> - if (ret <= 0) {
> - printk(KERN_ERR "failed to map scatterlist\n");
> - sg_free_table(sgt);
> - kfree(attach);
> - return ERR_PTR(-EIO);
> - }
> -
> - db_attach->priv = attach;
> + db_attach->priv = sgt;
>
> return sgt;
> }
> @@ -623,7 +601,7 @@ static int vb2_dc_map_dmabuf(void *mem_priv)
> struct vb2_dc_buf *buf = mem_priv;
> struct sg_table *sgt;
> unsigned long contig_size;
> - int ret = 0;
> + int ret = -EFAULT;
>
> if (WARN_ON(!buf->db_attach)) {
> printk(KERN_ERR "trying to pin a non attached buffer\n");
> @@ -642,12 +620,20 @@ static int vb2_dc_map_dmabuf(void *mem_priv)
> return -EINVAL;
> }
>
> + /* mapping new sglist to the client */
> + sgt->nents = dma_map_sg(b
[RFCv2 PATCH 5/9] v4l: vb2: add buffer exporting via dmabuf
Hi Tomasz,
Thanks for the patch.
On Tuesday 13 March 2012 11:17:03 Tomasz Stanislawski wrote:
> This patch adds extension to videobuf2-core. It allow to export a mmap
> buffer as a file descriptor.
>
> Signed-off-by: Tomasz Stanislawski
> Signed-off-by: Kyungmin Park
> ---
> drivers/media/video/videobuf2-core.c | 64
> ++ include/media/videobuf2-core.h |
> 2 +
> 2 files changed, 66 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/video/videobuf2-core.c
> b/drivers/media/video/videobuf2-core.c index e7df560..41c4bf8 100644
> --- a/drivers/media/video/videobuf2-core.c
> +++ b/drivers/media/video/videobuf2-core.c
> @@ -1553,6 +1553,70 @@ int vb2_dqbuf(struct vb2_queue *q, struct v4l2_buffer
> *b, bool nonblocking) }
> EXPORT_SYMBOL_GPL(vb2_dqbuf);
>
> +static int __find_plane_by_offset(struct vb2_queue *q, unsigned long off,
> + unsigned int *_buffer, unsigned int *_plane);
> +
Could you please move __find_plane_by_offset() up or move vb2_expbuf() down to
avoid the forward declaration ? The later might make more sense, you could
declare vb2_expbuf() right after vb2_mmap() (here and in videobuf2-core.h),
both functions perform similar tasks.
> +/**
> + * vb2_expbuf() - Export a buffer as a file descriptor
> + * @q: videobuf2 queue
> + * @b: export buffer structure passed from userspace to
> vidioc_expbuf
> + * handler in driver
> + *
> + * The return values from this function are intended to be directly
> returned
> + * from vidioc_expbuf handler in driver.
> + */
> +int vb2_expbuf(struct vb2_queue *q, struct v4l2_exportbuffer *eb)
> +{
> + struct vb2_buffer *vb = NULL;
> + struct vb2_plane *vb_plane;
> + unsigned int buffer, plane;
> + int ret;
> + struct dma_buf *dbuf;
> +
> + if (q->memory != V4L2_MEMORY_MMAP) {
> + dprintk(1, "Queue is not currently set up for mmap\n");
> + return -EINVAL;
> + }
> +
> + if (!q->mem_ops->get_dmabuf) {
> + dprintk(1, "Queue does not support DMA buffer exporting\n");
> + return -EINVAL;
> + }
> +
> + /*
> + * Find the plane corresponding to the offset passed by userspace.
> + */
> + ret = __find_plane_by_offset(q, eb->mem_offset, &buffer, &plane);
> + if (ret) {
> + dprintk(1, "invalid offset %u\n", eb->mem_offset);
> + return ret;
> + }
> +
> + vb = q->bufs[buffer];
> + vb_plane = &vb->planes[plane];
> +
> + dbuf = call_memop(q, get_dmabuf, vb_plane->mem_priv);
> + if (IS_ERR_OR_NULL(dbuf)) {
> + dprintk(1, "Failed to export buffer %d, plane %d\n",
> + buffer, plane);
> + return -EINVAL;
> + }
> +
> + ret = dma_buf_fd(dbuf);
> + if (ret < 0) {
> + dprintk(3, "buffer %d, plane %d failed to export (%d)\n",
> + buffer, plane, ret);
> + return ret;
> + }
> +
> + dprintk(3, "buffer %d, plane %d exported as %d descriptor\n",
> + buffer, plane, ret);
> + eb->fd = ret;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(vb2_expbuf);
> +
> /**
> * __vb2_queue_cancel() - cancel and stop (pause) streaming
> *
> diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
> index 412c6a4..548252b 100644
> --- a/include/media/videobuf2-core.h
> +++ b/include/media/videobuf2-core.h
> @@ -79,6 +79,7 @@ struct vb2_mem_ops {
> void(*prepare)(void *buf_priv);
> void(*finish)(void *buf_priv);
> void(*put)(void *buf_priv);
> + struct dma_buf *(*get_dmabuf)(void *buf_priv);
>
> void*(*get_userptr)(void *alloc_ctx, unsigned long vaddr,
> unsigned long size, int write);
> @@ -348,6 +349,7 @@ int vb2_queue_init(struct vb2_queue *q);
> void vb2_queue_release(struct vb2_queue *q);
>
> int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b);
> +int vb2_expbuf(struct vb2_queue *q, struct v4l2_exportbuffer *eb);
> int vb2_dqbuf(struct vb2_queue *q, struct v4l2_buffer *b, bool
> nonblocking);
>
> int vb2_streamon(struct vb2_queue *q, enum v4l2_buf_type type);
--
Regards,
Laurent Pinchart
[RFCv2 PATCH 4/9] v4l: add buffer exporting via dmabuf
Hi Tomasz,
Thanks for the patch.
On Tuesday 13 March 2012 11:17:02 Tomasz Stanislawski wrote:
> This patch adds extension to V4L2 api. It allow to export a mmap buffer as
> file descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset
> used by mmap and return a file descriptor on success.
I know code is more fun to write than documentation, but
Documentation/DocBook/media/v4l will be sad if this patch is merged as-is ;-)
> Signed-off-by: Tomasz Stanislawski
> Signed-off-by: Kyungmin Park
> ---
> drivers/media/video/v4l2-compat-ioctl32.c |1 +
> drivers/media/video/v4l2-ioctl.c | 11 +++
> include/linux/videodev2.h | 20
> include/media/v4l2-ioctl.h|2 ++
> 4 files changed, 34 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
> b/drivers/media/video/v4l2-compat-ioctl32.c index e6f67aa..fd157cb 100644
> --- a/drivers/media/video/v4l2-compat-ioctl32.c
> +++ b/drivers/media/video/v4l2-compat-ioctl32.c
> @@ -954,6 +954,7 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int
> cmd, unsigned long arg) case VIDIOC_S_FBUF32:
> case VIDIOC_OVERLAY32:
> case VIDIOC_QBUF32:
> + case VIDIOC_EXPBUF:
> case VIDIOC_DQBUF32:
> case VIDIOC_STREAMON32:
> case VIDIOC_STREAMOFF32:
> diff --git a/drivers/media/video/v4l2-ioctl.c
> b/drivers/media/video/v4l2-ioctl.c index 74cab51..a125016 100644
> --- a/drivers/media/video/v4l2-ioctl.c
> +++ b/drivers/media/video/v4l2-ioctl.c
> @@ -207,6 +207,7 @@ static const char *v4l2_ioctls[] = {
> [_IOC_NR(VIDIOC_S_FBUF)] = "VIDIOC_S_FBUF",
> [_IOC_NR(VIDIOC_OVERLAY)] = "VIDIOC_OVERLAY",
> [_IOC_NR(VIDIOC_QBUF)] = "VIDIOC_QBUF",
> + [_IOC_NR(VIDIOC_EXPBUF)] = "VIDIOC_EXPBUF",
> [_IOC_NR(VIDIOC_DQBUF)]= "VIDIOC_DQBUF",
> [_IOC_NR(VIDIOC_STREAMON)] = "VIDIOC_STREAMON",
> [_IOC_NR(VIDIOC_STREAMOFF)]= "VIDIOC_STREAMOFF",
> @@ -938,6 +939,16 @@ static long __video_do_ioctl(struct file *file,
> dbgbuf(cmd, vfd, p);
> break;
> }
> + case VIDIOC_EXPBUF:
> + {
> + struct v4l2_exportbuffer *p = arg;
> +
> + if (!ops->vidioc_expbuf)
> + break;
> +
> + ret = ops->vidioc_expbuf(file, fh, p);
You can pass arg to ops->vidioc_expbuf() directly, there's no need to create a
struct v4l2_exportbuffer *p variable.
> + break;
> + }
> case VIDIOC_DQBUF:
> {
> struct v4l2_buffer *p = arg;
> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> index bb6844e..e71c787 100644
> --- a/include/linux/videodev2.h
> +++ b/include/linux/videodev2.h
> @@ -680,6 +680,25 @@ struct v4l2_buffer {
> #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE0x0800
> #define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000
>
> +/**
> + * struct v4l2_exportbuffer - export of video buffer as DMABUF file
> descriptor
> + *
> + * @fd: file descriptor associated with DMABUF (set by driver)
> + * @mem_offset: for non-multiplanar buffers with memory ==
> V4L2_MEMORY_MMAP;
I don't think we will ever support exporting anything else than
V4L2_MEMORY_MMAP buffers. What will happen for multiplanar buffers ?
> + * offset from the start of the device memory for this plane,
> + * (or a "cookie" that should be passed to mmap() as offset)
> + *
Shouldn't the mem_offset field always be set to the mmap cookie value ? I'm a
bit confused by the "or" part, it seems to have been copied from the
v4l2_buffer documentation directly. We should clarify that.
> + * Contains data used for exporting a video buffer as DMABUF file
> + * descriptor. Uses the same 'cookie' as mmap() syscall. All reserved
> fields
> + * must be set to zero.
> + */
> +struct v4l2_exportbuffer {
> + __u32 fd;
> + __u32 reserved0;
Why is there a reserved field here ?
> + __u32 mem_offset;
> + __u32 reserved[13];
> +};
> +
> /*
> * O V E R L A Y P R E V I E W
> */
> @@ -2303,6 +2322,7 @@ struct v4l2_create_buffers {
> #define VIDIOC_S_FBUF _IOW('V', 11, struct v4l2_framebuffer)
> #define VIDIOC_OVERLAY_IOW('V', 14, int)
> #define VIDIOC_QBUF _IOWR('V', 15, struct v4l2_buffer)
> +#define VIDIOC_EXPBUF_IOWR('V', 16, struct v4l2_exportbuffer)
> #define VIDIOC_DQBUF _IOWR('V', 17, struct v4l2_buffer)
> #define VIDIOC_STREAMON _IOW('V', 18, int)
> #define VIDIOC_STREAMOFF _IOW('V', 19, int)
> diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
> index 4df031a..d8716c6f 100644
> --- a/include/media/v4l2-ioctl.h
> +++ b/include/media/v4l2-ioctl.h
> @@ -120,6 +120,8 @@ struct v4l2_ioctl_ops {
> int (*vidioc_reqbufs) (struct file *file, v
[RFCv2 PATCH 3/9] v4l: vb2: Add dma-contig allocator as dma_buf user
Hi Tomasz,
On Tuesday 13 March 2012 11:17:01 Tomasz Stanislawski wrote:
> From: Sumit Semwal
>
> This patch makes changes for adding dma-contig as a dma_buf user. It
> provides function implementations for the {attach, detach, map,
> unmap}_dmabuf() mem_ops of DMABUF memory type.
>
> Signed-off-by: Sumit Semwal
> Signed-off-by: Sumit Semwal
> [author of the original patch]
> Signed-off-by: Tomasz Stanislawski
> [integration with refactored dma-contig allocator]
> ---
> drivers/media/video/videobuf2-dma-contig.c | 116
> 1 files changed, 116 insertions(+), 0
> deletions(-)
>
> diff --git a/drivers/media/video/videobuf2-dma-contig.c
> b/drivers/media/video/videobuf2-dma-contig.c index c1dc043..746dd5f 100644
> --- a/drivers/media/video/videobuf2-dma-contig.c
> +++ b/drivers/media/video/videobuf2-dma-contig.c
> @@ -35,6 +35,9 @@ struct vb2_dc_buf {
>
> /* USERPTR related */
> struct vm_area_struct *vma;
> +
> + /* DMABUF related */
> + struct dma_buf_attachment *db_attach;
> };
>
> /*/
> @@ -485,6 +488,115 @@ fail_buf:
> }
>
> /*/
> +/* callbacks for DMABUF buffers*/
> +/*/
> +
> +static int vb2_dc_map_dmabuf(void *mem_priv)
> +{
> + struct vb2_dc_buf *buf = mem_priv;
> + struct sg_table *sgt;
> + unsigned long contig_size;
> + int ret = 0;
> +
> + if (WARN_ON(!buf->db_attach)) {
> + printk(KERN_ERR "trying to pin a non attached buffer\n");
> + return -EINVAL;
> + }
> +
> + if (WARN_ON(buf->dma_sgt)) {
> + printk(KERN_ERR "dmabuf buffer is already pinned\n");
> + return 0;
> + }
> +
> + /* get the associated scatterlist for this buffer */
> + sgt = dma_buf_map_attachment(buf->db_attach, buf->dma_dir);
> + if (IS_ERR_OR_NULL(sgt)) {
> + printk(KERN_ERR "Error getting dmabuf scatterlist\n");
> + return -EINVAL;
> + }
I've checked why dma_map_sg() was missing from here, and then remembered that
the exporter is still responsible for mapping the buffer to the importer's
device address space :-) I'll raise that topic separately.
> +
> + /* checking if dmabuf is big enough to store contiguous chunk */
> + contig_size = vb2_dc_get_contiguous_size(sgt);
> + if (contig_size < buf->size) {
> + printk(KERN_ERR "contiguous chunk of dmabuf is too small\n");
> + ret = -EFAULT;
> + goto fail_map;
> + }
> +
> + buf->dma_addr = sg_dma_address(sgt->sgl);
> + buf->dma_sgt = sgt;
> +
> + return 0;
> +
> +fail_map:
> + dma_buf_unmap_attachment(buf->db_attach, sgt);
> +
> + return ret;
> +}
> +
> +static void vb2_dc_unmap_dmabuf(void *mem_priv)
> +{
> + struct vb2_dc_buf *buf = mem_priv;
> + struct sg_table *sgt = buf->dma_sgt;
> +
> + if (WARN_ON(!buf->db_attach)) {
> + printk(KERN_ERR "trying to unpin a not attached buffer\n");
> + return;
> + }
> +
> + if (WARN_ON(!sgt)) {
> + printk(KERN_ERR "dmabuf buffer is already unpinned\n");
> + return;
> + }
> +
> + dma_buf_unmap_attachment(buf->db_attach, sgt);
> +
> + buf->dma_addr = 0;
> + buf->dma_sgt = NULL;
> +}
> +
> +static void vb2_dc_detach_dmabuf(void *mem_priv)
> +{
> + struct vb2_dc_buf *buf = mem_priv;
> +
> + if (buf->dma_addr)
> + vb2_dc_unmap_dmabuf(buf);
Can detach() be called with the buffer still mapped() ? Wouldn't that be a bug
in the caller ?
> +
> + /* detach this attachment */
> + dma_buf_detach(buf->db_attach->dmabuf, buf->db_attach);
> + kfree(buf);
> +}
There's nothing allocator-specific in the attach/detach operations. Shouldn't
they be moved to the vb2 core ?
> +
> +static void *vb2_dc_attach_dmabuf(void *alloc_ctx, struct dma_buf *dbuf,
> + unsigned long size, int write)
> +{
> + struct vb2_dc_buf *buf;
> + struct dma_buf_attachment *dba;
> +
> + if (dbuf->size < size)
> + return ERR_PTR(-EFAULT);
> +
> + buf = kzalloc(sizeof *buf, GFP_KERNEL);
> + if (!buf)
> + return ERR_PTR(-ENOMEM);
> +
> + buf->dev = alloc_ctx;
> + /* create attachment for the dmabuf with the user device */
> + dba = dma_buf_attach(dbuf, buf->dev);
> + if (IS_ERR(dba)) {
> + printk(KERN_ERR "failed to attach dmabuf\n");
> + kfree(buf);
> + return dba;
> + }
> +
> + buf->dma_dir = write ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
> + buf->size = size;
> + buf->db_attach = dba;
> +
> + return buf;
> +}
> +
> +/*/
> /* DMA CONTIG exported functions */
> /*/
>
> @@ -498,6 +610,10 @@ const struct vb2_mem_ops vb2_dma_contig_memops = {
[Linaro-mm-sig] [RFCv2 PATCH 2/9 - 4/4] v4l: vb2-dma-contig: update and code refactoring
Hi Tomasz,
Thanks for the patch.
On Thursday 22 March 2012 11:02:23 Laurent Pinchart wrote:
> From: Tomasz Stanislawski
>
> This patch combines updates and fixes to dma-contig allocator.
> Moreover the allocator code was refactored.
> The most important changes are:
> - functions were reordered
> - move compression of scatterlist to separete function
> - add support for multichunk but contiguous scatterlists
> - simplified implementation of vb2-dma-contig context structure
> - let mmap method to use dma_mmap_writecombine
> - add support for scatterlist in userptr mode
>
> Signed-off-by: Marek Szyprowski
> [mmap method]
> Signed-off-by: Andrzej Pietrasiewicz
> [scatterlist in userptr mode]
> Signed-off-by: Kamil Debski
> [bugfixing]
> Signed-off-by: Tomasz Stanislawski
> [core refactoring, helper functions]
> Signed-off-by: Kyungmin Park
> ---
> drivers/media/video/videobuf2-dma-contig.c | 400
> +--- 1 files changed, 365 insertions(+), 35
> deletions(-)
>
> diff --git a/drivers/media/video/videobuf2-dma-contig.c
> b/drivers/media/video/videobuf2-dma-contig.c index c898e6f..9965465 100644
> --- a/drivers/media/video/videobuf2-dma-contig.c
> +++ b/drivers/media/video/videobuf2-dma-contig.c
> @@ -10,9 +10,12 @@
> * the Free Software Foundation.
> */
>
> +#include
> +#include
> #include
> +#include
> +#include
> #include
> -#include
>
> #include
> #include
> @@ -22,16 +25,115 @@ struct vb2_dc_buf {
> void*vaddr;
> unsigned long size;
> dma_addr_t dma_addr;
> + struct sg_table *dma_sgt;
> + enum dma_data_direction dma_dir;
>
> /* MMAP related */
> struct vb2_vmarea_handler handler;
> atomic_trefcount;
> + struct sg_table *sgt_base;
>
> /* USERPTR related */
> struct vm_area_struct *vma;
> };
>
> /*/
> +/*scatterlist table functions*/
> +/*/
> +
> +static struct sg_table *vb2_dc_pages_to_sgt(struct page **pages,
> + unsigned long n_pages, size_t offset, size_t offset2)
> +{
> + struct sg_table *sgt;
> + int i, j; /* loop counters */
> + int cur_page, chunks;
> + int ret;
> + struct scatterlist *s;
> +
> + sgt = kzalloc(sizeof *sgt, GFP_KERNEL);
> + if (!sgt)
> + return ERR_PTR(-ENOMEM);
> +
> + /* compute number of chunks */
> + chunks = 1;
> + for (i = 1; i < n_pages; ++i)
> + if (pages[i] != pages[i - 1] + 1)
> + ++chunks;
> +
> + ret = sg_alloc_table(sgt, chunks, GFP_KERNEL);
> + if (ret) {
> + kfree(sgt);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + /* merging chunks and putting them into the scatterlist */
> + cur_page = 0;
> + for_each_sg(sgt->sgl, s, sgt->orig_nents, i) {
> + size_t size = PAGE_SIZE;
> +
> + for (j = cur_page + 1; j < n_pages; ++j) {
> + if (pages[j] != pages[j - 1] + 1)
> + break;
> + size += PAGE_SIZE;
> + }
> +
> + /* cut offset if chunk starts at the first page */
> + if (cur_page == 0)
> + size -= offset;
> + /* cut offset2 if chunk ends at the last page */
> + if (j == n_pages)
> + size -= offset2;
> +
> + sg_set_page(s, pages[cur_page], size, offset);
> + offset = 0;
> + cur_page = j;
> + }
> +
> + return sgt;
> +}
> +
> +static void vb2_dc_release_sgtable(struct sg_table *sgt)
> +{
> + sg_free_table(sgt);
> + kfree(sgt);
> +}
> +
> +static void vb2_dc_put_sgtable(struct sg_table *sgt, int dirty)
> +{
> + struct scatterlist *s;
> + int i, j;
> +
> + for_each_sg(sgt->sgl, s, sgt->nents, i) {
> + struct page *page = sg_page(s);
> + int n_pages = PAGE_ALIGN(s->offset + s->length) >> PAGE_SHIFT;
> +
> + for (j = 0; j < n_pages; ++j, ++page) {
> + if (dirty)
> + set_page_dirty_lock(page);
> + put_page(page);
> + }
> + }
> +
> + vb2_dc_release_sgtable(sgt);
> +}
> +
> +static unsigned long vb2_dc_get_contiguous_size(struct sg_table *sgt)
> +{
> + struct scatterlist *s;
> + dma_addr_t expected = sg_dma_address(sgt->sgl);
> + int i;
> + unsigned long size = 0;
> +
> + for_each_sg(sgt->sgl, s, sgt->nents, i) {
> + if (sg_dma_address(s) != expected)
> + break;
> + expected = sg_dma_address(s) + sg_dma_len(s);
> + size += sg_dma_len(s);
> + }
> + return size;
> +}
> +
> +/*/
[PATCH] dma-buf: document fd flags and O_CLOEXEC requirement
On 20 March 2012 03:12, Rob Clark wrote: > From: Rob Clark > > Otherwise subsystems will get this wrong and end up with a second > export ioctl with the flag and O_CLOEXEC support added. > > Signed-off-by: Rob Clark > Reviewed-by: Daniel Vetter > --- > Updated version of Daniel's original documentation patch with (hopefully) > improved wording, and a better description of the motivation. Thanks; applied this in place of Daniel's to for-next. > BR, ~Sumit.
[Linaro-mm-sig] [PATCH 3/4] dma_buf: Add documentation for the new cpu access support
On 19 March 2012 07:24, Rob Clark wrote: > On Sun, Mar 18, 2012 at 6:34 PM, Daniel Vetter > wrote: >> v2: Fix spelling issues noticed by Rob Clark. >> >> Signed-off-by: Daniel Vetter > > Signed-off-by: Rob Clark Thanks; applied to for-next. > BR, ~me.
[Bug 47708] LVDS panel does not turns off in stand-by mode
https://bugs.freedesktop.org/show_bug.cgi?id=47708 --- Comment #1 from Eugene Shalygin 2012-03-22 04:34:17 PDT --- Created attachment 58859 --> https://bugs.freedesktop.org/attachment.cgi?id=58859 Xorg log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Linaro-mm-sig] [PATCH] dma-buf: add support for kernel cpu access
On 20 March 2012 04:32, Daniel Vetter wrote: > Big differences to other contenders in the field (like ion) is > that this also supports highmem, so we have to split up the cpu > access from the kernel side into a prepare and a kmap step. > > Prepare is allowed to fail and should do everything required so that > the kmap calls can succeed (like swapin/backing storage allocation, > flushing, ...). > > More in-depth explanations will follow in the follow-up documentation > patch. > > Changes in v2: > > - Clear up begin_cpu_access confusion noticed by Sumit Semwal. > - Don't automatically fallback from the _atomic variants to the > ?non-atomic variants. The _atomic callbacks are not allowed to > ?sleep, so we want exporters to make this decision explicit. The > ?function signatures are explicit, so simpler exporters can still > ?use the same function for both. > - Make the unmap functions optional. Simpler exporters with permanent > ?mappings don't need to do anything at unmap time. > > Changes in v3: > > - Adjust the WARN_ON checks for the new ->ops functions as suggested > ?by Rob Clark and Sumit Semwal. > - Rebased on top of latest dma-buf-next git. > > Changes in v4: > > - Fixup a missing - in a return -EINVAL; statement. > > Signed-Off-by: Daniel Vetter Thanks; applied to for-next. > --- BR, ~Sumit.
[Bug 47708] New: LVDS panel does not turns off in stand-by mode
https://bugs.freedesktop.org/show_bug.cgi?id=47708 Bug #: 47708 Summary: LVDS panel does not turns off in stand-by mode Classification: Unclassified Product: DRI Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: eugene.shalygin at gmail.com Created attachment 58858 --> https://bugs.freedesktop.org/attachment.cgi?id=58858 dmesg When video goes into sleep mode, LVDS panel starts to show screens filled with b/w gradients and RGB colours in a cycle. In the same time a screen, connected via Display-Port goes into sleep mode correctly. This happens with and without X running. Ati drivers do not show such a behaviour. Hardware: Acer Aspire 8942g with Mobility Radeon HD 5850. Linux version 3.3 (but this happens starting with version 2.6.2x of 2.6.3x when I've tried KMS for the first time). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Linaro-mm-sig] [PATCH 1/4] dma-buf: don't hold the mutex around map/unmap calls
On 19 March 2012 05:04, Daniel Vetter wrote: > The mutex protects the attachment list and hence needs to be held > around the callbakc to the exporters (optional) attach/detach > functions. > > Holding the mutex around the map/unmap calls doesn't protect any > dma_buf state. Exporters need to properly protect any of their own > state anyway (to protect against calls from their own interfaces). > So this only makes the locking messier (and lockdep easier to anger). > > Therefore let's just drop this. > > v2: Rebased on top of latest dma-buf-next git. > > Signed-off-by: Daniel Vetter > Reviewed-by: Rob Clark Thanks; Applied to for-next. > --- BR, ~Sumit.
[RFCv2 PATCH 2/9 - 4/4] v4l: vb2-dma-contig: update and code refactoring
From: Tomasz Stanislawski
This patch combines updates and fixes to dma-contig allocator.
Moreover the allocator code was refactored.
The most important changes are:
- functions were reordered
- move compression of scatterlist to separete function
- add support for multichunk but contiguous scatterlists
- simplified implementation of vb2-dma-contig context structure
- let mmap method to use dma_mmap_writecombine
- add support for scatterlist in userptr mode
Signed-off-by: Marek Szyprowski
[mmap method]
Signed-off-by: Andrzej Pietrasiewicz
[scatterlist in userptr mode]
Signed-off-by: Kamil Debski
[bugfixing]
Signed-off-by: Tomasz Stanislawski
[core refactoring, helper functions]
Signed-off-by: Kyungmin Park
---
drivers/media/video/videobuf2-dma-contig.c | 400 +---
1 files changed, 365 insertions(+), 35 deletions(-)
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c
index c898e6f..9965465 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -10,9 +10,12 @@
* the Free Software Foundation.
*/
+#include
+#include
#include
+#include
+#include
#include
-#include
#include
#include
@@ -22,16 +25,115 @@ struct vb2_dc_buf {
void*vaddr;
unsigned long size;
dma_addr_t dma_addr;
+ struct sg_table *dma_sgt;
+ enum dma_data_direction dma_dir;
/* MMAP related */
struct vb2_vmarea_handler handler;
atomic_trefcount;
+ struct sg_table *sgt_base;
/* USERPTR related */
struct vm_area_struct *vma;
};
/*/
+/*scatterlist table functions*/
+/*/
+
+static struct sg_table *vb2_dc_pages_to_sgt(struct page **pages,
+ unsigned long n_pages, size_t offset, size_t offset2)
+{
+ struct sg_table *sgt;
+ int i, j; /* loop counters */
+ int cur_page, chunks;
+ int ret;
+ struct scatterlist *s;
+
+ sgt = kzalloc(sizeof *sgt, GFP_KERNEL);
+ if (!sgt)
+ return ERR_PTR(-ENOMEM);
+
+ /* compute number of chunks */
+ chunks = 1;
+ for (i = 1; i < n_pages; ++i)
+ if (pages[i] != pages[i - 1] + 1)
+ ++chunks;
+
+ ret = sg_alloc_table(sgt, chunks, GFP_KERNEL);
+ if (ret) {
+ kfree(sgt);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ /* merging chunks and putting them into the scatterlist */
+ cur_page = 0;
+ for_each_sg(sgt->sgl, s, sgt->orig_nents, i) {
+ size_t size = PAGE_SIZE;
+
+ for (j = cur_page + 1; j < n_pages; ++j) {
+ if (pages[j] != pages[j - 1] + 1)
+ break;
+ size += PAGE_SIZE;
+ }
+
+ /* cut offset if chunk starts at the first page */
+ if (cur_page == 0)
+ size -= offset;
+ /* cut offset2 if chunk ends at the last page */
+ if (j == n_pages)
+ size -= offset2;
+
+ sg_set_page(s, pages[cur_page], size, offset);
+ offset = 0;
+ cur_page = j;
+ }
+
+ return sgt;
+}
+
+static void vb2_dc_release_sgtable(struct sg_table *sgt)
+{
+ sg_free_table(sgt);
+ kfree(sgt);
+}
+
+static void vb2_dc_put_sgtable(struct sg_table *sgt, int dirty)
+{
+ struct scatterlist *s;
+ int i, j;
+
+ for_each_sg(sgt->sgl, s, sgt->nents, i) {
+ struct page *page = sg_page(s);
+ int n_pages = PAGE_ALIGN(s->offset + s->length) >> PAGE_SHIFT;
+
+ for (j = 0; j < n_pages; ++j, ++page) {
+ if (dirty)
+ set_page_dirty_lock(page);
+ put_page(page);
+ }
+ }
+
+ vb2_dc_release_sgtable(sgt);
+}
+
+static unsigned long vb2_dc_get_contiguous_size(struct sg_table *sgt)
+{
+ struct scatterlist *s;
+ dma_addr_t expected = sg_dma_address(sgt->sgl);
+ int i;
+ unsigned long size = 0;
+
+ for_each_sg(sgt->sgl, s, sgt->nents, i) {
+ if (sg_dma_address(s) != expected)
+ break;
+ expected = sg_dma_address(s) + sg_dma_len(s);
+ size += sg_dma_len(s);
+ }
+ return size;
+}
+
+/*/
/* callbacks for all buffers */
/*/
@@ -45,8 +147,6 @@ static void *vb2_dc_cookie(void *buf_priv)
static void *vb2_dc_vaddr(void *buf_priv)
{
struct vb2_dc_buf *buf = buf_priv
[RFCv2 PATCH 2/9 - 3/4] v4l: vb2-dma-contig: Remove unneeded allocation context structure
vb2-dma-contig returns a vb2_dc_conf structure instance as the vb2
allocation context. That structure only stores a pointer to the physical
device. Remove it and use the device pointer directly as the allocation
context.
Signed-off-by: Laurent Pinchart
---
drivers/media/video/videobuf2-dma-contig.c | 29 ++-
1 files changed, 7 insertions(+), 22 deletions(-)
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c
index 6bc4651..c898e6f 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -17,12 +17,8 @@
#include
#include
-struct vb2_dc_conf {
- struct device *dev;
-};
-
struct vb2_dc_buf {
- struct vb2_dc_conf *conf;
+ struct device *dev;
void*vaddr;
unsigned long size;
dma_addr_t dma_addr;
@@ -71,7 +67,7 @@ static void vb2_dc_put(void *buf_priv)
struct vb2_dc_buf *buf = buf_priv;
if (atomic_dec_and_test(&buf->refcount)) {
- dma_free_coherent(buf->conf->dev, buf->size, buf->vaddr,
+ dma_free_coherent(buf->dev, buf->size, buf->vaddr,
buf->dma_addr);
kfree(buf);
}
@@ -79,23 +75,21 @@ static void vb2_dc_put(void *buf_priv)
static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
{
- struct vb2_dc_conf *conf = alloc_ctx;
+ struct device *dev = alloc_ctx;
struct vb2_dc_buf *buf;
buf = kzalloc(sizeof *buf, GFP_KERNEL);
if (!buf)
return ERR_PTR(-ENOMEM);
- buf->vaddr = dma_alloc_coherent(conf->dev, size, &buf->dma_addr,
- GFP_KERNEL);
+ buf->vaddr = dma_alloc_coherent(dev, size, &buf->dma_addr, GFP_KERNEL);
if (!buf->vaddr) {
- dev_err(conf->dev, "dma_alloc_coherent of size %ld failed\n",
- size);
+ dev_err(dev, "dma_alloc_coherent of size %ld failed\n", size);
kfree(buf);
return ERR_PTR(-ENOMEM);
}
- buf->conf = conf;
+ buf->dev = dev;
buf->size = size;
buf->handler.refcount = &buf->refcount;
@@ -180,21 +174,12 @@ EXPORT_SYMBOL_GPL(vb2_dma_contig_memops);
void *vb2_dma_contig_init_ctx(struct device *dev)
{
- struct vb2_dc_conf *conf;
-
- conf = kzalloc(sizeof *conf, GFP_KERNEL);
- if (!conf)
- return ERR_PTR(-ENOMEM);
-
- conf->dev = dev;
-
- return conf;
+ return dev;
}
EXPORT_SYMBOL_GPL(vb2_dma_contig_init_ctx);
void vb2_dma_contig_cleanup_ctx(void *alloc_ctx)
{
- kfree(alloc_ctx);
}
EXPORT_SYMBOL_GPL(vb2_dma_contig_cleanup_ctx);
--
1.7.3.4
[RFCv2 PATCH 2/9 - 2/4] v4l: vb2-dma-contig: Reorder functions
Group functions by buffer type.
Signed-off-by: Laurent Pinchart
---
drivers/media/video/videobuf2-dma-contig.c | 94 ---
1 files changed, 56 insertions(+), 38 deletions(-)
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c
index 5207eb1..6bc4651 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -24,14 +24,58 @@ struct vb2_dc_conf {
struct vb2_dc_buf {
struct vb2_dc_conf *conf;
void*vaddr;
- dma_addr_t dma_addr;
unsigned long size;
- struct vm_area_struct *vma;
- atomic_trefcount;
+ dma_addr_t dma_addr;
+
+ /* MMAP related */
struct vb2_vmarea_handler handler;
+ atomic_trefcount;
+
+ /* USERPTR related */
+ struct vm_area_struct *vma;
};
-static void vb2_dc_put(void *buf_priv);
+/*/
+/* callbacks for all buffers */
+/*/
+
+static void *vb2_dc_cookie(void *buf_priv)
+{
+ struct vb2_dc_buf *buf = buf_priv;
+
+ return &buf->dma_addr;
+}
+
+static void *vb2_dc_vaddr(void *buf_priv)
+{
+ struct vb2_dc_buf *buf = buf_priv;
+ if (!buf)
+ return 0;
+
+ return buf->vaddr;
+}
+
+static unsigned int vb2_dc_num_users(void *buf_priv)
+{
+ struct vb2_dc_buf *buf = buf_priv;
+
+ return atomic_read(&buf->refcount);
+}
+
+/*/
+/*callbacks for MMAP buffers */
+/*/
+
+static void vb2_dc_put(void *buf_priv)
+{
+ struct vb2_dc_buf *buf = buf_priv;
+
+ if (atomic_dec_and_test(&buf->refcount)) {
+ dma_free_coherent(buf->conf->dev, buf->size, buf->vaddr,
+ buf->dma_addr);
+ kfree(buf);
+ }
+}
static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
{
@@ -63,40 +107,6 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned long
size)
return buf;
}
-static void vb2_dc_put(void *buf_priv)
-{
- struct vb2_dc_buf *buf = buf_priv;
-
- if (atomic_dec_and_test(&buf->refcount)) {
- dma_free_coherent(buf->conf->dev, buf->size, buf->vaddr,
- buf->dma_addr);
- kfree(buf);
- }
-}
-
-static void *vb2_dc_cookie(void *buf_priv)
-{
- struct vb2_dc_buf *buf = buf_priv;
-
- return &buf->dma_addr;
-}
-
-static void *vb2_dc_vaddr(void *buf_priv)
-{
- struct vb2_dc_buf *buf = buf_priv;
- if (!buf)
- return 0;
-
- return buf->vaddr;
-}
-
-static unsigned int vb2_dc_num_users(void *buf_priv)
-{
- struct vb2_dc_buf *buf = buf_priv;
-
- return atomic_read(&buf->refcount);
-}
-
static int vb2_dc_mmap(void *buf_priv, struct vm_area_struct *vma)
{
struct vb2_dc_buf *buf = buf_priv;
@@ -110,6 +120,10 @@ static int vb2_dc_mmap(void *buf_priv, struct
vm_area_struct *vma)
&vb2_common_vm_ops, &buf->handler);
}
+/*/
+/* callbacks for USERPTR buffers */
+/*/
+
static void *vb2_dc_get_userptr(void *alloc_ctx, unsigned long vaddr,
unsigned long size, int write)
{
@@ -148,6 +162,10 @@ static void vb2_dc_put_userptr(void *mem_priv)
kfree(buf);
}
+/*/
+/* DMA CONTIG exported functions */
+/*/
+
const struct vb2_mem_ops vb2_dma_contig_memops = {
.alloc = vb2_dc_alloc,
.put= vb2_dc_put,
--
1.7.3.4
[RFCv2 PATCH 2/9 - 1/4] v4l: vb2-dma-contig: Shorten vb2_dma_contig prefix to vb2_dc
Signed-off-by: Laurent Pinchart
---
drivers/media/video/videobuf2-dma-contig.c | 36 ++--
1 files changed, 18 insertions(+), 18 deletions(-)
Needless to say, feel free to modify authorship information for these patches
based on the original authors.
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c
index f17ad98..5207eb1 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -31,9 +31,9 @@ struct vb2_dc_buf {
struct vb2_vmarea_handler handler;
};
-static void vb2_dma_contig_put(void *buf_priv);
+static void vb2_dc_put(void *buf_priv);
-static void *vb2_dma_contig_alloc(void *alloc_ctx, unsigned long size)
+static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
{
struct vb2_dc_conf *conf = alloc_ctx;
struct vb2_dc_buf *buf;
@@ -55,7 +55,7 @@ static void *vb2_dma_contig_alloc(void *alloc_ctx, unsigned
long size)
buf->size = size;
buf->handler.refcount = &buf->refcount;
- buf->handler.put = vb2_dma_contig_put;
+ buf->handler.put = vb2_dc_put;
buf->handler.arg = buf;
atomic_inc(&buf->refcount);
@@ -63,7 +63,7 @@ static void *vb2_dma_contig_alloc(void *alloc_ctx, unsigned
long size)
return buf;
}
-static void vb2_dma_contig_put(void *buf_priv)
+static void vb2_dc_put(void *buf_priv)
{
struct vb2_dc_buf *buf = buf_priv;
@@ -74,14 +74,14 @@ static void vb2_dma_contig_put(void *buf_priv)
}
}
-static void *vb2_dma_contig_cookie(void *buf_priv)
+static void *vb2_dc_cookie(void *buf_priv)
{
struct vb2_dc_buf *buf = buf_priv;
return &buf->dma_addr;
}
-static void *vb2_dma_contig_vaddr(void *buf_priv)
+static void *vb2_dc_vaddr(void *buf_priv)
{
struct vb2_dc_buf *buf = buf_priv;
if (!buf)
@@ -90,14 +90,14 @@ static void *vb2_dma_contig_vaddr(void *buf_priv)
return buf->vaddr;
}
-static unsigned int vb2_dma_contig_num_users(void *buf_priv)
+static unsigned int vb2_dc_num_users(void *buf_priv)
{
struct vb2_dc_buf *buf = buf_priv;
return atomic_read(&buf->refcount);
}
-static int vb2_dma_contig_mmap(void *buf_priv, struct vm_area_struct *vma)
+static int vb2_dc_mmap(void *buf_priv, struct vm_area_struct *vma)
{
struct vb2_dc_buf *buf = buf_priv;
@@ -110,7 +110,7 @@ static int vb2_dma_contig_mmap(void *buf_priv, struct
vm_area_struct *vma)
&vb2_common_vm_ops, &buf->handler);
}
-static void *vb2_dma_contig_get_userptr(void *alloc_ctx, unsigned long vaddr,
+static void *vb2_dc_get_userptr(void *alloc_ctx, unsigned long vaddr,
unsigned long size, int write)
{
struct vb2_dc_buf *buf;
@@ -137,7 +137,7 @@ static void *vb2_dma_contig_get_userptr(void *alloc_ctx,
unsigned long vaddr,
return buf;
}
-static void vb2_dma_contig_put_userptr(void *mem_priv)
+static void vb2_dc_put_userptr(void *mem_priv)
{
struct vb2_dc_buf *buf = mem_priv;
@@ -149,14 +149,14 @@ static void vb2_dma_contig_put_userptr(void *mem_priv)
}
const struct vb2_mem_ops vb2_dma_contig_memops = {
- .alloc = vb2_dma_contig_alloc,
- .put= vb2_dma_contig_put,
- .cookie = vb2_dma_contig_cookie,
- .vaddr = vb2_dma_contig_vaddr,
- .mmap = vb2_dma_contig_mmap,
- .get_userptr= vb2_dma_contig_get_userptr,
- .put_userptr= vb2_dma_contig_put_userptr,
- .num_users = vb2_dma_contig_num_users,
+ .alloc = vb2_dc_alloc,
+ .put= vb2_dc_put,
+ .cookie = vb2_dc_cookie,
+ .vaddr = vb2_dc_vaddr,
+ .mmap = vb2_dc_mmap,
+ .get_userptr= vb2_dc_get_userptr,
+ .put_userptr= vb2_dc_put_userptr,
+ .num_users = vb2_dc_num_users,
};
EXPORT_SYMBOL_GPL(vb2_dma_contig_memops);
--
1.7.3.4
[RFCv2 PATCH 2/9] v4l: vb2-dma-contig: update and code refactoring
Hi Tomasz, Thanks for the patch. On Tuesday 13 March 2012 11:17:00 Tomasz Stanislawski wrote: > This patch combines updates and fixes to dma-contig allocator. > Moreover the allocator code was refactored. > The most important changes are: > - functions were reordered > - move compression of scatterlist to separete function > - add support for multichunk but contiguous scatterlists > - simplified implementation of vb2-dma-contig context structure > - let mmap method to use dma_mmap_writecombine > - add support for scatterlist in userptr mode Combining all this makes it pretty difficult to review the patch. What about splitting the patch into the following ? - Function rename (s/vb2_dma_contig_/vb2_dc_/) - Code reordering - Replace custom alloc_ctx structure with direct struct device usage - The rest, possibly further split into MMAP and USERPTR changes That would make the patch easier to review. I've already split it according to the above (with the MMAP and USERPTR changes kept together as the original patch). I'll post the patches in reply to this mail, with my comments as further replies. -- Regards, Laurent Pinchart
[patch] drm/udl: unlock before returning in udl_gem_mmap()
If we hit an error here, then we should unlock and unreference obj
before returning.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
index 852642d..6de6130 100644
--- a/drivers/gpu/drm/udl/udl_gem.c
+++ b/drivers/gpu/drm/udl/udl_gem.c
@@ -210,7 +210,7 @@ int udl_gem_mmap(struct drm_file *file, struct drm_device
*dev,
ret = udl_gem_get_pages(gobj, GFP_KERNEL);
if (ret)
- return ret;
+ goto out;
if (!gobj->base.map_list.map) {
ret = drm_gem_create_mmap_offset(obj);
if (ret)
Re: [Linaro-mm-sig] [RFCv2 PATCH 2/9 - 4/4] v4l: vb2-dma-contig: update and code refactoring
On 03/22/2012 03:52 PM, Subash Patel wrote: > Hi Laurent, > > On 03/22/2012 08:12 PM, Laurent Pinchart wrote: >> Hi Tomasz, >> >> On Thursday 22 March 2012 14:36:33 Tomasz Stanislawski wrote: >>> Hi Laurent, >>> Thank you very much for your comments and question. >>> They were very useful. >> >> You're welcome. >> >>> Please refer to the comments below. >>> >>> On 03/22/2012 11:50 AM, Laurent Pinchart wrote: On Thursday 22 March 2012 11:02:23 Laurent Pinchart wrote: > From: Tomasz Stanislawski > [snip] >>> The physical address is already present in buf->dma_addr, but it is only >>> valid if the device has no MMU. Notice that vb2-dma-contig possess no >>> knowledge if MMU is present for a given device. >> >> That's why buf->dma_addr can't be considered as a physical address. It's only >> useful in the device context. >> >>> The sg list is not going to be single-entry if the device is provided with >>> its own MMU. >> >> There's something I don't get then. vb2-dma-contig deals with physically >> contiguous buffers. The buffer is backed by physically contiguous pages, so >> the sg list should have a single entry. >> > I think at present, vb2-dma-contig is abused for any kind of memory > allocation (continuous or not). Wouldnt it be good to have a > proper working setup for videobuf2-dma-sg instead? Driver which chooses to > use continuous, shall assign vb2_queue->mem_ops = > vb2_dma_contig_memops. The devices which know they have a MMU backing can > assign the same to vb2_dma_sg_memops. But as of now, > we try to use vb2_dma_contig_memops for all kind of operation. I have also > done this mistake, and wish I repaired it and posted > it before :( > Hi Subash, At first, I do not think that vb2-dma-contig is abused for any kind of allocation. It is used only for DMA coherent contiguous mapping what is very close to vb2-dma-contig's original purpose. One thing has to be said loudly: "The driver does not need to and should not know if IOMMU is present or not." The DMA framework must know if device uses IOMMU or not. Reason: the memory is allocated, free, flushed, mapped only by DMA framework. Usage of vb2-dma-contig or vb2-dma-sg depends only on the way how the memory is configured into the device. Most of embedded devices use only buffer's start address and buffer size (often indirectly specified by width/height and format). It mean that device needs a buffer that is contiguous for its DMA engine. In such a case, the driver should ALWAYS use vb2-dma-contig. The DMA framework hidden deep in dma_alloc_coherent internals will deal with IOMMU configuration. I hope you find this information useful. Regards, Tomasz Stanislawski ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [RFCv2 PATCH 2/9 - 4/4] v4l: vb2-dma-contig: update and code refactoring
Hi Laurent,
On 03/22/2012 03:42 PM, Laurent Pinchart wrote:
> Hi Tomasz,
>
> On Thursday 22 March 2012 14:36:33 Tomasz Stanislawski wrote:
>> Hi Laurent,
>> Thank you very much for your comments and question.
>> They were very useful.
>
> You're welcome.
>
>> Please refer to the comments below.
>>
>> On 03/22/2012 11:50 AM, Laurent Pinchart wrote:
>>> On Thursday 22 March 2012 11:02:23 Laurent Pinchart wrote:
From: Tomasz Stanislawski
This patch combines updates and fixes to dma-contig allocator.
Moreover the allocator code was refactored.
The most important changes are:
- functions were reordered
- move compression of scatterlist to separete function
- add support for multichunk but contiguous scatterlists
- simplified implementation of vb2-dma-contig context structure
- let mmap method to use dma_mmap_writecombine
- add support for scatterlist in userptr mode
>
> [snip]
>
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c index c898e6f..9965465
100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
>
> [snip]
>
static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
{
struct device *dev = alloc_ctx;
struct vb2_dc_buf *buf;
+ int ret;
+ int
n_pages;
buf = kzalloc(sizeof *buf, GFP_KERNEL);
if (!buf)
return ERR_PTR(-ENOMEM);
- buf->vaddr = dma_alloc_coherent(dev, size, &buf->dma_addr,
> GFP_KERNEL);
+ buf->dev = dev;
+ buf->size = size;
+ buf->vaddr = dma_alloc_coherent(buf->dev, buf->size, &buf->dma_addr,
+ GFP_KERNEL);
+
+ ret = -ENOMEM;
if (!buf->vaddr) {
- dev_err(dev, "dma_alloc_coherent of size %ld failed\n", size);
- kfree(buf);
- return ERR_PTR(-ENOMEM);
+ dev_err(dev, "dma_alloc_coherent of size %ld failed\n",
+ size);
+ goto fail_buf;
}
- buf->dev = dev;
- buf->size = size;
+ WARN_ON((unsigned long)buf->vaddr & ~PAGE_MASK);
+ WARN_ON(buf->dma_addr & ~PAGE_MASK);
+
+ n_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
+
+ pages = kmalloc(n_pages * sizeof pages[0], GFP_KERNEL);
+ if (!pages) {
+ printk(KERN_ERR "failed to alloc page table\n");
+ goto fail_dma;
+ }
+
+ ret = dma_get_pages(dev, buf->vaddr, buf->dma_addr, pages, n_pages);
>>>
>>> As the only purpose of this is to retrieve a list of pages that will be
>>> used to create a single-entry sgt, wouldn't it be possible to shortcut
>>> the code and get the physical address of the buffer directly ?
>>
>> The physical address should not be used since they are meaningless in a
>> context of different devices. It seams that only the list of pages is
>> more-or-less portable between different drivers.
>
> The pages are physically contiguous. The physical address of the first page
> is
> thus all you need.
No. DMA-CONTIG buffers do not have to be physically contiguous. Please refer
below.
>
> struct page and physical addresses can be used interchangeably in this case
> if
> I'm not mistaken. If you want to go with pages, you could use the first page
> only instead of the physical buffer address.
>
Ok. There are bus addresses, physical addresses, DMA addresses and PFNs.
As I understand PFNs and 'struct page' can be interchanged, at least in one
direction.
The PFNs are used to create a bus address, I mean addresses that are recognized
by
a RAM chip. So a list of PFNs seams to be the most portable way of describing
the memory, isn't it?
>> The physical address is already present in buf->dma_addr, but it is only
>> valid if the device has no MMU. Notice that vb2-dma-contig possess no
>> knowledge if MMU is present for a given device.
>
> That's why buf->dma_addr can't be considered as a physical address. It's only
> useful in the device context.
>
ok
>> The sg list is not going to be single-entry if the device is provided with
>> its own MMU.
>
> There's something I don't get then. vb2-dma-contig deals with physically
> contiguous buffers. The buffer is backed by physically contiguous pages, so
> the sg list should have a single entry.
>
As I understand dma-contig deal with DMA contiguous buffers, it means buffers
that are contiguous from device point of view. Therefore those buffers do NOT
have to be physically contiguous if the device has its own IOMMU.
+ if (ret < 0) {
+ printk(KERN_ERR "failed to get buffer pages from DMA API\n");
+ goto fail_pages;
+ }
+ if (ret != n_pages) {
+ ret = -EFAULT;
+ printk(KERN_ERR "failed to get all pages from DMA API\n");
+ goto fail_pages;
+
[RFCv2 PATCH 1/9] v4l: vb2: fixes for DMABUF support
Hi Tomasz,
Thanks for the patch.
On Tuesday 13 March 2012 11:16:59 Tomasz Stanislawski wrote:
> This patch contains fixes to DMABUF support in vb2-core.
> - fixes number of arguments of call_memop macro
> - fixes setup of plane length
> - fixes handling of error pointers
>
> Signed-off-by: Tomasz Stanislawski
> Signed-off-by: Kyungmin Park
Tested-by: Laurent Pinchart
I suppose this will be squashed with Sumit's "[RFCv1 2/4] v4l:vb2: add support
for shared buffer (dma_buf)" patch.
> ---
> drivers/media/video/videobuf2-core.c | 24 +++-
> include/media/videobuf2-core.h |6 +++---
> 2 files changed, 14 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/media/video/videobuf2-core.c
> b/drivers/media/video/videobuf2-core.c index 951cb56..e7df560 100644
> --- a/drivers/media/video/videobuf2-core.c
> +++ b/drivers/media/video/videobuf2-core.c
> @@ -118,7 +118,7 @@ static void __vb2_buf_dmabuf_put(struct vb2_buffer *vb)
> void *mem_priv = vb->planes[plane].mem_priv;
>
> if (mem_priv) {
> - call_memop(q, plane, detach_dmabuf, mem_priv);
> + call_memop(q, detach_dmabuf, mem_priv);
> dma_buf_put(vb->planes[plane].dbuf);
> vb->planes[plane].dbuf = NULL;
> vb->planes[plane].mem_priv = NULL;
> @@ -905,6 +905,8 @@ static int __fill_vb2_buffer(struct vb2_buffer *vb,
> const struct v4l2_buffer *b, }
> if (b->memory == V4L2_MEMORY_DMABUF) {
> for (plane = 0; plane < vb->num_planes; ++plane) {
> + v4l2_planes[plane].bytesused =
> + b->m.planes[plane].bytesused;
> v4l2_planes[plane].m.fd =
> b->m.planes[plane].m.fd;
> }
> }
> @@ -1052,17 +1054,13 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb,
> const struct v4l2_buffer *b) if (IS_ERR_OR_NULL(dbuf)) {
> dprintk(1, "qbuf: invalid dmabuf fd for "
> "plane %d\n", plane);
> - ret = PTR_ERR(dbuf);
> + ret = -EINVAL;
> goto err;
> }
>
> - /* this doesn't get filled in until __fill_vb2_buffer(),
> - * since it isn't known until after dma_buf_get()..
> - */
> - planes[plane].length = dbuf->size;
> -
> /* Skip the plane if already verified */
> if (dbuf == vb->planes[plane].dbuf) {
> + planes[plane].length = dbuf->size;
> dma_buf_put(dbuf);
> continue;
> }
> @@ -1072,7 +1070,7 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const
> struct v4l2_buffer *b)
>
> /* Release previously acquired memory if present */
> if (vb->planes[plane].mem_priv) {
> - call_memop(q, plane, detach_dmabuf,
> + call_memop(q, detach_dmabuf,
> vb->planes[plane].mem_priv);
> dma_buf_put(vb->planes[plane].dbuf);
> }
> @@ -1080,8 +1078,8 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const
> struct v4l2_buffer *b) vb->planes[plane].mem_priv = NULL;
>
> /* Acquire each plane's memory */
> - mem_priv = q->mem_ops->attach_dmabuf(
> - q->alloc_ctx[plane], dbuf);
> + mem_priv = call_memop(q, attach_dmabuf, q->alloc_ctx[plane],
> + dbuf, q->plane_sizes[plane], write);
> if (IS_ERR(mem_priv)) {
> dprintk(1, "qbuf: failed acquiring dmabuf "
> "memory for plane %d\n", plane);
> @@ -1089,6 +1087,7 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const
> struct v4l2_buffer *b) goto err;
> }
>
> + planes[plane].length = dbuf->size;
> vb->planes[plane].dbuf = dbuf;
> vb->planes[plane].mem_priv = mem_priv;
> }
> @@ -1098,8 +1097,7 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const
> struct v4l2_buffer *b) * the buffer(s)..
>*/
> for (plane = 0; plane < vb->num_planes; ++plane) {
> - ret = q->mem_ops->map_dmabuf(
> - vb->planes[plane].mem_priv, write);
> + ret = call_memop(q, map_dmabuf, vb->planes[plane].mem_priv);
> if (ret) {
> dprintk(1, "qbuf: failed mapping dmabuf "
> "memory for plane %d\n", plane);
> @@ -1527,7 +1525,7 @@ int vb2_dqbuf(struct vb2_queue *q, struct v4l2_buffer
> *b, bool nonblocking) */
> if (q->memory == V4L2_MEMORY_DMABUF)
> for (plane = 0; plane < vb->num_planes; ++plane)
> - call_memop(q, plane, unmap_dmabuf,
> + call_memop(q, un
[Bug 42876] System doesn't boot with GTX 550 Ti
https://bugzilla.kernel.org/show_bug.cgi?id=42876 --- Comment #5 from Artyom Kunyov 2012-03-22 08:25:06 --- It worked for me as well with kernel 3.3.0, but with the wrong display resolution, and GNOME Shell was really slow. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
Re: [Linaro-mm-sig] [RFCv2 PATCH 4/9] v4l: add buffer exporting via dmabuf
Hi Subash,
On Thursday 22 March 2012 20:29:57 Subash Patel wrote:
> On 03/22/2012 07:37 PM, Laurent Pinchart wrote:
> > On Thursday 22 March 2012 19:27:01 Subash Patel wrote:
> >> On 03/22/2012 04:46 PM, Laurent Pinchart wrote:
> >>> On Tuesday 13 March 2012 11:17:02 Tomasz Stanislawski wrote:
> > [snip]
> >
> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> index bb6844e..e71c787 100644
> --- a/include/linux/videodev2.h
> +++ b/include/linux/videodev2.h
> @@ -680,6 +680,25 @@ struct v4l2_buffer {
>
> #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE 0x0800
> #define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000
>
> +/**
> + * struct v4l2_exportbuffer - export of video buffer as DMABUF file
> descriptor
> + *
> + * @fd: file descriptor associated with DMABUF (set by driver)
> + * @mem_offset: for non-multiplanar buffers with memory ==
> V4L2_MEMORY_MMAP;
> >>>
> >>> I don't think we will ever support exporting anything else than
> >>> V4L2_MEMORY_MMAP buffers. What will happen for multiplanar buffers ?
> >>>
> + * offset from the start of the device memory for this
> plane,
> + * (or a "cookie" that should be passed to mmap() as
> offset)
> + *
> >>>
> >>> Shouldn't the mem_offset field always be set to the mmap cookie value ?
> >>> I'm a bit confused by the "or" part, it seems to have been copied from
> >>> the v4l2_buffer documentation directly. We should clarify that.
> >>>
> + * Contains data used for exporting a video buffer as DMABUF file
> + * descriptor. Uses the same 'cookie' as mmap() syscall. All reserved
> fields
> + * must be set to zero.
> + */
> +struct v4l2_exportbuffer {
> +__u32 fd;
> +__u32 reserved0;
> >>>
> >>> Why is there a reserved field here ?
> >>
> >> +1 to Laurent. Any particular need for reserved0 and reserved[13] below?
> >> I think one void user pointer is sufficient even for future need.
> >
> > I'd rather have more than one void user pointer, just in case. A couple of
> > bytes won't be expensive,
>
> Just an off-topic note. When I learnt to hit keyboard for programming(in
> linux for embedded), I had strict guidelines not to declare variables as
> I like, as memory and computing was very precious then.
Somewhere on my TODO list is a Kalman filter implementation for a
microcontroller with 512 bytes of RAM. I know what you mean :-)
> A decade later, people no more think its expensive to keep 14*3 bytes*(who
> knows how many dma_buf objects) in the system.
> Just a side note, thats all :)
For objects that will exist in many instances, saving memory is important (you
would need to be really convincing to add a single bit to struct page for
instance), but struct v4l2_exportbuffer is only used to hold parameters for an
ioctl. That's temporary memory, so I think we can spare a couple of extra
bytes if it can help with ABI stability.
> > and they will save lots of hassle in the future if
> > we need to add a couple of fields. I was just wondering why there was a
> > reserved field between fd and mem_offset.
> >
> +__u32 mem_offset;
> +__u32 reserved[13];
> +};
> +
> >>
> >> Also, what is the reason for returning the fd through this structure? To
> >> keep it aligned with other v4l2 calls? I liked(or now hate making change
> >> in the app) how it was being returned through the ioctl in your last
> >> patch.
> >
> > Probably to be consistent with the V4L2 API, yes. It won't make a big
> > difference for applications, I would favor consistency in this case.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm nouveau destaging + Kelper modesetting support
Hi Linus, This pull request is unexpected and not something I had mentioned previously. so NVIDIA announced new Kepler GPUs this morning, and Ben has killed himself getting modesetting support for them together to have on launch day. Most of the code to support the new chips has already gone in, however this pull contains a few more pieces along with the final enables so the driver binds to the new Kepler cards. Its quite amazing that nouveau can support a GPU on its launch day even if its just unaccelerated modesetting, and I'd like to have support in the next kernel. In order to sweeten the deal, Ben has also requested nouveau destage and become ABI stable, the only change is the version number bump which he prepared userspace for quite a long time ago. The driver hasn't broken ABI since that one big break that caused a lot of fuss. It's also quite a small set of code, and not likely to break anything. Dave. The following changes since commit 5466c7b1683a23dbbcfb7ee4a71c4f23886001c7: drm/i915: use DDC_ADDR instead of hard-coding it (2012-03-21 10:20:38 +) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-nouveau-destage Ben Skeggs (14): drm/nouveau/ttm: always do buffer moves on kernel channel drm/nouveau: remove subchannel names from places where it doesn't matter drm/nouveau: move fence sequence check to start of loop drm/nvc0-/disp: reimplement flip completion method as fifo method drm/nouveau: remove m2mf creation on userspace channels drm/nouveau: inform userspace of new kernel subchannel requirements drm/nouveau: oops, increase channel dispc_vma to 4 drm/nvd0/disp: ignore clock set if no pclk drm/nouveau: bump version to 1.0.0 drm/nouveau: move out of staging drivers drm/nouveau: add bios connector type for dms59 drm/nve0: initial modesetting support for kepler chipsets drm/nve0/disp: nvidia randomly decided to move the dithering method drm/nouveau/dp: support version 4.0 of DP table Dave Airlie (1): Merge branch 'drm-nouveau-next' of git://git.freedesktop.org/git/nouveau/linux-2.6 into drm-next drivers/gpu/drm/Kconfig |2 + drivers/gpu/drm/nouveau/nouveau_bios.c |3 +- drivers/gpu/drm/nouveau/nouveau_bios.h |2 + drivers/gpu/drm/nouveau/nouveau_bo.c| 11 +-- drivers/gpu/drm/nouveau/nouveau_channel.c | 34 +++--- drivers/gpu/drm/nouveau/nouveau_connector.c | 13 +-- drivers/gpu/drm/nouveau/nouveau_display.c | 14 ++- drivers/gpu/drm/nouveau/nouveau_dma.c | 61 +--- drivers/gpu/drm/nouveau/nouveau_dma.h |4 +- drivers/gpu/drm/nouveau/nouveau_dp.c| 11 ++ drivers/gpu/drm/nouveau/nouveau_drv.h | 40 +--- drivers/gpu/drm/nouveau/nouveau_fence.c | 35 +++--- drivers/gpu/drm/nouveau/nouveau_gem.c | 10 +-- drivers/gpu/drm/nouveau/nouveau_state.c | 152 +++ drivers/gpu/drm/nouveau/nv50_display.c | 12 +- drivers/gpu/drm/nouveau/nvc0_fifo.c | 36 ++- drivers/gpu/drm/nouveau/nvc0_graph.c|9 -- drivers/gpu/drm/nouveau/nvd0_display.c | 23 - drivers/staging/Kconfig |2 - 19 files changed, 288 insertions(+), 186 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm - radeon southern islands / trinity support
Hi Linus, This applies after my drm-next pull request sent yesterday. It is support from AMD for their newest GPU and APUs. The products called RadeonHD 7xxx, and the Trinity APU series. This did come in a bit late, due to some over-complicated AMD internal review process, which from the outside seems unnecessary once the company has decided it wants to support open source. However as I said previously I'd rather not put the people who've got this hw for 3 months now being forced to use fglrx on it if there is open code. Its pretty well self contained and just plugs into the driver in various places. The following changes since commit da0df92b57311aa1b26a2a90599ed16e1e968b90: drm: allow loading an EDID as firmware to override broken monitor (2012-03-20 10:09:28 +) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-radeon-sitn-support Alex Deucher (46): drm/radeon/kms: Upstream ObjectID.h updates drm/radeon/kms: upstream atombios.h updates drm/radeon/kms: upstream power table updates drm/radeon/kms: add SI chip families drm/radeon/kms: add initial DCE6 display watermark support drm/radeon/kms: fix up atom HPD gpio parsing for DCE6 drm/radeon/kms/atom: DCE6 no longer has crtcmemreq bits drm/radeon/kms/atom: add support for crtc power gating drm/radeon/kms: DCE6 disp eng pll updates drm/radeon/kms/atom: add support for DCE6.x dig transmitters drm/radeon/kms: DP aux updates for DCE6 drm/radeon/kms: update comments about dig encoders/transmitters drm/radeon/kms/atom: add support for SI SetVoltage table drm/radeon/kms: update power table parsing for SI drm/radeon/kms: add support for internal thermal sensor on SI drm/radeon/kms: add gpu init support for SI drm/radeon/kms: Add support for SI GPU reset drm/radeon/kms: add support for MC/VM setup on SI drm/radeon/kms: add support for the CONST IB to the CS ioctl drm/radeon/kms: add VM CS checker for SI drm/radeon/kms: Only VM CS ioctl is supported on SI (v2) drm/radeon/kms: add ucode loading for SI drm/radeon/kms: add support for MC ucode loading on SI drm/radeon/kms: add support for CP setup on SI drm/radeon/kms: add IB and fence dispatch functions for SI drm/radeon/kms: Add support for RLC init on SI drm/radeon/kms: add support for interrupts on SI drm/radeon/kms: fill in startup/shutdown callbacks for SI drm/radeon/kms: add support for compute rings in CS ioctl on SI drm/radeon/kms: add radeon_asic struct for SI drm/radeon/kms: Add SI pci ids drm/radeon/kms: add trinity (TN) chip family drm/radeon/kms: no support for internal thermal sensor on TN yet drm/radeon/kms: DCE6.1 watermark updates for TN drm/radeon/kms: DCE6.1 disp eng pll updates drm/radeon/kms: Adjust pll picker for DCE6.1 drm/radeon/kms: disable PPLL0 on DCE6.1 when not in use drm/radeon/kms/DCE6.1: ss is not supported on the internal pplls drm/radeon/kms: Add checks for TN in the DP bridge code drm/radeon/kms: cayman gpu init updates for trinity drm/radeon/kms: Update evergreen functions for trinity drm/radeon/kms/vm: set vram base offset properly for TN drm/radeon/kms: add support for ucode loading on trinity (v2) drm/radeon/kms: add radeon_asic struct for trinity drm/radeon/kms: add trinity pci ids drm/radeon/kms: update duallink checks for DCE6 Michel Dänzer (1): drm/radeon: Update radeon_info_ioctl for SI. (v2) Tom Stellard (1): drm/radeon/kms: add info query for max pipes drivers/gpu/drm/radeon/Makefile |2 +- drivers/gpu/drm/radeon/ObjectID.h |5 + drivers/gpu/drm/radeon/atombios.h | 1109 +++- drivers/gpu/drm/radeon/atombios_crtc.c | 100 +- drivers/gpu/drm/radeon/atombios_dp.c|6 +- drivers/gpu/drm/radeon/atombios_encoders.c | 71 +- drivers/gpu/drm/radeon/evergreen.c | 25 +- drivers/gpu/drm/radeon/evergreen_blit_kms.c |2 +- drivers/gpu/drm/radeon/ni.c | 141 +- drivers/gpu/drm/radeon/nid.h|1 + drivers/gpu/drm/radeon/r600.c | 25 +- drivers/gpu/drm/radeon/r600d.h |4 + drivers/gpu/drm/radeon/radeon.h | 55 +- drivers/gpu/drm/radeon/radeon_asic.c| 208 ++ drivers/gpu/drm/radeon/radeon_asic.h| 25 + drivers/gpu/drm/radeon/radeon_atombios.c| 78 +- drivers/gpu/drm/radeon/radeon_connectors.c |2 +- drivers/gpu/drm/radeon/radeon_cs.c | 63 +- drivers/gpu/drm/radeon/radeon_device.c |6 +- drivers/gpu/drm/radeon/radeon_display.c |2 +- drivers/gpu/drm/radeon/radeon_drv.c |3 +- drivers/gpu/drm/radeon/radeon_encoders.c|6 +- drivers/gpu/drm/radeon/radeon_family.h |4 + drivers/gpu/drm/radeon/radeon_kms.c
Re: [Linaro-mm-sig] [RFCv2 PATCH 4/9] v4l: add buffer exporting via dmabuf
On Thursday 22 March 2012 15:26:08 Daniel Vetter wrote:
> On Thu, Mar 22, 2012 at 03:07:18PM +0100, Laurent Pinchart wrote:
> > > >> + * Contains data used for exporting a video buffer as DMABUF file
> > > >> + * descriptor. Uses the same 'cookie' as mmap() syscall. All
> > > >> reserved
> > > >> fields
> > > >> + * must be set to zero.
> > > >> + */
> > > >> +struct v4l2_exportbuffer {
> > > >> + __u32 fd;
> > > >> + __u32 reserved0;
> > > >
> > > > Why is there a reserved field here ?
> > >
> > > +1 to Laurent. Any particular need for reserved0 and reserved[13] below?
> > > I think one void user pointer is sufficient even for future need.
> >
> > I'd rather have more than one void user pointer, just in case. A couple of
> > bytes won't be expensive, and they will save lots of hassle in the future
> > if we need to add a couple of fields. I was just wondering why there was
> > a reserved field between fd and mem_offset.
>
> Quick comment from a random bystander: __u32 is not big enough for a void*
> pointer from userspace ...
That's why I'm happy with 14 reserved __u32. That should be enough for
userspace pointers in the foreseable future :-)
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [RFCv2 PATCH 2/9 - 4/4] v4l: vb2-dma-contig: update and code refactoring
Hi Tomasz,
On Thursday 22 March 2012 14:36:33 Tomasz Stanislawski wrote:
> Hi Laurent,
> Thank you very much for your comments and question.
> They were very useful.
You're welcome.
> Please refer to the comments below.
>
> On 03/22/2012 11:50 AM, Laurent Pinchart wrote:
> > On Thursday 22 March 2012 11:02:23 Laurent Pinchart wrote:
> >> From: Tomasz Stanislawski
> >>
> >> This patch combines updates and fixes to dma-contig allocator.
> >> Moreover the allocator code was refactored.
> >> The most important changes are:
> >> - functions were reordered
> >> - move compression of scatterlist to separete function
> >> - add support for multichunk but contiguous scatterlists
> >> - simplified implementation of vb2-dma-contig context structure
> >> - let mmap method to use dma_mmap_writecombine
> >> - add support for scatterlist in userptr mode
[snip]
> >> diff --git a/drivers/media/video/videobuf2-dma-contig.c
> >> b/drivers/media/video/videobuf2-dma-contig.c index c898e6f..9965465
> >> 100644
> >> --- a/drivers/media/video/videobuf2-dma-contig.c
> >> +++ b/drivers/media/video/videobuf2-dma-contig.c
[snip]
> >> static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
> >> {
> >>
> >>struct device *dev = alloc_ctx;
> >>struct vb2_dc_buf *buf;
> >>
> >> + int ret;
> >> + int
> >> n_pages;http://165.213.219.115/cgi-bin/gitweb.cgi?p=mirror/linux-3.0-mid
> >> as;a=shortlog;h=refs/heads/exynos-3.0-dev +struct page **pages =
> >> NULL;
> >>
> >>buf = kzalloc(sizeof *buf, GFP_KERNEL);
> >>if (!buf)
> >>
> >>return ERR_PTR(-ENOMEM);
> >>
> >> - buf->vaddr = dma_alloc_coherent(dev, size, &buf->dma_addr,
GFP_KERNEL);
> >> + buf->dev = dev;
> >> + buf->size = size;
> >> + buf->vaddr = dma_alloc_coherent(buf->dev, buf->size, &buf->dma_addr,
> >> + GFP_KERNEL);
> >> +
> >> + ret = -ENOMEM;
> >>
> >>if (!buf->vaddr) {
> >>
> >> - dev_err(dev, "dma_alloc_coherent of size %ld failed\n", size);
> >> - kfree(buf);
> >> - return ERR_PTR(-ENOMEM);
> >> + dev_err(dev, "dma_alloc_coherent of size %ld failed\n",
> >> + size);
> >> + goto fail_buf;
> >>
> >>}
> >>
> >> - buf->dev = dev;
> >> - buf->size = size;
> >> + WARN_ON((unsigned long)buf->vaddr & ~PAGE_MASK);
> >> + WARN_ON(buf->dma_addr & ~PAGE_MASK);
> >> +
> >> + n_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
> >> +
> >> + pages = kmalloc(n_pages * sizeof pages[0], GFP_KERNEL);
> >> + if (!pages) {
> >> + printk(KERN_ERR "failed to alloc page table\n");
> >> + goto fail_dma;
> >> + }
> >> +
> >> + ret = dma_get_pages(dev, buf->vaddr, buf->dma_addr, pages, n_pages);
> >
> > As the only purpose of this is to retrieve a list of pages that will be
> > used to create a single-entry sgt, wouldn't it be possible to shortcut
> > the code and get the physical address of the buffer directly ?
>
> The physical address should not be used since they are meaningless in a
> context of different devices. It seams that only the list of pages is
> more-or-less portable between different drivers.
The pages are physically contiguous. The physical address of the first page is
thus all you need.
struct page and physical addresses can be used interchangeably in this case if
I'm not mistaken. If you want to go with pages, you could use the first page
only instead of the physical buffer address.
> The physical address is already present in buf->dma_addr, but it is only
> valid if the device has no MMU. Notice that vb2-dma-contig possess no
> knowledge if MMU is present for a given device.
That's why buf->dma_addr can't be considered as a physical address. It's only
useful in the device context.
> The sg list is not going to be single-entry if the device is provided with
> its own MMU.
There's something I don't get then. vb2-dma-contig deals with physically
contiguous buffers. The buffer is backed by physically contiguous pages, so
the sg list should have a single entry.
> >> + if (ret < 0) {
> >> + printk(KERN_ERR "failed to get buffer pages from DMA API\n");
> >> + goto fail_pages;
> >> + }
> >> + if (ret != n_pages) {
> >> + ret = -EFAULT;
> >> + printk(KERN_ERR "failed to get all pages from DMA API\n");
> >> + goto fail_pages;
> >> + }
> >> +
> >> + buf->sgt_base = vb2_dc_pages_to_sgt(pages, n_pages, 0, 0);
> >> + if (IS_ERR(buf->sgt_base)) {
> >> + ret = PTR_ERR(buf->sgt_base);
> >> + printk(KERN_ERR "failed to prepare sg table\n");
> >> + goto fail_pages;
> >> + }
> >
> > buf->sgt_base isn't used in this patch. I would move the buf->sgt_base
> > creation code to the patch that uses it then, or to its own patch just
> > before the patch that uses it.
>
> Good point. The sgt_base is used by exporter only. Thanks for noticing it.
>
> >> +
> >> + /* pages are no longer needed */
> >> + kfree(pages);
> >>
> >>buf->handler.re
Re: [Linaro-mm-sig] [RFCv2 PATCH 4/9] v4l: add buffer exporting via dmabuf
On Thu, Mar 22, 2012 at 03:07:18PM +0100, Laurent Pinchart wrote:
> > >> + * Contains data used for exporting a video buffer as DMABUF file
> > >> + * descriptor. Uses the same 'cookie' as mmap() syscall. All reserved
> > >> fields
> > >> + * must be set to zero.
> > >> + */
> > >> +struct v4l2_exportbuffer {
> > >> +__u32 fd;
> > >> +__u32 reserved0;
> > >
> > > Why is there a reserved field here ?
> >
> > +1 to Laurent. Any particular need for reserved0 and reserved[13] below?
> > I think one void user pointer is sufficient even for future need.
>
> I'd rather have more than one void user pointer, just in case. A couple of
> bytes won't be expensive, and they will save lots of hassle in the future if
> we need to add a couple of fields. I was just wondering why there was a
> reserved field between fd and mem_offset.
Quick comment from a random bystander: __u32 is not big enough for a void*
pointer from userspace ...
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [RFCv2 PATCH 4/9] v4l: add buffer exporting via dmabuf
Hi Subash,
On Thursday 22 March 2012 19:27:01 Subash Patel wrote:
> On 03/22/2012 04:46 PM, Laurent Pinchart wrote:
> > On Tuesday 13 March 2012 11:17:02 Tomasz Stanislawski wrote:
[snip]
> >> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> >> index bb6844e..e71c787 100644
> >> --- a/include/linux/videodev2.h
> >> +++ b/include/linux/videodev2.h
> >> @@ -680,6 +680,25 @@ struct v4l2_buffer {
> >>
> >> #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE0x0800
> >> #define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000
> >>
> >> +/**
> >> + * struct v4l2_exportbuffer - export of video buffer as DMABUF file
> >> descriptor
> >> + *
> >> + * @fd: file descriptor associated with DMABUF (set by driver)
> >> + * @mem_offset: for non-multiplanar buffers with memory ==
> >> V4L2_MEMORY_MMAP;
> >
> > I don't think we will ever support exporting anything else than
> > V4L2_MEMORY_MMAP buffers. What will happen for multiplanar buffers ?
> >
> >> + *offset from the start of the device memory for this
> >> plane,
> >> + *(or a "cookie" that should be passed to mmap() as
> >> offset)
> >> + *
> >
> > Shouldn't the mem_offset field always be set to the mmap cookie value ?
> > I'm a bit confused by the "or" part, it seems to have been copied from
> > the v4l2_buffer documentation directly. We should clarify that.
> >
> >> + * Contains data used for exporting a video buffer as DMABUF file
> >> + * descriptor. Uses the same 'cookie' as mmap() syscall. All reserved
> >> fields
> >> + * must be set to zero.
> >> + */
> >> +struct v4l2_exportbuffer {
> >> + __u32 fd;
> >> + __u32 reserved0;
> >
> > Why is there a reserved field here ?
>
> +1 to Laurent. Any particular need for reserved0 and reserved[13] below?
> I think one void user pointer is sufficient even for future need.
I'd rather have more than one void user pointer, just in case. A couple of
bytes won't be expensive, and they will save lots of hassle in the future if
we need to add a couple of fields. I was just wondering why there was a
reserved field between fd and mem_offset.
> >> + __u32 mem_offset;
> >> + __u32 reserved[13];
> >> +};
> >> +
>
> Also, what is the reason for returning the fd through this structure? To
> keep it aligned with other v4l2 calls? I liked(or now hate making change
> in the app) how it was being returned through the ioctl in your last patch.
Probably to be consistent with the V4L2 API, yes. It won't make a big
difference for applications, I would favor consistency in this case.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [RFCv2 PATCH 2/9 - 4/4] v4l: vb2-dma-contig: update and code refactoring
Hi Laurent,
Thank you very much for your comments and question.
They were very useful.
Please refer to the comments below.
On 03/22/2012 11:50 AM, Laurent Pinchart wrote:
> Hi Tomasz,
>
> Thanks for the patch.
>
> On Thursday 22 March 2012 11:02:23 Laurent Pinchart wrote:
>> From: Tomasz Stanislawski
>>
>> This patch combines updates and fixes to dma-contig allocator.
>> Moreover the allocator code was refactored.
>> The most important changes are:
>> - functions were reordered
>> - move compression of scatterlist to separete function
>> - add support for multichunk but contiguous scatterlists
>> - simplified implementation of vb2-dma-contig context structure
>> - let mmap method to use dma_mmap_writecombine
>> - add support for scatterlist in userptr mode
>>
>> Signed-off-by: Marek Szyprowski
>> [mmap method]
>> Signed-off-by: Andrzej Pietrasiewicz
>> [scatterlist in userptr mode]
>> Signed-off-by: Kamil Debski
>> [bugfixing]
>> Signed-off-by: Tomasz Stanislawski
>> [core refactoring, helper functions]
>> Signed-off-by: Kyungmin Park
>> ---
>> drivers/media/video/videobuf2-dma-contig.c | 400
>> +--- 1 files changed, 365 insertions(+), 35
>> deletions(-)
>>
>> diff --git a/drivers/media/video/videobuf2-dma-contig.c
>> b/drivers/media/video/videobuf2-dma-contig.c index c898e6f..9965465 100644
>> --- a/drivers/media/video/videobuf2-dma-contig.c
>> +++ b/drivers/media/video/videobuf2-dma-contig.c
>> @@ -10,9 +10,12 @@
>> * the Free Software Foundation.
>> */
>>
>> +#include
>> +#include
>> #include
>> +#include
>> +#include
>> #include
>> -#include
>>
>> #include
>> #include
>> @@ -22,16 +25,115 @@ struct vb2_dc_buf {
>> void*vaddr;
>> unsigned long size;
>> dma_addr_t dma_addr;
>> +struct sg_table *dma_sgt;
>> +enum dma_data_direction dma_dir;
>>
>> /* MMAP related */
>> struct vb2_vmarea_handler handler;
>> atomic_trefcount;
>> +struct sg_table *sgt_base;
>>
>> /* USERPTR related */
>> struct vm_area_struct *vma;
>> };
>>
>> /*/
>> +/*scatterlist table functions*/
>> +/*/
>> +
>> +static struct sg_table *vb2_dc_pages_to_sgt(struct page **pages,
>> +unsigned long n_pages, size_t offset, size_t offset2)
>> +{
>> +struct sg_table *sgt;
>> +int i, j; /* loop counters */
>> +int cur_page, chunks;
>> +int ret;
>> +struct scatterlist *s;
>> +
>> +sgt = kzalloc(sizeof *sgt, GFP_KERNEL);
>> +if (!sgt)
>> +return ERR_PTR(-ENOMEM);
>> +
>> +/* compute number of chunks */
>> +chunks = 1;
>> +for (i = 1; i < n_pages; ++i)
>> +if (pages[i] != pages[i - 1] + 1)
>> +++chunks;
>> +
>> +ret = sg_alloc_table(sgt, chunks, GFP_KERNEL);
>> +if (ret) {
>> +kfree(sgt);
>> +return ERR_PTR(-ENOMEM);
>> +}
>> +
>> +/* merging chunks and putting them into the scatterlist */
>> +cur_page = 0;
>> +for_each_sg(sgt->sgl, s, sgt->orig_nents, i) {
>> +size_t size = PAGE_SIZE;
>> +
>> +for (j = cur_page + 1; j < n_pages; ++j) {
>> +if (pages[j] != pages[j - 1] + 1)
>> +break;
>> +size += PAGE_SIZE;
>> +}
>> +
>> +/* cut offset if chunk starts at the first page */
>> +if (cur_page == 0)
>> +size -= offset;
>> +/* cut offset2 if chunk ends at the last page */
>> +if (j == n_pages)
>> +size -= offset2;
>> +
>> +sg_set_page(s, pages[cur_page], size, offset);
>> +offset = 0;
>> +cur_page = j;
>> +}
>> +
>> +return sgt;
>> +}
>> +
>> +static void vb2_dc_release_sgtable(struct sg_table *sgt)
>> +{
>> +sg_free_table(sgt);
>> +kfree(sgt);
>> +}
>> +
>> +static void vb2_dc_put_sgtable(struct sg_table *sgt, int dirty)
>> +{
>> +struct scatterlist *s;
>> +int i, j;
>> +
>> +for_each_sg(sgt->sgl, s, sgt->nents, i) {
>> +struct page *page = sg_page(s);
>> +int n_pages = PAGE_ALIGN(s->offset + s->length) >> PAGE_SHIFT;
>> +
>> +for (j = 0; j < n_pages; ++j, ++page) {
>> +if (dirty)
>> +set_page_dirty_lock(page);
>> +put_page(page);
>> +}
>> +}
>> +
>> +vb2_dc_release_sgtable(sgt);
>> +}
>> +
>> +static unsigned long vb2_dc_get_contiguous_size(struct sg_table *sgt)
>> +{
>> +struct scatterlist *s;
>> +dma_addr_t expected = sg_dma_address(sgt->sgl);
>> +int i;
>> +unsigned long size = 0;
>> +
>> +for_each_sg(sgt->sgl, s, sgt->nents, i) {
>> +if (sg_dm
Re: [RFCv2 PATCH 7/9] v4l: vb2-dma-contig: change map/unmap behaviour
On Thu, Mar 22, 2012 at 13:15, Laurent Pinchart wrote: > On Tuesday 13 March 2012 11:17:05 Tomasz Stanislawski wrote: >> The DMABUF documentation says that the map_dma_buf callback should return >> scatterlist that is mapped into a caller's address space. In practice, >> almost none of existing implementations of DMABUF exporter does it. Â This >> patch breaks the DMABUF specification in order to allow exchange DMABUF >> buffers between other APIs like DRM. > > Then it's time to fix the spec, and squash 6/9 and 7/9 together (I started > reviewing 6/9 and the implementation puzzled me until I saw the "fixes" in > 7/9). Nope. The drm proof of concept stuff that just grabbed the struct pages pointers from the sg_table has always just been a gross hack to get things of the ground. With proper kernel cpu access and mmap support we can ditch these, and Dave Airlie has already started with that: http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-dmabuf2 Furthermore the kernel cpu access helpers are designed to just plug into the corresponding ttm helpers. It'll be slightly more messy for drm/i915 and udl because they don't use ttm. And the afaik the proof of concept stuff from Rob Clark very much depends upon handing out addresses in the targets device address space. And there are other scenarios that just require this, besides that it makes imo more sense from an api design pov. Yours, Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFCv2 PATCH 7/9] v4l: vb2-dma-contig: change map/unmap behaviour
Hi Tomasz,
Thanks for the patch.
On Tuesday 13 March 2012 11:17:05 Tomasz Stanislawski wrote:
> The DMABUF documentation says that the map_dma_buf callback should return
> scatterlist that is mapped into a caller's address space. In practice,
> almost none of existing implementations of DMABUF exporter does it. This
> patch breaks the DMABUF specification in order to allow exchange DMABUF
> buffers between other APIs like DRM.
Then it's time to fix the spec, and squash 6/9 and 7/9 together (I started
reviewing 6/9 and the implementation puzzled me until I saw the "fixes" in
7/9).
We need to agree on a behaviour for the mapping API. I've thought from the
beginning that mapping the buffer to the importer's device address space
should be the responsibility of the importer, not the exporter. If we move to
that approach, we should probably rename the map and unmap functions as they
won't deal with mappings anymore. I recall that pin/unpin were proposed at
some point (possible during a meeting at the ELC).
One possible issue with handling mappings in the importer is that the exporter
won't be able to implement any mapping/unmapping hack that might be needed. As
the DMA SG API doesn't seem to support VM_PFNMAP memory (see the explanation
in my reply to 2/9), we will be left without a solution if an exporter uses
memory not backed with struct page.
> Signed-off-by: Tomasz Stanislawski
> Signed-off-by: Kyungmin Park
> ---
> drivers/media/video/videobuf2-dma-contig.c | 64
> 1 files changed, 27 insertions(+), 37
> deletions(-)
>
> diff --git a/drivers/media/video/videobuf2-dma-contig.c
> b/drivers/media/video/videobuf2-dma-contig.c index d95b23a..32bb16b 100644
> --- a/drivers/media/video/videobuf2-dma-contig.c
> +++ b/drivers/media/video/videobuf2-dma-contig.c
> @@ -315,11 +315,6 @@ static int vb2_dc_mmap(void *buf_priv, struct
> vm_area_struct *vma) /* DMABUF ops for exporters */
> /*/
>
> -struct vb2_dc_attachment {
> - struct sg_table sgt;
> - enum dma_data_direction dir;
> -};
> -
> static int vb2_dc_dmabuf_ops_attach(struct dma_buf *dbuf, struct device
> *dev, struct dma_buf_attachment *dbuf_attach)
> {
> @@ -330,17 +325,13 @@ static int vb2_dc_dmabuf_ops_attach(struct dma_buf
> *dbuf, struct device *dev, static void vb2_dc_dmabuf_ops_detach(struct
> dma_buf *dbuf,
> struct dma_buf_attachment *db_attach)
> {
> - struct vb2_dc_attachment *attach = db_attach->priv;
> - struct sg_table *sgt;
> + struct sg_table *sgt = db_attach->priv;
>
> - if (!attach)
> + if (!sgt)
> return;
>
> - sgt = &attach->sgt;
> -
> - dma_unmap_sg(db_attach->dev, sgt->sgl, sgt->nents, attach->dir);
> sg_free_table(sgt);
> - kfree(attach);
> + kfree(sgt);
> db_attach->priv = NULL;
> }
>
> @@ -349,26 +340,22 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
> {
> struct dma_buf *dbuf = db_attach->dmabuf;
> struct vb2_dc_buf *buf = dbuf->priv;
> - struct vb2_dc_attachment *attach = db_attach->priv;
> - struct sg_table *sgt;
> + struct sg_table *sgt = db_attach->priv;
> struct scatterlist *rd, *wr;
> int i, ret;
>
> /* return previously mapped sg table */
> - if (attach)
> - return &attach->sgt;
> + if (sgt)
> + return sgt;
>
> - attach = kzalloc(sizeof *attach, GFP_KERNEL);
> - if (!attach)
> + sgt = kzalloc(sizeof *sgt, GFP_KERNEL);
> + if (!sgt)
> return ERR_PTR(-ENOMEM);
>
> - sgt = &attach->sgt;
> - attach->dir = dir;
> -
> /* copying the buf->base_sgt to attachment */
> ret = sg_alloc_table(sgt, buf->sgt_base->orig_nents, GFP_KERNEL);
> if (ret) {
> - kfree(attach);
> + kfree(sgt);
> return ERR_PTR(-ENOMEM);
> }
>
> @@ -380,16 +367,7 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
> wr = sg_next(wr);
> }
>
> - /* mapping new sglist to the client */
> - ret = dma_map_sg(db_attach->dev, sgt->sgl, sgt->orig_nents, dir);
> - if (ret <= 0) {
> - printk(KERN_ERR "failed to map scatterlist\n");
> - sg_free_table(sgt);
> - kfree(attach);
> - return ERR_PTR(-EIO);
> - }
> -
> - db_attach->priv = attach;
> + db_attach->priv = sgt;
>
> return sgt;
> }
> @@ -623,7 +601,7 @@ static int vb2_dc_map_dmabuf(void *mem_priv)
> struct vb2_dc_buf *buf = mem_priv;
> struct sg_table *sgt;
> unsigned long contig_size;
> - int ret = 0;
> + int ret = -EFAULT;
>
> if (WARN_ON(!buf->db_attach)) {
> printk(KERN_ERR "trying to pin a non attached buffer\n");
> @@ -642,12 +620,20 @@ static int vb2_dc_map_dmabuf(void *mem_priv)
> return -EINVAL;
> }
>
> + /* mapping new sglist to the client */
> + sgt->nents = dma_map_sg(b
[Bug 47708] LVDS panel does not turns off in stand-by mode
https://bugs.freedesktop.org/show_bug.cgi?id=47708 --- Comment #1 from Eugene Shalygin 2012-03-22 04:34:17 PDT --- Created attachment 58859 --> https://bugs.freedesktop.org/attachment.cgi?id=58859 Xorg log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 47708] New: LVDS panel does not turns off in stand-by mode
https://bugs.freedesktop.org/show_bug.cgi?id=47708 Bug #: 47708 Summary: LVDS panel does not turns off in stand-by mode Classification: Unclassified Product: DRI Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: eugene.shaly...@gmail.com Created attachment 58858 --> https://bugs.freedesktop.org/attachment.cgi?id=58858 dmesg When video goes into sleep mode, LVDS panel starts to show screens filled with b/w gradients and RGB colours in a cycle. In the same time a screen, connected via Display-Port goes into sleep mode correctly. This happens with and without X running. Ati drivers do not show such a behaviour. Hardware: Acer Aspire 8942g with Mobility Radeon HD 5850. Linux version 3.3 (but this happens starting with version 2.6.2x of 2.6.3x when I've tried KMS for the first time). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFCv2 PATCH 5/9] v4l: vb2: add buffer exporting via dmabuf
Hi Tomasz,
Thanks for the patch.
On Tuesday 13 March 2012 11:17:03 Tomasz Stanislawski wrote:
> This patch adds extension to videobuf2-core. It allow to export a mmap
> buffer as a file descriptor.
>
> Signed-off-by: Tomasz Stanislawski
> Signed-off-by: Kyungmin Park
> ---
> drivers/media/video/videobuf2-core.c | 64
> ++ include/media/videobuf2-core.h |
> 2 +
> 2 files changed, 66 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/video/videobuf2-core.c
> b/drivers/media/video/videobuf2-core.c index e7df560..41c4bf8 100644
> --- a/drivers/media/video/videobuf2-core.c
> +++ b/drivers/media/video/videobuf2-core.c
> @@ -1553,6 +1553,70 @@ int vb2_dqbuf(struct vb2_queue *q, struct v4l2_buffer
> *b, bool nonblocking) }
> EXPORT_SYMBOL_GPL(vb2_dqbuf);
>
> +static int __find_plane_by_offset(struct vb2_queue *q, unsigned long off,
> + unsigned int *_buffer, unsigned int *_plane);
> +
Could you please move __find_plane_by_offset() up or move vb2_expbuf() down to
avoid the forward declaration ? The later might make more sense, you could
declare vb2_expbuf() right after vb2_mmap() (here and in videobuf2-core.h),
both functions perform similar tasks.
> +/**
> + * vb2_expbuf() - Export a buffer as a file descriptor
> + * @q: videobuf2 queue
> + * @b: export buffer structure passed from userspace to
> vidioc_expbuf
> + * handler in driver
> + *
> + * The return values from this function are intended to be directly
> returned
> + * from vidioc_expbuf handler in driver.
> + */
> +int vb2_expbuf(struct vb2_queue *q, struct v4l2_exportbuffer *eb)
> +{
> + struct vb2_buffer *vb = NULL;
> + struct vb2_plane *vb_plane;
> + unsigned int buffer, plane;
> + int ret;
> + struct dma_buf *dbuf;
> +
> + if (q->memory != V4L2_MEMORY_MMAP) {
> + dprintk(1, "Queue is not currently set up for mmap\n");
> + return -EINVAL;
> + }
> +
> + if (!q->mem_ops->get_dmabuf) {
> + dprintk(1, "Queue does not support DMA buffer exporting\n");
> + return -EINVAL;
> + }
> +
> + /*
> + * Find the plane corresponding to the offset passed by userspace.
> + */
> + ret = __find_plane_by_offset(q, eb->mem_offset, &buffer, &plane);
> + if (ret) {
> + dprintk(1, "invalid offset %u\n", eb->mem_offset);
> + return ret;
> + }
> +
> + vb = q->bufs[buffer];
> + vb_plane = &vb->planes[plane];
> +
> + dbuf = call_memop(q, get_dmabuf, vb_plane->mem_priv);
> + if (IS_ERR_OR_NULL(dbuf)) {
> + dprintk(1, "Failed to export buffer %d, plane %d\n",
> + buffer, plane);
> + return -EINVAL;
> + }
> +
> + ret = dma_buf_fd(dbuf);
> + if (ret < 0) {
> + dprintk(3, "buffer %d, plane %d failed to export (%d)\n",
> + buffer, plane, ret);
> + return ret;
> + }
> +
> + dprintk(3, "buffer %d, plane %d exported as %d descriptor\n",
> + buffer, plane, ret);
> + eb->fd = ret;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(vb2_expbuf);
> +
> /**
> * __vb2_queue_cancel() - cancel and stop (pause) streaming
> *
> diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
> index 412c6a4..548252b 100644
> --- a/include/media/videobuf2-core.h
> +++ b/include/media/videobuf2-core.h
> @@ -79,6 +79,7 @@ struct vb2_mem_ops {
> void(*prepare)(void *buf_priv);
> void(*finish)(void *buf_priv);
> void(*put)(void *buf_priv);
> + struct dma_buf *(*get_dmabuf)(void *buf_priv);
>
> void*(*get_userptr)(void *alloc_ctx, unsigned long vaddr,
> unsigned long size, int write);
> @@ -348,6 +349,7 @@ int vb2_queue_init(struct vb2_queue *q);
> void vb2_queue_release(struct vb2_queue *q);
>
> int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b);
> +int vb2_expbuf(struct vb2_queue *q, struct v4l2_exportbuffer *eb);
> int vb2_dqbuf(struct vb2_queue *q, struct v4l2_buffer *b, bool
> nonblocking);
>
> int vb2_streamon(struct vb2_queue *q, enum v4l2_buf_type type);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFCv2 PATCH 4/9] v4l: add buffer exporting via dmabuf
Hi Tomasz,
Thanks for the patch.
On Tuesday 13 March 2012 11:17:02 Tomasz Stanislawski wrote:
> This patch adds extension to V4L2 api. It allow to export a mmap buffer as
> file descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset
> used by mmap and return a file descriptor on success.
I know code is more fun to write than documentation, but
Documentation/DocBook/media/v4l will be sad if this patch is merged as-is ;-)
> Signed-off-by: Tomasz Stanislawski
> Signed-off-by: Kyungmin Park
> ---
> drivers/media/video/v4l2-compat-ioctl32.c |1 +
> drivers/media/video/v4l2-ioctl.c | 11 +++
> include/linux/videodev2.h | 20
> include/media/v4l2-ioctl.h|2 ++
> 4 files changed, 34 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
> b/drivers/media/video/v4l2-compat-ioctl32.c index e6f67aa..fd157cb 100644
> --- a/drivers/media/video/v4l2-compat-ioctl32.c
> +++ b/drivers/media/video/v4l2-compat-ioctl32.c
> @@ -954,6 +954,7 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int
> cmd, unsigned long arg) case VIDIOC_S_FBUF32:
> case VIDIOC_OVERLAY32:
> case VIDIOC_QBUF32:
> + case VIDIOC_EXPBUF:
> case VIDIOC_DQBUF32:
> case VIDIOC_STREAMON32:
> case VIDIOC_STREAMOFF32:
> diff --git a/drivers/media/video/v4l2-ioctl.c
> b/drivers/media/video/v4l2-ioctl.c index 74cab51..a125016 100644
> --- a/drivers/media/video/v4l2-ioctl.c
> +++ b/drivers/media/video/v4l2-ioctl.c
> @@ -207,6 +207,7 @@ static const char *v4l2_ioctls[] = {
> [_IOC_NR(VIDIOC_S_FBUF)] = "VIDIOC_S_FBUF",
> [_IOC_NR(VIDIOC_OVERLAY)] = "VIDIOC_OVERLAY",
> [_IOC_NR(VIDIOC_QBUF)] = "VIDIOC_QBUF",
> + [_IOC_NR(VIDIOC_EXPBUF)] = "VIDIOC_EXPBUF",
> [_IOC_NR(VIDIOC_DQBUF)]= "VIDIOC_DQBUF",
> [_IOC_NR(VIDIOC_STREAMON)] = "VIDIOC_STREAMON",
> [_IOC_NR(VIDIOC_STREAMOFF)]= "VIDIOC_STREAMOFF",
> @@ -938,6 +939,16 @@ static long __video_do_ioctl(struct file *file,
> dbgbuf(cmd, vfd, p);
> break;
> }
> + case VIDIOC_EXPBUF:
> + {
> + struct v4l2_exportbuffer *p = arg;
> +
> + if (!ops->vidioc_expbuf)
> + break;
> +
> + ret = ops->vidioc_expbuf(file, fh, p);
You can pass arg to ops->vidioc_expbuf() directly, there's no need to create a
struct v4l2_exportbuffer *p variable.
> + break;
> + }
> case VIDIOC_DQBUF:
> {
> struct v4l2_buffer *p = arg;
> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> index bb6844e..e71c787 100644
> --- a/include/linux/videodev2.h
> +++ b/include/linux/videodev2.h
> @@ -680,6 +680,25 @@ struct v4l2_buffer {
> #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE0x0800
> #define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000
>
> +/**
> + * struct v4l2_exportbuffer - export of video buffer as DMABUF file
> descriptor
> + *
> + * @fd: file descriptor associated with DMABUF (set by driver)
> + * @mem_offset: for non-multiplanar buffers with memory ==
> V4L2_MEMORY_MMAP;
I don't think we will ever support exporting anything else than
V4L2_MEMORY_MMAP buffers. What will happen for multiplanar buffers ?
> + * offset from the start of the device memory for this plane,
> + * (or a "cookie" that should be passed to mmap() as offset)
> + *
Shouldn't the mem_offset field always be set to the mmap cookie value ? I'm a
bit confused by the "or" part, it seems to have been copied from the
v4l2_buffer documentation directly. We should clarify that.
> + * Contains data used for exporting a video buffer as DMABUF file
> + * descriptor. Uses the same 'cookie' as mmap() syscall. All reserved
> fields
> + * must be set to zero.
> + */
> +struct v4l2_exportbuffer {
> + __u32 fd;
> + __u32 reserved0;
Why is there a reserved field here ?
> + __u32 mem_offset;
> + __u32 reserved[13];
> +};
> +
> /*
> * O V E R L A Y P R E V I E W
> */
> @@ -2303,6 +2322,7 @@ struct v4l2_create_buffers {
> #define VIDIOC_S_FBUF _IOW('V', 11, struct v4l2_framebuffer)
> #define VIDIOC_OVERLAY_IOW('V', 14, int)
> #define VIDIOC_QBUF _IOWR('V', 15, struct v4l2_buffer)
> +#define VIDIOC_EXPBUF_IOWR('V', 16, struct v4l2_exportbuffer)
> #define VIDIOC_DQBUF _IOWR('V', 17, struct v4l2_buffer)
> #define VIDIOC_STREAMON _IOW('V', 18, int)
> #define VIDIOC_STREAMOFF _IOW('V', 19, int)
> diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
> index 4df031a..d8716c6f 100644
> --- a/include/media/v4l2-ioctl.h
> +++ b/include/media/v4l2-ioctl.h
> @@ -120,6 +120,8 @@ struct v4l2_ioctl_ops {
> int (*vidioc_reqbufs) (struct file *file, v
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #43 from Alexandre Demers 2012-03-21 21:11:41 PDT --- Created attachment 58846 --> https://bugs.freedesktop.org/attachment.cgi?id=58846 Different error message Running RenderFeatTest.bin64 with yesterday's gits still crash at the same spot, but doesn't produce the "radeon :01:00.0: offset 0x20 is in reserved area 0x80" error. GPU locks up, as you can see in the dmesg output. Once hung, I have to reset my computer to be able to use the radeon driver again, otherwise I'm running under software rendering (softpipe). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [RFCv2 PATCH 3/9] v4l: vb2: Add dma-contig allocator as dma_buf user
Hi Tomasz,
On Tuesday 13 March 2012 11:17:01 Tomasz Stanislawski wrote:
> From: Sumit Semwal
>
> This patch makes changes for adding dma-contig as a dma_buf user. It
> provides function implementations for the {attach, detach, map,
> unmap}_dmabuf() mem_ops of DMABUF memory type.
>
> Signed-off-by: Sumit Semwal
> Signed-off-by: Sumit Semwal
> [author of the original patch]
> Signed-off-by: Tomasz Stanislawski
> [integration with refactored dma-contig allocator]
> ---
> drivers/media/video/videobuf2-dma-contig.c | 116
> 1 files changed, 116 insertions(+), 0
> deletions(-)
>
> diff --git a/drivers/media/video/videobuf2-dma-contig.c
> b/drivers/media/video/videobuf2-dma-contig.c index c1dc043..746dd5f 100644
> --- a/drivers/media/video/videobuf2-dma-contig.c
> +++ b/drivers/media/video/videobuf2-dma-contig.c
> @@ -35,6 +35,9 @@ struct vb2_dc_buf {
>
> /* USERPTR related */
> struct vm_area_struct *vma;
> +
> + /* DMABUF related */
> + struct dma_buf_attachment *db_attach;
> };
>
> /*/
> @@ -485,6 +488,115 @@ fail_buf:
> }
>
> /*/
> +/* callbacks for DMABUF buffers*/
> +/*/
> +
> +static int vb2_dc_map_dmabuf(void *mem_priv)
> +{
> + struct vb2_dc_buf *buf = mem_priv;
> + struct sg_table *sgt;
> + unsigned long contig_size;
> + int ret = 0;
> +
> + if (WARN_ON(!buf->db_attach)) {
> + printk(KERN_ERR "trying to pin a non attached buffer\n");
> + return -EINVAL;
> + }
> +
> + if (WARN_ON(buf->dma_sgt)) {
> + printk(KERN_ERR "dmabuf buffer is already pinned\n");
> + return 0;
> + }
> +
> + /* get the associated scatterlist for this buffer */
> + sgt = dma_buf_map_attachment(buf->db_attach, buf->dma_dir);
> + if (IS_ERR_OR_NULL(sgt)) {
> + printk(KERN_ERR "Error getting dmabuf scatterlist\n");
> + return -EINVAL;
> + }
I've checked why dma_map_sg() was missing from here, and then remembered that
the exporter is still responsible for mapping the buffer to the importer's
device address space :-) I'll raise that topic separately.
> +
> + /* checking if dmabuf is big enough to store contiguous chunk */
> + contig_size = vb2_dc_get_contiguous_size(sgt);
> + if (contig_size < buf->size) {
> + printk(KERN_ERR "contiguous chunk of dmabuf is too small\n");
> + ret = -EFAULT;
> + goto fail_map;
> + }
> +
> + buf->dma_addr = sg_dma_address(sgt->sgl);
> + buf->dma_sgt = sgt;
> +
> + return 0;
> +
> +fail_map:
> + dma_buf_unmap_attachment(buf->db_attach, sgt);
> +
> + return ret;
> +}
> +
> +static void vb2_dc_unmap_dmabuf(void *mem_priv)
> +{
> + struct vb2_dc_buf *buf = mem_priv;
> + struct sg_table *sgt = buf->dma_sgt;
> +
> + if (WARN_ON(!buf->db_attach)) {
> + printk(KERN_ERR "trying to unpin a not attached buffer\n");
> + return;
> + }
> +
> + if (WARN_ON(!sgt)) {
> + printk(KERN_ERR "dmabuf buffer is already unpinned\n");
> + return;
> + }
> +
> + dma_buf_unmap_attachment(buf->db_attach, sgt);
> +
> + buf->dma_addr = 0;
> + buf->dma_sgt = NULL;
> +}
> +
> +static void vb2_dc_detach_dmabuf(void *mem_priv)
> +{
> + struct vb2_dc_buf *buf = mem_priv;
> +
> + if (buf->dma_addr)
> + vb2_dc_unmap_dmabuf(buf);
Can detach() be called with the buffer still mapped() ? Wouldn't that be a bug
in the caller ?
> +
> + /* detach this attachment */
> + dma_buf_detach(buf->db_attach->dmabuf, buf->db_attach);
> + kfree(buf);
> +}
There's nothing allocator-specific in the attach/detach operations. Shouldn't
they be moved to the vb2 core ?
> +
> +static void *vb2_dc_attach_dmabuf(void *alloc_ctx, struct dma_buf *dbuf,
> + unsigned long size, int write)
> +{
> + struct vb2_dc_buf *buf;
> + struct dma_buf_attachment *dba;
> +
> + if (dbuf->size < size)
> + return ERR_PTR(-EFAULT);
> +
> + buf = kzalloc(sizeof *buf, GFP_KERNEL);
> + if (!buf)
> + return ERR_PTR(-ENOMEM);
> +
> + buf->dev = alloc_ctx;
> + /* create attachment for the dmabuf with the user device */
> + dba = dma_buf_attach(dbuf, buf->dev);
> + if (IS_ERR(dba)) {
> + printk(KERN_ERR "failed to attach dmabuf\n");
> + kfree(buf);
> + return dba;
> + }
> +
> + buf->dma_dir = write ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
> + buf->size = size;
> + buf->db_attach = dba;
> +
> + return buf;
> +}
> +
> +/*/
> /* DMA CONTIG exported functions */
> /*/
>
> @@ -498,6 +610,10 @@ const struct vb2_mem_ops vb2_dma_contig_memops = {
Re: [Linaro-mm-sig] [RFCv2 PATCH 2/9 - 4/4] v4l: vb2-dma-contig: update and code refactoring
Hi Tomasz,
Thanks for the patch.
On Thursday 22 March 2012 11:02:23 Laurent Pinchart wrote:
> From: Tomasz Stanislawski
>
> This patch combines updates and fixes to dma-contig allocator.
> Moreover the allocator code was refactored.
> The most important changes are:
> - functions were reordered
> - move compression of scatterlist to separete function
> - add support for multichunk but contiguous scatterlists
> - simplified implementation of vb2-dma-contig context structure
> - let mmap method to use dma_mmap_writecombine
> - add support for scatterlist in userptr mode
>
> Signed-off-by: Marek Szyprowski
> [mmap method]
> Signed-off-by: Andrzej Pietrasiewicz
> [scatterlist in userptr mode]
> Signed-off-by: Kamil Debski
> [bugfixing]
> Signed-off-by: Tomasz Stanislawski
> [core refactoring, helper functions]
> Signed-off-by: Kyungmin Park
> ---
> drivers/media/video/videobuf2-dma-contig.c | 400
> +--- 1 files changed, 365 insertions(+), 35
> deletions(-)
>
> diff --git a/drivers/media/video/videobuf2-dma-contig.c
> b/drivers/media/video/videobuf2-dma-contig.c index c898e6f..9965465 100644
> --- a/drivers/media/video/videobuf2-dma-contig.c
> +++ b/drivers/media/video/videobuf2-dma-contig.c
> @@ -10,9 +10,12 @@
> * the Free Software Foundation.
> */
>
> +#include
> +#include
> #include
> +#include
> +#include
> #include
> -#include
>
> #include
> #include
> @@ -22,16 +25,115 @@ struct vb2_dc_buf {
> void*vaddr;
> unsigned long size;
> dma_addr_t dma_addr;
> + struct sg_table *dma_sgt;
> + enum dma_data_direction dma_dir;
>
> /* MMAP related */
> struct vb2_vmarea_handler handler;
> atomic_trefcount;
> + struct sg_table *sgt_base;
>
> /* USERPTR related */
> struct vm_area_struct *vma;
> };
>
> /*/
> +/*scatterlist table functions*/
> +/*/
> +
> +static struct sg_table *vb2_dc_pages_to_sgt(struct page **pages,
> + unsigned long n_pages, size_t offset, size_t offset2)
> +{
> + struct sg_table *sgt;
> + int i, j; /* loop counters */
> + int cur_page, chunks;
> + int ret;
> + struct scatterlist *s;
> +
> + sgt = kzalloc(sizeof *sgt, GFP_KERNEL);
> + if (!sgt)
> + return ERR_PTR(-ENOMEM);
> +
> + /* compute number of chunks */
> + chunks = 1;
> + for (i = 1; i < n_pages; ++i)
> + if (pages[i] != pages[i - 1] + 1)
> + ++chunks;
> +
> + ret = sg_alloc_table(sgt, chunks, GFP_KERNEL);
> + if (ret) {
> + kfree(sgt);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + /* merging chunks and putting them into the scatterlist */
> + cur_page = 0;
> + for_each_sg(sgt->sgl, s, sgt->orig_nents, i) {
> + size_t size = PAGE_SIZE;
> +
> + for (j = cur_page + 1; j < n_pages; ++j) {
> + if (pages[j] != pages[j - 1] + 1)
> + break;
> + size += PAGE_SIZE;
> + }
> +
> + /* cut offset if chunk starts at the first page */
> + if (cur_page == 0)
> + size -= offset;
> + /* cut offset2 if chunk ends at the last page */
> + if (j == n_pages)
> + size -= offset2;
> +
> + sg_set_page(s, pages[cur_page], size, offset);
> + offset = 0;
> + cur_page = j;
> + }
> +
> + return sgt;
> +}
> +
> +static void vb2_dc_release_sgtable(struct sg_table *sgt)
> +{
> + sg_free_table(sgt);
> + kfree(sgt);
> +}
> +
> +static void vb2_dc_put_sgtable(struct sg_table *sgt, int dirty)
> +{
> + struct scatterlist *s;
> + int i, j;
> +
> + for_each_sg(sgt->sgl, s, sgt->nents, i) {
> + struct page *page = sg_page(s);
> + int n_pages = PAGE_ALIGN(s->offset + s->length) >> PAGE_SHIFT;
> +
> + for (j = 0; j < n_pages; ++j, ++page) {
> + if (dirty)
> + set_page_dirty_lock(page);
> + put_page(page);
> + }
> + }
> +
> + vb2_dc_release_sgtable(sgt);
> +}
> +
> +static unsigned long vb2_dc_get_contiguous_size(struct sg_table *sgt)
> +{
> + struct scatterlist *s;
> + dma_addr_t expected = sg_dma_address(sgt->sgl);
> + int i;
> + unsigned long size = 0;
> +
> + for_each_sg(sgt->sgl, s, sgt->nents, i) {
> + if (sg_dma_address(s) != expected)
> + break;
> + expected = sg_dma_address(s) + sg_dma_len(s);
> + size += sg_dma_len(s);
> + }
> + return size;
> +}
> +
> +/*/
[RFCv2 PATCH 2/9 - 4/4] v4l: vb2-dma-contig: update and code refactoring
From: Tomasz Stanislawski
This patch combines updates and fixes to dma-contig allocator.
Moreover the allocator code was refactored.
The most important changes are:
- functions were reordered
- move compression of scatterlist to separete function
- add support for multichunk but contiguous scatterlists
- simplified implementation of vb2-dma-contig context structure
- let mmap method to use dma_mmap_writecombine
- add support for scatterlist in userptr mode
Signed-off-by: Marek Szyprowski
[mmap method]
Signed-off-by: Andrzej Pietrasiewicz
[scatterlist in userptr mode]
Signed-off-by: Kamil Debski
[bugfixing]
Signed-off-by: Tomasz Stanislawski
[core refactoring, helper functions]
Signed-off-by: Kyungmin Park
---
drivers/media/video/videobuf2-dma-contig.c | 400 +---
1 files changed, 365 insertions(+), 35 deletions(-)
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c
index c898e6f..9965465 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -10,9 +10,12 @@
* the Free Software Foundation.
*/
+#include
+#include
#include
+#include
+#include
#include
-#include
#include
#include
@@ -22,16 +25,115 @@ struct vb2_dc_buf {
void*vaddr;
unsigned long size;
dma_addr_t dma_addr;
+ struct sg_table *dma_sgt;
+ enum dma_data_direction dma_dir;
/* MMAP related */
struct vb2_vmarea_handler handler;
atomic_trefcount;
+ struct sg_table *sgt_base;
/* USERPTR related */
struct vm_area_struct *vma;
};
/*/
+/*scatterlist table functions*/
+/*/
+
+static struct sg_table *vb2_dc_pages_to_sgt(struct page **pages,
+ unsigned long n_pages, size_t offset, size_t offset2)
+{
+ struct sg_table *sgt;
+ int i, j; /* loop counters */
+ int cur_page, chunks;
+ int ret;
+ struct scatterlist *s;
+
+ sgt = kzalloc(sizeof *sgt, GFP_KERNEL);
+ if (!sgt)
+ return ERR_PTR(-ENOMEM);
+
+ /* compute number of chunks */
+ chunks = 1;
+ for (i = 1; i < n_pages; ++i)
+ if (pages[i] != pages[i - 1] + 1)
+ ++chunks;
+
+ ret = sg_alloc_table(sgt, chunks, GFP_KERNEL);
+ if (ret) {
+ kfree(sgt);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ /* merging chunks and putting them into the scatterlist */
+ cur_page = 0;
+ for_each_sg(sgt->sgl, s, sgt->orig_nents, i) {
+ size_t size = PAGE_SIZE;
+
+ for (j = cur_page + 1; j < n_pages; ++j) {
+ if (pages[j] != pages[j - 1] + 1)
+ break;
+ size += PAGE_SIZE;
+ }
+
+ /* cut offset if chunk starts at the first page */
+ if (cur_page == 0)
+ size -= offset;
+ /* cut offset2 if chunk ends at the last page */
+ if (j == n_pages)
+ size -= offset2;
+
+ sg_set_page(s, pages[cur_page], size, offset);
+ offset = 0;
+ cur_page = j;
+ }
+
+ return sgt;
+}
+
+static void vb2_dc_release_sgtable(struct sg_table *sgt)
+{
+ sg_free_table(sgt);
+ kfree(sgt);
+}
+
+static void vb2_dc_put_sgtable(struct sg_table *sgt, int dirty)
+{
+ struct scatterlist *s;
+ int i, j;
+
+ for_each_sg(sgt->sgl, s, sgt->nents, i) {
+ struct page *page = sg_page(s);
+ int n_pages = PAGE_ALIGN(s->offset + s->length) >> PAGE_SHIFT;
+
+ for (j = 0; j < n_pages; ++j, ++page) {
+ if (dirty)
+ set_page_dirty_lock(page);
+ put_page(page);
+ }
+ }
+
+ vb2_dc_release_sgtable(sgt);
+}
+
+static unsigned long vb2_dc_get_contiguous_size(struct sg_table *sgt)
+{
+ struct scatterlist *s;
+ dma_addr_t expected = sg_dma_address(sgt->sgl);
+ int i;
+ unsigned long size = 0;
+
+ for_each_sg(sgt->sgl, s, sgt->nents, i) {
+ if (sg_dma_address(s) != expected)
+ break;
+ expected = sg_dma_address(s) + sg_dma_len(s);
+ size += sg_dma_len(s);
+ }
+ return size;
+}
+
+/*/
/* callbacks for all buffers */
/*/
@@ -45,8 +147,6 @@ static void *vb2_dc_cookie(void *buf_priv)
static void *vb2_dc_vaddr(void *buf_priv)
{
struct vb2_dc_buf *buf = bu
[RFCv2 PATCH 2/9 - 3/4] v4l: vb2-dma-contig: Remove unneeded allocation context structure
vb2-dma-contig returns a vb2_dc_conf structure instance as the vb2
allocation context. That structure only stores a pointer to the physical
device. Remove it and use the device pointer directly as the allocation
context.
Signed-off-by: Laurent Pinchart
---
drivers/media/video/videobuf2-dma-contig.c | 29 ++-
1 files changed, 7 insertions(+), 22 deletions(-)
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c
index 6bc4651..c898e6f 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -17,12 +17,8 @@
#include
#include
-struct vb2_dc_conf {
- struct device *dev;
-};
-
struct vb2_dc_buf {
- struct vb2_dc_conf *conf;
+ struct device *dev;
void*vaddr;
unsigned long size;
dma_addr_t dma_addr;
@@ -71,7 +67,7 @@ static void vb2_dc_put(void *buf_priv)
struct vb2_dc_buf *buf = buf_priv;
if (atomic_dec_and_test(&buf->refcount)) {
- dma_free_coherent(buf->conf->dev, buf->size, buf->vaddr,
+ dma_free_coherent(buf->dev, buf->size, buf->vaddr,
buf->dma_addr);
kfree(buf);
}
@@ -79,23 +75,21 @@ static void vb2_dc_put(void *buf_priv)
static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
{
- struct vb2_dc_conf *conf = alloc_ctx;
+ struct device *dev = alloc_ctx;
struct vb2_dc_buf *buf;
buf = kzalloc(sizeof *buf, GFP_KERNEL);
if (!buf)
return ERR_PTR(-ENOMEM);
- buf->vaddr = dma_alloc_coherent(conf->dev, size, &buf->dma_addr,
- GFP_KERNEL);
+ buf->vaddr = dma_alloc_coherent(dev, size, &buf->dma_addr, GFP_KERNEL);
if (!buf->vaddr) {
- dev_err(conf->dev, "dma_alloc_coherent of size %ld failed\n",
- size);
+ dev_err(dev, "dma_alloc_coherent of size %ld failed\n", size);
kfree(buf);
return ERR_PTR(-ENOMEM);
}
- buf->conf = conf;
+ buf->dev = dev;
buf->size = size;
buf->handler.refcount = &buf->refcount;
@@ -180,21 +174,12 @@ EXPORT_SYMBOL_GPL(vb2_dma_contig_memops);
void *vb2_dma_contig_init_ctx(struct device *dev)
{
- struct vb2_dc_conf *conf;
-
- conf = kzalloc(sizeof *conf, GFP_KERNEL);
- if (!conf)
- return ERR_PTR(-ENOMEM);
-
- conf->dev = dev;
-
- return conf;
+ return dev;
}
EXPORT_SYMBOL_GPL(vb2_dma_contig_init_ctx);
void vb2_dma_contig_cleanup_ctx(void *alloc_ctx)
{
- kfree(alloc_ctx);
}
EXPORT_SYMBOL_GPL(vb2_dma_contig_cleanup_ctx);
--
1.7.3.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFCv2 PATCH 2/9 - 2/4] v4l: vb2-dma-contig: Reorder functions
Group functions by buffer type.
Signed-off-by: Laurent Pinchart
---
drivers/media/video/videobuf2-dma-contig.c | 94 ---
1 files changed, 56 insertions(+), 38 deletions(-)
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c
index 5207eb1..6bc4651 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -24,14 +24,58 @@ struct vb2_dc_conf {
struct vb2_dc_buf {
struct vb2_dc_conf *conf;
void*vaddr;
- dma_addr_t dma_addr;
unsigned long size;
- struct vm_area_struct *vma;
- atomic_trefcount;
+ dma_addr_t dma_addr;
+
+ /* MMAP related */
struct vb2_vmarea_handler handler;
+ atomic_trefcount;
+
+ /* USERPTR related */
+ struct vm_area_struct *vma;
};
-static void vb2_dc_put(void *buf_priv);
+/*/
+/* callbacks for all buffers */
+/*/
+
+static void *vb2_dc_cookie(void *buf_priv)
+{
+ struct vb2_dc_buf *buf = buf_priv;
+
+ return &buf->dma_addr;
+}
+
+static void *vb2_dc_vaddr(void *buf_priv)
+{
+ struct vb2_dc_buf *buf = buf_priv;
+ if (!buf)
+ return 0;
+
+ return buf->vaddr;
+}
+
+static unsigned int vb2_dc_num_users(void *buf_priv)
+{
+ struct vb2_dc_buf *buf = buf_priv;
+
+ return atomic_read(&buf->refcount);
+}
+
+/*/
+/*callbacks for MMAP buffers */
+/*/
+
+static void vb2_dc_put(void *buf_priv)
+{
+ struct vb2_dc_buf *buf = buf_priv;
+
+ if (atomic_dec_and_test(&buf->refcount)) {
+ dma_free_coherent(buf->conf->dev, buf->size, buf->vaddr,
+ buf->dma_addr);
+ kfree(buf);
+ }
+}
static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
{
@@ -63,40 +107,6 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned long
size)
return buf;
}
-static void vb2_dc_put(void *buf_priv)
-{
- struct vb2_dc_buf *buf = buf_priv;
-
- if (atomic_dec_and_test(&buf->refcount)) {
- dma_free_coherent(buf->conf->dev, buf->size, buf->vaddr,
- buf->dma_addr);
- kfree(buf);
- }
-}
-
-static void *vb2_dc_cookie(void *buf_priv)
-{
- struct vb2_dc_buf *buf = buf_priv;
-
- return &buf->dma_addr;
-}
-
-static void *vb2_dc_vaddr(void *buf_priv)
-{
- struct vb2_dc_buf *buf = buf_priv;
- if (!buf)
- return 0;
-
- return buf->vaddr;
-}
-
-static unsigned int vb2_dc_num_users(void *buf_priv)
-{
- struct vb2_dc_buf *buf = buf_priv;
-
- return atomic_read(&buf->refcount);
-}
-
static int vb2_dc_mmap(void *buf_priv, struct vm_area_struct *vma)
{
struct vb2_dc_buf *buf = buf_priv;
@@ -110,6 +120,10 @@ static int vb2_dc_mmap(void *buf_priv, struct
vm_area_struct *vma)
&vb2_common_vm_ops, &buf->handler);
}
+/*/
+/* callbacks for USERPTR buffers */
+/*/
+
static void *vb2_dc_get_userptr(void *alloc_ctx, unsigned long vaddr,
unsigned long size, int write)
{
@@ -148,6 +162,10 @@ static void vb2_dc_put_userptr(void *mem_priv)
kfree(buf);
}
+/*/
+/* DMA CONTIG exported functions */
+/*/
+
const struct vb2_mem_ops vb2_dma_contig_memops = {
.alloc = vb2_dc_alloc,
.put= vb2_dc_put,
--
1.7.3.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFCv2 PATCH 2/9 - 1/4] v4l: vb2-dma-contig: Shorten vb2_dma_contig prefix to vb2_dc
Signed-off-by: Laurent Pinchart
---
drivers/media/video/videobuf2-dma-contig.c | 36 ++--
1 files changed, 18 insertions(+), 18 deletions(-)
Needless to say, feel free to modify authorship information for these patches
based on the original authors.
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c
index f17ad98..5207eb1 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -31,9 +31,9 @@ struct vb2_dc_buf {
struct vb2_vmarea_handler handler;
};
-static void vb2_dma_contig_put(void *buf_priv);
+static void vb2_dc_put(void *buf_priv);
-static void *vb2_dma_contig_alloc(void *alloc_ctx, unsigned long size)
+static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
{
struct vb2_dc_conf *conf = alloc_ctx;
struct vb2_dc_buf *buf;
@@ -55,7 +55,7 @@ static void *vb2_dma_contig_alloc(void *alloc_ctx, unsigned
long size)
buf->size = size;
buf->handler.refcount = &buf->refcount;
- buf->handler.put = vb2_dma_contig_put;
+ buf->handler.put = vb2_dc_put;
buf->handler.arg = buf;
atomic_inc(&buf->refcount);
@@ -63,7 +63,7 @@ static void *vb2_dma_contig_alloc(void *alloc_ctx, unsigned
long size)
return buf;
}
-static void vb2_dma_contig_put(void *buf_priv)
+static void vb2_dc_put(void *buf_priv)
{
struct vb2_dc_buf *buf = buf_priv;
@@ -74,14 +74,14 @@ static void vb2_dma_contig_put(void *buf_priv)
}
}
-static void *vb2_dma_contig_cookie(void *buf_priv)
+static void *vb2_dc_cookie(void *buf_priv)
{
struct vb2_dc_buf *buf = buf_priv;
return &buf->dma_addr;
}
-static void *vb2_dma_contig_vaddr(void *buf_priv)
+static void *vb2_dc_vaddr(void *buf_priv)
{
struct vb2_dc_buf *buf = buf_priv;
if (!buf)
@@ -90,14 +90,14 @@ static void *vb2_dma_contig_vaddr(void *buf_priv)
return buf->vaddr;
}
-static unsigned int vb2_dma_contig_num_users(void *buf_priv)
+static unsigned int vb2_dc_num_users(void *buf_priv)
{
struct vb2_dc_buf *buf = buf_priv;
return atomic_read(&buf->refcount);
}
-static int vb2_dma_contig_mmap(void *buf_priv, struct vm_area_struct *vma)
+static int vb2_dc_mmap(void *buf_priv, struct vm_area_struct *vma)
{
struct vb2_dc_buf *buf = buf_priv;
@@ -110,7 +110,7 @@ static int vb2_dma_contig_mmap(void *buf_priv, struct
vm_area_struct *vma)
&vb2_common_vm_ops, &buf->handler);
}
-static void *vb2_dma_contig_get_userptr(void *alloc_ctx, unsigned long vaddr,
+static void *vb2_dc_get_userptr(void *alloc_ctx, unsigned long vaddr,
unsigned long size, int write)
{
struct vb2_dc_buf *buf;
@@ -137,7 +137,7 @@ static void *vb2_dma_contig_get_userptr(void *alloc_ctx,
unsigned long vaddr,
return buf;
}
-static void vb2_dma_contig_put_userptr(void *mem_priv)
+static void vb2_dc_put_userptr(void *mem_priv)
{
struct vb2_dc_buf *buf = mem_priv;
@@ -149,14 +149,14 @@ static void vb2_dma_contig_put_userptr(void *mem_priv)
}
const struct vb2_mem_ops vb2_dma_contig_memops = {
- .alloc = vb2_dma_contig_alloc,
- .put= vb2_dma_contig_put,
- .cookie = vb2_dma_contig_cookie,
- .vaddr = vb2_dma_contig_vaddr,
- .mmap = vb2_dma_contig_mmap,
- .get_userptr= vb2_dma_contig_get_userptr,
- .put_userptr= vb2_dma_contig_put_userptr,
- .num_users = vb2_dma_contig_num_users,
+ .alloc = vb2_dc_alloc,
+ .put= vb2_dc_put,
+ .cookie = vb2_dc_cookie,
+ .vaddr = vb2_dc_vaddr,
+ .mmap = vb2_dc_mmap,
+ .get_userptr= vb2_dc_get_userptr,
+ .put_userptr= vb2_dc_put_userptr,
+ .num_users = vb2_dc_num_users,
};
EXPORT_SYMBOL_GPL(vb2_dma_contig_memops);
--
1.7.3.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm main pull for 3.4-rc1
Hi Linus, now mainline has a duplicated patch set for exynos drm driver so please revert the patch below from mainline before merging with drm-next to avoid conflict. subject: drm exynos: use drm_fb_helper_set_par directly commit id: 34418c25d64844625118b5eedc493f7904d77659 this patch had already been included in Dave's drm-next. I am sorry to trouble. Thanks, Inki Dae 2012? 3? 21? ?? 7:47, Dave Airlie ?? ?: > > Hi Linus, > > This is the main drm pull request, I'm probably going to send two more > smaller ones, will explain below. > > This contains a patch that is also in the fbdev tree, but it should be the > same patch, it added an API for hot unplugging framebuffer devices, and I > need that API for a new driver. > > It also contains some changes to the i2c tree which Jean has acked, and > one change to moorestown platform stuff in x86. > > Highlights: > new drivers: UDL driver for USB displaylink devices, kms only, should > support correct hotplug operations. > core: i2c speedups + better hotplug support, EDID overriding via firmware > interface - allows user to load a firmware for a broken monitor/kvm from > userspace, it even has documentation for it. > exynos: new HDMI audio + hdmi 1.4 + virtual output driver > gma500: code cleanup > radeon: cleanups, CS optimisations, streamout support and pageflip fix > nouveau: NVD9 displayport support + more reclocking work > i915: re-enabling GMBUS, finish gpu patch (might help hibernation who > knows), missed irq fixes, stencil tiling fixes, interlaced support, > aliasesd PPGTT support for SNB/IVB, swizzling for SNB/IVB, semaphore fixes > > As well as the usual bunch of cleanups and fixes all over the place. > > I've got two things I'd like to merge a bit later: > > a) AMD support for all their new radeonhd 7000 series GPU and APUs. AMD > dropped this a bit late due to insane internal review processes, (please > AMD just follow Intel and let open source guys ship stuff early) however I > don't want to penalise people who own this hardware (since its been on > sale for 3-4 months and GPU hw doesn't exactly have a lifetime in years) > and consign them to using closed drivers for longer than necessary. The > changes are well contained and just plug into the driver new gpu > functionality so they should be fairly regression proof. I just want to > give them a bit of a run on the hw AMD kindly sent me. > > b) drm prime/dma-buf interface code. This is just infrastructure code to > expose the dma-buf stuff to drm drivers and to userspace. I'm not planning > on pushing any driver support in this cycle (except maybe exynos), but I'd > like to get the infrastructure code in so for the next cycle I can start > getting the driver support into the individual drivers. We have started > driver support for i915, nouveau and udl along with I think exynos and > omap in staging. However this code relies on the dma-buf tree being pulled > into your tree first since it needs the latest interfaces from that tree. > I'll push to get that tree sent asap. > > (oh and any warnings you see in i915 are gcc's fault from what anyone can > see). > > Regards, > Dave. > > The following changes since commit fde7d9049e55ab85a390be7f415d74c9f62dd0f9: > > ?Linux 3.3-rc7 (2012-03-10 13:49:52 -0800) > > are available in the git repository at: > ?git://people.freedesktop.org/~airlied/linux drm-next > > Adam Jackson (7): > ? ? ?drm/i915: Silence _DSM errors > ? ? ?drm/i915: Implement plane-disabled assertion for PCH too > ? ? ?drm/i915: Fix assert_pch_hdmi_disabled to mention HDMI (not DP) > ? ? ?drm/i915: Remove a comment about PCH from the non-PCH path > ? ? ?drm/i915/dp: Tweak auxch clock divider for PCH > ? ? ?drm/i915/dp: Use auxch precharge value of 5 everywhere > ? ? ?drm/i915/dp: Check for AUXCH error before checking for success > > Alan Cox (8): > ? ? ?gma500: plug in more of the gamma functionality > ? ? ?gma500: clean up some of the struct fields we no longer use > ? ? ?gma500: now move the Oaktrail save state into its own structure > ? ? ?gma500: Kconfig documentation tweak > ? ? ?gma500: re-order calling on the fix setup so we set up after the DRM > layer > ? ? ?gma500: rework register stuff sanely > ? ? ?gma500: Fix resume paths > ? ? ?gma500: suspend/resume support for Cedartrail > > Alex Deucher (19): > ? ? ?drm/radeon/kms/dce3+: add support for hw i2c using atom > ? ? ?drm/radeon/kms: add r1xx/r2xx support for CS_KEEP_TILING_FLAGS > ? ? ?drm/radeon/kms: add r1xx/r2xx CS support for tiled textures > ? ? ?drm/radeon/kms: add wait_for_vblank asic callback > ? ? ?drm/radeon/kms: add a radeon asic callback for mc idle > ? ? ?drm/radeon/kms: reorganize hpd callbacks > ? ? ?drm/radeon/kms: reorganize page flip callbacks > ? ? ?drm/radeon/kms: reorganize pm callbacks > ? ? ?drm/radeon/kms: reorganize copy callbacks > ? ? ?drm/radeon/kms: reorganize irq callbacks > ? ? ?drm/radeon/kms: remove unused cp callbacks from radeon_asic > ? ? ?drm/radeon/kms: make ring_start, ring_test, and ib_t
Re: [RFCv2 PATCH 2/9] v4l: vb2-dma-contig: update and code refactoring
Hi Tomasz, Thanks for the patch. On Tuesday 13 March 2012 11:17:00 Tomasz Stanislawski wrote: > This patch combines updates and fixes to dma-contig allocator. > Moreover the allocator code was refactored. > The most important changes are: > - functions were reordered > - move compression of scatterlist to separete function > - add support for multichunk but contiguous scatterlists > - simplified implementation of vb2-dma-contig context structure > - let mmap method to use dma_mmap_writecombine > - add support for scatterlist in userptr mode Combining all this makes it pretty difficult to review the patch. What about splitting the patch into the following ? - Function rename (s/vb2_dma_contig_/vb2_dc_/) - Code reordering - Replace custom alloc_ctx structure with direct struct device usage - The rest, possibly further split into MMAP and USERPTR changes That would make the patch easier to review. I've already split it according to the above (with the MMAP and USERPTR changes kept together as the original patch). I'll post the patches in reply to this mail, with my comments as further replies. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 42876] System doesn't boot with GTX 550 Ti
https://bugzilla.kernel.org/show_bug.cgi?id=42876 --- Comment #5 from Artyom Kunyov 2012-03-22 08:25:06 --- It worked for me as well with kernel 3.3.0, but with the wrong display resolution, and GNOME Shell was really slow. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFCv2 PATCH 1/9] v4l: vb2: fixes for DMABUF support
Hi Tomasz,
Thanks for the patch.
On Tuesday 13 March 2012 11:16:59 Tomasz Stanislawski wrote:
> This patch contains fixes to DMABUF support in vb2-core.
> - fixes number of arguments of call_memop macro
> - fixes setup of plane length
> - fixes handling of error pointers
>
> Signed-off-by: Tomasz Stanislawski
> Signed-off-by: Kyungmin Park
Tested-by: Laurent Pinchart
I suppose this will be squashed with Sumit's "[RFCv1 2/4] v4l:vb2: add support
for shared buffer (dma_buf)" patch.
> ---
> drivers/media/video/videobuf2-core.c | 24 +++-
> include/media/videobuf2-core.h |6 +++---
> 2 files changed, 14 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/media/video/videobuf2-core.c
> b/drivers/media/video/videobuf2-core.c index 951cb56..e7df560 100644
> --- a/drivers/media/video/videobuf2-core.c
> +++ b/drivers/media/video/videobuf2-core.c
> @@ -118,7 +118,7 @@ static void __vb2_buf_dmabuf_put(struct vb2_buffer *vb)
> void *mem_priv = vb->planes[plane].mem_priv;
>
> if (mem_priv) {
> - call_memop(q, plane, detach_dmabuf, mem_priv);
> + call_memop(q, detach_dmabuf, mem_priv);
> dma_buf_put(vb->planes[plane].dbuf);
> vb->planes[plane].dbuf = NULL;
> vb->planes[plane].mem_priv = NULL;
> @@ -905,6 +905,8 @@ static int __fill_vb2_buffer(struct vb2_buffer *vb,
> const struct v4l2_buffer *b, }
> if (b->memory == V4L2_MEMORY_DMABUF) {
> for (plane = 0; plane < vb->num_planes; ++plane) {
> + v4l2_planes[plane].bytesused =
> + b->m.planes[plane].bytesused;
> v4l2_planes[plane].m.fd =
> b->m.planes[plane].m.fd;
> }
> }
> @@ -1052,17 +1054,13 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb,
> const struct v4l2_buffer *b) if (IS_ERR_OR_NULL(dbuf)) {
> dprintk(1, "qbuf: invalid dmabuf fd for "
> "plane %d\n", plane);
> - ret = PTR_ERR(dbuf);
> + ret = -EINVAL;
> goto err;
> }
>
> - /* this doesn't get filled in until __fill_vb2_buffer(),
> - * since it isn't known until after dma_buf_get()..
> - */
> - planes[plane].length = dbuf->size;
> -
> /* Skip the plane if already verified */
> if (dbuf == vb->planes[plane].dbuf) {
> + planes[plane].length = dbuf->size;
> dma_buf_put(dbuf);
> continue;
> }
> @@ -1072,7 +1070,7 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const
> struct v4l2_buffer *b)
>
> /* Release previously acquired memory if present */
> if (vb->planes[plane].mem_priv) {
> - call_memop(q, plane, detach_dmabuf,
> + call_memop(q, detach_dmabuf,
> vb->planes[plane].mem_priv);
> dma_buf_put(vb->planes[plane].dbuf);
> }
> @@ -1080,8 +1078,8 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const
> struct v4l2_buffer *b) vb->planes[plane].mem_priv = NULL;
>
> /* Acquire each plane's memory */
> - mem_priv = q->mem_ops->attach_dmabuf(
> - q->alloc_ctx[plane], dbuf);
> + mem_priv = call_memop(q, attach_dmabuf, q->alloc_ctx[plane],
> + dbuf, q->plane_sizes[plane], write);
> if (IS_ERR(mem_priv)) {
> dprintk(1, "qbuf: failed acquiring dmabuf "
> "memory for plane %d\n", plane);
> @@ -1089,6 +1087,7 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const
> struct v4l2_buffer *b) goto err;
> }
>
> + planes[plane].length = dbuf->size;
> vb->planes[plane].dbuf = dbuf;
> vb->planes[plane].mem_priv = mem_priv;
> }
> @@ -1098,8 +1097,7 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const
> struct v4l2_buffer *b) * the buffer(s)..
>*/
> for (plane = 0; plane < vb->num_planes; ++plane) {
> - ret = q->mem_ops->map_dmabuf(
> - vb->planes[plane].mem_priv, write);
> + ret = call_memop(q, map_dmabuf, vb->planes[plane].mem_priv);
> if (ret) {
> dprintk(1, "qbuf: failed mapping dmabuf "
> "memory for plane %d\n", plane);
> @@ -1527,7 +1525,7 @@ int vb2_dqbuf(struct vb2_queue *q, struct v4l2_buffer
> *b, bool nonblocking) */
> if (q->memory == V4L2_MEMORY_DMABUF)
> for (plane = 0; plane < vb->num_planes; ++plane)
> - call_memop(q, plane, unmap_dmabuf,
> + call_memop(q, un
[Linaro-mm-sig] [PATCH] [RFC] dma-buf: mmap support
On Wed, Mar 21, 2012 at 03:44:38PM -0700, Rebecca Schultz Zavin wrote: > Couldn't this just as easily be handled by not having those mappings > be mapped cached or write combine to userspace? They'd be coherent, > just slow. I'm not sure we can actually say that all these cpu access > are necessary slow path operations anyway. On android we do sometimes > decide to software render things to eliminate the overhead of > maintaining a hardware context for context switching the gpu. If you > want cached or writecombine mappings you'd have to manage them > explicitly. If you can't manage them explicitly you have to settle > for slow. That seems reasonable to me. Well the usual approach is writecombine, which doesn't need any explicit cache management. > As far as I can tell with explicit operations I have to invalidate > before touching from mmap and clean after. With these implicit ones, > I stil have to invalidate and clean, but now I also have to remap them > before and after. I don't know what the performance hit of this > remapping step is, but I'd like to if you have any insight. We have a few inefficiencies in the drm/i915 fault path which makes it slow, but generally pagefault performance should be rather quick (at least quicker than flushing the actual data). At least if your fault handler is somewhat clever and prefaults a few more pages in both x and y direction. But if that's too slow, I'm open to extending dma-buf later on to support more explicit cache management for userspace mmaps (like I've explained below in my previous mail). I just think we should have real benchmark results (and hence some real users of dma-buf) before we add this complexity. Atm I have no idea whether it's worth it. After all, as soon as we expect a lot of rendering/processing, some special dsp/gpu/whatever is likely to take over. > > Imo the best way to enable cached mappings is to later on extend dma-buf > > (as soon as we have some actual exporters/importers in the mainline > > kernel) with an optional cached_mmap interface which requires explict > > prepare_mmap_access/finish_mmap_acces calls. Then if both exporter and > > importer support this, it could get used - otherwise the dma-buf layer > > could transparently fall back to coherent mappings. Yours, Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
