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

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

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

https://bugzilla.kernel.org/show_bug.cgi?id=43138 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment

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

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

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

https://bugzilla.kernel.org/show_bug.cgi?id=43138 bugtraq at hobbit.in-berlin.de changed: What|Removed |Added Platform|All |i386 --- Comment #2

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

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:

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

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.

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

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

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

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

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

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

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

ignature Size: 198 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120420/0367c77e/attachment.pgp>

state of drm next

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

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

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

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: > >>> >

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

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

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

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

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

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

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

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

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

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 +++

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

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

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

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

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

vb2-dma-contig returns a vb2_dc_conf structure instance as the vb2 allocation context. That structure only stores a pointer to the physical device. Remove it and use the device pointer directly as the allocation context. Signed-off-by: Tomasz Stanislawski Acked-by: Laurent Pinchart ---

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

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

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

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

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

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

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

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

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

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

[PATCHv5 00/13] Integration of videobuf2 with dmabuf

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

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

rom 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-de

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

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

[PATCHv5 00/13] Integration of videobuf2 with dmabuf

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

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

t 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.

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

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

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

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

https://bugs.freedesktop.org/show_bug.cgi?id=27541 Chris Wilson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

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

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

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

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

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

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

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

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

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

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 >

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

[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

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

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

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

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

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

d... 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

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,

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

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

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

https://bugzilla.kernel.org/show_bug.cgi?id=42729 subscription.discussion at gmail.com changed: What|Removed |Added Status|NEW |RESOLVED

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

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

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

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:

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

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

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

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

state of drm next

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

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

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

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

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

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 ---

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

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

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

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

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

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

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

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

[RFC 0/4] Add NVIDIA Tegra DRM support

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

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

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

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

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 ---

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

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

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

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, >>>

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

> > 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

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

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

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

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

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

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

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

> +/* 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; > +

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

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. :)

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

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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 |

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

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

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

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 >

[RFC 0/4] Add NVIDIA Tegra DRM support

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 > >

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

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

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

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

[RFC 0/4] Add NVIDIA Tegra DRM support

, 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/attac

[RFC 0/4] Add NVIDIA Tegra DRM support

ailable 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

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

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

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|

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

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

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

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 +-

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

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 ---

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

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 -

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

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

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

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

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

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

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

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(-)

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

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 ++-

  1   2   >