[Bug 49029] New: [DRM,KMS,R300,laptop]Power management not working

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49029

 Bug #: 49029
   Summary: [DRM,KMS,R300,laptop]Power management not working
Classification: Unclassified
   Product: DRI
   Version: unspecified
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: malicorne at chez.com


Created attachment 60410
  --> https://bugs.freedesktop.org/attachment.cgi?id=60410
drm output from kernel.log

Hi,
Archlinux running on a compal CL56 (radeon mobility 9700).
kernel is 3.2.11 and I can't find any file for power management :
- /sys/class/drm/card0/device/power_method doesn't exist and can't be created
- /sys/class/drm/card0/device/power_profile doesn't exist and can't be created

Please find attached drm output from kernel.log.
Apart from that it's working fine but the lack of power management reduce the
run from a battery from 4h to 1h30.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 43138] Radeon HD5450 fails to load cedar firmware ?

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=43138


Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com




--- Comment #4 from Alex Deucher   2012-04-20 
20:27:34 ---
Sounds like there's a problem with your initrd or kernel if you built the ucode
into the kernel.  This is an issue on your end.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 43138] Radeon HD5450 fails to load cedar firmware ?

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=43138





--- Comment #3 from bugtraq at hobbit.in-berlin.de  2012-04-20 19:46:24 ---
already tried fetching from http://people.freedesktop.org/~agd5f/radeon_ucode/
directly as well as installing standard Debian distri kernel & firmware
package, same error, not sure though if the numbers in the error were absolute
identical
- was some time ago, 3D accel isn't _that_ important as long as everything else
works fine, now finally got around to writing a bugreport

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 43138] Radeon HD5450 fails to load cedar firmware ?

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=43138


bugtraq at hobbit.in-berlin.de changed:

   What|Removed |Added

   Platform|All |i386




--- Comment #2 from bugtraq at hobbit.in-berlin.de  2012-04-20 19:41:40 ---
-rw-r--r-- 1 root root 5504 Jan 19 04:25 CEDAR_me.bin
-rw-r--r-- 1 root root 4480 Jan 19 04:25 CEDAR_pfp.bin
-rw-r--r-- 1 root root 3072 Jan 19 04:25 CEDAR_rlc.bin

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 48772] Signal unstable over Display Port on 2560x1440 monitor

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=48772

--- Comment #12 from Alex Deucher  2012-04-20 12:01:54 PDT 
---
Can you attach the xorg log and dmesg output with the DP monitor attached? 
What's the modeline for the 2560x1440 mode?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 2/2] drm: Drop the NV12M and YUV420M formats

[ville.syrj...@linux.intel.com]

From: Ville Syrj?l? 

The NV12M/YUV420M formats are identical to the NV12/YUV420 formats.
So just remove these duplicated format names.

This might look like breaking the ABI, but the code has never actually
accepted these formats, so nothing can be using them.

Signed-off-by: Ville Syrj?l? 
---
 include/drm/drm_fourcc.h |6 +-
 1 files changed, 1 insertions(+), 5 deletions(-)

diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index bdf0152..f462118 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -107,8 +107,7 @@
 #define DRM_FORMAT_NV16fourcc_code('N', 'V', '1', '6') /* 2x1 
subsampled Cr:Cb plane */
 #define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1 
subsampled Cb:Cr plane */

-/* 2 non contiguous plane YCbCr */
-#define DRM_FORMAT_NV12M   fourcc_code('N', 'M', '1', '2') /* 2x2 
subsampled Cr:Cb plane */
+/* special NV12 tiled format */
 #define DRM_FORMAT_NV12MT  fourcc_code('T', 'M', '1', '2') /* 2x2 
subsampled Cr:Cb plane 64x32 macroblocks */

 /*
@@ -131,7 +130,4 @@
 #define DRM_FORMAT_YUV444  fourcc_code('Y', 'U', '2', '4') /* 
non-subsampled Cb (1) and Cr (2) planes */
 #define DRM_FORMAT_YVU444  fourcc_code('Y', 'V', '2', '4') /* 
non-subsampled Cr (1) and Cb (2) planes */

-/* 3 non contiguous plane YCbCr */
-#define DRM_FORMAT_YUV420M fourcc_code('Y', 'M', '1', '2') /* 2x2 
subsampled Cb (1) and Cr (2) planes */
-
 #endif /* DRM_FOURCC_H */
-- 
1.7.3.4

[PATCH 1/2] drm: exynos: Use DRM_FORMAT_{NV12, YUV420} instead of DRM_FORMAT_{NV12M, YUV420M}

[ville.syrj...@linux.intel.com]

From: Ville Syrj?l? 

The NV12M/YUV420M formats are identical to the already existing standard
NV12/YUV420 formats. The M variants will be removed, so convert the
driver to use the standard names.

Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Signed-off-by: Ville Syrj?l? 
---
Extra note: Based on a quick look, the driver appears to lack
sufficient sanity checks wrt. the framebuffer layout. I guess it
just assumes that handles[0] != handles[1] and offsets[] = { 0 }.

 drivers/gpu/drm/exynos/exynos_drm_fb.h |4 ++--
 drivers/gpu/drm/exynos/exynos_mixer.c  |2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.h 
b/drivers/gpu/drm/exynos/exynos_drm_fb.h
index 3ecb30d..5082375 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.h
@@ -31,10 +31,10 @@
 static inline int exynos_drm_format_num_buffers(uint32_t format)
 {
switch (format) {
-   case DRM_FORMAT_NV12M:
+   case DRM_FORMAT_NV12:
case DRM_FORMAT_NV12MT:
return 2;
-   case DRM_FORMAT_YUV420M:
+   case DRM_FORMAT_YUV420:
return 3;
default:
return 1;
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 4d5f41e..f1e2369 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -370,7 +370,7 @@ static void vp_video_buffer(struct mixer_context *ctx, int 
win)
switch (win_data->pixel_format) {
case DRM_FORMAT_NV12MT:
tiled_mode = true;
-   case DRM_FORMAT_NV12M:
+   case DRM_FORMAT_NV12:
crcb_mode = false;
buf_num = 2;
break;
-- 
1.7.3.4

[PATCH 0/1] [RFC] DRM locking issues during early open

[Andy Whitcroft]

On Fri, Apr 20, 2012 at 11:34:43AM +0100, Dave Airlie wrote:
> >
> > I may be reading things wrong but the initialisation does indeed hold
> > drm_global_mutex, but and back when this first occured we would have
> > been using kernel_lock() which was at least partially reentrant right?
> 
> Yup if we slept with the BKL held we'd have allowed others to get past it,
> but also I introduced the global mutex in pci a while back

Yeah I have managed to get access to more details on the bug, and
actually we are opening the drm device successfully, we then attempt a
DRM_SETVERSION ioctl on it and it is that that appears to fail both for
1.4 and 1.1.

It is somewhat perplexing to understand how that is possible, though I
will note that the stub f_ops do not contain an ioctl op but I cannot
see any mechanism by which we might return a validly open file without
putting the driver specific ops in it.

-apw

[PATCH 3/7] DRM: add sdrm layer for general embedded system support

[Sascha Hauer]

On Fri, Apr 20, 2012 at 03:25:58PM +0100, Mark Brown wrote:
> On Fri, Apr 20, 2012 at 02:38:43PM +0200, Thierry Reding wrote:
> > * Dave Airlie wrote:
> > > I get the feeling the drm can just be a virtual platform device of
> > > some sort, then it reads the device tree and binds all the information
> > > on what crtc/encoders are available,
> 
> > That's pretty much what I've come up with in the second round of Tegra DRM
> > patches. Basically display controllers and outputs (RGB, HDMI, TVO, DSI) get
> > separate drivers and register themselves with the DRM driver which then 
> > looks
> > at the device tree to see which display controllers to register as CRTCs and
> > parses a list of connector nodes to create encoder/connector pairs that
> > define the physical connectors and their corresponding outputs.
> 
> > I did take a brief look at the SDRM patches as well and they didn't quite
> > seem to fit what was needed for Tegra. But if time allows I'll take a closer
> > look.
> 
> This sounds an awful lot like how ASoC hangs together...

Very much, yes. In ASoC and DRM we both have several physical devices spread
around the SoC which form a logical device. I assume that before ASoC existed
also everyone had a single PCI device which could be used to collect the
information together.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[PATCH 3/7] DRM: add sdrm layer for general embedded system support

[Thierry Reding]

* Mark Brown wrote:
> On Fri, Apr 20, 2012 at 04:49:43PM +0200, Thierry Reding wrote:
> > * Mark Brown wrote:
> 
> > > This sounds an awful lot like how ASoC hangs together...
> 
> > What in particular sounds awful?
> 
> Nothing - "an awful" is an English idiom for "very".

I know =) But it has a somewhat negative connotation, from which I deduced
that you somehow thought it wasn't a good solution.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120420/0367c77e/attachment.pgp>

state of drm next

[Alex Deucher]

On Fri, Apr 20, 2012 at 8:27 AM, Dave Airlie  wrote:
> Hi,
>
> So I've spent today trawling and most likely missing patches on the
> list for -next.
>
> -next before today had:
> an intel -next from Daniel
> radeon - copy optimisation, pci bus master race fix.
> two agp patches
>
> I've merged today into drm-core-next
> Ville's framebuffer creation sanity check series
> Paulo's CEA/EDID patches that touch core (I think there are two i915
> patches that can come via Daniel).
> Lars-Peter Clausen: CEA/EDID patches
> Ajax's: DMT modes adding patches
>
> I've also got in -next:
> mjg59's work on multiple gpu with EFI interactions, I'll push to
> -core-next once it stops breaking builds on misc arches!
>
> So feel free to point me at anything I've missed or haven't commented
> on, and everyone keep reviewing everyone else's stuff as a path to
> success, as I'm busy!!

Can you pick the following patches?
http://lists.freedesktop.org/archives/dri-devel/2012-March/020577.html
http://lists.freedesktop.org/archives/dri-devel/2012-March/020717.html
http://lists.freedesktop.org/archives/dri-devel/2012-March/020855.html

There's also this one which needs a bit more work:
http://people.freedesktop.org/~agd5f/0001-WIP-port-of-hdmi-dp-audio-code-to-newer-kernel.patch

Alex

>
> Dave.
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/7] DRM: add sdrm layer for general embedded system support

[Thierry Reding]

* Mark Brown wrote:
> On Fri, Apr 20, 2012 at 02:38:43PM +0200, Thierry Reding wrote:
> > * Dave Airlie wrote:
> > > I get the feeling the drm can just be a virtual platform device of
> > > some sort, then it reads the device tree and binds all the information
> > > on what crtc/encoders are available,
> 
> > That's pretty much what I've come up with in the second round of Tegra DRM
> > patches. Basically display controllers and outputs (RGB, HDMI, TVO, DSI) get
> > separate drivers and register themselves with the DRM driver which then 
> > looks
> > at the device tree to see which display controllers to register as CRTCs and
> > parses a list of connector nodes to create encoder/connector pairs that
> > define the physical connectors and their corresponding outputs.
> 
> > I did take a brief look at the SDRM patches as well and they didn't quite
> > seem to fit what was needed for Tegra. But if time allows I'll take a closer
> > look.
> 
> This sounds an awful lot like how ASoC hangs together...

What in particular sounds awful?

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120420/a3a3e867/attachment.pgp>

[PATCH 1/4] drm: Move drm_format_num_planes() to drm_crtc.c

[Ville Syrjälä]

On Fri, Apr 20, 2012 at 07:48:07AM -0500, Rob Clark wrote:
> On Fri, Apr 20, 2012 at 7:29 AM, Dave Airlie  wrote:
> > On Fri, Apr 20, 2012 at 1:23 PM, Ville Syrj?l?
> >  wrote:
> >> On Fri, Apr 20, 2012 at 12:43:03PM +0100, Dave Airlie wrote:
> >>> On Thu, Apr 5, 2012 at 7:35 PM, ? wrote:
> >>> > From: Ville Syrj?l? 
> >>> >
> >>> > There will be a need for this function in drm_crtc.c later. This
> >>> > avoids making drm_crtc.c depend on drm_crtc_helper.c.
> >>>
> >>> Hi Ville,
> >>>
> >>> I've applied these 4 patches, but I might have lost some others for
> >>> you, let me know if there is some other stuff I should be reviewing
> >>> for -next.
> >>
> >> IIRC only one patch fell through the cracks:
> >> Subject: [PATCH] drm: Unify and fix idr error handling
> >> Message-Id: <1331834311-30757-1-git-send-email-ville.syrjala at 
> >> linux.intel.com>
> >
> > Thanks I'll take a look at that,
> >
> >>
> >> BTW you never gave any statement wrt. removing NV12M and YUV420M from
> >> drm_fourcc.h. I can send a patch if you agree, and if not, well then
> >> someone has to actually change the code to treat them exactly the same
> >> as NV12 and YUV420.
> >
> > I'm probably not qualified, if you and jbarnes and say one other
> > non-Intel person agree, then send the patch with R-b and I'll apply
> > it.
> 
> I agree that they seem like the same thing (as their non-M
> counterparts) to me..  maybe the one exception is if there was hw that
> somehow *only* supported discontiguous multi-planar.

The way things are currently, anyone can feed the driver either
contiguous or discontiguous planes using either format.

As a hint to userspace the M version might work, except it still
doesn't tell you anything on how you need to allocate or align the
planes. Since memory allocation is driver specific anyway, I see no
point in overloading the pixel formats with that information. Some
other mechanism to communicate such information would be needed if
there is a desire to make it generic.

> I can't really
> tell if this is the case in current exynos, it seems to only advertise
> XRGB (but possibly I'm looking in the wrong place).
> 
> For drivers that have weird requirements, I'd suggest they use the non
> 7-bit ascii space (ie. one or more of bytes in fourcc is non-ascii, so
> as to not conflict with potential future standard fourcc's) driver
> specific format values.

We could define a DRM_FORMAT_DRIVER_SPECIFIC bit just like we have
DRM_FORMAT_BIG_ENDIAN. We still have three bits to choose from. OTOH
I'm not too worried about standard fourccs since we already differ
from the standard names anyway.

-- 
Ville Syrj?l?
Intel OTC

[PATCHv5 13/13] v4l: s5p-fimc: support for dmabuf importing

[Tomasz Stanislawski]

This patch enhances s5p-fimc with support for DMABUF importing via
V4L2_MEMORY_DMABUF memory type.

Signed-off-by: Tomasz Stanislawski 
Signed-off-by: Kyungmin Park 
Acked-by: Sylwester Nawrocki 
---
 drivers/media/video/Kconfig |1 +
 drivers/media/video/s5p-fimc/fimc-capture.c |2 +-
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index f2479c5..9de9ddc 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -1133,6 +1133,7 @@ config  VIDEO_SAMSUNG_S5P_FIMC
VIDEO_V4L2_SUBDEV_API && EXPERIMENTAL
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
+   select DMA_SHARED_BUFFER
---help---
  This is a v4l2 driver for Samsung S5P and EXYNOS4 camera
  host interface and video postprocessor.
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c 
b/drivers/media/video/s5p-fimc/fimc-capture.c
index b06efd2..38fb39e 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -1530,7 +1530,7 @@ int fimc_register_capture_device(struct fimc_dev *fimc,
q = >vid_cap.vbq;
memset(q, 0, sizeof(*q));
q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
-   q->io_modes = VB2_MMAP | VB2_USERPTR;
+   q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF;
q->drv_priv = fimc->vid_cap.ctx;
q->ops = _capture_qops;
q->mem_ops = _dma_contig_memops;
-- 
1.7.5.4

[PATCHv5 12/13] v4l: s5p-tv: mixer: support for dmabuf importing

[Tomasz Stanislawski]

This patch enhances s5p-tv with support for DMABUF importing via
V4L2_MEMORY_DMABUF memory type.

Signed-off-by: Tomasz Stanislawski 
Signed-off-by: Kyungmin Park 
---
 drivers/media/video/s5p-tv/Kconfig   |1 +
 drivers/media/video/s5p-tv/mixer_video.c |2 +-
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/s5p-tv/Kconfig 
b/drivers/media/video/s5p-tv/Kconfig
index f248b28..2e80126 100644
--- a/drivers/media/video/s5p-tv/Kconfig
+++ b/drivers/media/video/s5p-tv/Kconfig
@@ -10,6 +10,7 @@ config VIDEO_SAMSUNG_S5P_TV
bool "Samsung TV driver for S5P platform (experimental)"
depends on PLAT_S5P && PM_RUNTIME
depends on EXPERIMENTAL
+   select DMA_SHARED_BUFFER
default n
---help---
  Say Y here to enable selecting the TV output devices for
diff --git a/drivers/media/video/s5p-tv/mixer_video.c 
b/drivers/media/video/s5p-tv/mixer_video.c
index f7ca5cc..6b45d93 100644
--- a/drivers/media/video/s5p-tv/mixer_video.c
+++ b/drivers/media/video/s5p-tv/mixer_video.c
@@ -1074,7 +1074,7 @@ struct mxr_layer *mxr_base_layer_create(struct mxr_device 
*mdev,

layer->vb_queue = (struct vb2_queue) {
.type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
-   .io_modes = VB2_MMAP | VB2_USERPTR,
+   .io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF,
.drv_priv = layer,
.buf_struct_size = sizeof(struct mxr_buffer),
.ops = _video_qops,
-- 
1.7.5.4

[PATCHv5 11/13] v4l: vb2-dma-contig: add support for dma_buf importing

[Tomasz Stanislawski]

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]
Acked-by: Laurent Pinchart 
---
 drivers/media/video/videobuf2-dma-contig.c |  113 
 1 files changed, 113 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/videobuf2-dma-contig.c 
b/drivers/media/video/videobuf2-dma-contig.c
index 93f86a0..5cf3107 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -10,6 +10,7 @@
  * the Free Software Foundation.
  */

+#include 
 #include 
 #include 
 #include 
@@ -33,6 +34,9 @@ struct vb2_dc_buf {

/* USERPTR related */
struct vm_area_struct   *vma;
+
+   /* DMABUF related */
+   struct dma_buf_attachment   *db_attach;
 };

 /*/
@@ -422,6 +426,111 @@ 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;
+
+   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;
+   }
+
+   /* 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 is too small %lu/%lu b\n",
+   contig_size, buf->size);
+   dma_buf_unmap_attachment(buf->db_attach, sgt, buf->dma_dir);
+   return -EFAULT;
+   }
+
+   buf->dma_addr = sg_dma_address(sgt->sgl);
+   buf->dma_sgt = sgt;
+
+   return 0;
+}
+
+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_dir);
+
+   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 vb2 works correctly you should never detach mapped buffer */
+   if (WARN_ON(buf->dma_addr))
+   vb2_dc_unmap_dmabuf(buf);
+
+   /* detach this attachment */
+   dma_buf_detach(buf->db_attach->dmabuf, buf->db_attach);
+   kfree(buf);
+}
+
+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   */
 /*/

@@ -435,6 +544,10 @@ const struct vb2_mem_ops vb2_dma_contig_memops = {
.put_userptr= vb2_dc_put_userptr,
.prepare= vb2_dc_prepare,
.finish = vb2_dc_finish,
+   .map_dmabuf = vb2_dc_map_dmabuf,
+   .unmap_dmabuf   = vb2_dc_unmap_dmabuf,
+   .attach_dmabuf  = vb2_dc_attach_dmabuf,
+   .detach_dmabuf  = vb2_dc_detach_dmabuf,
.num_users  = vb2_dc_num_users,
 };
 EXPORT_SYMBOL_GPL(vb2_dma_contig_memops);

[PATCHv5 10/13] v4l: vb2-dma-contig: add prepare/finish to dma-contig allocator

[Tomasz Stanislawski]

From: Marek Szyprowski 

Add prepare/finish callbacks to vb2-dma-contig allocator.

Signed-off-by: Marek Szyprowski 
---
 drivers/media/video/videobuf2-dma-contig.c |   24 
 1 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/videobuf2-dma-contig.c 
b/drivers/media/video/videobuf2-dma-contig.c
index 9cbc8d4..93f86a0 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -149,6 +149,28 @@ static unsigned int vb2_dc_num_users(void *buf_priv)
return atomic_read(>refcount);
 }

+static void vb2_dc_prepare(void *buf_priv)
+{
+   struct vb2_dc_buf *buf = buf_priv;
+   struct sg_table *sgt = buf->dma_sgt;
+
+   if (!sgt)
+   return;
+
+   dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->nents, buf->dma_dir);
+}
+
+static void vb2_dc_finish(void *buf_priv)
+{
+   struct vb2_dc_buf *buf = buf_priv;
+   struct sg_table *sgt = buf->dma_sgt;
+
+   if (!sgt)
+   return;
+
+   dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->nents, buf->dma_dir);
+}
+
 /*/
 /*callbacks for MMAP buffers */
 /*/
@@ -411,6 +433,8 @@ const struct vb2_mem_ops vb2_dma_contig_memops = {
.mmap   = vb2_dc_mmap,
.get_userptr= vb2_dc_get_userptr,
.put_userptr= vb2_dc_put_userptr,
+   .prepare= vb2_dc_prepare,
+   .finish = vb2_dc_finish,
.num_users  = vb2_dc_num_users,
 };
 EXPORT_SYMBOL_GPL(vb2_dma_contig_memops);
-- 
1.7.5.4

[PATCHv5 09/13] v4l: vb2: add prepare/finish callbacks to allocators

[Tomasz Stanislawski]

From: Marek Szyprowski 

This patch adds support for prepare/finish callbacks in VB2 allocators. These
callback are used for buffer flushing.

Signed-off-by: Marek Szyprowski 
Acked-by: Laurent Pinchart 
---
 drivers/media/video/videobuf2-core.c |   11 +++
 include/media/videobuf2-core.h   |7 +++
 2 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/videobuf2-core.c 
b/drivers/media/video/videobuf2-core.c
index d26b1cc..b431dc6 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -842,6 +842,7 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
vb2_buffer_state state)
 {
struct vb2_queue *q = vb->vb2_queue;
unsigned long flags;
+   unsigned int plane;

if (vb->state != VB2_BUF_STATE_ACTIVE)
return;
@@ -852,6 +853,10 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
vb2_buffer_state state)
dprintk(4, "Done processing on buffer %d, state: %d\n",
vb->v4l2_buf.index, vb->state);

+   /* sync buffers */
+   for (plane = 0; plane < vb->num_planes; ++plane)
+   call_memop(q, finish, vb->planes[plane].mem_priv);
+
/* Add the buffer to the done buffers list */
spin_lock_irqsave(>done_lock, flags);
vb->state = state;
@@ -1134,9 +1139,15 @@ err:
 static void __enqueue_in_driver(struct vb2_buffer *vb)
 {
struct vb2_queue *q = vb->vb2_queue;
+   unsigned int plane;

vb->state = VB2_BUF_STATE_ACTIVE;
atomic_inc(>queued_count);
+
+   /* sync buffers */
+   for (plane = 0; plane < vb->num_planes; ++plane)
+   call_memop(q, prepare, vb->planes[plane].mem_priv);
+
q->ops->buf_queue(vb);
 }

diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 859bbaf..d079f92 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -56,6 +56,10 @@ struct vb2_fileio_data;
  * dmabuf
  * @unmap_dmabuf: releases access control to the dmabuf - allocator is notified
  *   that this driver is done using the dmabuf for now
+ * @prepare:   called everytime the buffer is passed from userspace to the
+ * driver, usefull for cache synchronisation, optional
+ * @finish:called everytime the buffer is passed back from the driver
+ * to the userspace, also optional
  * @vaddr: return a kernel virtual address to a given memory buffer
  * associated with the passed private structure or NULL if no
  * such mapping exists
@@ -82,6 +86,9 @@ struct vb2_mem_ops {
unsigned long size, int write);
void(*put_userptr)(void *buf_priv);

+   void(*prepare)(void *buf_priv);
+   void(*finish)(void *buf_priv);
+
void*(*attach_dmabuf)(void *alloc_ctx, struct dma_buf *dbuf,
unsigned long size, int write);
void(*detach_dmabuf)(void *buf_priv);
-- 
1.7.5.4

[PATCHv5 08/13] v4l: vb2-dma-contig: add support for scatterlist in userptr mode

[Tomasz Stanislawski]

From: Andrzej Pietrasiewicz 

This patch introduces usage of dma_map_sg to map memory behind
a userspace pointer to a device as dma-contiguous mapping.

Signed-off-by: Andrzej Pietrasiewicz 
Signed-off-by: Marek Szyprowski 
[bugfixing]
Signed-off-by: Kamil Debski 
[bugfixing]
Signed-off-by: Tomasz Stanislawski 
[add sglist subroutines/code refactoring]
Signed-off-by: Kyungmin Park 
---
 drivers/media/video/videobuf2-dma-contig.c |  279 ++--
 1 files changed, 262 insertions(+), 17 deletions(-)

diff --git a/drivers/media/video/videobuf2-dma-contig.c 
b/drivers/media/video/videobuf2-dma-contig.c
index 476e536..9cbc8d4 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -11,6 +11,8 @@
  */

 #include 
+#include 
+#include 
 #include 
 #include 

@@ -22,6 +24,8 @@ struct vb2_dc_buf {
void*vaddr;
unsigned long   size;
dma_addr_t  dma_addr;
+   enum dma_data_direction dma_dir;
+   struct sg_table *dma_sgt;

/* MMAP related */
struct vb2_vmarea_handler   handler;
@@ -32,6 +36,95 @@ struct vb2_dc_buf {
 };

 /*/
+/*scatterlist table functions*/
+/*/
+
+static struct sg_table *vb2_dc_pages_to_sgt(struct page **pages,
+   unsigned int n_pages, unsigned long offset, unsigned long size)
+{
+   struct sg_table *sgt;
+   unsigned int chunks;
+   unsigned int i;
+   unsigned int cur_page;
+   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) {
+   unsigned long chunk_size;
+   unsigned int j;
+
+   for (j = cur_page + 1; j < n_pages; ++j)
+   if (pages[j] != pages[j - 1] + 1)
+   break;
+
+   chunk_size = ((j - cur_page) << PAGE_SHIFT) - offset;
+   sg_set_page(s, pages[cur_page], min(size, chunk_size), offset);
+   size -= chunk_size;
+   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_sgt_foreach_page(struct sg_table *sgt,
+   void (*cb)(struct page *pg))
+{
+   struct scatterlist *s;
+   unsigned int i;
+
+   for_each_sg(sgt->sgl, s, sgt->nents, i) {
+   struct page *page = sg_page(s);
+   unsigned int n_pages = PAGE_ALIGN(s->offset + s->length)
+   >> PAGE_SHIFT;
+   unsigned int j;
+
+   for (j = 0; j < n_pages; ++j, ++page)
+   cb(page);
+   }
+}
+
+static unsigned long vb2_dc_get_contiguous_size(struct sg_table *sgt)
+{
+   struct scatterlist *s;
+   dma_addr_t expected = sg_dma_address(sgt->sgl);
+   unsigned 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 */
 /*/

@@ -116,42 +209,194 @@ static int vb2_dc_mmap(void *buf_priv, struct 
vm_area_struct *vma)
 /*   callbacks for USERPTR buffers   */
 /*/

+static inline int vma_is_io(struct vm_area_struct *vma)
+{
+   return !!(vma->vm_flags & (VM_IO | VM_PFNMAP));
+}
+
+static struct vm_area_struct *vb2_dc_get_user_vma(
+   unsigned long start, unsigned long size)
+{
+   struct vm_area_struct *vma;
+
+   /* current->mm->mmap_sem is taken by videobuf2 core */
+   vma = find_vma(current->mm, start);
+   if (!vma) {
+   printk(KERN_ERR "no vma for address %lu\n", start);
+   return ERR_PTR(-EFAULT);
+   }
+
+   if (vma->vm_end - vma->vm_start < size) {
+   printk(KERN_ERR "vma at %lu is too small for %lu bytes\n",
+   start, size);
+   return ERR_PTR(-EFAULT);

[PATCHv5 07/13] v4l: vb2-dma-contig: Reorder functions

[Tomasz Stanislawski]

From: Laurent Pinchart 

Group functions by buffer type.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/video/videobuf2-dma-contig.c |   92 ---
 1 files changed, 54 insertions(+), 38 deletions(-)

diff --git a/drivers/media/video/videobuf2-dma-contig.c 
b/drivers/media/video/videobuf2-dma-contig.c
index ff0a662..476e536 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -20,14 +20,56 @@
 struct vb2_dc_buf {
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;
+
+   /* 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 >dma_addr;
+}
+
+static void *vb2_dc_vaddr(void *buf_priv)
+{
+   struct vb2_dc_buf *buf = buf_priv;
+
+   return buf->vaddr;
+}
+
+static unsigned int vb2_dc_num_users(void *buf_priv)
+{
+   struct vb2_dc_buf *buf = buf_priv;
+
+   return atomic_read(>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(>refcount))
+   return;
+
+   dma_free_coherent(buf->dev, buf->size, buf->vaddr, buf->dma_addr);
+   kfree(buf);
+}

 static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
 {
@@ -57,40 +99,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(>refcount)) {
-   dma_free_coherent(buf->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 >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(>refcount);
-}
-
 static int vb2_dc_mmap(void *buf_priv, struct vm_area_struct *vma)
 {
struct vb2_dc_buf *buf = buf_priv;
@@ -104,6 +112,10 @@ static int vb2_dc_mmap(void *buf_priv, struct 
vm_area_struct *vma)
  _common_vm_ops, >handler);
 }

+/*/
+/*   callbacks for USERPTR buffers   */
+/*/
+
 static void *vb2_dc_get_userptr(void *alloc_ctx, unsigned long vaddr,
unsigned long size, int write)
 {
@@ -142,6 +154,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.5.4

[PATCHv5 06/13] v4l: vb2-dma-contig: Remove unneeded allocation context structure

[Tomasz Stanislawski]

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: Tomasz Stanislawski 
Acked-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 5207eb1..ff0a662 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;
dma_addr_t  dma_addr;
unsigned long   size;
@@ -35,23 +31,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, >dma_addr,
-   GFP_KERNEL);
+   buf->vaddr = dma_alloc_coherent(dev, size, >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 = >refcount;
@@ -68,7 +62,7 @@ static void vb2_dc_put(void *buf_priv)
struct vb2_dc_buf *buf = buf_priv;

if (atomic_dec_and_test(>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);
}
@@ -162,21 +156,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.5.4

[PATCHv5 05/13] v4l: vb2-dma-contig: Shorten vb2_dma_contig prefix to vb2_dc

[Tomasz Stanislawski]

From: Laurent Pinchart 

Signed-off-by: Laurent Pinchart 
---
 drivers/media/video/videobuf2-dma-contig.c |   36 ++--
 1 files changed, 18 insertions(+), 18 deletions(-)

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 = >refcount;
-   buf->handler.put = vb2_dma_contig_put;
+   buf->handler.put = vb2_dc_put;
buf->handler.arg = buf;

atomic_inc(>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 >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(>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)
  _common_vm_ops, >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.5.4

[PATCHv5 04/13] v4l: vb: remove warnings about MEMORY_DMABUF

[Tomasz Stanislawski]

From: Sumit Semwal 

Adding DMABUF memory type causes videobuf to complain about not using it
in some switch cases. This patch removes these warnings.

Signed-off-by: Sumit Semwal 
Acked-by: Laurent Pinchart 
---
 drivers/media/video/videobuf-core.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/videobuf-core.c 
b/drivers/media/video/videobuf-core.c
index de4fa4e..b457c8b 100644
--- a/drivers/media/video/videobuf-core.c
+++ b/drivers/media/video/videobuf-core.c
@@ -335,6 +335,9 @@ static void videobuf_status(struct videobuf_queue *q, 
struct v4l2_buffer *b,
case V4L2_MEMORY_OVERLAY:
b->m.offset  = vb->boff;
break;
+   case V4L2_MEMORY_DMABUF:
+   /* DMABUF is not handled in videobuf framework */
+   break;
}

b->flags= 0;
@@ -411,6 +414,7 @@ int __videobuf_mmap_setup(struct videobuf_queue *q,
break;
case V4L2_MEMORY_USERPTR:
case V4L2_MEMORY_OVERLAY:
+   case V4L2_MEMORY_DMABUF:
/* nothing */
break;
}
-- 
1.7.5.4

[PATCHv5 03/13] v4l: vb2: add support for shared buffer (dma_buf)

[Tomasz Stanislawski]

From: Sumit Semwal 

This patch adds support for DMABUF memory type in videobuf2. It calls relevant
APIs of dma_buf for v4l reqbuf / qbuf / dqbuf operations.

For this version, the support is for videobuf2 as a user of the shared buffer;
so the allocation of the buffer is done outside of V4L2. [A sample allocator of
dma-buf shared buffer is given at [1]]

[1]: Rob Clark's DRM:
   https://github.com/robclark/kernel-omap4/commits/drmplane-dmabuf

Signed-off-by: Tomasz Stanislawski 
   [original work in the PoC for buffer sharing]
Signed-off-by: Sumit Semwal 
Signed-off-by: Sumit Semwal 
Acked-by: Laurent Pinchart 
---
 drivers/media/video/videobuf2-core.c |  196 +-
 include/media/videobuf2-core.h   |   27 +
 2 files changed, 219 insertions(+), 4 deletions(-)

diff --git a/drivers/media/video/videobuf2-core.c 
b/drivers/media/video/videobuf2-core.c
index 2e8f1df..d26b1cc 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -106,6 +106,36 @@ static void __vb2_buf_userptr_put(struct vb2_buffer *vb)
 }

 /**
+ * __vb2_plane_dmabuf_put() - release memory associated with
+ * a DMABUF shared plane
+ */
+static void __vb2_plane_dmabuf_put(struct vb2_queue *q, struct vb2_plane *p)
+{
+   if (!p->mem_priv)
+   return;
+
+   if (p->dbuf_mapped)
+   call_memop(q, unmap_dmabuf, p->mem_priv);
+
+   call_memop(q, detach_dmabuf, p->mem_priv);
+   dma_buf_put(p->dbuf);
+   memset(p, 0, sizeof *p);
+}
+
+/**
+ * __vb2_buf_dmabuf_put() - release memory associated with
+ * a DMABUF shared buffer
+ */
+static void __vb2_buf_dmabuf_put(struct vb2_buffer *vb)
+{
+   struct vb2_queue *q = vb->vb2_queue;
+   unsigned int plane;
+
+   for (plane = 0; plane < vb->num_planes; ++plane)
+   __vb2_plane_dmabuf_put(q, >planes[plane]);
+}
+
+/**
  * __setup_offsets() - setup unique offsets ("cookies") for every plane in
  * every buffer on the queue
  */
@@ -227,6 +257,8 @@ static void __vb2_free_mem(struct vb2_queue *q, unsigned 
int buffers)
/* Free MMAP buffers or release USERPTR buffers */
if (q->memory == V4L2_MEMORY_MMAP)
__vb2_buf_mem_free(vb);
+   else if (q->memory == V4L2_MEMORY_DMABUF)
+   __vb2_buf_dmabuf_put(vb);
else
__vb2_buf_userptr_put(vb);
}
@@ -349,6 +381,12 @@ static int __fill_v4l2_buffer(struct vb2_buffer *vb, 
struct v4l2_buffer *b)
 */
memcpy(b->m.planes, vb->v4l2_planes,
b->length * sizeof(struct v4l2_plane));
+
+   if (q->memory == V4L2_MEMORY_DMABUF) {
+   unsigned int plane;
+   for (plane = 0; plane < vb->num_planes; ++plane)
+   b->m.planes[plane].m.fd = 0;
+   }
} else {
/*
 * We use length and offset in v4l2_planes array even for
@@ -360,6 +398,8 @@ static int __fill_v4l2_buffer(struct vb2_buffer *vb, struct 
v4l2_buffer *b)
b->m.offset = vb->v4l2_planes[0].m.mem_offset;
else if (q->memory == V4L2_MEMORY_USERPTR)
b->m.userptr = vb->v4l2_planes[0].m.userptr;
+   else if (q->memory == V4L2_MEMORY_DMABUF)
+   b->m.fd = 0;
}

/*
@@ -451,6 +491,20 @@ static int __verify_mmap_ops(struct vb2_queue *q)
 }

 /**
+ * __verify_dmabuf_ops() - verify that all memory operations required for
+ * DMABUF queue type have been provided
+ */
+static int __verify_dmabuf_ops(struct vb2_queue *q)
+{
+   if (!(q->io_modes & VB2_DMABUF) || !q->mem_ops->attach_dmabuf ||
+   !q->mem_ops->detach_dmabuf  || !q->mem_ops->map_dmabuf ||
+   !q->mem_ops->unmap_dmabuf)
+   return -EINVAL;
+
+   return 0;
+}
+
+/**
  * vb2_reqbufs() - Initiate streaming
  * @q: videobuf2 queue
  * @req:   struct passed from userspace to vidioc_reqbufs handler in driver
@@ -483,8 +537,9 @@ int vb2_reqbufs(struct vb2_queue *q, struct 
v4l2_requestbuffers *req)
return -EBUSY;
}

-   if (req->memory != V4L2_MEMORY_MMAP
-   && req->memory != V4L2_MEMORY_USERPTR) {
+   if (req->memory != V4L2_MEMORY_MMAP &&
+   req->memory != V4L2_MEMORY_DMABUF &&
+   req->memory != V4L2_MEMORY_USERPTR) {
dprintk(1, "reqbufs: unsupported memory type\n");
return -EINVAL;
}
@@ -513,6 +568,11 @@ int vb2_reqbufs(struct vb2_queue *q, struct 
v4l2_requestbuffers *req)
return -EINVAL;
}

+   if (req->memory == V4L2_MEMORY_DMABUF && __verify_dmabuf_ops(q)) {
+   dprintk(1, "reqbufs: DMABUF for current setup unsupported\n");
+   return -EINVAL;
+   }
+
if (req->count == 0 || 

[PATCHv5 02/13] Documentation: media: description of DMABUF importing in V4L2

[Tomasz Stanislawski]

This patch adds description and usage examples for importing
DMABUF file descriptor in V4L2.

Signed-off-by: Tomasz Stanislawski 
Signed-off-by: Kyungmin Park 
---
 Documentation/DocBook/media/v4l/compat.xml |4 +
 Documentation/DocBook/media/v4l/io.xml |  179 
 .../DocBook/media/v4l/vidioc-create-bufs.xml   |1 +
 Documentation/DocBook/media/v4l/vidioc-qbuf.xml|   15 ++
 Documentation/DocBook/media/v4l/vidioc-reqbufs.xml |   47 +++---
 5 files changed, 224 insertions(+), 22 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/compat.xml 
b/Documentation/DocBook/media/v4l/compat.xml
index bce97c5..2a2083d 100644
--- a/Documentation/DocBook/media/v4l/compat.xml
+++ b/Documentation/DocBook/media/v4l/compat.xml
@@ -2523,6 +2523,10 @@ ioctls.
 
  Selection API. 
 
+
+ Importing DMABUF file descriptors as a new IO method described
+ in .
+
   
 

diff --git a/Documentation/DocBook/media/v4l/io.xml 
b/Documentation/DocBook/media/v4l/io.xml
index b815929..f8fb559 100644
--- a/Documentation/DocBook/media/v4l/io.xml
+++ b/Documentation/DocBook/media/v4l/io.xml
@@ -472,6 +472,162 @@ rest should be evident.
   
   

+  
+Streaming I/O (DMA buffer importing)
+
+
+  Experimental
+  This is an  experimental 
+  interface and may change in the future.
+
+
+The DMABUF framework provides a generic mean for sharing buffers between
+ multiple devices. Device drivers that support DMABUF can export a DMA buffer
+to userspace as a file descriptor (known as the exporter role), import a DMA
+buffer from userspace using a file descriptor previously exported for a
+different or the same device (known as the importer role), or both. This
+section describes the DMABUF importer role API in V4L2.
+
+Input and output devices support the streaming I/O method when the
+V4L2_CAP_STREAMING flag in the
+capabilities field of  returned by
+the  ioctl is set. Whether importing DMA buffers through
+DMABUF file descriptors is supported is determined by calling the
+ ioctl with the memory type set to
+V4L2_MEMORY_DMABUF.
+
+This I/O method is dedicated for sharing DMA buffers between V4L and
+other APIs.  Buffers (planes) are allocated by a driver on behalf of the
+application, and exported to the application as file descriptors using an API
+specific to the allocator driver.  Only those file descriptor are exchanged,
+these files and meta-information are passed in  (or in
+ in the multi-planar API case).  The driver must be switched into
+DMABUF I/O mode by calling the  with the desired buffer type.
+No buffers (planes) are allocated beforehand, consequently they are not indexed
+and cannot be queried like mapped buffers with the
+VIDIOC_QUERYBUF ioctl.
+
+
+  Initiating streaming I/O with DMABUF file descriptors
+
+  
+ reqbuf;
+
+memset (reqbuf, 0, sizeof (reqbuf));
+reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+reqbuf.memory = V4L2_MEMORY_DMABUF;
+
+if (ioctl (fd, , reqbuf) == -1) {
+   if (errno == EINVAL)
+   printf ("Video capturing or DMABUF streaming is not 
supported\n");
+   else
+   perror ("VIDIOC_REQBUFS");
+
+   exit (EXIT_FAILURE);
+}
+  
+
+
+Buffer (plane) file is passed on the fly with the 
+ioctl. In case of multiplanar buffers, every plane can be associated with a
+different DMABUF descriptor.Although buffers are commonly cycled, applications
+can pass different DMABUF descriptor at each VIDIOC_QBUF
+call.
+
+
+  Queueing DMABUF using single plane API
+
+  
+int buffer_queue(int v4lfd, int index, int dmafd)
+{
+buf;
+
+   memset(buf, 0, sizeof buf);
+   buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+   buf.memory = V4L2_MEMORY_DMABUF;
+   buf.index = index;
+   buf.m.fd = dmafd;
+
+   if (ioctl (v4lfd, , buf) == -1) {
+   perror ("VIDIOC_QBUF");
+   return -1;
+   }
+
+   return 0;
+}
+  
+
+
+
+  Queueing DMABUF using multi plane API
+
+  
+int buffer_queue_mp(int v4lfd, int index, int dmafd[], int n_planes)
+{
+buf;
+planes[VIDEO_MAX_PLANES];
+   int i;
+
+   memset(buf, 0, sizeof buf);
+   buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
+   buf.memory = V4L2_MEMORY_DMABUF;
+   buf.index = index;
+   buf.m.planes = planes;
+   buf.length = n_planes;
+
+   memset(planes, 0, sizeof planes);
+
+   for (i = 0; i  n_planes; ++i)
+   buf.m.planes[i].m.fd = dmafd[i];
+
+   if (ioctl (v4lfd, , buf) == -1) {
+   perror ("VIDIOC_QBUF");
+   return -1;
+   }
+
+   return 0;
+}
+  
+
+
+Filled or displayed buffers are dequeued with the
+ ioctl. The driver can unlock the buffer at any
+time between the completion of the DMA and this ioctl. The memory is
+also unlocked when  is called, , or
+when the device is closed.
+
+For 

[PATCHv5 01/13] v4l: Add DMABUF as a memory type

[Tomasz Stanislawski]

From: Sumit Semwal 

Adds DMABUF memory type to v4l framework. Also adds the related file
descriptor in v4l2_plane and v4l2_buffer.

Signed-off-by: Tomasz Stanislawski 
   [original work in the PoC for buffer sharing]
Signed-off-by: Sumit Semwal 
Signed-off-by: Sumit Semwal 
Acked-by: Laurent Pinchart 
---
 include/linux/videodev2.h |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index c9c9a46..d884d4a 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -185,6 +185,7 @@ enum v4l2_memory {
V4L2_MEMORY_MMAP = 1,
V4L2_MEMORY_USERPTR  = 2,
V4L2_MEMORY_OVERLAY  = 3,
+   V4L2_MEMORY_DMABUF   = 4,
 };

 /* see also http://vektor.theorem.ca/graphics/ycbcr/ */
@@ -588,6 +589,8 @@ struct v4l2_requestbuffers {
  * should be passed to mmap() called on the video node)
  * @userptr:   when memory is V4L2_MEMORY_USERPTR, a userspace pointer
  * pointing to this plane
+ * @fd:when memory is V4L2_MEMORY_DMABUF, a userspace 
file
+ * descriptor associated with this plane
  * @data_offset:   offset in the plane to the start of data; usually 0,
  * unless there is a header in front of the data
  *
@@ -602,6 +605,7 @@ struct v4l2_plane {
union {
__u32   mem_offset;
unsigned long   userptr;
+   int fd;
} m;
__u32   data_offset;
__u32   reserved[11];
@@ -624,6 +628,8 @@ struct v4l2_plane {
  * (or a "cookie" that should be passed to mmap() as offset)
  * @userptr:   for non-multiplanar buffers with memory == V4L2_MEMORY_USERPTR;
  * a userspace pointer pointing to this buffer
+ * @fd:for non-multiplanar buffers with memory == 
V4L2_MEMORY_DMABUF;
+ * a userspace file descriptor associated with this buffer
  * @planes:for multiplanar buffers; userspace pointer to the array of plane
  * info structs for this buffer
  * @length:size in bytes of the buffer (NOT its payload) for single-plane
@@ -650,6 +656,7 @@ struct v4l2_buffer {
__u32   offset;
unsigned long   userptr;
struct v4l2_plane *planes;
+   int fd;
} m;
__u32   length;
__u32   input;
-- 
1.7.5.4

[PATCHv5 00/13] Integration of videobuf2 with dmabuf

[Tomasz Stanislawski]

Hello everyone,
This patchset adds support for DMABUF [2] importing to V4L2 stack.
The support for DMABUF exporting was moved to separate patchset
due to dependency on patches for DMA mapping redesign by
Marek Szyprowski [4].

v5:
- removed change of importer/exporter behaviour
- fixes vb2_dc_pages_to_sgt basing on Laurent's hints
- changed pin/unpin words to lock/unlock in Doc

v4:
- rebased on mainline 3.4-rc2
- included missing importing support for s5p-fimc and s5p-tv
- added patch for changing map/unmap for importers
- fixes to Documentation part
- coding style fixes
- pairing {map/unmap}_dmabuf in vb2-core
- fixing variable types and semantic of arguments in videobufb2-dma-contig.c

v3:
- rebased on mainline 3.4-rc1
- split 'code refactor' patch to multiple smaller patches
- squashed fixes to Sumit's patches
- patchset is no longer dependant on 'DMA mapping redesign'
- separated path for handling IO and non-IO mappings
- add documentation for DMABUF importing to V4L
- removed all DMABUF exporter related code
- removed usage of dma_get_pages extension

v2:
- extended VIDIOC_EXPBUF argument from integer memoffset to struct
  v4l2_exportbuffer
- added patch that breaks DMABUF spec on (un)map_atachment callcacks but allows
  to work with existing implementation of DMABUF prime in DRM
- all dma-contig code refactoring patches were squashed
- bugfixes

v1: List of changes since [1].
- support for DMA api extension dma_get_pages, the function is used to retrieve
  pages used to create DMA mapping.
- small fixes/code cleanup to videobuf2
- added prepare and finish callbacks to vb2 allocators, it is used keep
  consistency between dma-cpu acess to the memory (by Marek Szyprowski)
- support for exporting of DMABUF buffer in V4L2 and Videobuf2, originated from
  [3].
- support for dma-buf exporting in vb2-dma-contig allocator
- support for DMABUF for s5p-tv and s5p-fimc (capture interface) drivers,
  originated from [3]
- changed handling for userptr buffers (by Marek Szyprowski, Andrzej
  Pietrasiewicz)
- let mmap method to use dma_mmap_writecombine call (by Marek Szyprowski)

[1] 
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/42966/focus=42968
[2] https://lkml.org/lkml/2011/12/26/29
[3] 
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/36354/focus=36355
[4] http://thread.gmane.org/gmane.linux.kernel.cross-arch/12819

Andrzej Pietrasiewicz (1):
  v4l: vb2-dma-contig: add support for scatterlist in userptr mode

Laurent Pinchart (2):
  v4l: vb2-dma-contig: Shorten vb2_dma_contig prefix to vb2_dc
  v4l: vb2-dma-contig: Reorder functions

Marek Szyprowski (2):
  v4l: vb2: add prepare/finish callbacks to allocators
  v4l: vb2-dma-contig: add prepare/finish to dma-contig allocator

Sumit Semwal (4):
  v4l: Add DMABUF as a memory type
  v4l: vb2: add support for shared buffer (dma_buf)
  v4l: vb: remove warnings about MEMORY_DMABUF
  v4l: vb2-dma-contig: add support for dma_buf importing

Tomasz Stanislawski (4):
  Documentation: media: description of DMABUF importing in V4L2
  v4l: vb2-dma-contig: Remove unneeded allocation context structure
  v4l: s5p-tv: mixer: support for dmabuf importing
  v4l: s5p-fimc: support for dmabuf importing

 Documentation/DocBook/media/v4l/compat.xml |4 +
 Documentation/DocBook/media/v4l/io.xml |  179 +++
 .../DocBook/media/v4l/vidioc-create-bufs.xml   |1 +
 Documentation/DocBook/media/v4l/vidioc-qbuf.xml|   15 +
 Documentation/DocBook/media/v4l/vidioc-reqbufs.xml |   47 +-
 drivers/media/video/Kconfig|1 +
 drivers/media/video/s5p-fimc/fimc-capture.c|2 +-
 drivers/media/video/s5p-tv/Kconfig |1 +
 drivers/media/video/s5p-tv/mixer_video.c   |2 +-
 drivers/media/video/videobuf-core.c|4 +
 drivers/media/video/videobuf2-core.c   |  207 -
 drivers/media/video/videobuf2-dma-contig.c |  529 +---
 include/linux/videodev2.h  |7 +
 include/media/videobuf2-core.h |   34 ++
 14 files changed, 932 insertions(+), 101 deletions(-)

-- 
1.7.5.4

[PATCH 3/7] DRM: add sdrm layer for general embedded system support

[Mark Brown]

On Fri, Apr 20, 2012 at 05:15:18PM +0200, Sascha Hauer wrote:
> On Fri, Apr 20, 2012 at 03:25:58PM +0100, Mark Brown wrote:

> > This sounds an awful lot like how ASoC hangs together...

> Very much, yes. In ASoC and DRM we both have several physical devices spread
> around the SoC which form a logical device. I assume that before ASoC existed
> also everyone had a single PCI device which could be used to collect the
> information together.

Yeah, it's a similar issue - on PC hardware we tend to have a single
integrated device which does everything (at least from the point of view
of the outside world, physically things may sometimes be split).
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120420/61d9507c/attachment-0001.pgp>

[PATCHv5 01/13] v4l: Add DMABUF as a memory type

[Tomasz Stanislawski]

From: Sumit Semwal 

Adds DMABUF memory type to v4l framework. Also adds the related file
descriptor in v4l2_plane and v4l2_buffer.

Signed-off-by: Tomasz Stanislawski 
   [original work in the PoC for buffer sharing]
Signed-off-by: Sumit Semwal 
Signed-off-by: Sumit Semwal 
Acked-by: Laurent Pinchart 
---
 include/linux/videodev2.h |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index c9c9a46..d884d4a 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -185,6 +185,7 @@ enum v4l2_memory {
V4L2_MEMORY_MMAP = 1,
V4L2_MEMORY_USERPTR  = 2,
V4L2_MEMORY_OVERLAY  = 3,
+   V4L2_MEMORY_DMABUF   = 4,
 };

 /* see also http://vektor.theorem.ca/graphics/ycbcr/ */
@@ -588,6 +589,8 @@ struct v4l2_requestbuffers {
  * should be passed to mmap() called on the video node)
  * @userptr:   when memory is V4L2_MEMORY_USERPTR, a userspace pointer
  * pointing to this plane
+ * @fd:when memory is V4L2_MEMORY_DMABUF, a userspace 
file
+ * descriptor associated with this plane
  * @data_offset:   offset in the plane to the start of data; usually 0,
  * unless there is a header in front of the data
  *
@@ -602,6 +605,7 @@ struct v4l2_plane {
union {
__u32   mem_offset;
unsigned long   userptr;
+   int fd;
} m;
__u32   data_offset;
__u32   reserved[11];
@@ -624,6 +628,8 @@ struct v4l2_plane {
  * (or a "cookie" that should be passed to mmap() as offset)
  * @userptr:   for non-multiplanar buffers with memory == V4L2_MEMORY_USERPTR;
  * a userspace pointer pointing to this buffer
+ * @fd:for non-multiplanar buffers with memory == 
V4L2_MEMORY_DMABUF;
+ * a userspace file descriptor associated with this buffer
  * @planes:for multiplanar buffers; userspace pointer to the array of plane
  * info structs for this buffer
  * @length:size in bytes of the buffer (NOT its payload) for single-plane
@@ -650,6 +656,7 @@ struct v4l2_buffer {
__u32   offset;
unsigned long   userptr;
struct v4l2_plane *planes;
+   int fd;
} m;
__u32   length;
__u32   input;
-- 
1.7.5.4

[PATCHv5 00/13] Integration of videobuf2 with dmabuf

[Tomasz Stanislawski]

Hello everyone,
This patchset adds support for DMABUF [2] importing to V4L2 stack.
The support for DMABUF exporting was moved to separate patchset
due to dependency on patches for DMA mapping redesign by
Marek Szyprowski [4].

v5:
- removed change of importer/exporter behaviour
- fixes vb2_dc_pages_to_sgt basing on Laurent's hints
- changed pin/unpin words to lock/unlock in Doc

v4:
- rebased on mainline 3.4-rc2
- included missing importing support for s5p-fimc and s5p-tv
- added patch for changing map/unmap for importers
- fixes to Documentation part
- coding style fixes
- pairing {map/unmap}_dmabuf in vb2-core
- fixing variable types and semantic of arguments in videobufb2-dma-contig.c

v3:
- rebased on mainline 3.4-rc1
- split 'code refactor' patch to multiple smaller patches
- squashed fixes to Sumit's patches
- patchset is no longer dependant on 'DMA mapping redesign'
- separated path for handling IO and non-IO mappings
- add documentation for DMABUF importing to V4L
- removed all DMABUF exporter related code
- removed usage of dma_get_pages extension

v2:
- extended VIDIOC_EXPBUF argument from integer memoffset to struct
  v4l2_exportbuffer
- added patch that breaks DMABUF spec on (un)map_atachment callcacks but allows
  to work with existing implementation of DMABUF prime in DRM
- all dma-contig code refactoring patches were squashed
- bugfixes

v1: List of changes since [1].
- support for DMA api extension dma_get_pages, the function is used to retrieve
  pages used to create DMA mapping.
- small fixes/code cleanup to videobuf2
- added prepare and finish callbacks to vb2 allocators, it is used keep
  consistency between dma-cpu acess to the memory (by Marek Szyprowski)
- support for exporting of DMABUF buffer in V4L2 and Videobuf2, originated from
  [3].
- support for dma-buf exporting in vb2-dma-contig allocator
- support for DMABUF for s5p-tv and s5p-fimc (capture interface) drivers,
  originated from [3]
- changed handling for userptr buffers (by Marek Szyprowski, Andrzej
  Pietrasiewicz)
- let mmap method to use dma_mmap_writecombine call (by Marek Szyprowski)

[1] 
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/42966/focus=42968
[2] https://lkml.org/lkml/2011/12/26/29
[3] 
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/36354/focus=36355
[4] http://thread.gmane.org/gmane.linux.kernel.cross-arch/12819

Andrzej Pietrasiewicz (1):
  v4l: vb2-dma-contig: add support for scatterlist in userptr mode

Laurent Pinchart (2):
  v4l: vb2-dma-contig: Shorten vb2_dma_contig prefix to vb2_dc
  v4l: vb2-dma-contig: Reorder functions

Marek Szyprowski (2):
  v4l: vb2: add prepare/finish callbacks to allocators
  v4l: vb2-dma-contig: add prepare/finish to dma-contig allocator

Sumit Semwal (4):
  v4l: Add DMABUF as a memory type
  v4l: vb2: add support for shared buffer (dma_buf)
  v4l: vb: remove warnings about MEMORY_DMABUF
  v4l: vb2-dma-contig: add support for dma_buf importing

Tomasz Stanislawski (4):
  Documentation: media: description of DMABUF importing in V4L2
  v4l: vb2-dma-contig: Remove unneeded allocation context structure
  v4l: s5p-tv: mixer: support for dmabuf importing
  v4l: s5p-fimc: support for dmabuf importing

 Documentation/DocBook/media/v4l/compat.xml |4 +
 Documentation/DocBook/media/v4l/io.xml |  179 +++
 .../DocBook/media/v4l/vidioc-create-bufs.xml   |1 +
 Documentation/DocBook/media/v4l/vidioc-qbuf.xml|   15 +
 Documentation/DocBook/media/v4l/vidioc-reqbufs.xml |   47 +-
 drivers/media/video/Kconfig|1 +
 drivers/media/video/s5p-fimc/fimc-capture.c|2 +-
 drivers/media/video/s5p-tv/Kconfig |1 +
 drivers/media/video/s5p-tv/mixer_video.c   |2 +-
 drivers/media/video/videobuf-core.c|4 +
 drivers/media/video/videobuf2-core.c   |  207 -
 drivers/media/video/videobuf2-dma-contig.c |  529 +---
 include/linux/videodev2.h  |7 +
 include/media/videobuf2-core.h |   34 ++
 14 files changed, 932 insertions(+), 101 deletions(-)

-- 
1.7.5.4

[PATCH 3/7] DRM: add sdrm layer for general embedded system support

[Mark Brown]

On Fri, Apr 20, 2012 at 04:49:43PM +0200, Thierry Reding wrote:
> * Mark Brown wrote:

> > This sounds an awful lot like how ASoC hangs together...

> What in particular sounds awful?

Nothing - "an awful" is an English idiom for "very".
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120420/2cae7345/attachment.pgp>

[PATCH 1/2] drm/i915/tv: fix open-coded ARRAY_SIZE.

[Daniel Vetter]

On Fri, Apr 20, 2012 at 01:24:59PM +0100, Chris Wilson wrote:
> On Fri, 20 Apr 2012 13:13:54 +0100, Dave Airlie  wrote:
> > From: Dave Airlie 
> > 
> > Signed-off-by: Dave Airlie 
> Reviewed-by: Chris Wilson 
Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[RFC v2] Revive the work on render-nodes branch

[Daniel Vetter]

On Fri, Apr 20, 2012 at 11:20:45AM +0100, Dave Airlie wrote:
> On Thu, Apr 12, 2012 at 7:19 PM, Ilija Hadzic
>  wrote:
> > The following set of patches is the reword of the series
> > sent two weeks ago [2] that will revive the drm-render-nodes [1]
> > branch. Details of the original series are described in [2].
> 
> Thanks for looking at this,
> 
> So one thing about adding render nodes, is it gives us the chance to
> maybe change the userspace API we expose to be more secure and have
> less cruft in it.
> 
> Now I'm weary of a major API redesign as this could bog things now and
> we'd never make forward progress, but I'd like to at least consider it
> before adding new device nodes and locking us into the old APIs.
> 
> The areas suggested before:
> 
> 1) GEM, drop flink/open ioctls - these make security hard, since once
> you share a buffer any GEM opener can get access to it. Solutions to
> this proposed before are flink_to and maybe using PRIME/dma-buf.
> 
> 2) master/device ownership. We might be able to drop the first opener
> is magically master, and require openers to ask for it somehow.
> 
> 3) drop the old map ioctls from this interface, irq by busid, drop the AGP.
> 
> I'm not talking about changing ioctl operation, more about introducing
> new ioctls and not allowing the old ones on the new nodes.

My current plan to clean up the ioctl interface mess in drm/i915 is to
start marking up any interfaces that userspace doesn't need any longer on
a per-device level (already started on this). We can't drop the old
support code, but this way we can at least stop supporting old interfaces
on newer cards.

The problem with that approach is that the drm middle-layer (hot topic
today, I guess) gets in the way of this - we have to set the driver
feature flags while registering the driver and can't change them when we
initialize for a specific device. E.g. for i915 kms we need the old
mapping interfaces and the agp support mess only on i945 because we
shipped horrible userspace that only works on these platforms (XvMC
implementation fwiw).

My plan there is to remove the middle-layer smell by moving the drm
support subsystem initialization into the driver code. So imo we can solve
3) naturally by disabling old crap on new chips.

No strong opinions on 1)&2), but sounds reasonable.

Cheers, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[Bug 27541] [830M] [KMS] internal display goes nuts during boot

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=27541

Chris Wilson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #5 from Chris Wilson  2012-04-20 
08:38:31 PDT ---
I believe this was the missing drm_mode_set_crtcinfo() bug. Please try a recent
kernel.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 3/7] DRM: add sdrm layer for general embedded system support

[Daniel Vetter]

On Fri, Apr 20, 2012 at 03:10:05PM +0200, Sascha Hauer wrote:
> (BTW each driver in drm has this layer somewhere in it. If I had hidden
> it in imx specific functions I probably wouldn't have raised any
> questions, but I don't want to go that way)

That's _exactly_ what you should be doing. And once you have more than one
driver that works in a similar way, you can extract the common code as
helper functions to make life easier. Like Rob did with a few gem
helpers they needed in omapdrm/gma500.

For your case it sounds like a new set of modeset helper functions
tailored for the embedded use-case would be good (as Dave Airlie
suggested). Adding yet another middle-layer (like sdrm is) that forces
drivers to go through it usually ends up in tears. And drm core
unfortunately still has too much middle-layer heritage: For an awful lot
of setup and teardown issues it's the core of the problme - because
drivers can't control when drm sets up and tears down certain things, it's
done at the wrong time (for certain drivers at least). Same problem when
the abstraction doesn't quite fit.

Helper functions leave the driver in full control of what's going on, and
working around hw-specific madness with ease.

https://lwn.net/Articles/336262/ is the canonical reference for why a lot
of kernel people are allergic to anything that looks like a middle-layer.

Yours, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH 3/7] DRM: add sdrm layer for general embedded system support

[Mark Brown]

On Fri, Apr 20, 2012 at 02:38:43PM +0200, Thierry Reding wrote:
> * Dave Airlie wrote:
> > I get the feeling the drm can just be a virtual platform device of
> > some sort, then it reads the device tree and binds all the information
> > on what crtc/encoders are available,

> That's pretty much what I've come up with in the second round of Tegra DRM
> patches. Basically display controllers and outputs (RGB, HDMI, TVO, DSI) get
> separate drivers and register themselves with the DRM driver which then looks
> at the device tree to see which display controllers to register as CRTCs and
> parses a list of connector nodes to create encoder/connector pairs that
> define the physical connectors and their corresponding outputs.

> I did take a brief look at the SDRM patches as well and they didn't quite
> seem to fit what was needed for Tegra. But if time allows I'll take a closer
> look.

This sounds an awful lot like how ASoC hangs together...

[PATCH 1/4] drm: Move drm_format_num_planes() to drm_crtc.c

[Ville Syrjälä]

On Fri, Apr 20, 2012 at 12:43:03PM +0100, Dave Airlie wrote:
> On Thu, Apr 5, 2012 at 7:35 PM,   wrote:
> > From: Ville Syrj?l? 
> >
> > There will be a need for this function in drm_crtc.c later. This
> > avoids making drm_crtc.c depend on drm_crtc_helper.c.
> 
> Hi Ville,
> 
> I've applied these 4 patches, but I might have lost some others for
> you, let me know if there is some other stuff I should be reviewing
> for -next.

IIRC only one patch fell through the cracks:
Subject: [PATCH] drm: Unify and fix idr error handling
Message-Id: <1331834311-30757-1-git-send-email-ville.syrjala at linux.intel.com>

BTW you never gave any statement wrt. removing NV12M and YUV420M from
drm_fourcc.h. I can send a patch if you agree, and if not, well then
someone has to actually change the code to treat them exactly the same
as NV12 and YUV420.

-- 
Ville Syrj?l?
Intel OTC

[PATCH 3/7] DRM: add sdrm layer for general embedded system support

[Sascha Hauer]

On Fri, Apr 20, 2012 at 02:38:43PM +0200, Thierry Reding wrote:
> * Dave Airlie wrote:
> > I get the feeling the drm can just be a virtual platform device of
> > some sort, then it reads the device tree and binds all the information
> > on what crtc/encoders are available,
> 
> That's pretty much what I've come up with in the second round of Tegra DRM
> patches. Basically display controllers and outputs (RGB, HDMI, TVO, DSI) get
> separate drivers and register themselves with the DRM driver which then looks
> at the device tree to see which display controllers to register as CRTCs and
> parses a list of connector nodes to create encoder/connector pairs that
> define the physical connectors and their corresponding outputs.
> 
> I did take a brief look at the SDRM patches as well and they didn't quite
> seem to fit what was needed for Tegra. But if time allows I'll take a closer
> look.

Can you elaborate which parts don't fit? I am very interested to
improve this situation, and I think having code to share will be a
benefit for us all.

I know that the patches I wrote are no one-solution-fits-for-all yet,
they are mainly something to show that drm drivers do not have to be
huge complex drivers.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[Bug 48772] Signal unstable over Display Port on 2560x1440 monitor

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=48772

--- Comment #11 from Alex Deucher  2012-04-20 08:19:54 PDT 
---
(In reply to comment #9)
> 
> I never really understood this problem, not since the days of sdr. Single
> channel ddr3-1066 provides roughly 8 times the raw bandwidth of what a
> 2560x1440 resolution (at 32bpp, 60hz) needs so that should be plenty to serve
> other MC clients as well (with lesser priority). So what's the problem there,
> too small buffer size for scanout?

I'm just speculating.  I suspect it's more of a latency/timing thing than
bandwidth.  If the request is not there when the LB needs it, it'll run dry.

(In reply to comment #10)
> Does the driver know it's memory bandwidth so it could remove modes it cannot
> drive from the list?

It could and does in some cases and there's even code to check it in the
watermark setup although it probably needs a bit of tweaking for APUs. 
Unfortunately the way the drm is structured makes it hard to do a good job
since modesetting is per crtc so you only get a partial picture.  I'll talk to
the display team and see what they have to say.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 3/7] DRM: add sdrm layer for general embedded system support

[Sascha Hauer]

[Added some embedded graphics maintainers to Cc who might be interested
in this]

On Fri, Apr 20, 2012 at 11:02:02AM +0100, Dave Airlie wrote:
> On Wed, Apr 11, 2012 at 4:33 PM, Sascha Hauer  
> wrote:
> > This patch adds support for creating simple drm devices. The
> > basic idea of this patch is that drm drivers using the sdrm layer
> > no longer have to implement a full drm device but instead only
> > register crtcs, encoders and connectors with the sdrm layer. The
> > sdrm layer then registers a drm device with the drm core and
> > takes care of the drm device.
> 
> I'm sorry to say I totally hate this on every level. I think I said to
> you before that midlayers are not the answer, and this is a hella big
> midlayer.
> 
> I understand the SoC architecture but I can't think this is the way forward.
> 
> The problems I see from a highlevel:
> 
> This layer is highly restrictive on its users, I get the feeling once
> you get to implement 2-3 complete drivers or try and implement a
> driver say on x86 that should work in a similar fashion you are going
> to realise you made things overly generic and the driver can't change
> it.

That's maybe where our philosophies clash. I'd say that drivers should just
have enough freedom to get their job done whereas you want to give
drivers the freedom to do anything they want. I come from an area where
we have dozens of drivers which mostly are quite similar, in the ARM
world we currently try to get the duplication out of the drivers because
otherwise we can't handle the sheer amount of devices we have.

> Then the drivers will start to workaround the midlayer and we'll
> end up worse off. I don't really want to pick on specifics but the
> taking over of the fb ops is on example,

The layer can be extended when we need it, no need to work around it. I
took over the fb ops because currently I don't need to adjust them. I
know that some devices have accelerated blit operations and this means
that we may add a way to overwrite the ops later. Same with the ioctls.
I didn't provide a way to add device specific ioctls now, partly because
currently I don't need them, partly to get this series out.

> 
> I think this should work as a set of helpers that might work in place
> of the current set of helpers. The current helpers are very directed
> towards desktop x86 experience, so a new set of these might be better.

Hm, this means duplicating the helpers. The KMS support is to a great
extend defined by the helpers. Duplicating them would mean more code
fragmentation and different behaviour from a users point of view. I'd
rather not go this way.

> 
> I get the feeling the drm can just be a virtual platform device of
> some sort, then it reads the device tree and binds all the information
> on what crtc/encoders are available,

We can do that. Currently I use a string matching mechanism to tie
together the different pieces of a device, but sooner or later it will
be devicetree anyway, so no problem to convert this sooner instead of
later. The only problem I see with this is that for example X86 will not
have devicetree, so I see a value in not binding whatever we come up
with too tight to devicetree.

> 
> Also the mode group stuff isn't legacy, the render nodes stuff posted
> is what is intended to use it for, again it may not be useful on ARM,
> but on desktop it has a very useful use case.

I didn't remove them because they are not useful, but because currently
I couldn't add an encoder/connector to a active drm device (see how the
exynos driver currently works around this, I doubt it will work this way
once the legacy_mode_group handling is actually used). The fact that this
is currently unused motivated me to remove it. That said, I can live without
it, no problem.

> 
> I'm sorry to not provide the answer I would fine acceptable, maybe if
> I had a week of time to write something I could figure it out, maybe
> someone else can give advice on how this sort of thing might look,
> Linearo/ARM guys can some of you guys look at this?

Take these patches as my try to show that something has to change to
make drm stuff more widely usable on embedded devices. As said, there
are dozens of different devices out there, many of them are dumb
framebuffer devices like the PXA and i.MX driver I posted, others are
more advanced like the exynos, tegra and the newer i.MX devices. Some of
the bigger players can effort to write (and maintain?) a 300KB driver,
others can not. Those who cannot currently stay in drivers/video, but
this has limitations when it comes to overlay, hot pluggable monitors,
multiple crtcs, etc.

I'd like to find a solution for this which makes us all happy. In the
end reducing the amount of code duplication also helps you as a
maintainer.

(BTW each driver in drm has this layer somewhere in it. If I had hidden
it in imx specific functions I probably wouldn't have raised any
questions, but I don't want to go that way)

Sascha




-- 
Pengutronix e.K.  

[PATCH v4 02/14] Documentation: media: description of DMABUF importing in V4L2

[Rémi Denis-Courmont]

On Fri, 20 Apr 2012 14:25:01 +0200, Tomasz Stanislawski
 wrote:
>>> The USERPTR simplifies userspace code but introduce
>>> a lot of complexity problems for the kernel drivers
>>> and frameworks.
>> 
>> It is not only a simplification. In some cases, USERPTR is the only I/O
>> method that supports zero copy in pretty much any circumstance.
> 
> Only for devices that have its own IOMMU that can access system memory.

Newer versions of the UVC driver have USERTPR, and simingly gspca seems
too. That is practically all USB capture devices... That might be
irrelevant for a smartphone manufacturer. That is very relevant for desktop
applications.

> Moreover the userptr must come from malloc or be a mmaped file.
> The other case are drivers that touch memory using CPU in the kernel
> space like VIVI or USB drivers.

I'd argue that USB is the most common case of V4L2 on the desktop...

>> When the user cannot reliably predict the maximum number of required
>> buffers, predicts a value larger than the device will negotiate, or
>> needs buffers to outlive STREAMOFF (?), MMAP requires memory copying.
>> USERPTR does not.
> 
> What does outlive STREAMOFF means in this context?

Depending how your multimedia pipeline is built, it is plausible that the
V4L2 source is shutdown (STREAMOFF then close()) before buffers coming from
it are released/destroyed downstream. I might be wrong, but I would expect
that V4L2 MMAP buffers become invalid after STREAMOFF+close()?

> Anyway, IMO allocation of the buffers at VIDIOC_REQBUFS was not the best
> idea because it introduces an allocation overhead for negotiations of
> the number of the buffers. An allocation at mmap was to late. There is a
> need for some intermediate state between REQBUFS and mmap. The ioctl
> BUF_PREPARE may help here.
> 
> Can you give me an example of a sane application is forced to negotiate
a
> larger number of buffers than it is actually going to use?

Outside the embedded world, the application typically does not know what
the latency of the multimedia pipeline is. If the latency is not known, the
number of buffers needed for zero copy cannot be precomputed for REQBUFS,
say:

count = 1 + latency / frame interval.

Even for a trivial analog TV viewer application, lip synchronization
requires picture frames to be bufferred to be long enough to account for
the latency of the audio input, dejitter, filtering and audio output. Those
values are usually not well determined at the time of requesting buffers
from the video capture device. Also the application may want to play nice
with PulseAudio. Then it will get very long audio buffers with very few
audio periods... more latency.

It gets harder or outright impossible for frameworks dealing with
complicated or arbitrary pipelines such as LibVLC or gstreamer. There is
far too much unpredictability and variability downstream of the V4L2 source
to estimate latency, and infer the number of buffers needed.

>> Now, I do realize that some devices cannot support USERPTR efficiently,
>> then they should not support USERPTR. 
> 
> The problem is not there is *NO* device that can handle USERPTR
reliably.
> The can handle USERPTR generated by malloc or page cache (not sure).
> Memory mmaped from other devices, frameworks etc may or may not work.
> Even if the device has its IOMMU the DMA layer provides no generic way
to
> transform from one device to the mapping in some other device.

I'm not saying that USERPTR should replace DMABUF. I'm saying USERPTR has
advantages over MMAP that DMABUF does not seem to cover as yet (if only
libv4l2 would not inhibit USERPTR...).

I'm definitely not saying that applications should rely on USERPTR being
supported. We agree that not all devices can support USERPTR.

> The userptr has its niches were it works pretty well like Web cams or
VIVI.
> I am saying that if ever DMABUF becomes a good alternative for USERPTR
> than maybe we should consider encouraging dropping USERPTR in the new
> drivers as 'obsolete' feature and providing some emulation layer in
libv4l2
> for legacy applications.

Sure.

-- 
R?mi Denis-Courmont
Sent from my collocated server

[PATCH v4 14/14] v4l: fimc: support for dmabuf importing

[Sylwester Nawrocki]

Hi Tomasz,

On 04/13/2012 05:47 PM, Tomasz Stanislawski wrote:
> This patch enhances s5p-fimc with support for DMABUF importing via
> V4L2_MEMORY_DMABUF memory type.
> 
> Signed-off-by: Tomasz Stanislawski 
> Signed-off-by: Kyungmin Park 

Acked-by: Sylwester Nawrocki 

Just one nitpick, please change the commit summary prefix from
"v4l: fimc: ..." to "s5p-fimc: ..." when sending upstream.

Thanks.

[PATCH 3/7] DRM: add sdrm layer for general embedded system support

[Thierry Reding]

* Dave Airlie wrote:
> I get the feeling the drm can just be a virtual platform device of
> some sort, then it reads the device tree and binds all the information
> on what crtc/encoders are available,

That's pretty much what I've come up with in the second round of Tegra DRM
patches. Basically display controllers and outputs (RGB, HDMI, TVO, DSI) get
separate drivers and register themselves with the DRM driver which then looks
at the device tree to see which display controllers to register as CRTCs and
parses a list of connector nodes to create encoder/connector pairs that
define the physical connectors and their corresponding outputs.

I did take a brief look at the SDRM patches as well and they didn't quite
seem to fit what was needed for Tegra. But if time allows I'll take a closer
look.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120420/704fc456/attachment.pgp>

[Intel-gfx] [PATCH 00/12] Add more DMT and common modes

[Takashi Iwai]

At Fri, 20 Apr 2012 13:05:48 +0100,
Dave Airlie wrote:
> 
> On Thu, Apr 19, 2012 at 3:58 PM, Takashi Iwai  wrote:
> > At Thu, 19 Apr 2012 14:03:58 +0200,
> > Takashi Iwai wrote:
> >>
> >> At Tue, 17 Apr 2012 17:26:26 +0200,
> >> Takashi Iwai wrote:
> >> >
> >> > At Fri, 13 Apr 2012 16:56:26 -0400,
> >> > Adam Jackson wrote:
> >> > >
> >> > > On 4/13/12 4:33 PM, Adam Jackson wrote:
> >> > > > Incorporates some feedback from Rodrigo and Takashi. ?Major themes 
> >> > > > of the
> >> > > > series:
> >> > > >
> >> > > > - Fix the DMT list to include reduced-blanking modes
> >> > > > - Add modes from DMT for any range descriptor type
> >> > > > - Add an extra modes list for things not in DMT
> >> > > > - For ranges that specify a formula, generate timings from the extra 
> >> > > > modes
> >> > > >
> >> > > > This still doesn't address the driver policy decision of "I know I 
> >> > > > have
> >> > > > a scaler, add modes as if there were a range descriptor even if 
> >> > > > there's
> >> > > > not one". ?But it should at least make clear what such a helper 
> >> > > > function
> >> > > > should do.
> >> > >
> >> > > One minor buglet in this series that's not obvious from inspection (and
> >> > > that I didn't realize until just now) is that putting 1366x768 in the
> >> > > minimode list won't do what you want, since the mode you get back will
> >> > > be 1368x768. ?Probably we should move the manual-underscan hack into 
> >> > > the
> >> > > timing generators themselves.
> >> >
> >> > Sounds like a good compromise. ?We have already hacks in drm_edid.c
> >> > for HDMI TV, so one exception more isn't that bad ;)
> 
> I've pulled the series into -next along with the NULL check fix.

Thanks!

> the only outstanding bit is the hack.

Also the packed attributes are missing in the new structs.
The fix patch is below.


Takashi

---

From: Takashi Iwai 
Subject: [PATCH 2/2] drm/edid: Add packed attribute to new gtf2 and cvt structs

The new structs added in struct detailed_data_monitor_range must be
marked with packed attribute although the outer struct itself is
already marked as packed.  Otherwise these 7-bytes structs may be
aligned, and give the wrong position and size for the data.

Signed-off-by: Takashi Iwai 
---
 include/drm/drm_edid.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 8cefbbe..0cac551 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -99,7 +99,7 @@ struct detailed_data_monitor_range {
__le16 m;
u8 k;
u8 j; /* need to divide by 2 */
-   } gtf2;
+   } __attribute__((packed)) gtf2;
struct {
u8 version;
u8 data1; /* high 6 bits: extra clock resolution */
@@ -108,7 +108,7 @@ struct detailed_data_monitor_range {
u8 flags; /* preferred aspect and blanking support */
u8 supported_scalings;
u8 preferred_refresh;
-   } cvt;
+   } __attribute__((packed)) cvt;
} formula;
 } __attribute__((packed));

-- 
1.7.9.2

[Intel-gfx] [PATCH 00/12] Add more DMT and common modes

[Takashi Iwai]

At Fri, 20 Apr 2012 13:04:42 +0100,
Dave Airlie wrote:
> 
> On Thu, Apr 19, 2012 at 1:03 PM, Takashi Iwai  wrote:
> > At Tue, 17 Apr 2012 17:26:26 +0200,
> > Takashi Iwai wrote:
> >>
> >> At Fri, 13 Apr 2012 16:56:26 -0400,
> >> Adam Jackson wrote:
> >> >
> >> > On 4/13/12 4:33 PM, Adam Jackson wrote:
> >> > > Incorporates some feedback from Rodrigo and Takashi. ?Major themes of 
> >> > > the
> >> > > series:
> >> > >
> >> > > - Fix the DMT list to include reduced-blanking modes
> >> > > - Add modes from DMT for any range descriptor type
> >> > > - Add an extra modes list for things not in DMT
> >> > > - For ranges that specify a formula, generate timings from the extra 
> >> > > modes
> >> > >
> >> > > This still doesn't address the driver policy decision of "I know I have
> >> > > a scaler, add modes as if there were a range descriptor even if there's
> >> > > not one". ?But it should at least make clear what such a helper 
> >> > > function
> >> > > should do.
> >> >
> >> > One minor buglet in this series that's not obvious from inspection (and
> >> > that I didn't realize until just now) is that putting 1366x768 in the
> >> > minimode list won't do what you want, since the mode you get back will
> >> > be 1368x768. ?Probably we should move the manual-underscan hack into the
> >> > timing generators themselves.
> >>
> >> Sounds like a good compromise. ?We have already hacks in drm_edid.c
> >> for HDMI TV, so one exception more isn't that bad ;)
> >
> > FYI, I tried the hack below and it seems working.
> >
> Is this hack going to be a real patch? ajax care to review?

For the easiness, below is the patch with my sign-off.


thanks,

Takashi

---

From: Takashi Iwai 
Subject: [PATCH 1/2] drm/edid: Add a workaround for 1366x768 HD panel

HD panel (1366x768) found most commonly on laptops can't be represented
exactly in CVT/DMT expression, which leads to 1368x768 instead, because
1366 can't be divided by 8.

Add a hack to convert to 1366x768 manually as an exception.

Signed-off-by: Takashi Iwai 
---
 drivers/gpu/drm/drm_edid.c |   15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index bad2f11..c6366e9 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1039,6 +1039,19 @@ drm_dmt_modes_for_range(struct drm_connector *connector, 
struct edid *edid,
return modes;
 }

+/* fix up 1366x768 mode from 1368x768;
+ * GFT/CVT can't express 1366 width which isn't dividable by 8
+ */
+static void fixup_mode_1366x768(struct drm_display_mode *mode)
+{
+   if (mode->hdisplay == 1368 && mode->vdisplay == 768) {
+   mode->hdisplay = 1366;
+   mode->hsync_start--;
+   mode->hsync_end--;
+   drm_mode_set_name(mode);
+   }
+}
+
 static int
 drm_gtf_modes_for_range(struct drm_connector *connector, struct edid *edid,
struct detailed_timing *timing)
@@ -1053,6 +1066,7 @@ drm_gtf_modes_for_range(struct drm_connector *connector, 
struct edid *edid,
if (!newmode)
return modes;

+   fixup_mode_1366x768(newmode);
if (!mode_in_range(newmode, edid, timing)) {
drm_mode_destroy(dev, newmode);
continue;
@@ -1080,6 +1094,7 @@ drm_cvt_modes_for_range(struct drm_connector *connector, 
struct edid *edid,
if (!newmode)
return modes;

+   fixup_mode_1366x768(newmode);
if (!mode_in_range(newmode, edid, timing)) {
drm_mode_destroy(dev, newmode);
continue;
-- 
1.7.9.2

[Bug 42729] Monitor EDID handling causes system freezes every few seconds.

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=42729


subscription.discussion at gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH v4 02/14] Documentation: media: description of DMABUF importing in V4L2

[Tomasz Stanislawski]

Hi Remi,

On 04/20/2012 12:56 PM, R?mi Denis-Courmont wrote:
> On Fri, 20 Apr 2012 10:41:37 +0200, Tomasz Stanislawski
>  wrote:
>>> Am I understanding wrong or are you saying that you want to drop
> userptr
>>> from V4L2 API in long-term? If so, why?
>>
>> Dropping userptr is just some brainstorming idea.
>> It was found out that userptr is not a good mean
>> for buffer exchange between to two devices.
> 
> I can believe that. But I am also inclined to believe that DMABUF is
> targetted at device-to-device transfer, while USERPTR is targetted at
> device-to-user (or user-to-device) transfers. Are you saying applications
> should use DMABUF and memory map the buffers?

No. As I sad before: it is *too early* to drop userptr and expect application
to use DMABUF and MMAPs only. This was just some hypothetical idea.

DMABUF is dedicated for  dev-dev transfers. However, looking at the current
speed of appearances of  DMABUF extensions it may be expected that one day
it starts supporting making DMA buffer from a user pointer.
Currently there are already extensions for MMAP and cache synchronization.
Who know what will happen future versions. However these are only
hypothetical issues.

Or would you care to explain
> how DMABUF addresses the problem space of USERPTR?

Allowing to attach a DMABUF to some userptr using some new magic IOCTL.
I think that sooner or later someone will find this feature useful.

> 
>> The USERPTR simplifies userspace code but introduce
>> a lot of complexity problems for the kernel drivers
>> and frameworks.
> 
> It is not only a simplification. In some cases, USERPTR is the only I/O
> method that supports zero copy in pretty much any circumstance.

Only for devices that have its own IOMMU that can access system memory.
Moreover the userptr must come from malloc or be a mmaped file.
The other case are drivers that touch memory using CPU in the kernel
space like VIVI or USB drivers.

> When the user cannot reliably predict the maximum number of required buffers,
> predicts a value larger than the device will negotiate, or needs buffers to
> outlive STREAMOFF (?), MMAP requires memory copying. USERPTR does not.

What does outlive STREAMOFF means in this context?

Anyway, IMO allocation of the buffers at VIDIOC_REQBUFS was not the best idea
because it introduces an allocation overhead for negotiations of the number
of the buffers. An allocation at mmap was to late. There is a need for some
intermediate state between REQBUFS and mmap. The ioctl BUF_PREPARE may help 
here.

Can you give me an example of a sane application is forced to negotiate a larger
number of buffers than it is actually going to use?

> 
> Now, I do realize that some devices cannot support USERPTR efficiently,
> then they should not support USERPTR. 

The problem is not there is *NO* device that can handle USERPTR reliably.
The can handle USERPTR generated by malloc or page cache (not sure).
Memory mmaped from other devices, frameworks etc may or may not work.
Even if the device has its IOMMU the DMA layer provides no generic way to
transform from one device to the mapping in some other device.

It is done using platform-defendant hacks like extracting PFNs from mappings,
hack-forming them into struct pages or scatterlists, mapping it and hoping
that the memory is not going to release it in some other thread.

The only sure way is to copy data from userptr to MMAP buffer.

But for those devices that can, it
> seems quite a nice performance enhancement.

The userptr has its niches were it works pretty well like Web cams or VIVI.
I am saying that if ever DMABUF becomes a good alternative for USERPTR
than maybe we should consider encouraging dropping USERPTR in the new
drivers as 'obsolete' feature and providing some emulation layer in libv4l2
for legacy applications.

Regards,
Tomasz Stanislawski

[PATCH 10/13] drm/radeon: return -ENOENT in fence_wait_*

[Michel Dänzer]

On Fre, 2012-04-20 at 12:24 +0200, Christian K?nig wrote: 
> On 20.04.2012 11:15, Michel D?nzer wrote:
> > On Fre, 2012-04-20 at 10:49 +0200, Christian K?nig wrote:
> >> On 20.04.2012 09:20, Michel D?nzer wrote:
> >>> On Fre, 2012-04-20 at 00:39 +0200, Christian K?nig wrote:
>  Signed-off-by: Christian K?nig
>  ---
> drivers/gpu/drm/radeon/radeon_fence.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
> 
>  diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
>  b/drivers/gpu/drm/radeon/radeon_fence.c
>  index 1a9765a..764ab7e 100644
>  --- a/drivers/gpu/drm/radeon/radeon_fence.c
>  +++ b/drivers/gpu/drm/radeon/radeon_fence.c
>  @@ -286,7 +286,7 @@ int radeon_fence_wait_next(struct radeon_device 
>  *rdev, int ring)
>   }
>   if (list_empty(>fence_drv[ring].emitted)) {
>   write_unlock_irqrestore(>fence_lock, irq_flags);
>  -return 0;
>  +return -ENOENT;
>   }
>   fence = list_entry(rdev->fence_drv[ring].emitted.next,
>  struct radeon_fence, list);
>  @@ -310,7 +310,7 @@ int radeon_fence_wait_last(struct radeon_device 
>  *rdev, int ring)
>   }
>   if (list_empty(>fence_drv[ring].emitted)) {
>   write_unlock_irqrestore(>fence_lock, irq_flags);
>  -return 0;
>  +return -ENOENT;
>   }
>   fence = list_entry(rdev->fence_drv[ring].emitted.prev,
>  struct radeon_fence, list);
> >>> It seems weird to declare a fence wait as failed when there are no
> >>> outstanding fences in the first place. If there are callers which
> >>> require outstanding fences, they should probably handle that themselves..
> >> Why that sounds so weird? Ok, maybe for radeon_fence_wait_last that's
> >> questionable,
> > Indeed. It happens not to break radeon_suspend_kms because it doesn't
> > check the return value, but otherwise it would fail spuriously.
> >
> >
> >> but for radeon_fence_wait_next it's quite clear to me that
> >> we should signal the caller that there is no fence to wait for.
> >>
> >> The problem I wanted to fix with that is the usage of
> >> radeon_fence_wait_next in radeon_ring_alloc (for example):
> >>> int radeon_ring_alloc(struct radeon_device *rdev, struct radeon_ring
> >>> *ring, unsigned ndw)
> >>> {
> >>>  int r;
> >>>
> >>>  /* Align requested size with padding so unlock_commit can
> >>>   * pad safely */
> >>>  ndw = (ndw + ring->align_mask)&  ~ring->align_mask;
> >>>  while (ndw>  (ring->ring_free_dw - 1)) {
> >>>  radeon_ring_free_size(rdev, ring);
> >>>  if (ndw<  ring->ring_free_dw) {
> >>>  break;
> >>>  }
> >>>  r = radeon_fence_wait_next(rdev,
> >>> radeon_ring_index(rdev, ring));
> >>>  if (r)
> >>>  return r;
> >>>  }
> >>>  ring->count_dw = ndw;
> >>>  ring->wptr_old = ring->wptr;
> >>>  return 0;
> >>> }
> >> If the ring is full, but actually has no more fences in it (which in my
> >> case was caused by my stupidity and actually shouldn't happen otherwise)
> >> this loop will just busy wait with a critical mutex locked for something
> >> that never happens.
> > My suggestion was to explicitly check for that in radeon_ring_alloc. But
> > I guess right now it doesn't really matter, as it's the only caller. :)
> Yeah, but when we check that explicitly we need to call into the fence 
> code twice, without locking in between, so the result of the first call 
> could change before the second call happens etc... well that's just crap.
> 
> So what do you think of this: Just add the -ENOENT to fence_wait_next 
> and rename fence_wait_last to fence_wait_empty instead?

Sounds good.


-- 
Earthling Michel D?nzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer

[PATCH 1/4] drm: Move drm_format_num_planes() to drm_crtc.c

[Dave Airlie]

On Fri, Apr 20, 2012 at 1:23 PM, Ville Syrj?l?
 wrote:
> On Fri, Apr 20, 2012 at 12:43:03PM +0100, Dave Airlie wrote:
>> On Thu, Apr 5, 2012 at 7:35 PM, ? wrote:
>> > From: Ville Syrj?l? 
>> >
>> > There will be a need for this function in drm_crtc.c later. This
>> > avoids making drm_crtc.c depend on drm_crtc_helper.c.
>>
>> Hi Ville,
>>
>> I've applied these 4 patches, but I might have lost some others for
>> you, let me know if there is some other stuff I should be reviewing
>> for -next.
>
> IIRC only one patch fell through the cracks:
> Subject: [PATCH] drm: Unify and fix idr error handling
> Message-Id: <1331834311-30757-1-git-send-email-ville.syrjala at 
> linux.intel.com>

Thanks I'll take a look at that,

>
> BTW you never gave any statement wrt. removing NV12M and YUV420M from
> drm_fourcc.h. I can send a patch if you agree, and if not, well then
> someone has to actually change the code to treat them exactly the same
> as NV12 and YUV420.

I'm probably not qualified, if you and jbarnes and say one other
non-Intel person agree, then send the patch with R-b and I'll apply
it.

Dave.

[Bug 43138] Radeon HD5450 fails to load cedar firmware ?

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=43138





--- Comment #1 from Michel D?nzer   2012-04-20 13:28:55 
---
(In reply to comment #0)
> r600_cp: Bogus length 4480 in firmware "radeon/CEDAR_me.bin"
> r600_rlc: Bogus length 5504 in firmware "radeon/CEDAR_rlc.bin"

What does

 ls -l /lib/firmware/radeon/CEDAR_*

say?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

state of drm next

[Dave Airlie]

Hi,

So I've spent today trawling and most likely missing patches on the
list for -next.

-next before today had:
an intel -next from Daniel
radeon - copy optimisation, pci bus master race fix.
two agp patches

I've merged today into drm-core-next
Ville's framebuffer creation sanity check series
Paulo's CEA/EDID patches that touch core (I think there are two i915
patches that can come via Daniel).
Lars-Peter Clausen: CEA/EDID patches
Ajax's: DMT modes adding patches

I've also got in -next:
mjg59's work on multiple gpu with EFI interactions, I'll push to
-core-next once it stops breaking builds on misc arches!

So feel free to point me at anything I've missed or haven't commented
on, and everyone keep reviewing everyone else's stuff as a path to
success, as I'm busy!!

Dave.

[PATCH 1/2] drm/i915/tv: fix open-coded ARRAY_SIZE.

[Chris Wilson]

On Fri, 20 Apr 2012 13:13:54 +0100, Dave Airlie  wrote:
> From: Dave Airlie 
> 
> Signed-off-by: Dave Airlie 
Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 2/2] drm/nouveau: fix open-coded ARRAY_SIZE in volt code

[Dave Airlie]

From: Dave Airlie 

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/nouveau/nouveau_volt.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_volt.c 
b/drivers/gpu/drm/nouveau/nouveau_volt.c
index b010cb9..fdc8f77 100644
--- a/drivers/gpu/drm/nouveau/nouveau_volt.c
+++ b/drivers/gpu/drm/nouveau/nouveau_volt.c
@@ -29,7 +29,7 @@
 #include "nouveau_gpio.h"

 static const enum dcb_gpio_tag vidtag[] = { 0x04, 0x05, 0x06, 0x1a, 0x73 };
-static int nr_vidtag = sizeof(vidtag) / sizeof(vidtag[0]);
+static int nr_vidtag = ARRAY_SIZE(vidtag);

 int
 nouveau_voltage_gpio_get(struct drm_device *dev)
-- 
1.7.7.6

[PATCH 1/2] drm/i915/tv: fix open-coded ARRAY_SIZE.

[Dave Airlie]

From: Dave Airlie 

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/i915/intel_tv.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index ca12c70..67f444d 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -811,7 +811,7 @@ intel_tv_mode_lookup(const char *tv_format)
 {
int i;

-   for (i = 0; i < sizeof(tv_modes) / sizeof(tv_modes[0]); i++) {
+   for (i = 0; i < ARRAY_SIZE(tv_modes); i++) {
const struct tv_mode *tv_mode = _modes[i];

if (!strcmp(tv_format, tv_mode->name))
-- 
1.7.7.6

[Bug 43138] New: Radeon HD5450 fails to load cedar firmware ?

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=43138

   Summary: Radeon HD5450 fails to load cedar firmware ?
   Product: Drivers
   Version: 2.5
Kernel Version: 3.3.2.
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-dri at kernel-bugs.osdl.org
ReportedBy: bugtraq at hobbit.in-berlin.de
Regression: No


lspci
03:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Cedar
PRO [Radeon HD 5450]
03:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Cedar HDMI Audio
[Radeon HD 5400/6300 Series]

dmesg snippets
[drm] Initialized drm 1.1.0 20060810
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (CEDAR 0x1002:0x68F9 0x1043:0x0366).
[drm] register mmio base: 0xFDCC
[drm] register mmio size: 131072
ATOM BIOS: 68F9.12.16.0.2.AS03
radeon :03:00.0: VRAM: 1024M 0x - 0x3FFF (1024M
used)
radeon :03:00.0: GTT: 512M 0x4000 - 0x5FFF
[drm] Detected VRAM RAM=1024M, BAR=256M
[drm] RAM width 64bits DDR
[drm] radeon: 1024M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
radeon :03:00.0: irq 44 for MSI/MSI-X
radeon :03:00.0: radeon: using MSI.
[drm] radeon: irq initialized.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] radeon: ib pool ready.
[drm] Loading CEDAR Microcode
r600_cp: Bogus length 4480 in firmware "radeon/CEDAR_me.bin"
r600_rlc: Bogus length 5504 in firmware "radeon/CEDAR_rlc.bin"
[drm:evergreen_startup] *ERROR* Failed to load firmware!
radeon :03:00.0: disabling GPU acceleration

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Intel-gfx] [PATCH 00/12] Add more DMT and common modes

[Dave Airlie]

On Thu, Apr 19, 2012 at 3:58 PM, Takashi Iwai  wrote:
> At Thu, 19 Apr 2012 14:03:58 +0200,
> Takashi Iwai wrote:
>>
>> At Tue, 17 Apr 2012 17:26:26 +0200,
>> Takashi Iwai wrote:
>> >
>> > At Fri, 13 Apr 2012 16:56:26 -0400,
>> > Adam Jackson wrote:
>> > >
>> > > On 4/13/12 4:33 PM, Adam Jackson wrote:
>> > > > Incorporates some feedback from Rodrigo and Takashi. ?Major themes of 
>> > > > the
>> > > > series:
>> > > >
>> > > > - Fix the DMT list to include reduced-blanking modes
>> > > > - Add modes from DMT for any range descriptor type
>> > > > - Add an extra modes list for things not in DMT
>> > > > - For ranges that specify a formula, generate timings from the extra 
>> > > > modes
>> > > >
>> > > > This still doesn't address the driver policy decision of "I know I have
>> > > > a scaler, add modes as if there were a range descriptor even if there's
>> > > > not one". ?But it should at least make clear what such a helper 
>> > > > function
>> > > > should do.
>> > >
>> > > One minor buglet in this series that's not obvious from inspection (and
>> > > that I didn't realize until just now) is that putting 1366x768 in the
>> > > minimode list won't do what you want, since the mode you get back will
>> > > be 1368x768. ?Probably we should move the manual-underscan hack into the
>> > > timing generators themselves.
>> >
>> > Sounds like a good compromise. ?We have already hacks in drm_edid.c
>> > for HDMI TV, so one exception more isn't that bad ;)

I've pulled the series into -next along with the NULL check fix.

the only outstanding bit is the hack.

Thanks,
Dave.

[Intel-gfx] [PATCH 00/12] Add more DMT and common modes

[Dave Airlie]

On Thu, Apr 19, 2012 at 1:03 PM, Takashi Iwai  wrote:
> At Tue, 17 Apr 2012 17:26:26 +0200,
> Takashi Iwai wrote:
>>
>> At Fri, 13 Apr 2012 16:56:26 -0400,
>> Adam Jackson wrote:
>> >
>> > On 4/13/12 4:33 PM, Adam Jackson wrote:
>> > > Incorporates some feedback from Rodrigo and Takashi. ?Major themes of the
>> > > series:
>> > >
>> > > - Fix the DMT list to include reduced-blanking modes
>> > > - Add modes from DMT for any range descriptor type
>> > > - Add an extra modes list for things not in DMT
>> > > - For ranges that specify a formula, generate timings from the extra 
>> > > modes
>> > >
>> > > This still doesn't address the driver policy decision of "I know I have
>> > > a scaler, add modes as if there were a range descriptor even if there's
>> > > not one". ?But it should at least make clear what such a helper function
>> > > should do.
>> >
>> > One minor buglet in this series that's not obvious from inspection (and
>> > that I didn't realize until just now) is that putting 1366x768 in the
>> > minimode list won't do what you want, since the mode you get back will
>> > be 1368x768. ?Probably we should move the manual-underscan hack into the
>> > timing generators themselves.
>>
>> Sounds like a good compromise. ?We have already hacks in drm_edid.c
>> for HDMI TV, so one exception more isn't that bad ;)
>
> FYI, I tried the hack below and it seems working.
>
Is this hack going to be a real patch? ajax care to review?

Dave.

[PATCH v4 02/14] Documentation: media: description of DMABUF importing in V4L2

[Rémi Denis-Courmont]

On Fri, 20 Apr 2012 10:41:37 +0200, Tomasz Stanislawski
 wrote:
>> Am I understanding wrong or are you saying that you want to drop
userptr
>> from V4L2 API in long-term? If so, why?
> 
> Dropping userptr is just some brainstorming idea.
> It was found out that userptr is not a good mean
> for buffer exchange between to two devices.

I can believe that. But I am also inclined to believe that DMABUF is
targetted at device-to-device transfer, while USERPTR is targetted at
device-to-user (or user-to-device) transfers. Are you saying applications
should use DMABUF and memory map the buffers? Or would you care to explain
how DMABUF addresses the problem space of USERPTR?

> The USERPTR simplifies userspace code but introduce
> a lot of complexity problems for the kernel drivers
> and frameworks.

It is not only a simplification. In some cases, USERPTR is the only I/O
method that supports zero copy in pretty much any circumstance. When the
user cannot reliably predict the maximum number of required buffers,
predicts a value larger than the device will negotiate, or needs buffers to
outlive STREAMOFF (?), MMAP requires memory copying. USERPTR does not.

Now, I do realize that some devices cannot support USERPTR efficiently,
then they should not support USERPTR. But for those devices that can, it
seems quite a nice performance enhancement.

-- 
R?mi Denis-Courmont
Sent from my collocated server

[RFC 0/4] Add NVIDIA Tegra DRM support

[Jon Mayo]

On 04/19/2012 11:05 PM, Lucas Stach wrote:
> Am Freitag, den 20.04.2012, 07:02 +0200 schrieb Thierry Reding:
*cut*
>
> Yes, I think we should go the route that Jerome Glisse pointed out: get
> in a basic KMS driver first and hide any accel ioctl under a staging
> config option.

Everyone seems happy with that, I have no objections.

*cut*
>
> I'm really interested how this turns out in the end. I hope we can get a
> somewhat stable cooperation between NVIDIA and the community, like AMD
> has established at the moment.

Well, we always strive to be better than AMD ;-)
But seriously, I don't think GPU technology would be where it is today 
if NVIDIA and AMD didn't compete aggressively.

But our mobile division is more like TI, Qualcomm, Freescale and other 
SoC vendors. Upstreaming changes for arch/arm has so far been a 
different challenge than only updating drivers/gpu for x86. Mostly 
because there are so many aspects to SoCs compared to a driver for a 
graphics card or PC chipset. And it doesn't help that arch/arm is a real 
mess of wildly different SoCs, and it lacks the stability and maturity 
of the x86 code base. The state of ARM is every vendor's fault, every 
chip generation can be a complete resign of one or more subsystems. x86 
tends to be layers of extensions and enhancements from 1-3 vendors.

But even if Mobile doesn't consider AMD or Intel to be among the 
competition, we certainly watch and listen to good open source 
contributors and try to learn from their successes and mistakes. (and 
our own mistakes, we're not perfect!)

What I'm trying to say is that Tegra's business needs are different, so 
you should not be surprised to see different behavior from us. There are 
a lot of difficult issues with open sourcing the work done by my desktop 
colleagues. But those barriers don't apply to Tegra. Different product, 
different market, different rules.

>>
>>> (My vote is NVIDIA starts using this DRM in-house and builds new
>>> extensions on top of it, sharing patches on LKML when the hardware is
>>> released)
>>
>> That sounds like a good plan. Ideally you should even share the patches as
>> soon as they're ready. That'll give viewers some head start and you can fix
>> the code even before the hardware is released.
>
> One thing I would like to have is upstream first. We have seen much
> Tegra development in both the nv-linux and chromium trees, but those
> things are going upstream extremely slowly. I can understand that this
> strategy was beneficial for a fast bring up of the new Tegra hardware,
> but the DRM driver shouldn't be time critical and so everything should
> be done to meet upstream quality from the start.
>
> -- Lucas
>
>

We have a team of interested engineers assigned to just that problem.
Fractured trees are not efficient for us internally either. We want 
upstream to be our common repository for most changes. And internally we 
have been stricter about conforming to Linux kernel coding conventions 
in attempt to give ourselves less work when we get to upstreaming a 
change. I'll be happy when I can tell my customers they can just grab 
the latest Tegra updates from git.kernel.org

Hopefully our efforts will begin to convince you.

- Jon

[PATCH 1/4] drm: Move drm_format_num_planes() to drm_crtc.c

[Dave Airlie]

On Thu, Apr 5, 2012 at 7:35 PM,   wrote:
> From: Ville Syrj?l? 
>
> There will be a need for this function in drm_crtc.c later. This
> avoids making drm_crtc.c depend on drm_crtc_helper.c.

Hi Ville,

I've applied these 4 patches, but I might have lost some others for
you, let me know if there is some other stuff I should be reviewing
for -next.

Dave.

[PATCH 10/13] drm/radeon: return -ENOENT in fence_wait_*

[Christian König]

On 20.04.2012 11:15, Michel D?nzer wrote:
> On Fre, 2012-04-20 at 10:49 +0200, Christian K?nig wrote:
>> On 20.04.2012 09:20, Michel D?nzer wrote:
>>> On Fre, 2012-04-20 at 00:39 +0200, Christian K?nig wrote:
 Signed-off-by: Christian K?nig
 ---
drivers/gpu/drm/radeon/radeon_fence.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
 b/drivers/gpu/drm/radeon/radeon_fence.c
 index 1a9765a..764ab7e 100644
 --- a/drivers/gpu/drm/radeon/radeon_fence.c
 +++ b/drivers/gpu/drm/radeon/radeon_fence.c
 @@ -286,7 +286,7 @@ int radeon_fence_wait_next(struct radeon_device *rdev, 
 int ring)
}
if (list_empty(>fence_drv[ring].emitted)) {
write_unlock_irqrestore(>fence_lock, irq_flags);
 -  return 0;
 +  return -ENOENT;
}
fence = list_entry(rdev->fence_drv[ring].emitted.next,
   struct radeon_fence, list);
 @@ -310,7 +310,7 @@ int radeon_fence_wait_last(struct radeon_device *rdev, 
 int ring)
}
if (list_empty(>fence_drv[ring].emitted)) {
write_unlock_irqrestore(>fence_lock, irq_flags);
 -  return 0;
 +  return -ENOENT;
}
fence = list_entry(rdev->fence_drv[ring].emitted.prev,
   struct radeon_fence, list);
>>> It seems weird to declare a fence wait as failed when there are no
>>> outstanding fences in the first place. If there are callers which
>>> require outstanding fences, they should probably handle that themselves..
>> Why that sounds so weird? Ok, maybe for radeon_fence_wait_last that's
>> questionable,
> Indeed. It happens not to break radeon_suspend_kms because it doesn't
> check the return value, but otherwise it would fail spuriously.
>
>
>> but for radeon_fence_wait_next it's quite clear to me that
>> we should signal the caller that there is no fence to wait for.
>>
>> The problem I wanted to fix with that is the usage of
>> radeon_fence_wait_next in radeon_ring_alloc (for example):
>>> int radeon_ring_alloc(struct radeon_device *rdev, struct radeon_ring
>>> *ring, unsigned ndw)
>>> {
>>>  int r;
>>>
>>>  /* Align requested size with padding so unlock_commit can
>>>   * pad safely */
>>>  ndw = (ndw + ring->align_mask)&  ~ring->align_mask;
>>>  while (ndw>  (ring->ring_free_dw - 1)) {
>>>  radeon_ring_free_size(rdev, ring);
>>>  if (ndw<  ring->ring_free_dw) {
>>>  break;
>>>  }
>>>  r = radeon_fence_wait_next(rdev,
>>> radeon_ring_index(rdev, ring));
>>>  if (r)
>>>  return r;
>>>  }
>>>  ring->count_dw = ndw;
>>>  ring->wptr_old = ring->wptr;
>>>  return 0;
>>> }
>> If the ring is full, but actually has no more fences in it (which in my
>> case was caused by my stupidity and actually shouldn't happen otherwise)
>> this loop will just busy wait with a critical mutex locked for something
>> that never happens.
> My suggestion was to explicitly check for that in radeon_ring_alloc. But
> I guess right now it doesn't really matter, as it's the only caller. :)
Yeah, but when we check that explicitly we need to call into the fence 
code twice, without locking in between, so the result of the first call 
could change before the second call happens etc... well that's just crap.

So what do you think of this: Just add the -ENOENT to fence_wait_next 
and rename fence_wait_last to fence_wait_empty instead?

Well I'm just trying to program defensively here, making it as robust as 
possible to both technically and human errors.

Christian.

[PATCH v4 02/14] Documentation: media: description of DMABUF importing in V4L2

[Mauro Carvalho Chehab]

Em 20-04-2012 09:25, Tomasz Stanislawski escreveu:
> Hi Remi,

>> Now, I do realize that some devices cannot support USERPTR efficiently,
>> then they should not support USERPTR. 
> 
> The problem is not there is *NO* device that can handle USERPTR reliably.
> The can handle USERPTR generated by malloc or page cache (not sure).
> Memory mmaped from other devices, frameworks etc may or may not work.
> Even if the device has its IOMMU the DMA layer provides no generic way to
> transform from one device to the mapping in some other device.
> 
> It is done using platform-defendant hacks like extracting PFNs from mappings,
> hack-forming them into struct pages or scatterlists, mapping it and hoping
> that the memory is not going to release it in some other thread.
> 
> The only sure way is to copy data from userptr to MMAP buffer.

All you're talking about is related to userptr abuse that happened
on Embedded devices, of using it for something that were never
meant to be used (dev2dev).

While the DMABUF patches aren't applied, there's just one mode defined
at the V4L2 API for dev2dev: overlay mode[1].

Most embedded applications and drivers decided that, instead of using
overlay mode, to abuse of userptr to do dev2dev. As you've pointed,
it was noticed in practice that this sometimes fail.

Yes, such abuse should be dropped, and DMABUF is the right way to
address it.

That doesn't mean that USERPTR should be dropped for the thing it were
originally created: dev2user or user2dev.

Regards,
Mauro

[1] Even so, not all PC motherboards are capable of supporting the overlay mode:
it is known that several chipsets have problems on their DMA engines, 
with causes data losses when a DMA transfer happens without passing through 
the system main memory (PCI2PCI transfers). So, drivers check the PCI quirks 
table to detect if dev2dev is supported, before exposing overlay mode to
userspace.

[PATCH 13/13] drm/radeon: rework recursive gpu reset handling

[Christian König]

On 20.04.2012 09:50, Daniel Vetter wrote:
> On Fri, Apr 20, 2012 at 07:57:09AM +0100, Dave Airlie wrote:
>> 2012/4/19 Christian K?nig:
>>> Instead of all this humpy pumpy with recursive
>>> mutex (which also fixes only halve of the problem)
>>> move the actual gpu reset out of the fence code,
>>> return -EDEADLK and then reset the gpu in the
>>> calling ioctl function.
>> I'm trying to figure out if this has any disadvantages over doing what
>> I proposed before and just kicking a thread to reset the gpu.
>>
>> It seems like this should also avoid the locking problems, I'd like to
>> make sure we don't return -EDEADLK to userspace by accident anywhere,
>> since I don't think it prepared for it and it would be an ABI change.
> Fyi, the trick i915 uses to solve the reset problem is to bail out with
> -EAGAIN and rely on drmIOCtl restarting the ioctl. This way we use the
> same codepaths we use to bail out when getting a signal, and thanks to X
> these are rather well-tested. The hangcheck code also fires of a work item to
> do all the reset magic. In all the ioctls that might wait for the gpu we
> have a fancy piece of code which checks whether a gpu reset is pending,
> and if so waits for that to complete. It also checks whether the reset
> succeeded and if not bails out with -EIO.
> -Daniel
Well I considered using an asynchronous work item also, but didn't know 
how to probably prevent multiple GPU resets at the same time, signaling 
the result back to the ioctls, etc.. It just seemed to be more 
complicated without any real benefit (maybe except that you don't have 
to check every ioctl result separately, but there are not so many).

Also I didn't know what to tell userspace to retry the current 
operation, but if it's already prepared for -EAGAIN than this sounds 
like the proper solution here.

And regarding returning -EDEADLK to userspace: I think I handle every 
ioctl that could cause the lockup detection to run, but checking that 
again won't hurt.

Christian.

[PATCH 0/1] [RFC] DRM locking issues during early open

[Dave Airlie]

>
> I may be reading things wrong but the initialisation does indeed hold
> drm_global_mutex, but and back when this first occured we would have
> been using kernel_lock() which was at least partially reentrant right?

Yup if we slept with the BKL held we'd have allowed others to get past it,

but also I introduced the global mutex in pci a while back

commit b64c115eb22516ecd187c74ad6de3f1693f1dc7b
Author: Dave Airlie 
Date:   Tue Sep 14 20:14:38 2010 +1000

drm: fix race between driver loading and userspace open.

Not 100% sure this is due to BKL removal, its most likely a combination
of that + userspace timing changes in udev/plymouth. The drm adds the sysfs
device before the driver has completed internal loading, this causes udev
to make the node and plymouth to open it before we've completed loading.

The proper solution is to delay the sysfs manipulation until later
in loading
however this causes knock on issues with sysfs connector nodes, so
we can use
the global mutex to serialise loading and userspace opens.

Reported-by: Toni Spets (hifi on #radeon)
Signed-off-by: Dave Airlie 

by a while I mean nearly 1.5 yrs ago, with the intent of fixing it this way.

Dave.

[PATCH 0/1] [RFC] DRM locking issues during early open

[Andy Whitcroft]

On Fri, Apr 20, 2012 at 10:40:35AM +0100, Dave Airlie wrote:

> I've just revisited this, maybe I'm going insane but why does
> drm_global_mutex not stop this?
> 
> drm_get_pci_dev takes drm_global_mutex before calling drm_fill_in_dev
> and drm_get_minor.
> 
> Now the fops should be pointing at stub_open at this point, as we
> won't have switched to the per device fops yet,
> and one of the first things drm_stub_open does is take the
> drm_global_mutex before doing the idr lookup.
> 
> So is the problem opening some sysfs or proc file early?

I may be reading things wrong but the initialisation does indeed hold
drm_global_mutex, but and back when this first occured we would have
been using kernel_lock() which was at least partially reentrant right?

Anyhow, I will go back to the reporter and try and get a proper
reproduce by, there is no point in fixing something which is something
else.

-apw

[RFC v2] Revive the work on render-nodes branch

[Dave Airlie]

On Thu, Apr 12, 2012 at 7:19 PM, Ilija Hadzic
 wrote:
> The following set of patches is the reword of the series
> sent two weeks ago [2] that will revive the drm-render-nodes [1]
> branch. Details of the original series are described in [2].

Thanks for looking at this,

So one thing about adding render nodes, is it gives us the chance to
maybe change the userspace API we expose to be more secure and have
less cruft in it.

Now I'm weary of a major API redesign as this could bog things now and
we'd never make forward progress, but I'd like to at least consider it
before adding new device nodes and locking us into the old APIs.

The areas suggested before:

1) GEM, drop flink/open ioctls - these make security hard, since once
you share a buffer any GEM opener can get access to it. Solutions to
this proposed before are flink_to and maybe using PRIME/dma-buf.

2) master/device ownership. We might be able to drop the first opener
is magically master, and require openers to ask for it somehow.

3) drop the old map ioctls from this interface, irq by busid, drop the AGP.

I'm not talking about changing ioctl operation, more about introducing
new ioctls and not allowing the old ones on the new nodes.

Dave.

[PATCH 10/13] drm/radeon: return -ENOENT in fence_wait_*

[Michel Dänzer]

On Fre, 2012-04-20 at 10:49 +0200, Christian K?nig wrote: 
> On 20.04.2012 09:20, Michel D?nzer wrote:
> > On Fre, 2012-04-20 at 00:39 +0200, Christian K?nig wrote:
> >> Signed-off-by: Christian K?nig
> >> ---
> >>   drivers/gpu/drm/radeon/radeon_fence.c |4 ++--
> >>   1 files changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
> >> b/drivers/gpu/drm/radeon/radeon_fence.c
> >> index 1a9765a..764ab7e 100644
> >> --- a/drivers/gpu/drm/radeon/radeon_fence.c
> >> +++ b/drivers/gpu/drm/radeon/radeon_fence.c
> >> @@ -286,7 +286,7 @@ int radeon_fence_wait_next(struct radeon_device *rdev, 
> >> int ring)
> >>}
> >>if (list_empty(>fence_drv[ring].emitted)) {
> >>write_unlock_irqrestore(>fence_lock, irq_flags);
> >> -  return 0;
> >> +  return -ENOENT;
> >>}
> >>fence = list_entry(rdev->fence_drv[ring].emitted.next,
> >>   struct radeon_fence, list);
> >> @@ -310,7 +310,7 @@ int radeon_fence_wait_last(struct radeon_device *rdev, 
> >> int ring)
> >>}
> >>if (list_empty(>fence_drv[ring].emitted)) {
> >>write_unlock_irqrestore(>fence_lock, irq_flags);
> >> -  return 0;
> >> +  return -ENOENT;
> >>}
> >>fence = list_entry(rdev->fence_drv[ring].emitted.prev,
> >>   struct radeon_fence, list);
> > It seems weird to declare a fence wait as failed when there are no
> > outstanding fences in the first place. If there are callers which
> > require outstanding fences, they should probably handle that themselves.
> 
> Why that sounds so weird? Ok, maybe for radeon_fence_wait_last that's 
> questionable,

Indeed. It happens not to break radeon_suspend_kms because it doesn't
check the return value, but otherwise it would fail spuriously.


> but for radeon_fence_wait_next it's quite clear to me that 
> we should signal the caller that there is no fence to wait for.
> 
> The problem I wanted to fix with that is the usage of 
> radeon_fence_wait_next in radeon_ring_alloc (for example):
> > int radeon_ring_alloc(struct radeon_device *rdev, struct radeon_ring 
> > *ring, unsigned ndw)
> > {
> > int r;
> >
> > /* Align requested size with padding so unlock_commit can
> >  * pad safely */
> > ndw = (ndw + ring->align_mask) & ~ring->align_mask;
> > while (ndw > (ring->ring_free_dw - 1)) {
> > radeon_ring_free_size(rdev, ring);
> > if (ndw < ring->ring_free_dw) {
> > break;
> > }
> > r = radeon_fence_wait_next(rdev, 
> > radeon_ring_index(rdev, ring));
> > if (r)
> > return r;
> > }
> > ring->count_dw = ndw;
> > ring->wptr_old = ring->wptr;
> > return 0;
> > }
> If the ring is full, but actually has no more fences in it (which in my 
> case was caused by my stupidity and actually shouldn't happen otherwise) 
> this loop will just busy wait with a critical mutex locked for something 
> that never happens.

My suggestion was to explicitly check for that in radeon_ring_alloc. But
I guess right now it doesn't really matter, as it's the only caller. :)


-- 
Earthling Michel D?nzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer

[PATCH 07/19] drm: initial multiple nodes ioctl work.

[Dave Airlie]

> +/* render node create and remove functions
> + ? if crtc/encoders/connectors/planes all == 0 then gpgpu node */
> +struct drm_render_node_create {
> + ? ? ? __u32 node_minor_id;
> + ? ? ? __u32 num_crtc;
> + ? ? ? __u32 num_encoder;
> + ? ? ? __u32 num_connector;
> + ? ? ? __u32 num_plane;
> + ? ? ? __u64 id_list_ptr;
> +};

This struct is wrongly aligned, you need a 32-bit pad after num plane.

Dave.

[PATCH 06/13] drm/radeon: improve sub allocator

[Christian König]

On 20.04.2012 09:24, Michel D?nzer wrote:
> On Fre, 2012-04-20 at 00:39 +0200, Christian K?nig wrote:
>> Make the suballocator self containing to locking
>> and fix a overrun bug which happens with
>> allocations of different alignments.
> Sounds like this should be split up into two changes. :)

Yeah you are probably right.

But wait a moment, thinking about it some more the overrun bug is 
actually a quite critical bug in mainline, cause it quickly leads to 
memory corruption if two users of the SA have different alignment 
restrictions. And hell, there currently is at least the IB pool (256 
bytes) and the VM code (4096 bytes alignment) using it, so this could be 
responsible for some of the VM corruptions we are seeing!!!

Going to write a patch immediately,
Christian.

[PATCH 05/19] drm: move dev_mapping to the minor node

[Dave Airlie]

On Thu, Apr 12, 2012 at 7:19 PM, Ilija Hadzic
 wrote:
> Make dev_mapping per-minor instead of per device. This is
> a preparatory patch for introducing render nodes. This
> will allow per-node instead of per-device mapping range,
> once we introduce render nodes.

One problem is this introduces a ttm/drm dependency that we don't
really have so far.

Dave

>
> Patch derived from 7c5cc4f63556e351e9e5980ed22accad410e3fdc
> originally authored by Dave Airlie.
>
> Signed-off-by: Ilija Hadzic 
> ---
> ?drivers/gpu/drm/drm_drv.c ? ? ? ? ? ? ?| ? ?1 -
> ?drivers/gpu/drm/drm_fops.c ? ? ? ? ? ? | ? ?8 
> ?drivers/gpu/drm/drm_vm.c ? ? ? ? ? ? ? | ? ?9 +
> ?drivers/gpu/drm/i915/i915_gem.c ? ? ? ?| ? ?7 +++
> ?drivers/gpu/drm/nouveau/nouveau_gem.c ?| ? ?4 ++--
> ?drivers/gpu/drm/radeon/radeon_object.c | ? ?4 ++--
> ?drivers/gpu/drm/radeon/radeon_ttm.c ? ?| ? ?6 +++---
> ?drivers/gpu/drm/ttm/ttm_bo.c ? ? ? ? ? | ? ?7 ---
> ?drivers/gpu/drm/vmwgfx/vmwgfx_drv.c ? ?| ? ?5 ++---
> ?drivers/staging/omapdrm/omap_gem.c ? ? | ? 10 --
> ?include/drm/drmP.h ? ? ? ? ? ? ? ? ? ? | ? ?3 ++-
> ?include/drm/drm_mem_util.h ? ? ? ? ? ? | ? ?3 +++
> ?include/drm/ttm/ttm_bo_driver.h ? ? ? ?| ? ?3 ++-
> ?13 files changed, 40 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index d166bd0..a4d7d44 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -236,7 +236,6 @@ int drm_lastclose(struct drm_device * dev)
> ? ? ? ? ? ?!drm_core_check_feature(dev, DRIVER_MODESET))
> ? ? ? ? ? ? ? ?drm_dma_takedown(dev);
>
> - ? ? ? dev->dev_mapping = NULL;
> ? ? ? ?mutex_unlock(>struct_mutex);
>
> ? ? ? ?DRM_DEBUG("lastclose completed\n");
> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> index 98cb064..4498d76 100644
> --- a/drivers/gpu/drm/drm_fops.c
> +++ b/drivers/gpu/drm/drm_fops.c
> @@ -141,10 +141,10 @@ int drm_open(struct inode *inode, struct file *filp)
> ? ? ? ?}
> ? ? ? ?if (!retcode) {
> ? ? ? ? ? ? ? ?mutex_lock(>struct_mutex);
> - ? ? ? ? ? ? ? if (minor->type == DRM_MINOR_LEGACY) {
> - ? ? ? ? ? ? ? ? ? ? ? if (dev->dev_mapping == NULL)
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? dev->dev_mapping = inode->i_mapping;
> - ? ? ? ? ? ? ? ? ? ? ? else if (dev->dev_mapping != inode->i_mapping)
> + ? ? ? ? ? ? ? if (minor->type == DRM_MINOR_LEGACY || minor->type == 
> DRM_MINOR_RENDER) {
> + ? ? ? ? ? ? ? ? ? ? ? if (minor->dev_mapping == NULL)
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? minor->dev_mapping = inode->i_mapping;
> + ? ? ? ? ? ? ? ? ? ? ? else if (minor->dev_mapping != inode->i_mapping)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?retcode = -ENODEV;
> ? ? ? ? ? ? ? ?}
> ? ? ? ? ? ? ? ?mutex_unlock(>struct_mutex);
> diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
> index 55cd615..bcd15b0 100644
> --- a/drivers/gpu/drm/drm_vm.c
> +++ b/drivers/gpu/drm/drm_vm.c
> @@ -687,3 +687,12 @@ int drm_mmap(struct file *filp, struct vm_area_struct 
> *vma)
> ? ? ? ?return ret;
> ?}
> ?EXPORT_SYMBOL(drm_mmap);
> +
> +void drm_unmap_mapping(struct drm_device *dev, loff_t const holebegin,
> + ? ? ? ? ? ? ? ? ? ? ?loff_t const holelen)
> +{
> + ? ? ? if (dev->primary->dev_mapping)
> + ? ? ? ? ? ? ? unmap_mapping_range(dev->primary->dev_mapping,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? holebegin, holelen, 1);
> +}
> +EXPORT_SYMBOL(drm_unmap_mapping);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 19a06c2..5eb0294 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1215,10 +1215,9 @@ i915_gem_release_mmap(struct drm_i915_gem_object *obj)
> ? ? ? ?if (!obj->fault_mappable)
> ? ? ? ? ? ? ? ?return;
>
> - ? ? ? if (obj->base.dev->dev_mapping)
> - ? ? ? ? ? ? ? unmap_mapping_range(obj->base.dev->dev_mapping,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
> (loff_t)obj->base.map_list.hash.key< - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? obj->base.size, 1);
> + ? ? ? drm_unmap_mapping(obj->base.dev,
> + ? ? ? ? ? ? ? ? ? ? ? ? (loff_t)obj->base.map_list.hash.key< + ? ? ? ? ? ? ? ? ? ? ? ? obj->base.size);
>
> ? ? ? ?obj->fault_mappable = false;
> ?}
> diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
> b/drivers/gpu/drm/nouveau/nouveau_gem.c
> index 7ce3fde..63521af 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_gem.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
> @@ -202,8 +202,8 @@ nouveau_gem_ioctl_new(struct drm_device *dev, void *data,
> ? ? ? ?struct nouveau_bo *nvbo = NULL;
> ? ? ? ?int ret = 0;
>
> - ? ? ? if (unlikely(dev_priv->ttm.bdev.dev_mapping == NULL))
> - ? ? ? ? ? ? ? dev_priv->ttm.bdev.dev_mapping = dev_priv->dev->dev_mapping;
> + ? ? ? if (unlikely(dev_priv->ttm.bdev.mapping_priv == NULL))
> + ? ? ? ? ? ? ? dev_priv->ttm.bdev.mapping_priv = (void *)dev;
>
> ? ? ? ?if (!dev_priv->engine.vram.flags_valid(dev, req->info.tile_flags)) {
> ? ? ? ? ? ? ? ?NV_ERROR(dev, "bad page flags: 0x%08x\n", 
> req->info.tile_flags);
> diff --git 

[PATCH 3/7] DRM: add sdrm layer for general embedded system support

[Dave Airlie]

On Wed, Apr 11, 2012 at 4:33 PM, Sascha Hauer  wrote:
> This patch adds support for creating simple drm devices. The
> basic idea of this patch is that drm drivers using the sdrm layer
> no longer have to implement a full drm device but instead only
> register crtcs, encoders and connectors with the sdrm layer. The
> sdrm layer then registers a drm device with the drm core and
> takes care of the drm device.

I'm sorry to say I totally hate this on every level. I think I said to
you before that midlayers are not the answer, and this is a hella big
midlayer.

I understand the SoC architecture but I can't think this is the way forward.

The problems I see from a highlevel:

This layer is highly restrictive on its users, I get the feeling once
you get to implement 2-3 complete drivers or try and implement a
driver say on x86 that should work in a similar fashion you are going
to realise you made things overly generic and the driver can't change
it. Then the drivers will start to workaround the midlayer and we'll
end up worse off. I don't really want to pick on specifics but the
taking over of the fb ops is on example,

I think this should work as a set of helpers that might work in place
of the current set of helpers. The current helpers are very directed
towards desktop x86 experience, so a new set of these might be better.

I get the feeling the drm can just be a virtual platform device of
some sort, then it reads the device tree and binds all the information
on what crtc/encoders are available,

Also the mode group stuff isn't legacy, the render nodes stuff posted
is what is intended to use it for, again it may not be useful on ARM,
but on desktop it has a very useful use case.

I'm sorry to not provide the answer I would fine acceptable, maybe if
I had a week of time to write something I could figure it out, maybe
someone else can give advice on how this sort of thing might look,
Linearo/ARM guys can some of you guys look at this?

Dave.

[PATCH v4 08/14] v4l: vb2-dma-contig: add support for scatterlist in userptr mode

[Tomasz Stanislawski]

Hi Laurent,


On 04/17/2012 02:43 AM, Laurent Pinchart wrote:
> Hi Tomasz,
> 
> Thanks for the patch.
> 
> On Friday 13 April 2012 17:47:50 Tomasz Stanislawski wrote:
>> From: Andrzej Pietrasiewicz 
>>
>> This patch introduces usage of dma_map_sg to map memory behind
>> a userspace pointer to a device as dma-contiguous mapping.
>>
>> Signed-off-by: Andrzej Pietrasiewicz 
>> Signed-off-by: Marek Szyprowski 
>>  [bugfixing]
>> Signed-off-by: Kamil Debski 
>>  [bugfixing]
>> Signed-off-by: Tomasz Stanislawski 
>>  [add sglist subroutines/code refactoring]
>> Signed-off-by: Kyungmin Park 
>> ---
>>  drivers/media/video/videobuf2-dma-contig.c |  287 +++--
>>  1 files changed, 270 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/media/video/videobuf2-dma-contig.c
>> b/drivers/media/video/videobuf2-dma-contig.c index 476e536..3a1e314 100644
>> --- a/drivers/media/video/videobuf2-dma-contig.c
>> +++ b/drivers/media/video/videobuf2-dma-contig.c
> 
> [snip]
> 

I found out that the function below may be useful for DMABUF
exporters and importers. I found that its code in
'[PATCH 1/4] [RFC] drm/exynos: DMABUF: Added support for exporting non-contig 
buffers'
by Prathyush K.

Therefore I posted a patch on linux-media:
'[PATCH] scatterlist: add sg_alloc_table_by_pages function'.

For now I will keep the function below (with your fixes). If
the patch above gets merged then the function will be removed.

Regards,
Tomasz Stanislawski

>> +static struct sg_table *vb2_dc_pages_to_sgt(struct page **pages,
>> +unsigned int n_pages, unsigned long offset, unsigned long size)
>> +{
>> +struct sg_table *sgt;
>> +unsigned int chunks;
>> +unsigned int i;
>> +unsigned int cur_page;
>> +int ret;
>> +struct scatterlist *s;
>> +unsigned int offset_end = n_pages * PAGE_SIZE - size;
> 
> Shouldn't offset_end be equal to n_page * PAGE_SIZE - size - offset ?
> 
>> +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;
> 
> This will shadow the size parameter, it's a bit confusing. You could rename 
> it 
> chunk_size.
> 
>> +unsigned int j;
>> +
>> +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 offset_end if chunk ends at the last page */
>> +if (j == n_pages)
>> +size -= offset_end;
>> +
>> +sg_set_page(s, pages[cur_page], size, offset);
>> +offset = 0;
> 
> What about just
> 
>   chunk_size -= offset;
>   sg_set_page(s, pages[cur_page], min(size, chunk_size), offset);
>   size -= chunk_size;
>   offset = 0;
> 
> You could then remove the offset_end calculation above.
> 
>> +cur_page = j;
>> +}
>> +
>> +return sgt;
>> +}
> 

[PATCH 10/13] drm/radeon: return -ENOENT in fence_wait_*

[Christian König]

On 20.04.2012 09:20, Michel D?nzer wrote:
> On Fre, 2012-04-20 at 00:39 +0200, Christian K?nig wrote:
>> Signed-off-by: Christian K?nig
>> ---
>>   drivers/gpu/drm/radeon/radeon_fence.c |4 ++--
>>   1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
>> b/drivers/gpu/drm/radeon/radeon_fence.c
>> index 1a9765a..764ab7e 100644
>> --- a/drivers/gpu/drm/radeon/radeon_fence.c
>> +++ b/drivers/gpu/drm/radeon/radeon_fence.c
>> @@ -286,7 +286,7 @@ int radeon_fence_wait_next(struct radeon_device *rdev, 
>> int ring)
>>  }
>>  if (list_empty(>fence_drv[ring].emitted)) {
>>  write_unlock_irqrestore(>fence_lock, irq_flags);
>> -return 0;
>> +return -ENOENT;
>>  }
>>  fence = list_entry(rdev->fence_drv[ring].emitted.next,
>> struct radeon_fence, list);
>> @@ -310,7 +310,7 @@ int radeon_fence_wait_last(struct radeon_device *rdev, 
>> int ring)
>>  }
>>  if (list_empty(>fence_drv[ring].emitted)) {
>>  write_unlock_irqrestore(>fence_lock, irq_flags);
>> -return 0;
>> +return -ENOENT;
>>  }
>>  fence = list_entry(rdev->fence_drv[ring].emitted.prev,
>> struct radeon_fence, list);
> It seems weird to declare a fence wait as failed when there are no
> outstanding fences in the first place. If there are callers which
> require outstanding fences, they should probably handle that themselves.

Why that sounds so weird? Ok, maybe for radeon_fence_wait_last that's 
questionable, but for radeon_fence_wait_next it's quite clear to me that 
we should signal the caller that there is no fence to wait for.

The problem I wanted to fix with that is the usage of 
radeon_fence_wait_next in radeon_ring_alloc (for example):
> int radeon_ring_alloc(struct radeon_device *rdev, struct radeon_ring 
> *ring, unsigned ndw)
> {
> int r;
>
> /* Align requested size with padding so unlock_commit can
>  * pad safely */
> ndw = (ndw + ring->align_mask) & ~ring->align_mask;
> while (ndw > (ring->ring_free_dw - 1)) {
> radeon_ring_free_size(rdev, ring);
> if (ndw < ring->ring_free_dw) {
> break;
> }
> r = radeon_fence_wait_next(rdev, 
> radeon_ring_index(rdev, ring));
> if (r)
> return r;
> }
> ring->count_dw = ndw;
> ring->wptr_old = ring->wptr;
> return 0;
> }
If the ring is full, but actually has no more fences in it (which in my 
case was caused by my stupidity and actually shouldn't happen otherwise) 
this loop will just busy wait with a critical mutex locked for something 
that never happens.

It actually shouldn't make any difference for real world applications, 
but it just prevents the users of those functions from doing something 
stupid.

Christian.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #26 from Tvrtko Ursulin  2012-04-20 
03:45:09 PDT ---
Other than that we are testing your patch on a wider range of monitors/displays
and if that goes well will take it.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 48772] Signal unstable over Display Port on 2560x1440 monitor

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=48772

--- Comment #10 from Tvrtko Ursulin  2012-04-20 
03:43:13 PDT ---
Does the driver know it's memory bandwidth so it could remove modes it cannot
drive from the list?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH v4 02/14] Documentation: media: description of DMABUF importing in V4L2

[Tomasz Stanislawski]

Hi Mauro,

On 04/19/2012 10:37 PM, Mauro Carvalho Chehab wrote:
> Em 19-04-2012 11:32, Tomasz Stanislawski escreveu:
>  
>> Hi Laurent,
>>
>> One may find similar sentences in MMAP, USERPTR and DMABUF.
>> Maybe the common parts like description of STREAMON/OFF,
>> QBUF/DQBUF shuffling should be moved to separate section
>> like "Streaming" :).
>>
>> Maybe it is worth to introduce a separate patch for this change.
>>
>> Frankly, I would prefer to keep the Doc in the current form till
>> importer support gets merged. Later the Doc could be fixed.
>>
>> BTW. What is the sense of merging userptr and dmabuf section
>> if userptr is going to dropped in long-term?
> 
> I didn't read yet the rest of the thread, so sorry, if I'm making wrong 
> assumptions...
> Am I understanding wrong or are you saying that you want to drop userptr
> from V4L2 API in long-term? If so, why?

Dropping userptr is just some brainstorming idea.
It was found out that userptr is not a good mean
for buffer exchange between to two devices.
The USERPTR simplifies userspace code but introduce
a lot of complexity problems for the kernel drivers
and frameworks.

The problem is that memory mmaped to the userspace may
not be a part of the system memory. It often happens for
devices that use remap_pfn or dma_mmap_* to mmap the
memory to the userspace.

It is was empirically conjured the it is not possible
to access this kind of memory by the other device
without a platform-specific hacks or workarounds.

The DMABUF was introduced to help in such a case.

The basic short-term idea is to drop userptr support for
buffers that are MMAPed by other device.

The userptr will be used for memory allocated using malloc
(anonymous pages) or (maybe) mmaped files. There are of
course cache synchronization problems but there are
a lesser concern.

However this approach will work only for devices that
have its own IOMMU which can be configured to access system
memory. Otherwise, the memory has to copied anyway
to device's own buffers.

Moreover copying a large amount of data should not happen
in the kernel-space.

All the reasons make userptr an unreliable and complex to
implement feature.

So my rough-idea was to remove USERPTR support from kernel
drivers (if possible of course) and to provide an emulation
layer in the userspace code like libv4l2.

Please note that it is only a rough idea. Just brainstorming :)

It is *too early* to start any discussion on this topic.
Especially until DMABUF is mature enough to become a good
alternative for userptr.

Regards,
Tomasz Stanislawski

> 
> Regards,
> Mauro
> 

[PATCH 0/1] [RFC] DRM locking issues during early open

[Dave Airlie]

On Thu, Apr 19, 2012 at 5:22 PM, Andy Whitcroft  wrote:
> We have been carrying a (rather poor) patch for an issue we identified in
> the DRM driver. ?This issue is triggered when a DRM device is initialising
> and userspace attempts to open it, typically in response to the sysfs
> device added event. ?Basically we allocate the minor numbers making
> the device available, and then call the drm load callback. ?Until this
> completes the device is really not ready and these early opens typically
> lead to oopses.
>
> We have been using the following patch to avoid this by marking the minors
> as in error until the load method has completed. ?This avoids the early
> open by simply erroring out the opens with EAGAIN. ?Obviously we should
> be delaying the open until the load method complete.
>
> I include the existing patch for completness (it is not really ready for
> merging) to illustrate the issue. ?I think it is logical that the wait
> should simply be delayed until the load has completed. ?I am proposing
> to include a wait queue associated with the idr cache for the drm minors
> which we can use to allow open callers to wait_event_interruptible() on.
> I'll be putting together a prototype shortly and will follow up with it.
>
> Thoughts?

I've just revisited this, maybe I'm going insane but why does
drm_global_mutex not stop this?

drm_get_pci_dev takes drm_global_mutex before calling drm_fill_in_dev
and drm_get_minor.

Now the fops should be pointing at stub_open at this point, as we
won't have switched to the per device fops yet,
and one of the first things drm_stub_open does is take the
drm_global_mutex before doing the idr lookup.

So is the problem opening some sysfs or proc file early?

Dave.


>
> -apw
>
> Andy Whitcroft (1):
> ?drm -- stop early access to drm devices
>
> ?drivers/gpu/drm/drm_fops.c ? ? | ? ?8 ++--
> ?drivers/gpu/drm/drm_pci.c ? ? ?| ? ?4 
> ?drivers/gpu/drm/drm_platform.c | ? ?4 
> ?drivers/gpu/drm/drm_stub.c ? ? | ? ?2 +-
> ?4 files changed, 15 insertions(+), 3 deletions(-)
>
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/

[PATCH v4 02/14] Documentation: media: description of DMABUF importing in V4L2

[Mauro Carvalho Chehab]

Em 20-04-2012 07:56, R?mi Denis-Courmont escreveu:
> On Fri, 20 Apr 2012 10:41:37 +0200, Tomasz Stanislawski
>  wrote:
>>> Am I understanding wrong or are you saying that you want to drop
> userptr
>>> from V4L2 API in long-term? If so, why?
>>
>> Dropping userptr is just some brainstorming idea.
>> It was found out that userptr is not a good mean
>> for buffer exchange between to two devices.
> 
> I can believe that. But I am also inclined to believe that DMABUF is
> targetted at device-to-device transfer, while USERPTR is targetted at
> device-to-user (or user-to-device) transfers. Are you saying applications
> should use DMABUF and memory map the buffers? Or would you care to explain
> how DMABUF addresses the problem space of USERPTR?

I agree with R?mi. Userptr were never meant to be used by dev2dev
transfer. The overlay mode were designed for it.

I remember I've pointed it a few times at the mailing list.

The DMABUF is the proper replacement for the overlay mode, and, after
having it fully implemented, we can deprecate and remove the overlay
mode.
> 
>> The USERPTR simplifies userspace code but introduce
>> a lot of complexity problems for the kernel drivers
>> and frameworks.
> 
> It is not only a simplification. In some cases, USERPTR is the only I/O
> method that supports zero copy in pretty much any circumstance. When the
> user cannot reliably predict the maximum number of required buffers,
> predicts a value larger than the device will negotiate, or needs buffers to
> outlive STREAMOFF (?), MMAP requires memory copying. USERPTR does not.

Yes, that's my understand too. USERPTR works helps to
avoid buffer copying.
> 
> Now, I do realize that some devices cannot support USERPTR efficiently,
> then they should not support USERPTR. But for those devices that can, it
> seems quite a nice performance enhancement.

Agreed.

A quick note about that: for USB devices, with the current implementations,
there will always be a copy inside the Kernel, as the USB and other transport
headers should be removed.

For them, the cost of MMAP and USERPTR is the same (not all USB drivers
export USERPTR, because of a limitation at videobuf-vmalloc).

>> The problem is that memory mmaped to the userspace may
>> not be a part of the system memory. It often happens for
>> devices that use remap_pfn or dma_mmap_* to mmap the
>> memory to the userspace.
>> 
>> It is was empirically conjured the it is not possible
>> to access this kind of memory by the other device
>> without a platform-specific hacks or workarounds.

As I warned in the past: USERPTR were never meant to be used 
for dev2dev transfers.

>> 
>> The DMABUF was introduced to help in such a case.
>> 
>> The basic short-term idea is to drop userptr support for
>> buffers that are MMAPed by other device.

You should, instead, just drop userptr support on devices where
DMA scatter/gather is not supported, and migrate all dev2dev
use cases to DMABUF.

>> 
>> The userptr will be used for memory allocated using malloc
>> (anonymous pages) or (maybe) mmaped files. There are of
>> course cache synchronization problems but there are
>> a lesser concern.
>> 
>> However this approach will work only for devices that
>> have its own IOMMU which can be configured to access system
>> memory. Otherwise, the memory has to copied anyway
>> to device's own buffers.
>> 
>> Moreover copying a large amount of data should not happen
>> in the kernel-space.
>> 
>> All the reasons make userptr an unreliable and complex to
>> implement feature.
>> 
>> So my rough-idea was to remove USERPTR support from kernel
>> drivers (if possible of course) and to provide an emulation
>> layer in the userspace code like libv4l2.
>> 
>> Please note that it is only a rough idea. Just brainstorming :)

> It is *too early* to start any discussion on this topic.
> Especially until DMABUF is mature enough to become a good
> alternative for userptr.

Looking at the hole picture, dropping USERPTR would only make 
sense if it is broken on dev2user (or user2dev) transfers.

Dropping its usage on dev2dev transfers makes sense, after having
DMABUF implemented. 

Yet, if some userspace application wants to abuse of USERPTR in order
to use it for dev2dev transfer, there's not much that can be done at 
Kernel level.

It makes sense to put a big warn at the V4L2 Docs telling that this
is not officially supported and can cause all sorts of issues at
the machine/system.

Regards,
Mauro

[Bug 46711] Monitor not turning on after DisplayPort re-plug in Xorg

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=46711

--- Comment #17 from Tvrtko Ursulin  2012-04-20 
03:07:55 PDT ---
Still leaves the monitor in that weird state (black screen but not powersave,
can't get to OSD menu) after re-plug.

"xset dpms force off" can put it into proper power save.

"xset dpms force on" then makes it work.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #25 from Tvrtko Ursulin  2012-04-20 
03:01:35 PDT ---
(In reply to comment #22)
> Created attachment 60315 [details] [review]
> possible fix
> 
> use fract fb div on APUs.  Tested on all the hw I have available.  Does this
> patch help with bug 48772 as well?

Doesn't seem to do anything for 48772.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 13/13] drm/radeon: rework recursive gpu reset handling

[Daniel Vetter]

On Fri, Apr 20, 2012 at 07:57:09AM +0100, Dave Airlie wrote:
> 2012/4/19 Christian K?nig :
> > Instead of all this humpy pumpy with recursive
> > mutex (which also fixes only halve of the problem)
> > move the actual gpu reset out of the fence code,
> > return -EDEADLK and then reset the gpu in the
> > calling ioctl function.
> 
> I'm trying to figure out if this has any disadvantages over doing what
> I proposed before and just kicking a thread to reset the gpu.
> 
> It seems like this should also avoid the locking problems, I'd like to
> make sure we don't return -EDEADLK to userspace by accident anywhere,
> since I don't think it prepared for it and it would be an ABI change.

Fyi, the trick i915 uses to solve the reset problem is to bail out with
-EAGAIN and rely on drmIOCtl restarting the ioctl. This way we use the
same codepaths we use to bail out when getting a signal, and thanks to X
these are rather well-tested. The hangcheck code also fires of a work item to
do all the reset magic. In all the ioctls that might wait for the gpu we
have a fancy piece of code which checks whether a gpu reset is pending,
and if so waits for that to complete. It also checks whether the reset
succeeded and if not bails out with -EIO.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH 06/13] drm/radeon: improve sub allocator

[Michel Dänzer]

On Fre, 2012-04-20 at 00:39 +0200, Christian K?nig wrote: 
> Make the suballocator self containing to locking
> and fix a overrun bug which happens with
> allocations of different alignments.

Sounds like this should be split up into two changes. :)


-- 
Earthling Michel D?nzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer

[PATCH 1/4] drm: Move drm_format_num_planes() to drm_crtc.c

[Rob Clark]

On Fri, Apr 20, 2012 at 8:49 AM, Ville Syrj?l?
 wrote:
> On Fri, Apr 20, 2012 at 07:48:07AM -0500, Rob Clark wrote:
>> On Fri, Apr 20, 2012 at 7:29 AM, Dave Airlie  wrote:
>> > On Fri, Apr 20, 2012 at 1:23 PM, Ville Syrj?l?
>> >  wrote:
>> >> On Fri, Apr 20, 2012 at 12:43:03PM +0100, Dave Airlie wrote:
>> >>> On Thu, Apr 5, 2012 at 7:35 PM, ? 
>> >>> wrote:
>> >>> > From: Ville Syrj?l? 
>> >>> >
>> >>> > There will be a need for this function in drm_crtc.c later. This
>> >>> > avoids making drm_crtc.c depend on drm_crtc_helper.c.
>> >>>
>> >>> Hi Ville,
>> >>>
>> >>> I've applied these 4 patches, but I might have lost some others for
>> >>> you, let me know if there is some other stuff I should be reviewing
>> >>> for -next.
>> >>
>> >> IIRC only one patch fell through the cracks:
>> >> Subject: [PATCH] drm: Unify and fix idr error handling
>> >> Message-Id: <1331834311-30757-1-git-send-email-ville.syrjala at 
>> >> linux.intel.com>
>> >
>> > Thanks I'll take a look at that,
>> >
>> >>
>> >> BTW you never gave any statement wrt. removing NV12M and YUV420M from
>> >> drm_fourcc.h. I can send a patch if you agree, and if not, well then
>> >> someone has to actually change the code to treat them exactly the same
>> >> as NV12 and YUV420.
>> >
>> > I'm probably not qualified, if you and jbarnes and say one other
>> > non-Intel person agree, then send the patch with R-b and I'll apply
>> > it.
>>
>> I agree that they seem like the same thing (as their non-M
>> counterparts) to me.. ?maybe the one exception is if there was hw that
>> somehow *only* supported discontiguous multi-planar.
>
> The way things are currently, anyone can feed the driver either
> contiguous or discontiguous planes using either format.
>
> As a hint to userspace the M version might work, except it still
> doesn't tell you anything on how you need to allocate or align the
> planes. Since memory allocation is driver specific anyway, I see no
> point in overloading the pixel formats with that information. Some
> other mechanism to communicate such information would be needed if
> there is a desire to make it generic.
>
>> I can't really
>> tell if this is the case in current exynos, it seems to only advertise
>> XRGB (but possibly I'm looking in the wrong place).
>>
>> For drivers that have weird requirements, I'd suggest they use the non
>> 7-bit ascii space (ie. one or more of bytes in fourcc is non-ascii, so
>> as to not conflict with potential future standard fourcc's) driver
>> specific format values.
>
> We could define a DRM_FORMAT_DRIVER_SPECIFIC bit just like we have

yeah, that is a good idea

> DRM_FORMAT_BIG_ENDIAN. We still have three bits to choose from. OTOH
> I'm not too worried about standard fourccs since we already differ
> from the standard names anyway.

well, was more just thinking from the point of view of clashes if we
add more standard names later but some driver somewhere was already
using that new fourcc name

Possibly I'm over-thinking this.. but seemed like a reasonable thing
to separate standard and non-standard formats before a bunch of driver
specific formats start cropping up.

BR,
-R

> --
> Ville Syrj?l?
> Intel OTC
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 10/13] drm/radeon: return -ENOENT in fence_wait_*

[Michel Dänzer]

On Fre, 2012-04-20 at 00:39 +0200, Christian K?nig wrote: 
> Signed-off-by: Christian K?nig 
> ---
>  drivers/gpu/drm/radeon/radeon_fence.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
> b/drivers/gpu/drm/radeon/radeon_fence.c
> index 1a9765a..764ab7e 100644
> --- a/drivers/gpu/drm/radeon/radeon_fence.c
> +++ b/drivers/gpu/drm/radeon/radeon_fence.c
> @@ -286,7 +286,7 @@ int radeon_fence_wait_next(struct radeon_device *rdev, 
> int ring)
>   }
>   if (list_empty(>fence_drv[ring].emitted)) {
>   write_unlock_irqrestore(>fence_lock, irq_flags);
> - return 0;
> + return -ENOENT;
>   }
>   fence = list_entry(rdev->fence_drv[ring].emitted.next,
>  struct radeon_fence, list);
> @@ -310,7 +310,7 @@ int radeon_fence_wait_last(struct radeon_device *rdev, 
> int ring)
>   }
>   if (list_empty(>fence_drv[ring].emitted)) {
>   write_unlock_irqrestore(>fence_lock, irq_flags);
> - return 0;
> + return -ENOENT;
>   }
>   fence = list_entry(rdev->fence_drv[ring].emitted.prev,
>  struct radeon_fence, list);

It seems weird to declare a fence wait as failed when there are no
outstanding fences in the first place. If there are callers which
require outstanding fences, they should probably handle that themselves.


-- 
Earthling Michel D?nzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer

[RFC 0/4] Add NVIDIA Tegra DRM support

[Lucas Stach]

Am Freitag, den 20.04.2012, 07:02 +0200 schrieb Thierry Reding:
> * Jon Mayo wrote:
> > On 04/19/2012 01:40 PM, Thierry Reding wrote:
> [...]
> > >So would it be possible to get a basic dumb KMS driver into mainline
> > >(non-staging) and phase in acceleration later on, with ABI guarantees? I
> > >guess development can go on in separate trees until the ABI is stable and 
> > >can
> > >subsequently be ported to the mainline driver.
> > >
> > >Is that an acceptable approach?
> > 
> > That certainly seems like the most reasonable approach to me. Get
> > KMS only in first. It's a useful driver as-is, and has the lowest
> > barrier to entry into upstream.
> > 
> > Then later we can phase in enhancements. We certainly have plenty of
> > places internally and externally to hash out acceleration
> > interfaces, and come to some consensus at at later date (either on
> > linux-tegra or direct email).
> 
> Okay. Let's do that then.

Yes, I think we should go the route that Jerome Glisse pointed out: get
in a basic KMS driver first and hide any accel ioctl under a staging
config option.
> 
> > We have a lot of concerns here. What is best for X11, what is best
> > for Android, how do we keep healthy open source implementations, and
> > how does NVIDIA move forward with supporting new Tegra on an open
> > source implementation.
> 
> I think by supporting the DRM we can get pretty far for X11. Writing a Tegra-
> specific driver based off xf86-video-modesetting can be done to use advanced
> features if they can't be abstracted away properly. DRM also paves the way
> for Wayland support.
> 
> What I see as somewhat of a problem is how to get NVIDIA and the community to
> work together (and work together well). We'll have to see how this works out,
> but I'd hate to see more resources wasted because everybody starts doing
> their own thing.

I'm really interested how this turns out in the end. I hope we can get a
somewhat stable cooperation between NVIDIA and the community, like AMD
has established at the moment.
> 
> > (My vote is NVIDIA starts using this DRM in-house and builds new
> > extensions on top of it, sharing patches on LKML when the hardware is
> > released)
> 
> That sounds like a good plan. Ideally you should even share the patches as
> soon as they're ready. That'll give viewers some head start and you can fix
> the code even before the hardware is released.

One thing I would like to have is upstream first. We have seen much
Tegra development in both the nv-linux and chromium trees, but those
things are going upstream extremely slowly. I can understand that this
strategy was beneficial for a fast bring up of the new Tegra hardware,
but the DRM driver shouldn't be time critical and so everything should
be done to meet upstream quality from the start.

-- Lucas

[PATCH 13/13] drm/radeon: rework recursive gpu reset handling

[Dave Airlie]

2012/4/19 Christian K?nig :
> Instead of all this humpy pumpy with recursive
> mutex (which also fixes only halve of the problem)
> move the actual gpu reset out of the fence code,
> return -EDEADLK and then reset the gpu in the
> calling ioctl function.

I'm trying to figure out if this has any disadvantages over doing what
I proposed before and just kicking a thread to reset the gpu.

It seems like this should also avoid the locking problems, I'd like to
make sure we don't return -EDEADLK to userspace by accident anywhere,
since I don't think it prepared for it and it would be an ABI change.

Dave.

[PATCH 1/4] drm: Move drm_format_num_planes() to drm_crtc.c

[Rob Clark]

On Fri, Apr 20, 2012 at 7:29 AM, Dave Airlie  wrote:
> On Fri, Apr 20, 2012 at 1:23 PM, Ville Syrj?l?
>  wrote:
>> On Fri, Apr 20, 2012 at 12:43:03PM +0100, Dave Airlie wrote:
>>> On Thu, Apr 5, 2012 at 7:35 PM, ? wrote:
>>> > From: Ville Syrj?l? 
>>> >
>>> > There will be a need for this function in drm_crtc.c later. This
>>> > avoids making drm_crtc.c depend on drm_crtc_helper.c.
>>>
>>> Hi Ville,
>>>
>>> I've applied these 4 patches, but I might have lost some others for
>>> you, let me know if there is some other stuff I should be reviewing
>>> for -next.
>>
>> IIRC only one patch fell through the cracks:
>> Subject: [PATCH] drm: Unify and fix idr error handling
>> Message-Id: <1331834311-30757-1-git-send-email-ville.syrjala at 
>> linux.intel.com>
>
> Thanks I'll take a look at that,
>
>>
>> BTW you never gave any statement wrt. removing NV12M and YUV420M from
>> drm_fourcc.h. I can send a patch if you agree, and if not, well then
>> someone has to actually change the code to treat them exactly the same
>> as NV12 and YUV420.
>
> I'm probably not qualified, if you and jbarnes and say one other
> non-Intel person agree, then send the patch with R-b and I'll apply
> it.

I agree that they seem like the same thing (as their non-M
counterparts) to me..  maybe the one exception is if there was hw that
somehow *only* supported discontiguous multi-planar.  I can't really
tell if this is the case in current exynos, it seems to only advertise
XRGB (but possibly I'm looking in the wrong place).

For drivers that have weird requirements, I'd suggest they use the non
7-bit ascii space (ie. one or more of bytes in fourcc is non-ascii, so
as to not conflict with potential future standard fourcc's) driver
specific format values.

BR,
-R

> Dave.
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 0/4] Add NVIDIA Tegra DRM support

[Thierry Reding]

* Jerome Glisse wrote:
> Or you can hide the accel ioctl behing a staging/experimental kernel
> option that give you right to change the ABI and do everything upstream.
> Once you like your abi you just remove the option and enable the
> ioctl for the default case.

If it's acceptable, that sound like the most promising way to go.

Thanks,
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120420/7c13f3b6/attachment.pgp>

[RFC 0/4] Add NVIDIA Tegra DRM support

[Thierry Reding]

* Jon Mayo wrote:
> On 04/19/2012 01:40 PM, Thierry Reding wrote:
[...]
> >So would it be possible to get a basic dumb KMS driver into mainline
> >(non-staging) and phase in acceleration later on, with ABI guarantees? I
> >guess development can go on in separate trees until the ABI is stable and can
> >subsequently be ported to the mainline driver.
> >
> >Is that an acceptable approach?
> 
> That certainly seems like the most reasonable approach to me. Get
> KMS only in first. It's a useful driver as-is, and has the lowest
> barrier to entry into upstream.
> 
> Then later we can phase in enhancements. We certainly have plenty of
> places internally and externally to hash out acceleration
> interfaces, and come to some consensus at at later date (either on
> linux-tegra or direct email).

Okay. Let's do that then.

> We have a lot of concerns here. What is best for X11, what is best
> for Android, how do we keep healthy open source implementations, and
> how does NVIDIA move forward with supporting new Tegra on an open
> source implementation.

I think by supporting the DRM we can get pretty far for X11. Writing a Tegra-
specific driver based off xf86-video-modesetting can be done to use advanced
features if they can't be abstracted away properly. DRM also paves the way
for Wayland support.

What I see as somewhat of a problem is how to get NVIDIA and the community to
work together (and work together well). We'll have to see how this works out,
but I'd hate to see more resources wasted because everybody starts doing
their own thing.

> (My vote is NVIDIA starts using this DRM in-house and builds new
> extensions on top of it, sharing patches on LKML when the hardware is
> released)

That sounds like a good plan. Ideally you should even share the patches as
soon as they're ready. That'll give viewers some head start and you can fix
the code even before the hardware is released.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120420/541539e0/attachment.pgp>

[Bug 48935] [r600g] WebGL conformance test textures/texture-mips.html fails

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=48935

--- Comment #1 from Pavel Ondra?ka  2012-04-19 
23:05:25 PDT ---
Most likely a duplicate of bug 44912.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 13/13] drm/radeon: rework recursive gpu reset handling

[Christian König]

Instead of all this humpy pumpy with recursive
mutex (which also fixes only halve of the problem)
move the actual gpu reset out of the fence code,
return -EDEADLK and then reset the gpu in the
calling ioctl function.

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon.h|   44 +---
 drivers/gpu/drm/radeon/radeon_cs.c |   21 +++---
 drivers/gpu/drm/radeon/radeon_device.c |7 +
 drivers/gpu/drm/radeon/radeon_fence.c  |   10 ++-
 drivers/gpu/drm/radeon/radeon_gart.c   |   16 ++--
 drivers/gpu/drm/radeon/radeon_gem.c|   14 ++
 6 files changed, 43 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 5912cab..aadc334 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -155,48 +155,6 @@ static inline int radeon_atrm_get_bios_chunk(uint8_t 
*bios, int offset, int len)
 #endif
 bool radeon_get_bios(struct radeon_device *rdev);

-
-/*
- * Mutex which allows recursive locking from the same process.
- */
-struct radeon_mutex {
-   struct mutexmutex;
-   struct task_struct  *owner;
-   int level;
-};
-
-static inline void radeon_mutex_init(struct radeon_mutex *mutex)
-{
-   mutex_init(>mutex);
-   mutex->owner = NULL;
-   mutex->level = 0;
-}
-
-static inline void radeon_mutex_lock(struct radeon_mutex *mutex)
-{
-   if (mutex_trylock(>mutex)) {
-   /* The mutex was unlocked before, so it's ours now */
-   mutex->owner = current;
-   } else if (mutex->owner != current) {
-   /* Another process locked the mutex, take it */
-   mutex_lock(>mutex);
-   mutex->owner = current;
-   }
-   /* Otherwise the mutex was already locked by this process */
-
-   mutex->level++;
-}
-
-static inline void radeon_mutex_unlock(struct radeon_mutex *mutex)
-{
-   if (--mutex->level > 0)
-   return;
-
-   mutex->owner = NULL;
-   mutex_unlock(>mutex);
-}
-
-
 /*
  * Dummy page
  */
@@ -1497,7 +1455,7 @@ struct radeon_device {
struct radeon_gem   gem;
struct radeon_pmpm;
uint32_tbios_scratch[RADEON_BIOS_NUM_SCRATCH];
-   struct radeon_mutex cs_mutex;
+   struct mutexcs_mutex;
struct radeon_wbwb;
struct radeon_dummy_pagedummy_page;
boolshutdown;
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index de40d33..2486b21 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -496,15 +496,23 @@ out:
return r;
 }

+static int radeon_cs_handle_lockup(struct radeon_device *rdev, int r)
+{
+   if (r == -EDEADLK) {
+   r = radeon_gpu_reset(rdev);
+   }
+   return r;
+}
+
 int radeon_cs_ioctl(struct drm_device *dev, void *data, struct drm_file *filp)
 {
struct radeon_device *rdev = dev->dev_private;
struct radeon_cs_parser parser;
int r;

-   radeon_mutex_lock(>cs_mutex);
+   mutex_lock(>cs_mutex);
if (!rdev->accel_working) {
-   radeon_mutex_unlock(>cs_mutex);
+   mutex_unlock(>cs_mutex);
return -EBUSY;
}
/* initialize parser */
@@ -517,7 +525,8 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
if (r) {
DRM_ERROR("Failed to initialize parser !\n");
radeon_cs_parser_fini(, r);
-   radeon_mutex_unlock(>cs_mutex);
+   r = radeon_cs_handle_lockup(rdev, r);
+   mutex_unlock(>cs_mutex);
return r;
}
r = radeon_cs_parser_relocs();
@@ -525,7 +534,8 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
if (r != -ERESTARTSYS)
DRM_ERROR("Failed to parse relocation %d!\n", r);
radeon_cs_parser_fini(, r);
-   radeon_mutex_unlock(>cs_mutex);
+   r = radeon_cs_handle_lockup(rdev, r);
+   mutex_unlock(>cs_mutex);
return r;
}
r = radeon_cs_ib_chunk(rdev, );
@@ -538,7 +548,8 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
}
 out:
radeon_cs_parser_fini(, r);
-   radeon_mutex_unlock(>cs_mutex);
+   r = radeon_cs_handle_lockup(rdev, r);
+   mutex_unlock(>cs_mutex);
return r;
 }

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 9189f8d..04f3f40 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -722,7 +722,7 @@ int radeon_device_init(struct radeon_device *rdev,

/* mutex 

[PATCH 12/13] drm/radeon: fix a bug with the ring syncing code

[Christian König]

Rings need to lock in order, otherwise
the ring subsystem can deadlock.

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon.h   |4 ++
 drivers/gpu/drm/radeon/radeon_cs.c|   33 ++
 drivers/gpu/drm/radeon/radeon_semaphore.c |   53 +
 drivers/gpu/drm/radeon/radeon_ttm.c   |   46 +++--
 4 files changed, 88 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index d46d5ac..5912cab 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -442,6 +442,10 @@ void radeon_semaphore_emit_signal(struct radeon_device 
*rdev, int ring,
  struct radeon_semaphore *semaphore);
 void radeon_semaphore_emit_wait(struct radeon_device *rdev, int ring,
struct radeon_semaphore *semaphore);
+int radeon_semaphore_sync_rings(struct radeon_device *rdev,
+   struct radeon_semaphore *semaphore,
+   bool sync_to[RADEON_NUM_RINGS],
+   int dst_ring);
 void radeon_semaphore_free(struct radeon_device *rdev,
   struct radeon_semaphore *semaphore);

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index e7b0b5d..de40d33 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -118,6 +118,7 @@ static int radeon_cs_get_ring(struct radeon_cs_parser *p, 
u32 ring, s32 priority
 static int radeon_cs_sync_rings(struct radeon_cs_parser *p)
 {
bool sync_to_ring[RADEON_NUM_RINGS] = { };
+   bool need_sync = false;
int i, r;

for (i = 0; i < p->nrelocs; i++) {
@@ -128,34 +129,22 @@ static int radeon_cs_sync_rings(struct radeon_cs_parser 
*p)
struct radeon_fence *fence = 
p->relocs[i].robj->tbo.sync_obj;
if (!radeon_fence_signaled(fence)) {
sync_to_ring[fence->ring] = true;
+   need_sync = true;
}
}
}

-   for (i = 0; i < RADEON_NUM_RINGS; ++i) {
-   /* no need to sync to our own or unused rings */
-   if (i == p->ring || !sync_to_ring[i] || !p->rdev->ring[i].ready)
-   continue;
-
-   if (!p->ib->fence->semaphore) {
-   r = radeon_semaphore_create(p->rdev, 
>ib->fence->semaphore);
-   if (r)
-   return r;
-   }
-
-   r = radeon_ring_lock(p->rdev, >rdev->ring[i], 3);
-   if (r)
-   return r;
-   radeon_semaphore_emit_signal(p->rdev, i, 
p->ib->fence->semaphore);
-   radeon_ring_unlock_commit(p->rdev, >rdev->ring[i]);
+   if (!need_sync) {
+   return 0;
+   }

-   r = radeon_ring_lock(p->rdev, >rdev->ring[p->ring], 3);
-   if (r)
-   return r;
-   radeon_semaphore_emit_wait(p->rdev, p->ring, 
p->ib->fence->semaphore);
-   radeon_ring_unlock_commit(p->rdev, >rdev->ring[p->ring]);
+   r = radeon_semaphore_create(p->rdev, >ib->fence->semaphore);
+   if (r) {
+   return r;
}
-   return 0;
+
+   return radeon_semaphore_sync_rings(p->rdev, p->ib->fence->semaphore,
+  sync_to_ring, p->ring);
 }

 int radeon_cs_parser_init(struct radeon_cs_parser *p, void *data)
diff --git a/drivers/gpu/drm/radeon/radeon_semaphore.c 
b/drivers/gpu/drm/radeon/radeon_semaphore.c
index a09cc05..ff1ce90 100644
--- a/drivers/gpu/drm/radeon/radeon_semaphore.c
+++ b/drivers/gpu/drm/radeon/radeon_semaphore.c
@@ -75,6 +75,59 @@ void radeon_semaphore_emit_wait(struct radeon_device *rdev, 
int ring,
radeon_semaphore_ring_emit(rdev, ring, >ring[ring], semaphore, 
true);
 }

+int radeon_semaphore_sync_rings(struct radeon_device *rdev,
+   struct radeon_semaphore *semaphore,
+   bool sync_to[RADEON_NUM_RINGS],
+   int dst_ring)
+{
+   int i, r;
+
+   for (i = 0; i < RADEON_NUM_RINGS; ++i) {
+   unsigned num_ops = i == dst_ring ? RADEON_NUM_RINGS : 1;
+
+   /* don't lock unused rings */
+   if (!sync_to[i] && i != dst_ring)
+   continue;
+
+   /* prevent GPU deadlocks */
+   if (!rdev->ring[i].ready) {
+   dev_err(rdev->dev, "Trying to sync to a disabled 
ring!");
+   r = -EINVAL;
+   goto error;
+   }
+
+r = radeon_ring_lock(rdev, >ring[i], num_ops * 4);
+if (r)
+   goto error;
+   }
+
+   for (i = 0; i < 

[PATCH 11/13] drm/radeon: rip out the ib pool

[Christian König]

It isn't necessary any more and the suballocator
seems to perform even better.

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon.h   |   22 +--
 drivers/gpu/drm/radeon/radeon_device.c|1 -
 drivers/gpu/drm/radeon/radeon_fence.c |   44 +-
 drivers/gpu/drm/radeon/radeon_gart.c  |   12 +-
 drivers/gpu/drm/radeon/radeon_ring.c  |  240 
 drivers/gpu/drm/radeon/radeon_semaphore.c |6 +-
 6 files changed, 123 insertions(+), 202 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 222939f..d46d5ac 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -249,6 +249,8 @@ extern void evergreen_tiling_fields(unsigned tiling_flags, 
unsigned *bankw,
 /*
  * Fences.
  */
+struct radeon_ib;
+
 struct radeon_fence_driver {
uint32_tscratch_reg;
uint64_tgpu_addr;
@@ -259,7 +261,6 @@ struct radeon_fence_driver {
wait_queue_head_t   queue;
struct list_headcreated;
struct list_heademitted;
-   struct list_headsignaled;
boolinitialized;
 };

@@ -274,6 +275,7 @@ struct radeon_fence {
/* RB, DMA, etc. */
int ring;
struct radeon_semaphore *semaphore;
+   struct radeon_ib*ib;
 };

 int radeon_fence_driver_start_ring(struct radeon_device *rdev, int ring);
@@ -289,6 +291,7 @@ int radeon_fence_wait_last(struct radeon_device *rdev, int 
ring);
 struct radeon_fence *radeon_fence_ref(struct radeon_fence *fence);
 void radeon_fence_unref(struct radeon_fence **fence);
 int radeon_fence_count_emitted(struct radeon_device *rdev, int ring);
+bool radeon_fence_set_associated_ib(struct radeon_fence *fence, struct 
radeon_ib *ib);

 /*
  * Tiling registers
@@ -603,7 +606,6 @@ void radeon_irq_kms_pflip_irq_put(struct radeon_device 
*rdev, int crtc);

 struct radeon_ib {
struct radeon_sa_bo sa_bo;
-   unsignedidx;
uint32_tlength_dw;
uint64_tgpu_addr;
uint32_t*ptr;
@@ -612,18 +614,6 @@ struct radeon_ib {
boolis_const_ib;
 };

-/*
- * locking -
- * mutex protects scheduled_ibs, ready, alloc_bm
- */
-struct radeon_ib_pool {
-   struct radeon_mutex mutex;
-   struct radeon_sa_managersa_manager;
-   struct radeon_ibibs[RADEON_IB_POOL_SIZE];
-   boolready;
-   unsignedhead_id;
-};
-
 struct radeon_ring {
struct radeon_bo*ring_obj;
volatile uint32_t   *ring;
@@ -764,7 +754,6 @@ struct si_rlc {
 int radeon_ib_get(struct radeon_device *rdev, int ring,
  struct radeon_ib **ib, unsigned size);
 void radeon_ib_free(struct radeon_device *rdev, struct radeon_ib **ib);
-bool radeon_ib_try_free(struct radeon_device *rdev, struct radeon_ib *ib);
 int radeon_ib_schedule(struct radeon_device *rdev, struct radeon_ib *ib);
 int radeon_ib_pool_init(struct radeon_device *rdev);
 void radeon_ib_pool_fini(struct radeon_device *rdev);
@@ -1497,7 +1486,8 @@ struct radeon_device {
rwlock_tfence_lock;
struct radeon_fence_driver  fence_drv[RADEON_NUM_RINGS];
struct radeon_ring  ring[RADEON_NUM_RINGS];
-   struct radeon_ib_pool   ib_pool;
+   boolib_pool_ready;
+   struct radeon_sa_managersa_manager;
struct radeon_irq   irq;
struct radeon_asic  *asic;
struct radeon_gem   gem;
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 8c49990..9189f8d 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -723,7 +723,6 @@ int radeon_device_init(struct radeon_device *rdev,
/* mutex initialization are all done here so we
 * can recall function without having locking issues */
radeon_mutex_init(>cs_mutex);
-   radeon_mutex_init(>ib_pool.mutex);
for (i = 0; i < RADEON_NUM_RINGS; ++i)
mutex_init(>ring[i].mutex);
mutex_init(>dc_hw_i2c_mutex);
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
b/drivers/gpu/drm/radeon/radeon_fence.c
index 764ab7e..0e8ac35 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -83,7 +83,8 @@ int radeon_fence_emit(struct radeon_device *rdev, struct 
radeon_fence *fence)
return 0;
 }

-static bool radeon_fence_poll_locked(struct radeon_device *rdev, int ring)
+static bool radeon_fence_poll_locked(struct radeon_device *rdev, int ring,
+struct list_head 

[PATCH 10/13] drm/radeon: return -ENOENT in fence_wait_*

[Christian König]

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon_fence.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
b/drivers/gpu/drm/radeon/radeon_fence.c
index 1a9765a..764ab7e 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -286,7 +286,7 @@ int radeon_fence_wait_next(struct radeon_device *rdev, int 
ring)
}
if (list_empty(>fence_drv[ring].emitted)) {
write_unlock_irqrestore(>fence_lock, irq_flags);
-   return 0;
+   return -ENOENT;
}
fence = list_entry(rdev->fence_drv[ring].emitted.next,
   struct radeon_fence, list);
@@ -310,7 +310,7 @@ int radeon_fence_wait_last(struct radeon_device *rdev, int 
ring)
}
if (list_empty(>fence_drv[ring].emitted)) {
write_unlock_irqrestore(>fence_lock, irq_flags);
-   return 0;
+   return -ENOENT;
}
fence = list_entry(rdev->fence_drv[ring].emitted.prev,
   struct radeon_fence, list);
-- 
1.7.5.4

[PATCH 09/13] drm/radeon: simplify semaphore handling

[Christian König]

Directly use the suballocator to get small chunks
of memory. It's equally fast and doesn't crash when
we encounter a GPU reset.

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/evergreen.c|1 -
 drivers/gpu/drm/radeon/ni.c   |1 -
 drivers/gpu/drm/radeon/r600.c |1 -
 drivers/gpu/drm/radeon/radeon.h   |   29 +--
 drivers/gpu/drm/radeon/radeon_device.c|2 -
 drivers/gpu/drm/radeon/radeon_semaphore.c |  137 +
 drivers/gpu/drm/radeon/rv770.c|1 -
 drivers/gpu/drm/radeon/si.c   |1 -
 8 files changed, 26 insertions(+), 147 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index ca47f52..a76389c 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3431,7 +3431,6 @@ void evergreen_fini(struct radeon_device *rdev)
evergreen_pcie_gart_fini(rdev);
r600_vram_scratch_fini(rdev);
radeon_gem_fini(rdev);
-   radeon_semaphore_driver_fini(rdev);
radeon_fence_driver_fini(rdev);
radeon_agp_fini(rdev);
radeon_bo_fini(rdev);
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 0146428..c0b0956 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1773,7 +1773,6 @@ void cayman_fini(struct radeon_device *rdev)
cayman_pcie_gart_fini(rdev);
r600_vram_scratch_fini(rdev);
radeon_gem_fini(rdev);
-   radeon_semaphore_driver_fini(rdev);
radeon_fence_driver_fini(rdev);
radeon_bo_fini(rdev);
radeon_atombios_fini(rdev);
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index c749e00..b8d9335 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2672,7 +2672,6 @@ void r600_fini(struct radeon_device *rdev)
r600_vram_scratch_fini(rdev);
radeon_agp_fini(rdev);
radeon_gem_fini(rdev);
-   radeon_semaphore_driver_fini(rdev);
radeon_fence_driver_fini(rdev);
radeon_bo_fini(rdev);
radeon_atombios_fini(rdev);
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 415a496..222939f 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -427,34 +427,12 @@ int radeon_mode_dumb_destroy(struct drm_file *file_priv,
 /*
  * Semaphores.
  */
-struct radeon_ring;
-
-#defineRADEON_SEMAPHORE_BO_SIZE256
-
-struct radeon_semaphore_driver {
-   rwlock_tlock;
-   struct list_headbo;
-};
-
-struct radeon_semaphore_bo;
-
-/* everything here is constant */
 struct radeon_semaphore {
-   struct list_headlist;
-   uint64_tgpu_addr;
-   uint32_t*cpu_ptr;
-   struct radeon_semaphore_bo  *bo;
-};
-
-struct radeon_semaphore_bo {
-   struct list_headlist;
-   struct radeon_ib*ib;
-   struct list_headfree;
-   struct radeon_semaphore semaphores[RADEON_SEMAPHORE_BO_SIZE/8];
-   unsignednused;
+   struct radeon_sa_bo sa_bo;
+   signed  waiters;
+   uint64_tgpu_addr;
 };

-void radeon_semaphore_driver_fini(struct radeon_device *rdev);
 int radeon_semaphore_create(struct radeon_device *rdev,
struct radeon_semaphore **semaphore);
 void radeon_semaphore_emit_signal(struct radeon_device *rdev, int ring,
@@ -1518,7 +1496,6 @@ struct radeon_device {
struct radeon_mman  mman;
rwlock_tfence_lock;
struct radeon_fence_driver  fence_drv[RADEON_NUM_RINGS];
-   struct radeon_semaphore_driver  semaphore_drv;
struct radeon_ring  ring[RADEON_NUM_RINGS];
struct radeon_ib_pool   ib_pool;
struct radeon_irq   irq;
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index dedb398..8c49990 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -733,11 +733,9 @@ int radeon_device_init(struct radeon_device *rdev,
mutex_init(>pm.mutex);
mutex_init(>vram_mutex);
rwlock_init(>fence_lock);
-   rwlock_init(>semaphore_drv.lock);
INIT_LIST_HEAD(>gem.objects);
init_waitqueue_head(>irq.vblank_queue);
init_waitqueue_head(>irq.idle_queue);
-   INIT_LIST_HEAD(>semaphore_drv.bo);
/* initialize vm here */
rdev->vm_manager.use_bitmap = 1;
rdev->vm_manager.max_pfn = 1 << 20;
diff --git a/drivers/gpu/drm/radeon/radeon_semaphore.c 
b/drivers/gpu/drm/radeon/radeon_semaphore.c
index 61dd4e3..4603fab 100644
--- a/drivers/gpu/drm/radeon/radeon_semaphore.c
+++ 

[PATCH 08/13] drm/radeon: add biggest hole tracking and wakequeue to the sa

[Christian König]

With that in place clients are automatically blocking
until their memory request can be handled.

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon.h  |5 +-
 drivers/gpu/drm/radeon/radeon_ring.c |   18 ++--
 drivers/gpu/drm/radeon/radeon_sa.c   |  192 +-
 3 files changed, 153 insertions(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 1aefbd9..415a496 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -381,17 +381,16 @@ struct radeon_bo_list {
  * alignment).
  */
 struct radeon_sa_manager {
-   spinlock_t  lock;
+   wait_queue_head_t   queue;
struct radeon_bo*bo;
struct list_headsa_bo;
unsignedsize;
+   struct list_head*biggest_hole;
uint64_tgpu_addr;
void*cpu_ptr;
uint32_tdomain;
 };

-struct radeon_sa_bo;
-
 /* sub-allocation buffer */
 struct radeon_sa_bo {
struct list_headlist;
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c 
b/drivers/gpu/drm/radeon/radeon_ring.c
index 1d9bce9..5942769 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -205,10 +205,16 @@ int radeon_ib_schedule(struct radeon_device *rdev, struct 
radeon_ib *ib)

 int radeon_ib_pool_init(struct radeon_device *rdev)
 {
-   struct radeon_sa_manager tmp;
int i, r;

-   r = radeon_sa_bo_manager_init(rdev, ,
+   radeon_mutex_lock(>ib_pool.mutex);
+   if (rdev->ib_pool.ready) {
+   return 0;
+   }
+   rdev->ib_pool.ready = true;
+   radeon_mutex_unlock(>ib_pool.mutex);
+
+   r = radeon_sa_bo_manager_init(rdev, >ib_pool.sa_manager,
  RADEON_IB_POOL_SIZE*64*1024,
  RADEON_GEM_DOMAIN_GTT);
if (r) {
@@ -216,14 +222,6 @@ int radeon_ib_pool_init(struct radeon_device *rdev)
}

radeon_mutex_lock(>ib_pool.mutex);
-   if (rdev->ib_pool.ready) {
-   radeon_mutex_unlock(>ib_pool.mutex);
-   radeon_sa_bo_manager_fini(rdev, );
-   return 0;
-   }
-
-   rdev->ib_pool.sa_manager = tmp;
-   INIT_LIST_HEAD(>ib_pool.sa_manager.sa_bo);
for (i = 0; i < RADEON_IB_POOL_SIZE; i++) {
rdev->ib_pool.ibs[i].fence = NULL;
rdev->ib_pool.ibs[i].idx = i;
diff --git a/drivers/gpu/drm/radeon/radeon_sa.c 
b/drivers/gpu/drm/radeon/radeon_sa.c
index 013a787..72ebb77 100644
--- a/drivers/gpu/drm/radeon/radeon_sa.c
+++ b/drivers/gpu/drm/radeon/radeon_sa.c
@@ -26,6 +26,7 @@
 /*
  * Authors:
  *Jerome Glisse 
+ *Christian K?nig 
  */
 #include "drmP.h"
 #include "drm.h"
@@ -37,9 +38,10 @@ int radeon_sa_bo_manager_init(struct radeon_device *rdev,
 {
int r;

-   spin_lock_init(_manager->lock);
+   init_waitqueue_head(_manager->queue);
sa_manager->bo = NULL;
sa_manager->size = size;
+   sa_manager->biggest_hole = _manager->sa_bo;
sa_manager->domain = domain;
INIT_LIST_HEAD(_manager->sa_bo);

@@ -58,6 +60,7 @@ void radeon_sa_bo_manager_fini(struct radeon_device *rdev,
 {
struct radeon_sa_bo *sa_bo, *tmp;

+   wake_up_all(_manager->queue);
if (!list_empty(_manager->sa_bo)) {
dev_err(rdev->dev, "sa_manager is not empty, clearing 
anyway\n");
}
@@ -129,81 +132,172 @@ int radeon_sa_bo_manager_suspend(struct radeon_device 
*rdev,
  *
  * Alignment can't be bigger than page size
  */
+
+static inline unsigned radeon_sa_bo_hole_start(struct radeon_sa_manager *m,
+  struct list_head *entry)
+{
+   struct radeon_sa_bo *sa_bo;
+
+   if (entry == >sa_bo)
+   return 0;
+
+   sa_bo = list_entry(entry, struct radeon_sa_bo, list);
+   return sa_bo->offset + sa_bo->size;
+}
+
+static inline unsigned radeon_sa_bo_hole_end(struct radeon_sa_manager *m,
+struct list_head *entry)
+{
+   if (entry->next == >sa_bo)
+   return m->size;
+
+   return list_entry(entry->next, struct radeon_sa_bo, list)->offset;
+}
+
+static inline unsigned radeon_sa_bo_hole_size(struct radeon_sa_manager *m,
+ struct list_head *entry,
+ unsigned align)
+{
+   unsigned start, end, wasted;
+   start = radeon_sa_bo_hole_start(m, m->biggest_hole);
+   wasted = start % align;
+   if (wasted)
+   start += align - wasted;
+
+   end = radeon_sa_bo_hole_end(m, m->biggest_hole);
+   return start < end ? end - start : 0;
+}
+
 int radeon_sa_bo_new(struct radeon_device *rdev,
 struct radeon_sa_manager *sa_manager,
 struct 

[PATCH 07/13] drm/radeon: add sub allocator debugfs file

[Christian König]

Dumping the current allocations.

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon_object.h |5 +
 drivers/gpu/drm/radeon/radeon_ring.c   |   22 ++
 drivers/gpu/drm/radeon/radeon_sa.c |   15 +++
 3 files changed, 42 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_object.h 
b/drivers/gpu/drm/radeon/radeon_object.h
index f9104be..d9b9333 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -161,5 +161,10 @@ extern int radeon_sa_bo_new(struct radeon_device *rdev,
unsigned size, unsigned align);
 extern void radeon_sa_bo_free(struct radeon_device *rdev,
  struct radeon_sa_bo *sa_bo);
+#if defined(CONFIG_DEBUG_FS)
+extern void radeon_sa_bo_dump_debug_info(struct radeon_sa_manager *sa_manager,
+struct seq_file *m);
+#endif
+

 #endif
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c 
b/drivers/gpu/drm/radeon/radeon_ring.c
index 1b020ef..1d9bce9 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -529,6 +529,23 @@ static int radeon_debugfs_ib_info(struct seq_file *m, void 
*data)
 static struct drm_info_list radeon_debugfs_ib_list[RADEON_IB_POOL_SIZE];
 static char radeon_debugfs_ib_names[RADEON_IB_POOL_SIZE][32];
 static unsigned radeon_debugfs_ib_idx[RADEON_IB_POOL_SIZE];
+
+static int radeon_debugfs_sa_info(struct seq_file *m, void *data)
+{
+   struct drm_info_node *node = (struct drm_info_node *) m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct radeon_device *rdev = dev->dev_private;
+
+   radeon_sa_bo_dump_debug_info(>ib_pool.sa_manager, m);
+
+   return 0;
+
+}
+
+static struct drm_info_list radeon_debugfs_sa_list[] = {
+{"radeon_sa_info", _debugfs_sa_info, 0, NULL},
+};
+
 #endif

 int radeon_debugfs_ring_init(struct radeon_device *rdev, struct radeon_ring 
*ring)
@@ -555,6 +572,11 @@ int radeon_debugfs_ib_init(struct radeon_device *rdev)
 {
 #if defined(CONFIG_DEBUG_FS)
unsigned i;
+   int r;
+
+   r = radeon_debugfs_add_files(rdev, radeon_debugfs_sa_list, 1);
+   if (r)
+   return r;

for (i = 0; i < RADEON_IB_POOL_SIZE; i++) {
sprintf(radeon_debugfs_ib_names[i], "radeon_ib_%04u", i);
diff --git a/drivers/gpu/drm/radeon/radeon_sa.c 
b/drivers/gpu/drm/radeon/radeon_sa.c
index 4ce5c51..013a787 100644
--- a/drivers/gpu/drm/radeon/radeon_sa.c
+++ b/drivers/gpu/drm/radeon/radeon_sa.c
@@ -192,3 +192,18 @@ void radeon_sa_bo_free(struct radeon_device *rdev, struct 
radeon_sa_bo *sa_bo)
list_del_init(_bo->list);
spin_unlock_irqrestore(_bo->manager->lock, flags);
 }
+
+#if defined(CONFIG_DEBUG_FS)
+void radeon_sa_bo_dump_debug_info(struct radeon_sa_manager *sa_manager,
+ struct seq_file *m)
+{
+   struct radeon_sa_bo *i;
+   unsigned long flags;
+
+   spin_lock_irqsave(_manager->lock, flags);
+   list_for_each_entry(i, _manager->sa_bo, list) {
+   seq_printf(m, "offset %08d: size %4d\n", i->offset, i->size);
+   }
+   spin_unlock_irqrestore(_manager->lock, flags);
+}
+#endif
-- 
1.7.5.4

[PATCH 06/13] drm/radeon: improve sub allocator

[Christian König]

Make the suballocator self containing to locking
and fix a overrun bug which happens with
allocations of different alignments.

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon.h|1 +
 drivers/gpu/drm/radeon/radeon_sa.c |   19 ---
 2 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 85a3aa9..1aefbd9 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -381,6 +381,7 @@ struct radeon_bo_list {
  * alignment).
  */
 struct radeon_sa_manager {
+   spinlock_t  lock;
struct radeon_bo*bo;
struct list_headsa_bo;
unsignedsize;
diff --git a/drivers/gpu/drm/radeon/radeon_sa.c 
b/drivers/gpu/drm/radeon/radeon_sa.c
index 4cce47e..4ce5c51 100644
--- a/drivers/gpu/drm/radeon/radeon_sa.c
+++ b/drivers/gpu/drm/radeon/radeon_sa.c
@@ -37,6 +37,7 @@ int radeon_sa_bo_manager_init(struct radeon_device *rdev,
 {
int r;

+   spin_lock_init(_manager->lock);
sa_manager->bo = NULL;
sa_manager->size = size;
sa_manager->domain = domain;
@@ -136,30 +137,30 @@ int radeon_sa_bo_new(struct radeon_device *rdev,
struct radeon_sa_bo *tmp;
struct list_head *head;
unsigned offset = 0, wasted = 0;
+   unsigned long flags;

BUG_ON(align > RADEON_GPU_PAGE_SIZE);
BUG_ON(size > sa_manager->size);
+   spin_lock_irqsave(_manager->lock, flags);

/* no one ? */
-   head = sa_manager->sa_bo.prev;
if (list_empty(_manager->sa_bo)) {
+   head = _manager->sa_bo;
goto out;
}

/* look for a hole big enough */
-   offset = 0;
list_for_each_entry(tmp, _manager->sa_bo, list) {
/* room before this object ? */
-   if ((tmp->offset - offset) >= size) {
+   if (offset < tmp->offset && (tmp->offset - offset) >= size) {
head = tmp->list.prev;
goto out;
}
offset = tmp->offset + tmp->size;
wasted = offset % align;
if (wasted) {
-   wasted = align - wasted;
+   offset += align - wasted;
}
-   offset += wasted;
}
/* room at the end ? */
head = sa_manager->sa_bo.prev;
@@ -167,11 +168,11 @@ int radeon_sa_bo_new(struct radeon_device *rdev,
offset = tmp->offset + tmp->size;
wasted = offset % align;
if (wasted) {
-   wasted = align - wasted;
+   offset += wasted = align - wasted;
}
-   offset += wasted;
if ((sa_manager->size - offset) < size) {
/* failed to find somethings big enough */
+   spin_unlock_irqrestore(_manager->lock, flags);
return -ENOMEM;
}

@@ -180,10 +181,14 @@ out:
sa_bo->offset = offset;
sa_bo->size = size;
list_add(_bo->list, head);
+   spin_unlock_irqrestore(_manager->lock, flags);
return 0;
 }

 void radeon_sa_bo_free(struct radeon_device *rdev, struct radeon_sa_bo *sa_bo)
 {
+   unsigned long flags;
+   spin_lock_irqsave(_bo->manager->lock, flags);
list_del_init(_bo->list);
+   spin_unlock_irqrestore(_bo->manager->lock, flags);
 }
-- 
1.7.5.4

[PATCH 05/13] drm/radeon: rework gpu lockup detection and processing

[Christian König]

Previusly multiple ring could trigger multiple GPU
resets at the same time.

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon.h   |3 +-
 drivers/gpu/drm/radeon/radeon_fence.c |  146 +
 2 files changed, 75 insertions(+), 74 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 8801657..85a3aa9 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -255,8 +255,7 @@ struct radeon_fence_driver {
volatile uint32_t   *cpu_addr;
atomic_tseq;
uint32_tlast_seq;
-   unsigned long   last_jiffies;
-   unsigned long   last_timeout;
+   unsigned long   last_activity;
wait_queue_head_t   queue;
struct list_headcreated;
struct list_heademitted;
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
b/drivers/gpu/drm/radeon/radeon_fence.c
index 36c411f..1a9765a 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -74,6 +74,10 @@ int radeon_fence_emit(struct radeon_device *rdev, struct 
radeon_fence *fence)
radeon_fence_ring_emit(rdev, fence->ring, fence);
trace_radeon_fence_emit(rdev->ddev, fence->seq);
fence->emitted = true;
+   /* are we the first fence on a previusly idle ring? */
+   if (list_empty(>fence_drv[fence->ring].emitted)) {
+   rdev->fence_drv[fence->ring].last_activity = jiffies;
+   }
list_move_tail(>list, >fence_drv[fence->ring].emitted);
write_unlock_irqrestore(>fence_lock, irq_flags);
return 0;
@@ -85,34 +89,14 @@ static bool radeon_fence_poll_locked(struct radeon_device 
*rdev, int ring)
struct list_head *i, *n;
uint32_t seq;
bool wake = false;
-   unsigned long cjiffies;

seq = radeon_fence_read(rdev, ring);
-   if (seq != rdev->fence_drv[ring].last_seq) {
-   rdev->fence_drv[ring].last_seq = seq;
-   rdev->fence_drv[ring].last_jiffies = jiffies;
-   rdev->fence_drv[ring].last_timeout = 
RADEON_FENCE_JIFFIES_TIMEOUT;
-   } else {
-   cjiffies = jiffies;
-   if (time_after(cjiffies, rdev->fence_drv[ring].last_jiffies)) {
-   cjiffies -= rdev->fence_drv[ring].last_jiffies;
-   if (time_after(rdev->fence_drv[ring].last_timeout, 
cjiffies)) {
-   /* update the timeout */
-   rdev->fence_drv[ring].last_timeout -= cjiffies;
-   } else {
-   /* the 500ms timeout is elapsed we should test
-* for GPU lockup
-*/
-   rdev->fence_drv[ring].last_timeout = 1;
-   }
-   } else {
-   /* wrap around update last jiffies, we will just wait
-* a little longer
-*/
-   rdev->fence_drv[ring].last_jiffies = cjiffies;
-   }
+   if (seq == rdev->fence_drv[ring].last_seq)
return false;
-   }
+
+   rdev->fence_drv[ring].last_seq = seq;
+   rdev->fence_drv[ring].last_activity = jiffies;
+
n = NULL;
list_for_each(i, >fence_drv[ring].emitted) {
fence = list_entry(i, struct radeon_fence, list);
@@ -207,66 +191,84 @@ int radeon_fence_wait(struct radeon_fence *fence, bool 
intr)
struct radeon_device *rdev;
unsigned long irq_flags, timeout;
u32 seq;
-   int r;
+   int i, r;
+   bool signaled;

if (fence == NULL) {
WARN(1, "Querying an invalid fence : %p !\n", fence);
-   return 0;
+   return -EINVAL;
}
+
rdev = fence->rdev;
-   if (radeon_fence_signaled(fence)) {
-   return 0;
-   }
-   timeout = rdev->fence_drv[fence->ring].last_timeout;
-retry:
-   /* save current sequence used to check for GPU lockup */
-   seq = rdev->fence_drv[fence->ring].last_seq;
-   trace_radeon_fence_wait_begin(rdev->ddev, seq);
-   if (intr) {
+   signaled = radeon_fence_signaled(fence);
+   while (!signaled) {
+   read_lock_irqsave(>fence_lock, irq_flags);
+   timeout = jiffies - RADEON_FENCE_JIFFIES_TIMEOUT;
+   if (time_after(rdev->fence_drv[fence->ring].last_activity, 
timeout)) {
+   /* the normal case, timeout is somewhere before 
last_activity */
+   timeout = rdev->fence_drv[fence->ring].last_activity - 
timeout;
+   } else {
+   /* either jiffies wrapped around, or no fence was 
signaled in the last 500ms
+

[PATCH 04/13] drm/radeon: use central function for IB testing

[Christian König]

Removing all the different error messages and
having just one standard behaviour over all
chipset generations.

Signed-off-by: Christian K?nig 
Reviewed-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/evergreen.c   |7 ++-
 drivers/gpu/drm/radeon/ni.c  |7 ++-
 drivers/gpu/drm/radeon/r100.c|7 ++-
 drivers/gpu/drm/radeon/r300.c|7 ++-
 drivers/gpu/drm/radeon/r420.c|7 ++-
 drivers/gpu/drm/radeon/r520.c|8 +++-
 drivers/gpu/drm/radeon/r600.c|7 ++-
 drivers/gpu/drm/radeon/radeon.h  |1 +
 drivers/gpu/drm/radeon/radeon_ring.c |   30 ++
 drivers/gpu/drm/radeon/rs400.c   |7 ++-
 drivers/gpu/drm/radeon/rs600.c   |7 ++-
 drivers/gpu/drm/radeon/rs690.c   |7 ++-
 drivers/gpu/drm/radeon/rv515.c   |8 +++-
 drivers/gpu/drm/radeon/rv770.c   |7 ++-
 14 files changed, 57 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index cfa372c..ca47f52 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3248,12 +3248,9 @@ static int evergreen_startup(struct radeon_device *rdev)
if (r)
return r;

-   r = radeon_ib_test(rdev, RADEON_RING_TYPE_GFX_INDEX, 
>ring[RADEON_RING_TYPE_GFX_INDEX]);
-   if (r) {
-   DRM_ERROR("radeon: failed testing IB (%d).\n", r);
-   rdev->accel_working = false;
+   r = radeon_ib_ring_tests(rdev);
+   if (r)
return r;
-   }

r = r600_audio_init(rdev);
if (r) {
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index a48ca53..0146428 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1601,12 +1601,9 @@ static int cayman_startup(struct radeon_device *rdev)
if (r)
return r;

-   r = radeon_ib_test(rdev, RADEON_RING_TYPE_GFX_INDEX, 
>ring[RADEON_RING_TYPE_GFX_INDEX]);
-   if (r) {
-   DRM_ERROR("radeon: failed testing IB (%d).\n", r);
-   rdev->accel_working = false;
+   r = radeon_ib_ring_tests(rdev);
+   if (r)
return r;
-   }

r = radeon_vm_manager_start(rdev);
if (r)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 4b677fc..62f9dab 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -3968,12 +3968,9 @@ static int r100_startup(struct radeon_device *rdev)
if (r)
return r;

-   r = radeon_ib_test(rdev, RADEON_RING_TYPE_GFX_INDEX, 
>ring[RADEON_RING_TYPE_GFX_INDEX]);
-   if (r) {
-   dev_err(rdev->dev, "failed testing IB (%d).\n", r);
-   rdev->accel_working = false;
+   r = radeon_ib_ring_tests(rdev);
+   if (r)
return r;
-   }

return 0;
 }
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index a63f432..26e0db8 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -1417,12 +1417,9 @@ static int r300_startup(struct radeon_device *rdev)
if (r)
return r;

-   r = radeon_ib_test(rdev, RADEON_RING_TYPE_GFX_INDEX, 
>ring[RADEON_RING_TYPE_GFX_INDEX]);
-   if (r) {
-   dev_err(rdev->dev, "failed testing IB (%d).\n", r);
-   rdev->accel_working = false;
+   r = radeon_ib_ring_tests(rdev);
+   if (r)
return r;
-   }

return 0;
 }
diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index f3fcaac..99137be 100644
--- a/drivers/gpu/drm/radeon/r420.c
+++ b/drivers/gpu/drm/radeon/r420.c
@@ -279,12 +279,9 @@ static int r420_startup(struct radeon_device *rdev)
if (r)
return r;

-   r = radeon_ib_test(rdev, RADEON_RING_TYPE_GFX_INDEX, 
>ring[RADEON_RING_TYPE_GFX_INDEX]);
-   if (r) {
-   dev_err(rdev->dev, "failed testing IB (%d).\n", r);
-   rdev->accel_working = false;
+   r = radeon_ib_ring_tests(rdev);
+   if (r)
return r;
-   }

return 0;
 }
diff --git a/drivers/gpu/drm/radeon/r520.c b/drivers/gpu/drm/radeon/r520.c
index ebcc15b..b5cf837 100644
--- a/drivers/gpu/drm/radeon/r520.c
+++ b/drivers/gpu/drm/radeon/r520.c
@@ -207,12 +207,10 @@ static int r520_startup(struct radeon_device *rdev)
if (r)
return r;

-   r = radeon_ib_test(rdev, RADEON_RING_TYPE_GFX_INDEX, 
>ring[RADEON_RING_TYPE_GFX_INDEX]);
-   if (r) {
-   dev_err(rdev->dev, "failed testing IB (%d).\n", r);
-   rdev->accel_working = false;
+   r = radeon_ib_ring_tests(rdev);
+   if (r)
return r;
-   }
+
return 0;
 }

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 4added1..c749e00 100644
---