[PATCH] m68k/video: Create

For now, it just contains the hack for cirrusfb on Amiga, which is moved out of with some slight modifications (use raw_*() instead of z_*(), which are defined on all m68k platforms). This makes it safe to include in all contexts. Before it could fail to compile with include/video/vga.h: In

[PATCH] scatterlist: add sg_alloc_table_by_pages function

Hi Tomasz, Thanks for the patch. On Wednesday 18 April 2012 11:44:59 Tomasz Stanislawski wrote: > This patch adds a new constructor for an sg table. The table is constructed > from an array of struct pages. All contiguous chunks of the pages are merged > into a single sg nodes. A user may

Linux 3.4-rc4

David & co, any ideas? There are other reports of problems with 3.3.x kernels, there's a report from Tim which may be related (also apparently working in 3.2, broken black screen in all 3.3.x). Nick, I realize you had trouble with a bisection already, but it might really be worth trying again.

VM lockdep warning

On 21.04.2012 19:30, Jerome Glisse wrote: > 2012/4/21 Christian K?nig: >> On 21.04.2012 17:57, Dave Airlie wrote: >>> 2012/4/21 Jerome Glisse: 2012/4/21 Christian K?nig: > On 21.04.2012 16:08, Jerome Glisse wrote: >> 2012/4/21 Christian K?nig: >>> Interesting, I'm pretty sure that

[Regression][3.4-rc3][intel-dri] MMIO read or write has been dropped ffffffff

On sobota, 21 kwietnia 2012 o 15:13:52 Daniel Vetter wrote: > On Sat, Apr 21, 2012 at 03:03:07PM +0200, Daniel Vetter wrote: > > On Sat, Apr 21, 2012 at 07:39:08AM +0200, Maciej Rutecki wrote: > > > Bad kernel: 3.4-rc3 > > > Last known good: 3.3 > > > > > > Subsystem: dri-intel (guess) > > > > >

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

Hi Tomasz, Thanks for the patch. On Friday 20 April 2012 16:45:29 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

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

Hi R?mi, On Friday 20 April 2012 15:03:17 R?mi Denis-Courmont wrote: > 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

VM lockdep warning

On 21.04.2012 17:57, Dave Airlie wrote: > 2012/4/21 Jerome Glisse: >> 2012/4/21 Christian K?nig: >>> On 21.04.2012 16:08, Jerome Glisse wrote: 2012/4/21 Christian K?nig: > Interesting, I'm pretty sure that I haven't touched the locking order of > the > cs_mutex vs. vm_mutex. >

[PATCH] drm/radeon: use a global mutex instead of per vm one

Resolving deadlock problems with the cs_mutex. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon.h|2 +- drivers/gpu/drm/radeon/radeon_device.c |1 + drivers/gpu/drm/radeon/radeon_gart.c | 25 + 3 files changed, 11 insertions(+), 17

[PATCH libdrm 4/4] modetest: print more about our properties

From: Paulo Zanoni In the future we'll have more than just connector properties, so create a dump_prop function that can handle any property (instead of the current dump_props function that only handles connector properties). Also, make this function print a lot more

[PATCH libdrm 3/4] modetest: call drmModeFreePlaneResources

From: Paulo Zanoni 24 (16 direct, 8 indirect) bytes in 1 blocks are definitely lost in loss record 2 of 7 at 0x402994D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) by 0x4A25950: drmMalloc (xf86drm.c:147) by 0x4A2E26D:

[PATCH libdrm 2/4] modetest: fix drmModeGetConnector memory leak

From: Paulo Zanoni Don't "continue" without freeing the connector. 192 bytes in 6 blocks are indirectly lost in loss record 6 of 12 at 0x4C2779D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) by 0x4E30DD8: drmMalloc (xf86drm.c:147) by

[PATCH libdrm 1/4] modetest: fix some compiler warnings

From: Paulo Zanoni Use unsigned int instead of int: - modetest.c:90:1: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] - modetest.c:98:1: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] -

[PATCH libdrm 3/5] modetest: print more about our properties

2012/3/29 Eugeni Dodonov : > On Thu, Mar 29, 2012 at 18:28, Paulo Zanoni wrote: > > > I don't know if it should go into a separate patch though. But it is aligned > to the other formatting patterns you do, and it certainly looks nicer this > way, and it shouldn't break anything anyway. So I am

[PATCH libdrm 1/5] modetest: fix some compiler warnings

2012/3/29 Eugeni Dodonov : > I wonder if we could drop the dead^W#ifd 0'ed code here as well, perhaps > with a separate patch? I don't think it will get used again in the future > (but I might be wrong). > Removing #if 0'ed code won't fix compiler warnings, so if we do this, it should be done in

VM lockdep warning

2012/4/21 Jerome Glisse : > 2012/4/21 Christian K?nig : >> On 21.04.2012 16:08, Jerome Glisse wrote: >>> >>> 2012/4/21 Christian K?nig: Interesting, I'm pretty sure that I haven't touched the locking order of the cs_mutex vs. vm_mutex. Maybe it is just some kind of

VM lockdep warning

On 21.04.2012 16:08, Jerome Glisse wrote: > 2012/4/21 Christian K?nig: >> Interesting, I'm pretty sure that I haven't touched the locking order of the >> cs_mutex vs. vm_mutex. >> >> Maybe it is just some kind of side effect, going to locking into it anyway. >> >> Christian. >> > It's the using,

i915: kernel errors at resume

On Sat, 2012-04-21 at 14:54 +0200, Daniel Vetter wrote: > Please file a bug report with the error state attach (the > entire thing), complete dmesg showing when the problem happens and a short > description of the issue at bugs.freedesktop.org against DRI, component > DRM/Intel. See

[Regression][3.4-rc3][intel-dri] MMIO read or write has been dropped ffffffff

On Sat, Apr 21, 2012 at 03:03:07PM +0200, Daniel Vetter wrote: > On Sat, Apr 21, 2012 at 07:39:08AM +0200, Maciej Rutecki wrote: > > Bad kernel: 3.4-rc3 > > Last known good: 3.3 > > > > Subsystem: dri-intel (guess) > > > > Steps to reproduce: > > 1. Suspend to ram > > 2. Resume > > > > After

i915: kernel errors at resume

On Sat, Apr 21, 2012 at 02:58:39PM +0200, Paul Bolle wrote: > On Sat, 2012-04-21 at 14:54 +0200, Daniel Vetter wrote: > > On Sat, Apr 21, 2012 at 02:25:55PM +0200, Paul Bolle wrote: > > > What part of that almost 700K file could be of interest? > > > > All of it. Please file a bug report with the

[Regression][3.4-rc3][intel-dri] MMIO read or write has been dropped ffffffff

On Sat, Apr 21, 2012 at 07:39:08AM +0200, Maciej Rutecki wrote: > Bad kernel: 3.4-rc3 > Last known good: 3.3 > > Subsystem: dri-intel (guess) > > Steps to reproduce: > 1. Suspend to ram > 2. Resume > > After resume laptop works ok, but in dmesg I found: > [ 164.098113] [ cut here

i915: kernel errors at resume

On Sat, 2012-04-21 at 14:54 +0200, Daniel Vetter wrote: > On Sat, Apr 21, 2012 at 02:25:55PM +0200, Paul Bolle wrote: > > What part of that almost 700K file could be of interest? > > All of it. Please file a bug report with the error state attach (the > entire thing), complete dmesg showing when

i915: kernel errors at resume

On Sat, Apr 21, 2012 at 02:25:55PM +0200, Paul Bolle wrote: > On Thu, 2012-04-19 at 11:04 +0200, Paul Bolle wrote: > > <6>[14673.824599] [drm] capturing error event; look for more information in > > /debug/dri/0/i915_error_state > > I triggered this issue once again in the session I run

VM lockdep warning

Interesting, I'm pretty sure that I haven't touched the locking order of the cs_mutex vs. vm_mutex. Maybe it is just some kind of side effect, going to locking into it anyway. Christian. On 21.04.2012 13:39, Dave Airlie wrote: > running 3.4.0-rc3 + Christian's reset patch series. > > The locks

i915: kernel errors at resume

On Thu, 2012-04-19 at 11:04 +0200, Paul Bolle wrote: > <6>[14673.824599] [drm] capturing error event; look for more information in > /debug/dri/0/i915_error_state I triggered this issue once again in the session I run currently: $ cat /sys/kernel/debug/dri/0/i915_error_state | wc -c

VM lockdep warning

2012/4/21 Christian K?nig : > On 21.04.2012 17:57, Dave Airlie wrote: >> >> 2012/4/21 Jerome Glisse: >>> >>> 2012/4/21 Christian K?nig: On 21.04.2012 16:08, Jerome Glisse wrote: > > 2012/4/21 Christian K?nig: >> >> Interesting, I'm pretty sure that I haven't touched the

[Bug 17902] [830M] need support for DVO-LVDS via na2501

https://bugs.freedesktop.org/show_bug.cgi?id=17902 --- Comment #70 from Daniel Vetter 2012-04-21 06:08:48 PDT --- Created attachment 60416 --> https://bugs.freedesktop.org/attachment.cgi?id=60416 drm driver reload script Looks like you've made a start alright. As I've said, I've you're

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

thanks for your patch but your patch set needs some codes for identifying whether pixel format is multiplanar or not as you mentioned. so I will add the codes and apply your patch set to exynos-drm-fixes branch for drm-fixes. 2012? 4? 21? ?? 12:26, ?? ?: > From: Ville Syrj?l? > > The

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

2012? 4? 20? ?? 11:22, 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,

VM lockdep warning

running 3.4.0-rc3 + Christian's reset patch series. The locks are definitely taken in different orders between vm_bo_add and cs ioctl. Dave. == [ INFO: possible circular locking dependency detected ] 3.4.0-rc3+ #33 Not tainted

Reworking of GPU reset logic

On 20.04.2012 01:47, Jerome Glisse wrote: > 2012/4/19 Christian K?nig: >> This includes mostly fixes for multi ring lockups and GPU resets, but it >> should general improve the behavior of the kernel mode driver in case >> something goes badly wrong. >> >> On the other hand it completely

[PATCHv5 00/13] Integration of videobuf2 with dmabuf

On 04/20/2012 09:45 AM, Tomasz Stanislawski wrote: > 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]. Would it

VM lockdep warning

2012/4/21 Christian K?nig : > On 21.04.2012 16:08, Jerome Glisse wrote: >> >> 2012/4/21 Christian K?nig: >>> >>> Interesting, I'm pretty sure that I haven't touched the locking order of >>> the >>> cs_mutex vs. vm_mutex. >>> >>> Maybe it is just some kind of side effect, going to locking into it

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

On Fri, Apr 20, 2012 at 03:33:14PM +0200, Daniel Vetter wrote: > 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

Reworking of GPU reset logic

2012/4/21 Christian K?nig : > On 20.04.2012 01:47, Jerome Glisse wrote: >> >> 2012/4/19 Christian K?nig: >>> >>> This includes mostly fixes for multi ring lockups and GPU resets, but it >>> should general improve the behavior of the kernel mode driver in case >>> something goes badly wrong. >>>

VM lockdep warning

2012/4/21 Christian K?nig : > Interesting, I'm pretty sure that I haven't touched the locking order of the > cs_mutex vs. vm_mutex. > > Maybe it is just some kind of side effect, going to locking into it anyway. > > Christian. > It's the using, init path take lock in different order than cs path

[Regression][3.4-rc3][intel-dri] MMIO read or write has been dropped ffffffff

Bad kernel: 3.4-rc3 Last known good: 3.3 Subsystem: dri-intel (guess) Steps to reproduce: 1. Suspend to ram 2. Resume After resume laptop works ok, but in dmesg I found: [ 164.098113] [ cut here ] [ 164.098124] WARNING: at drivers/gpu/drm/i915/i915_drv.c:398

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

https://bugzilla.kernel.org/show_bug.cgi?id=43138 --- Comment #5 from bugtraq at hobbit.in-berlin.de 2012-04-21 06:51:09 --- considering the age of that code I share your suspicions, but why then does a stock debian kernel & initrd show same behavior as my self-compiled (newer) one? --

[Bug 49030] New: Possible recursive locking detected in r600g

https://bugs.freedesktop.org/show_bug.cgi?id=49030 Bug #: 49030 Summary: Possible recursive locking detected in r600g Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW

[gma500] Fix screen blackouts

Hello, Since linux-3.3 I have been experiencing screen "blackouts" with the gma500_gfx driver. My laptop display would turn off and on again frequently. After activating the drm.debug=255 kernel option, the logs showed this during the blackout : [ 166.940676]

[Bug 17902] [830M] need support for DVO-LVDS via na2501

https://bugs.freedesktop.org/show_bug.cgi?id=17902 --- Comment #69 from Gilles Dartiguelongue 2012-04-20 16:41:09 PDT --- I pushed the current state of the code here: https://github.com/EvaSDK/linux/commit/d590f8631a2421ba6bcef7041888b3aa382f87c7 I commented out dpms code for testing, but

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

https://bugzilla.kernel.org/show_bug.cgi?id=43138 --- Comment #5 from bugt...@hobbit.in-berlin.de 2012-04-21 06:51:09 --- considering the age of that code I share your suspicions, but why then does a stock debian kernel initrd show same behavior as my self-compiled (newer) one? --

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

On Fri, Apr 20, 2012 at 03:33:14PM +0200, Daniel Vetter wrote: 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

Re: Reworking of GPU reset logic

On 20.04.2012 01:47, Jerome Glisse wrote: 2012/4/19 Christian Königdeathsim...@vodafone.de: This includes mostly fixes for multi ring lockups and GPU resets, but it should general improve the behavior of the kernel mode driver in case something goes badly wrong. On the other hand it

Re: [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 happy

[gma500] Fix screen blackouts

Hello, Since linux-3.3 I have been experiencing screen blackouts with the gma500_gfx driver. My laptop display would turn off and on again frequently. After activating the drm.debug=255 kernel option, the logs showed this during the blackout : [ 166.940676]

VM lockdep warning

running 3.4.0-rc3 + Christian's reset patch series. The locks are definitely taken in different orders between vm_bo_add and cs ioctl. Dave. == [ INFO: possible circular locking dependency detected ] 3.4.0-rc3+ #33 Not tainted

Re: i915: kernel errors at resume

On Thu, 2012-04-19 at 11:04 +0200, Paul Bolle wrote: 6[14673.824599] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state I triggered this issue once again in the session I run currently: $ cat /sys/kernel/debug/dri/0/i915_error_state | wc -c 689681

Re: VM lockdep warning

Interesting, I'm pretty sure that I haven't touched the locking order of the cs_mutex vs. vm_mutex. Maybe it is just some kind of side effect, going to locking into it anyway. Christian. On 21.04.2012 13:39, Dave Airlie wrote: running 3.4.0-rc3 + Christian's reset patch series. The locks

Re: i915: kernel errors at resume

On Sat, Apr 21, 2012 at 02:25:55PM +0200, Paul Bolle wrote: On Thu, 2012-04-19 at 11:04 +0200, Paul Bolle wrote: 6[14673.824599] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state I triggered this issue once again in the session I run currently: $

Re: i915: kernel errors at resume

On Sat, 2012-04-21 at 14:54 +0200, Daniel Vetter wrote: On Sat, Apr 21, 2012 at 02:25:55PM +0200, Paul Bolle wrote: What part of that almost 700K file could be of interest? All of it. Please file a bug report with the error state attach (the entire thing), complete dmesg showing when the

Re: [Regression][3.4-rc3][intel-dri] MMIO read or write has been dropped ffffffff

On Sat, Apr 21, 2012 at 07:39:08AM +0200, Maciej Rutecki wrote: Bad kernel: 3.4-rc3 Last known good: 3.3 Subsystem: dri-intel (guess) Steps to reproduce: 1. Suspend to ram 2. Resume After resume laptop works ok, but in dmesg I found: [ 164.098113] [ cut here

Re: i915: kernel errors at resume

On Sat, Apr 21, 2012 at 02:58:39PM +0200, Paul Bolle wrote: On Sat, 2012-04-21 at 14:54 +0200, Daniel Vetter wrote: On Sat, Apr 21, 2012 at 02:25:55PM +0200, Paul Bolle wrote: What part of that almost 700K file could be of interest? All of it. Please file a bug report with the error

[Bug 17902] [830M] need support for DVO-LVDS via na2501

https://bugs.freedesktop.org/show_bug.cgi?id=17902 --- Comment #70 from Daniel Vetter dan...@ffwll.ch 2012-04-21 06:08:48 PDT --- Created attachment 60416 -- https://bugs.freedesktop.org/attachment.cgi?id=60416 drm driver reload script Looks like you've made a start alright. As I've said, I've

Re: [Regression][3.4-rc3][intel-dri] MMIO read or write has been dropped ffffffff

On Sat, Apr 21, 2012 at 03:03:07PM +0200, Daniel Vetter wrote: On Sat, Apr 21, 2012 at 07:39:08AM +0200, Maciej Rutecki wrote: Bad kernel: 3.4-rc3 Last known good: 3.3 Subsystem: dri-intel (guess) Steps to reproduce: 1. Suspend to ram 2. Resume After resume laptop works ok,

Re: i915: kernel errors at resume

On Sat, 2012-04-21 at 14:54 +0200, Daniel Vetter wrote: Please file a bug report with the error state attach (the entire thing), complete dmesg showing when the problem happens and a short description of the issue at bugs.freedesktop.org against DRI, component DRM/Intel. See

Re: VM lockdep warning

2012/4/21 Christian König deathsim...@vodafone.de: Interesting, I'm pretty sure that I haven't touched the locking order of the cs_mutex vs. vm_mutex. Maybe it is just some kind of side effect, going to locking into it anyway. Christian. It's the using, init path take lock in different

Re: Reworking of GPU reset logic

2012/4/21 Christian König deathsim...@vodafone.de: On 20.04.2012 01:47, Jerome Glisse wrote: 2012/4/19 Christian Königdeathsim...@vodafone.de: This includes mostly fixes for multi ring lockups and GPU resets, but it should general improve the behavior of the kernel mode driver in case

Re: VM lockdep warning

On 21.04.2012 16:08, Jerome Glisse wrote: 2012/4/21 Christian Königdeathsim...@vodafone.de: Interesting, I'm pretty sure that I haven't touched the locking order of the cs_mutex vs. vm_mutex. Maybe it is just some kind of side effect, going to locking into it anyway. Christian. It's the

Re: VM lockdep warning

2012/4/21 Christian König deathsim...@vodafone.de: On 21.04.2012 16:08, Jerome Glisse wrote: 2012/4/21 Christian Königdeathsim...@vodafone.de: Interesting, I'm pretty sure that I haven't touched the locking order of the cs_mutex vs. vm_mutex. Maybe it is just some kind of side effect,

Re: VM lockdep warning

2012/4/21 Jerome Glisse j.gli...@gmail.com: 2012/4/21 Christian König deathsim...@vodafone.de: On 21.04.2012 16:08, Jerome Glisse wrote: 2012/4/21 Christian Königdeathsim...@vodafone.de: Interesting, I'm pretty sure that I haven't touched the locking order of the cs_mutex vs. vm_mutex.

Re: VM lockdep warning

On 21.04.2012 17:57, Dave Airlie wrote: 2012/4/21 Jerome Glissej.gli...@gmail.com: 2012/4/21 Christian Königdeathsim...@vodafone.de: On 21.04.2012 16:08, Jerome Glisse wrote: 2012/4/21 Christian Königdeathsim...@vodafone.de: Interesting, I'm pretty sure that I haven't touched the locking

Re: VM lockdep warning

2012/4/21 Christian König deathsim...@vodafone.de: On 21.04.2012 17:57, Dave Airlie wrote: 2012/4/21 Jerome Glissej.gli...@gmail.com: 2012/4/21 Christian Königdeathsim...@vodafone.de: On 21.04.2012 16:08, Jerome Glisse wrote: 2012/4/21 Christian Königdeathsim...@vodafone.de:

Re: [Regression][3.4-rc3][intel-dri] MMIO read or write has been dropped ffffffff

On sobota, 21 kwietnia 2012 o 15:13:52 Daniel Vetter wrote: On Sat, Apr 21, 2012 at 03:03:07PM +0200, Daniel Vetter wrote: On Sat, Apr 21, 2012 at 07:39:08AM +0200, Maciej Rutecki wrote: Bad kernel: 3.4-rc3 Last known good: 3.3 Subsystem: dri-intel (guess) Steps to

Re: VM lockdep warning

On 21.04.2012 19:30, Jerome Glisse wrote: 2012/4/21 Christian Königdeathsim...@vodafone.de: On 21.04.2012 17:57, Dave Airlie wrote: 2012/4/21 Jerome Glissej.gli...@gmail.com: 2012/4/21 Christian Königdeathsim...@vodafone.de: On 21.04.2012 16:08, Jerome Glisse wrote: 2012/4/21 Christian

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

Hi Tomasz, Thanks for the patch. On Friday 20 April 2012 16:45:29 Tomasz Stanislawski wrote: From: Andrzej Pietrasiewicz andrze...@samsung.com 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

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

Hi Rémi, On Friday 20 April 2012 15:03:17 Rémi Denis-Courmont wrote: 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.

[PATCH] m68k/video: Create asm/vga.h

For now, it just contains the hack for cirrusfb on Amiga, which is moved out of video/vga.h with some slight modifications (use raw_*() instead of z_*(), which are defined on all m68k platforms). This makes it safe to include video/vga.h in all contexts. Before it could fail to compile with

Re: [PATCH libdrm 1/5] modetest: fix some compiler warnings

2012/3/29 Eugeni Dodonov eug...@dodonov.net: I wonder if we could drop the dead^W#ifd 0'ed code here as well, perhaps with a separate patch? I don't think it will get used again in the future (but I might be wrong). Removing #if 0'ed code won't fix compiler warnings, so if we do this, it

Re: [PATCH libdrm 3/5] modetest: print more about our properties

2012/3/29 Eugeni Dodonov eug...@dodonov.net: On Thu, Mar 29, 2012 at 18:28, Paulo Zanoni przan...@gmail.com wrote: really-small-bikeshedding I don't know if it should go into a separate patch though. But it is aligned to the other formatting patterns you do, and it certainly looks nicer this

[PATCH libdrm 1/4] modetest: fix some compiler warnings

From: Paulo Zanoni paulo.r.zan...@intel.com Use unsigned int instead of int: - modetest.c:90:1: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] - modetest.c:98:1: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] -

[PATCH libdrm 2/4] modetest: fix drmModeGetConnector memory leak

From: Paulo Zanoni paulo.r.zan...@intel.com Don't continue without freeing the connector. 192 bytes in 6 blocks are indirectly lost in loss record 6 of 12 at 0x4C2779D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) by 0x4E30DD8: drmMalloc (xf86drm.c:147) by 0x4E35024:

[PATCH libdrm 3/4] modetest: call drmModeFreePlaneResources

From: Paulo Zanoni paulo.r.zan...@intel.com 24 (16 direct, 8 indirect) bytes in 1 blocks are definitely lost in loss record 2 of 7 at 0x402994D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) by 0x4A25950: drmMalloc (xf86drm.c:147) by 0x4A2E26D: drmModeGetPlaneResources

[PATCH libdrm 4/4] modetest: print more about our properties

From: Paulo Zanoni paulo.r.zan...@intel.com In the future we'll have more than just connector properties, so create a dump_prop function that can handle any property (instead of the current dump_props function that only handles connector properties). Also, make this function print a lot more

Re: [PATCH] scatterlist: add sg_alloc_table_by_pages function

Hi Tomasz, Thanks for the patch. On Wednesday 18 April 2012 11:44:59 Tomasz Stanislawski wrote: This patch adds a new constructor for an sg table. The table is constructed from an array of struct pages. All contiguous chunks of the pages are merged into a single sg nodes. A user may provide

Re: Linux 3.4-rc4

David co, any ideas? There are other reports of problems with 3.3.x kernels, there's a report from Tim timlie...@woh.rr.com which may be related (also apparently working in 3.2, broken black screen in all 3.3.x). Nick, I realize you had trouble with a bisection already, but it might really be