[drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

(Send similar post to LKML / linux.kernel but no responses there yet) Hello, we where building 3.1.4 kernel when we noticed BUG()s on bootup. Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in drm_vblank_cleanup+0x78/0x90 [drm] Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in

[PATCH] fixes to drm-next - TTM DMA code (v1)

> Hi! > > I'm not whether any drivers are still using the AGP backend? Actually the openchrome projects KMS kernel uses a AGP backend. > Calling unpopulate / (previous clear) each time unbind is done should be quite > inefficient with that one, as AGP sets up its own data structures and

[PATCH] modetest: add drm_plane support

From: Rob Clark Signed-off-by: Rob Clark --- tests/modetest/modetest.c | 166 ++--- 1 files changed, 157 insertions(+), 9 deletions(-) diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c index 1e4ec91..22ac620 100644 ---

[PATCH 2/2] drm: add support for private planes

From: Rob Clark In cases where the scanout hw is sufficiently similar between "overlay" and traditional crtc layers, it might be convenient to allow the driver to create internal drm_plane helper objects used by the drm_crtc implementation, rather than duplicate code between the

[PATCH 1/2] drm: disconnect plane from fb/crtc when disabled

From: Rob Clark Since plane->fb and plane->crtc are set in drm_mode_setplane() after update_plane(), They should be cleared after disable(). Signed-off-by: Rob Clark --- drivers/gpu/drm/drm_crtc.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git

[PATCH 2/2] drm/omap: drm API update: addfb2

On Mon, Dec 12, 2011 at 6:56 PM, Greg KH wrote: > On Mon, Dec 12, 2011 at 06:49:44PM -0600, Rob Clark wrote: >> From: Rob Clark >> >> Update to reflect changes in: >> "drm: add an fb creation ioctl that takes a pixel format v5" > > This one I'm going to have to wait for the drm api merges to

Memory corruption starting in i915 code, in 3.2-rc5

On Tue, Dec 13, 2011 at 10:14:46AM -0800, Keith Packard wrote: > On Tue, 13 Dec 2011 10:14:15 -0500, Alex Villac??s Lasso palosanto.com> wrote: > > > By using a bootable USB stick, I could check the logs, which > > showed many segfaults at /lib64/ld-2.14.90.so . > > Ouch! > > Please let me

[PATCH 00/23] kill drm cruft with fire

On Wed, Dec 07, 2011 at 02:19:39PM +, James Simmons wrote: > > > > >> Testing this on via would be awesome! Iirc I haven't changed anything > > > >> in > > > >> the via specific patches, but if it's more convenient you can also > > > >> directly test my branch: > > > >> > > > >>

Memory corruption starting in i915 code, in 3.2-rc5

On Tue, Dec 13, 2011 at 10:14:46AM -0800, Keith Packard wrote: > On Tue, 13 Dec 2011 10:14:15 -0500, Alex Villac??s Lasso palosanto.com> wrote: > > > By using a bootable USB stick, I could check the logs, which > > showed many segfaults at /lib64/ld-2.14.90.so . > > Ouch! > > Please let me

[drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

On Tue, Dec 13, 2011 at 6:46 PM, Jerome Glisse wrote: > On Tue, Dec 13, 2011 at 6:33 PM, batouzo wrote: >> On 12/14/2011 12:31 AM, Jerome Glisse wrote: >> Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in drm_vblank_cleanup+0x78/0x90 [drm] Allocated in

[drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

On Tue, Dec 13, 2011 at 6:33 PM, batouzo wrote: > On 12/14/2011 12:31 AM, Jerome Glisse wrote: > >>> Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in >>> drm_vblank_cleanup+0x78/0x90 [drm] >>> Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in >>> drm_vblank_cleanup+0x48/0x90 [drm]

[drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

On Tue, Dec 13, 2011 at 10:26:15PM +0100, batouzo wrote: > > (Send similar post to LKML / linux.kernel but no responses there yet) > > Hello, we where building 3.1.4 kernel when we noticed BUG()s on bootup. > > Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in >

[PATCH] fixes to drm-next - TTM DMA code (v1)

On 12/13/2011 05:07 PM, Jerome Glisse wrote: > On Mon, Dec 12, 2011 at 03:09:26PM -0500, Konrad Rzeszutek Wilk wrote: > >> Jerome pointed me to some accounting error in the DMA API debugging code and >> while I can't figure it out yet, I did notice some extreme slowness - which >> is due to

Patches queued to drm-intel-fixes

/lists.freedesktop.org/archives/dri-devel/attachments/20111213/268bf21b/attachment.pgp>

[Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

On Monday 12 December 2011, Robert Morell wrote: > > > > Doing a buffer sharing with something that is not GPL is not fun, as, if any > > issue rises there, it would be impossible to discover if the problem is > > either > > at the closed-source driver or at the open source one. At the time I

[PATCH] radeon: Set macrotile shape on Evergreen hardware

Evergreen and later Radeons let the driver choose a macro tile layout, within certain constraints. If we don't set the appropriate fields correctly, the card will use a layout that doesn't normally meet the constraints on Evergreen tiling. For now, select 8x8 aspect 1 macrotiles, as this makes it

radeon stable patches

On Tue, Dec 13, 2011 at 09:29:58AM -0500, Alex Deucher wrote: > Hi Greg, > > Can you cherry-pick the following patches back to the stable branches: > b4f15f808b9a79b6ad9032fa5f6d8b88e1e1bf11 > 1d33e1fc8dcce667a70387b666a8b6f60153d90f > cf2aff6eff251b6fbdaf8c253e65ff7c693de8cd > They fix the

[Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

(I've been away for the past two weeks, so I'm only now catching up) On Thursday 08 December 2011 22:44:08 Daniel Vetter wrote: > On Wed, Dec 7, 2011 at 14:40, Arnd Bergmann wrote: > > On Wednesday 07 December 2011, Semwal, Sumit wrote: > >> Thanks for the excellent discussion - it indeed is

Black screen with AMD A4-3300 support

Hi, I have a new ASUS K53TA notebook with AMD A4-3300 CPU and an extra Radeon HD6550M. I installed Fedora 16 on it but I get only black screen even during installation unless booted with nomodeset. But it's only VESA so there's no acceleration and there's no native LCD 1366x768 resolution, only

[PATCH] fixes to drm-next - TTM DMA code (v1)

On Tue, Dec 13, 2011 at 05:23:30PM +0100, Thomas Hellstrom wrote: > On 12/13/2011 05:07 PM, Jerome Glisse wrote: > >On Mon, Dec 12, 2011 at 03:09:26PM -0500, Konrad Rzeszutek Wilk wrote: > >>Jerome pointed me to some accounting error in the DMA API debugging code and > >>while I can't figure it

[PATCH 5/5] drm/exynos: Add plane support with fimd

Hi, Rob. below is my answer. > -Original Message- > From: Rob Clark [mailto:robdclark at gmail.com] > Sent: Tuesday, December 13, 2011 9:48 AM > To: Joonyoung Shim > Cc: Inki Dae; kyungmin.park at samsung.com; sw0312.kim at samsung.com; dri- > devel at lists.freedesktop.org > Subject: Re:

[PATCH] drm: Enable reading 3D capabilities of 3D monitor

/* 0x9 onwards is reserved for future */ > +}; If format is supposed to be an enum, why aren't you using these symbolic values? - ajax -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20111213/353b0808/attachment.pgp>

[ANNOUNCE] libdrm 2.4.29

: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20111213/6840bbf0/attachment.pgp>

EDID Override

eedesktop.org/archives/dri-devel/attachments/20111213/6f0a0de4/attachment-0001.asc>

[PATCH] fixes to drm-next - TTM DMA code (v1)

On Mon, Dec 12, 2011 at 03:09:26PM -0500, Konrad Rzeszutek Wilk wrote: > Jerome pointed me to some accounting error in the DMA API debugging code and > while I can't figure it out yet, I did notice some extreme slowness - which > is due to the nouveau driver calling the unpopulate (now that unbind

[PATCH] radeon: Set macrotile shape on Evergreen hardware

On Tue, Dec 13, 2011 at 03:08:53PM +, Simon Farnsworth wrote: > Evergreen and later Radeons let the driver choose a macro tile layout, > within certain constraints. If we don't set the appropriate fields > correctly, the card will use a layout that doesn't normally meet the > constraints on

Memory corruption starting in i915 code, in 3.2-rc5

or so. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20111213/00b01562/attachment.pgp>

Memory corruption starting in i915 code, in 3.2-rc5

El 12/12/11 11:41, Keith Packard escribi?: > On Mon, 12 Dec 2011 09:51:19 -0500, Alex Villac??s Lasso palosanto.com> wrote: > >> Ran kernel with reverted patch for 6 hours without issues so far. Will >> keep testing after work (issue happens with my home machine). > Thanks much. Let me know if

[PATCH] drm_edid: support CEA video modes

gy Center -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20111213/07b5e7e5/attachment.pgp>

[PATCH 5/5] drm/exynos: Add plane support with fimd

On 12/13/2011 06:59 AM, Rob Clark wrote: > On Fri, Dec 9, 2011 at 4:59 AM, Inki Dae wrote: >> From: Joonyoung Shim >> >> The exynos fimd supports 5 window overlays. Only one window overlay of >> fimd is used by the crtc, so we need plane feature to use the rest >> window overlays. >> >> This

radeon stable patches

org/archives/dri-devel/attachments/20111213/5c16aa3d/attachment-0003.patch> -- next part -- A non-text attachment was scrubbed... Name: 0002-drm-radeon-kms-rework-DP-bridge-checks.patch Type: text/x-diff Size: 9888 bytes Desc: not available URL: <http://lists.freede

[PATCH 5/5] drm/exynos: Add plane support with fimd

On 12/13/2011 07:48 AM, Rob Clark wrote: > On Fri, Dec 9, 2011 at 4:59 AM, Inki Dae wrote: >> +static int >> +exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, >> +struct drm_framebuffer *fb, int crtc_x, int crtc_y, >> +unsigned int

Black screen with AMD A4-3300 support

On 12/13/2011 06:49 AM, Boszormenyi Zoltan wrote: > I have a new ASUS K53TA notebook with AMD A4-3300 CPU > and an extra Radeon HD6550M. I installed Fedora 16 on it but > I get only black screen even during installation unless booted > with nomodeset. But it's only VESA so there's no acceleration

[PATCH 2/2] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

On Fri, Dec 09, 2011 at 03:53:49PM -0800, Keith Packard wrote: > RC6 should always work on IVB, and should work on SNB whenever IO > remapping is disabled. RC6 never works on Ironlake. Make the default > value for the parameter follow these guidelines. Setting the value > to either 0 or 1 will

[Bug 43771] New: [i915g] src/gallium/auxiliary/gallivm/lp_bld_sample_aos.c:821:lp_build_sample_mipmap: Assertion `img_filter == 1' failed.

https://bugs.freedesktop.org/show_bug.cgi?id=43771 Bug #: 43771 Summary: [i915g] src/gallium/auxiliary/gallivm/lp_bld_sample_aos.c:821: lp_build_sample_mipmap: Assertion `img_filter == 1' failed.

[Bug 43770] New: [i915g] src/gallium/drivers/i915/i915_fpc_emit.c:153:i915_emit_arith: Assertion `(((dest)>>29)&0x7) != 2' failed.

https://bugs.freedesktop.org/show_bug.cgi?id=43770 Bug #: 43770 Summary: [i915g] src/gallium/drivers/i915/i915_fpc_emit.c:153:i915_emit _arith: Assertion `(((dest)>>29)&0x7) != 2' failed. Classification: Unclassified

[Bug 38661] [i915g] src/gallium/drivers/i915/i915_state_static.c:122:update_framebuffer: Assertion `offset == 0' failed.

https://bugs.freedesktop.org/show_bug.cgi?id=38661 --- Comment #3 from Vinson Lee 2011-12-12 16:50:10 PST --- mesa: 23895cc006f3dbf96a502ddd15e291e071aff25a (master) Assert still occurs. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this

[Bug 43769] New: [i915g] src/gallium/drivers/i915/i915_fpc_translate.c:658:i915_translate_instruction: Assertion `0' failed.

https://bugs.freedesktop.org/show_bug.cgi?id=43769 Bug #: 43769 Summary: [i915g] src/gallium/drivers/i915/i915_fpc_translate.c:658:i915 _translate_instruction: Assertion `0' failed. Classification: Unclassified

[Bug 43768] New: [i915g] src/gallium/drivers/i915/i915_fpc_translate.c:1101:i915_translate_token: Assertion `ifs->constant_flags[i] == 0x0' failed.

https://bugs.freedesktop.org/show_bug.cgi?id=43768 Bug #: 43768 Summary: [i915g] src/gallium/drivers/i915/i915_fpc_translate.c:1101:i91 5_translate_token: Assertion `ifs->constant_flags[i] == 0x0' failed.

drm_framebuffer_cleanup cleanup..

On Fri, Dec 9, 2011 at 18:44, Dave Airlie wrote: > On Fri, Dec 9, 2011 at 5:40 PM, Rob Clark wrote: >> On Wed, Oct 19, 2011 at 8:27 AM, Daniel Vetter wrote: +static void omap_framebuffer_destroy(struct drm_framebuffer *fb) +{ + ? ? struct drm_device *dev = fb->dev; + ? ?

[ANNOUNCE] libdrm 2.4.29

This publishes some new API for Intel to be able to cap the number of VMA that libdrm_intel caches amongst its bo. This is intended to be used by clients to prevent applications (such as the xserver) from exhausting their per-process limits on inactive GTT mmaps whilst also mitigating against the

Black screen with AMD A4-3300 support

Hi, I have a new ASUS K53TA notebook with AMD A4-3300 CPU and an extra Radeon HD6550M. I installed Fedora 16 on it but I get only black screen even during installation unless booted with nomodeset. But it's only VESA so there's no acceleration and there's no native LCD 1366x768 resolution, only

EDID Override

Dear all, please find below a patch that will allow overriding a monitor's EDID with something provided by the user. This can be helpful in a number of situations as a quick google for edid override or similar suggests; I wrote it because my monitor is broken and doesn't provide any EDID at

Re: Black screen with AMD A4-3300 support

On 12/13/2011 06:49 AM, Boszormenyi Zoltan wrote: I have a new ASUS K53TA notebook with AMD A4-3300 CPU and an extra Radeon HD6550M. I installed Fedora 16 on it but I get only black screen even during installation unless booted with nomodeset. But it's only VESA so there's no acceleration and

Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

(I've been away for the past two weeks, so I'm only now catching up) On Thursday 08 December 2011 22:44:08 Daniel Vetter wrote: On Wed, Dec 7, 2011 at 14:40, Arnd Bergmann a...@arndb.de wrote: On Wednesday 07 December 2011, Semwal, Sumit wrote: Thanks for the excellent discussion - it

radeon stable patches

Hi Greg, Can you cherry-pick the following patches back to the stable branches: b4f15f808b9a79b6ad9032fa5f6d8b88e1e1bf11 1d33e1fc8dcce667a70387b666a8b6f60153d90f cf2aff6eff251b6fbdaf8c253e65ff7c693de8cd They fix the internal panel setup on certain fusion laptops. I've attached patches I

[PATCH] radeon: Set macrotile shape on Evergreen hardware

Evergreen and later Radeons let the driver choose a macro tile layout, within certain constraints. If we don't set the appropriate fields correctly, the card will use a layout that doesn't normally meet the constraints on Evergreen tiling. For now, select 8x8 aspect 1 macrotiles, as this makes it

Re: [PATCH] radeon: Set macrotile shape on Evergreen hardware

On Tue, Dec 13, 2011 at 03:08:53PM +, Simon Farnsworth wrote: Evergreen and later Radeons let the driver choose a macro tile layout, within certain constraints. If we don't set the appropriate fields correctly, the card will use a layout that doesn't normally meet the constraints on

Re: [PATCH] fixes to drm-next - TTM DMA code (v1)

On Mon, Dec 12, 2011 at 03:09:26PM -0500, Konrad Rzeszutek Wilk wrote: Jerome pointed me to some accounting error in the DMA API debugging code and while I can't figure it out yet, I did notice some extreme slowness - which is due to the nouveau driver calling the unpopulate (now that unbind +

Re: [PATCH] drm: Enable reading 3D capabilities of 3D monitor

On Fri, 2011-12-09 at 11:46 +, Kavuri, Sateesh wrote: + if ((multi_val == STRUCTURE_PRESENT) || + (multi_val == STRUCTURE_MASK_PRESENT) ) { + if ((edid_ext[i+15+hdmi_vic_len] 0x01) == 0x01) +

Re: [PATCH] fixes to drm-next - TTM DMA code (v1)

On 12/13/2011 05:07 PM, Jerome Glisse wrote: On Mon, Dec 12, 2011 at 03:09:26PM -0500, Konrad Rzeszutek Wilk wrote: Jerome pointed me to some accounting error in the DMA API debugging code and while I can't figure it out yet, I did notice some extreme slowness - which is due to the nouveau

Re: [PATCH] fixes to drm-next - TTM DMA code (v1)

On Tue, Dec 13, 2011 at 05:23:30PM +0100, Thomas Hellstrom wrote: On 12/13/2011 05:07 PM, Jerome Glisse wrote: On Mon, Dec 12, 2011 at 03:09:26PM -0500, Konrad Rzeszutek Wilk wrote: Jerome pointed me to some accounting error in the DMA API debugging code and while I can't figure it out yet, I

Re: Memory corruption starting in i915 code, in 3.2-rc5

On Tue, 13 Dec 2011 10:14:15 -0500, Alex Villací­s Lasso a_villa...@palosanto.com wrote: By using a bootable USB stick, I could check the logs, which showed many segfaults at /lib64/ld-2.14.90.so . Ouch! Please let me know if you find anything further; I'd like to get a revert sent upstream

Re: Memory corruption starting in i915 code, in 3.2-rc5

On Tue, Dec 13, 2011 at 10:14:46AM -0800, Keith Packard wrote: On Tue, 13 Dec 2011 10:14:15 -0500, Alex Villací­s Lasso a_villa...@palosanto.com wrote: By using a bootable USB stick, I could check the logs, which showed many segfaults at /lib64/ld-2.14.90.so . Ouch! Please let me

Re: [PATCH 00/23] kill drm cruft with fire

On Wed, Dec 07, 2011 at 02:19:39PM +, James Simmons wrote: Testing this on via would be awesome! Iirc I haven't changed anything in the via specific patches, but if it's more convenient you can also directly test my branch:

Re: Memory corruption starting in i915 code, in 3.2-rc5

El 12/12/11 11:41, Keith Packard escribió: On Mon, 12 Dec 2011 09:51:19 -0500, Alex Villací­s Lassoa_villa...@palosanto.com wrote: Ran kernel with reverted patch for 6 hours without issues so far. Will keep testing after work (issue happens with my home machine). Thanks much. Let me know if

[drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

(Send similar post to LKML / linux.kernel but no responses there yet) Hello, we where building 3.1.4 kernel when we noticed BUG()s on bootup. Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in drm_vblank_cleanup+0x78/0x90 [drm] Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in

Re: [PATCH] fixes to drm-next - TTM DMA code (v1)

Hi! I'm not whether any drivers are still using the AGP backend? Actually the openchrome projects KMS kernel uses a AGP backend. Calling unpopulate / (previous clear) each time unbind is done should be quite inefficient with that one, as AGP sets up its own data structures and copies

Re: radeon stable patches

On Tue, Dec 13, 2011 at 09:29:58AM -0500, Alex Deucher wrote: Hi Greg, Can you cherry-pick the following patches back to the stable branches: b4f15f808b9a79b6ad9032fa5f6d8b88e1e1bf11 1d33e1fc8dcce667a70387b666a8b6f60153d90f cf2aff6eff251b6fbdaf8c253e65ff7c693de8cd They fix the internal

Patches queued to drm-intel-fixes

Hi Keith, I've noticed that you merged my patch rm/i915: properly prefault for pread/pwrite into your -fixes branch (which I assume is headed for 3.2). Please remove that from your queue again for the following reasons: - The right thing to do is to fix up the prefault handlers in pagemap.h -

Re: Patches queued to drm-intel-fixes

On Wed, 14 Dec 2011 00:04:26 +0100, Daniel Vetter daniel.vet...@ffwll.ch wrote: Hi Keith, I've noticed that you merged my patch rm/i915: properly prefault for pread/pwrite into your -fixes branch (which I assume is headed for 3.2). Please remove that from your queue again for the following

Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

On Tue, Dec 13, 2011 at 10:26:15PM +0100, batouzo wrote: (Send similar post to LKML / linux.kernel but no responses there yet) Hello, we where building 3.1.4 kernel when we noticed BUG()s on bootup. Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in drm_vblank_cleanup+0x78/0x90

Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

On 12/14/2011 12:31 AM, Jerome Glisse wrote: Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in drm_vblank_cleanup+0x78/0x90 [drm] Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in drm_vblank_cleanup+0x48/0x90 [drm] It is Amd Bulldozer computer, with Radeon card: 01:00.0 VGA

Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

On Tue, Dec 13, 2011 at 6:33 PM, batouzo bato...@gmx.com wrote: On 12/14/2011 12:31 AM, Jerome Glisse wrote: Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in drm_vblank_cleanup+0x78/0x90 [drm] Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in drm_vblank_cleanup+0x48/0x90

Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

On Tue, Dec 13, 2011 at 6:46 PM, Jerome Glisse j.gli...@gmail.com wrote: On Tue, Dec 13, 2011 at 6:33 PM, batouzo bato...@gmx.com wrote: On 12/14/2011 12:31 AM, Jerome Glisse wrote: Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in drm_vblank_cleanup+0x78/0x90 [drm] Allocated in

[Bug 43655] Latest radeon dri driver on HD6950 with kernel 3.2 flickers

https://bugs.freedesktop.org/show_bug.cgi?id=43655 --- Comment #4 from Alexandre Demers alexandre.f.dem...@gmail.com 2011-12-13 17:48:47 PST --- Strangely, when rebisecting, I found commit a34815b96f9a21b3a2e2912dfd0d994acd2855e3 to be the bad one... It is really near to the first one. So, I'm

Re: [PATCH 2/2] drm/omap: drm API update: addfb2

On Mon, Dec 12, 2011 at 6:56 PM, Greg KH g...@kroah.com wrote: On Mon, Dec 12, 2011 at 06:49:44PM -0600, Rob Clark wrote: From: Rob Clark r...@ti.com Update to reflect changes in: drm: add an fb creation ioctl that takes a pixel format v5 This one I'm going to have to wait for the drm api

[PATCH 1/2] drm: disconnect plane from fb/crtc when disabled

From: Rob Clark r...@ti.com Since plane-fb and plane-crtc are set in drm_mode_setplane() after update_plane(), They should be cleared after disable(). Signed-off-by: Rob Clark r...@ti.com --- drivers/gpu/drm/drm_crtc.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git

[PATCH 2/2] drm: add support for private planes

From: Rob Clark r...@ti.com In cases where the scanout hw is sufficiently similar between overlay and traditional crtc layers, it might be convenient to allow the driver to create internal drm_plane helper objects used by the drm_crtc implementation, rather than duplicate code between the plane

[PATCH] modetest: add drm_plane support

From: Rob Clark r...@ti.com Signed-off-by: Rob Clark r...@ti.com --- tests/modetest/modetest.c | 166 ++--- 1 files changed, 157 insertions(+), 9 deletions(-) diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c index 1e4ec91..22ac620

Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

On 12/14/2011 12:47 AM, Jerome Glisse wrote: On Tue, Dec 13, 2011 at 6:46 PM, Jerome Glisse j.gli...@gmail.com wrote: On Tue, Dec 13, 2011 at 6:33 PM, batouzo bato...@gmx.com wrote: On 12/14/2011 12:31 AM, Jerome Glisse wrote: Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in

[PATCH] libdrm: fix sizes of memcpy to the drmModeAddFB2()

The variables(bo_handles, pitches and offsets) are the array having 4 elementary of uint32_t type. The their memcpy size is sizeof(uint32_t) * 4. Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com --- xf86drmMode.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git