Re: [RFC v2 8/8] drm: tegra: Add gr2d device

On 27.11.2012 09:33, Dave Airlie wrote: Third would be having a firewall in 2D driver checking the stream and ensuring all registers that accept addresses are written by values derived from dmabufs. I haven't tried implementing this, but it'd involve a lookup table in kernel and CPU reading

Re: [RFC v2 8/8] drm: tegra: Add gr2d device

On Tue, Nov 27, 2012 at 8:16 AM, Terje Bergström tbergst...@nvidia.com wrote: On 27.11.2012 09:33, Dave Airlie wrote: Third would be having a firewall in 2D driver checking the stream and ensuring all registers that accept addresses are written by values derived from dmabufs. I haven't tried

Re: [RFC v2 8/8] drm: tegra: Add gr2d device

On 27.11.2012 10:32, Dave Airlie wrote: On Tue, Nov 27, 2012 at 8:16 AM, Terje Bergström tbergst...@nvidia.com wrote: Thanks for the pointer, I looked at exynos code. It indeed checks the registers written to, but it doesn't prevent overrun by checking sizes of buffers and compare against

[Bug 57531] [GEM] RS780V allocation errors with piglit

https://bugs.freedesktop.org/show_bug.cgi?id=57531 Christian König deathsim...@vodafone.de changed: What|Removed |Added Status|NEW |RESOLVED

Re: [PATCH 1/1] drm/nouveau: remove duplicate inclusion of nouveau_ttm.h

ping On 20 November 2012 11:23, Sachin Kamat sachin.ka...@linaro.org wrote: nouveau_ttm.h was included twice. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/gpu/drm/nouveau/nouveau_drm.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git

Re: [PATCH 1/1] drm/nouveau/device: Remove duplicate inclusion of core/device.h

ping.. On 20 November 2012 11:35, Sachin Kamat sachin.ka...@linaro.org wrote: core/device.h was included twice. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/gpu/drm/nouveau/core/subdev/device/base.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git

Re: [PATCH 1/1] drm/nouveau: remove duplicate inclusion of nouveau_ttm.h

On 27 November 2012 09:09, Ben Skeggs bske...@redhat.com wrote: On Tue, 2012-11-27 at 09:04 +0530, Sachin Kamat wrote: ping On 20 November 2012 11:23, Sachin Kamat sachin.ka...@linaro.org wrote: nouveau_ttm.h was included twice. I've queued it in my tree, thanks! Thanks Ben. There is also

Re: [RFC v2 8/8] drm: tegra: Add gr2d device

Am Dienstag, den 27.11.2012, 10:45 +0200 schrieb Terje Bergström: On 27.11.2012 10:32, Dave Airlie wrote: On Tue, Nov 27, 2012 at 8:16 AM, Terje Bergström tbergst...@nvidia.com wrote: Thanks for the pointer, I looked at exynos code. It indeed checks the registers written to, but it

Re: [RFC v2 8/8] drm: tegra: Add gr2d device

On Tue, Nov 27, 2012 at 11:22:56AM +0100, Lucas Stach wrote: Am Dienstag, den 27.11.2012, 10:45 +0200 schrieb Terje Bergström: On 27.11.2012 10:32, Dave Airlie wrote: On Tue, Nov 27, 2012 at 8:16 AM, Terje Bergström tbergst...@nvidia.com wrote: Thanks for the pointer, I looked at

[Bug 51421] sin and cos is broken

https://bugs.freedesktop.org/show_bug.cgi?id=51421 Golubev Yaroslav my3blkan...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED

Re: [RFC v2 8/8] drm: tegra: Add gr2d device

On 27.11.2012 12:37, Thierry Reding wrote: But in that case it should be made mandatory at first until proper IOMMU support is enabled on Tegra30. Then it can be checked at driver probe time whether or not to enable the extra checks. That way we don't need a special Kconfig option and we still

Re: [RFC v2 1/8] video: tegra: Add nvhost driver

On Mon, Nov 26, 2012 at 02:19:07PM +0100, Terje Bergstrom wrote: + +struct nvhost_chip_support *nvhost_chip_ops; should be static? +static int __devinit nvhost_alloc_resources(struct nvhost_master *host) +{ + int err; + + err = nvhost_init_chip_support(host); + if (err)

Re: [RFC v2 2/8] video: tegra: Add syncpoint wait and interrupts

On Mon, Nov 26, 2012 at 02:19:08PM +0100, Terje Bergstrom wrote: +void nvhost_intr_stop(struct nvhost_intr *intr) +{ + unsigned int id; + struct nvhost_intr_syncpt *syncpt; + u32 nb_pts = nvhost_syncpt_nb_pts(intr_to_dev(intr)-syncpt); + + mutex_lock(intr-mutex); +

Re: [RFC v2 8/8] drm: tegra: Add gr2d device

Am Dienstag, den 27.11.2012, 13:31 +0200 schrieb Terje Bergström: On 27.11.2012 12:37, Thierry Reding wrote: But in that case it should be made mandatory at first until proper IOMMU support is enabled on Tegra30. Then it can be checked at driver probe time whether or not to enable the extra

Re: [PATCH 04/10] drm/ttm: change fence_lock to inner lock, v3

Op 22-11-12 21:29, Thomas Hellstrom schreef: On 11/22/2012 04:51 PM, Maarten Lankhorst wrote: Op 21-11-12 14:27, Thomas Hellstrom schreef: On 11/21/2012 02:12 PM, Maarten Lankhorst wrote: Op 21-11-12 13:42, Thomas Hellstrom schreef: On 11/21/2012 12:38 PM, Maarten Lankhorst wrote: Hey, Op

Re: [RFC v2 8/8] drm: tegra: Add gr2d device

On 27.11.2012 13:47, Lucas Stach wrote: I guess we could change IOMMU address spaces for the graphics units depending on the active channel. This would still be a bit of a performance hit, because of the necessary TLB flushing and so on, but should be much better than checking the whole

Re: Abstracting buffer sharing mechanism from the drm drivers

On 11/16/2012 01:14 PM, Jerome Glisse wrote: On Fri, Nov 16, 2012 at 12:05:40PM -0800, Aaron Plattner wrote: At the suggestion of a few drm developers, I'm looking at abstracting the buffer sharing mechanism away from the individual drm drivers and treating it as a low-level interface that

Re: [v3.7-rcx] drm/i915: *ERROR* Timed out waiting for forcewake old ack to clear

On Tue, 27 Nov 2012 17:29:36 +0100, Jörg Otte jrg.o...@gmail.com wrote: At boot-up with newer kernels (at least v3.6.x, v3.7-rc) I always see following on the bootup-display: 3.7-rcx: [drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out waiting for forcewake old ack to clear. 3.6.x:

Re: [RFC v2 5/8] ARM: tegra: Add auxiliary data for nvhost

On 11/26/2012 11:33 PM, Terje Bergström wrote: On 27.11.2012 01:39, Stephen Warren wrote: Clock names shouldn't be passed in platform data; instead, clk_get() should be passed the device object and device-relative (i.e. not global) clock name. I expect if the driver is fixed to make this

[Bug 56659] DRI_PRIME: triangle, rendering inside of which occurs with a noticeable delay

https://bugs.freedesktop.org/show_bug.cgi?id=56659 runetmem...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED

Re: [PATCH] drm: tegra: Use framebuffer pitch as line stride

On 11/26/2012 08:16 PM, Mark Zhang wrote: On 11/27/2012 06:37 AM, Stephen Warren wrote: On 11/22/2012 12:37 PM, Thierry Reding wrote: Instead of using the stride derived from the display mode, use the pitch associated with the currently active framebuffer. This fixes a bug where the LCD

[Bug 47481] Random blank screen: radeon_cs_ib_chunk Failed to schedule IB on AMD PALM

https://bugzilla.kernel.org/show_bug.cgi?id=47481 --- Comment #13 from Andre and...@all-ein.net 2012-11-27 20:17:53 --- I have to correct myself. The bug hits me again, this time only the HDMI output was active. Today after 4 hours the screen was blinking black and freezes except the mouse

[PATCH] radeon: fix pll/ctrc mapping on dce2 and dce3 hardware

From: Jerome Glisse jgli...@redhat.com This fix black screen on resume issue that some people are experiencing. There is a bug in the atombios code regarding pll/crtc mapping. The atombios code reverse the logic for the pll and crtc mapping. Signed-off-by: Jerome Glisse jgli...@redhat.com ---

Re: [PATCH] radeon: fix pll/ctrc mapping on dce2 and dce3 hardware

On Tue, Nov 27, 2012 at 4:12 PM, j.gli...@gmail.com wrote: From: Jerome Glisse jgli...@redhat.com This fix black screen on resume issue that some people are experiencing. There is a bug in the atombios code regarding pll/crtc mapping. The atombios code reverse the logic for the pll and crtc

Re: [PATCH] drm: tegra: Use framebuffer pitch as line stride

On 11/27/2012 11:17 AM, Stephen Warren wrote: On 11/26/2012 08:16 PM, Mark Zhang wrote: On 11/27/2012 06:37 AM, Stephen Warren wrote: On 11/22/2012 12:37 PM, Thierry Reding wrote: Instead of using the stride derived from the display mode, use the pitch associated with the currently active

Re: [PATCH] drm: tegra: Use framebuffer pitch as line stride

Am Dienstag, den 27.11.2012, 14:39 -0700 schrieb Stephen Warren: For your viewing pleasure (and playing with my new phone) :-) http://www.youtube.com/watch?v=ZJxJnONz7DA The external monitor is 1920x1200 I believe. Jon Mayo says the corruption in the video is display (memory fetch)

[pull] radeon drm-fixes-3.7

From: Alex Deucher alexander.deuc...@amd.com Hi Dave, One last fix for 3.7 from Jerome. This fixes a display regression which results in blank displays in some cases. The following changes since commit 452f19201f35d20a1a6c9009acbcfa6799163c6a: Merge branch 'drm-fixes-3.7' of

Re: [RFC v2 8/8] drm: tegra: Add gr2d device

On Tue, Nov 27, 2012 at 9:31 PM, Terje Bergström tbergst...@nvidia.com wrote: On 27.11.2012 12:37, Thierry Reding wrote: But in that case it should be made mandatory at first until proper IOMMU support is enabled on Tegra30. Then it can be checked at driver probe time whether or not to enable

[PATCH 1/2] radeon: fix pll/ctrc mapping on dce2 and dce3 hardware v2

From: Jerome Glisse jgli...@redhat.com This fix black screen on resume issue that some people are experiencing. There is a bug in the atombios code regarding pll/crtc mapping. The atombios code reverse the logic for the pll and crtc mapping. v2: DCE3 or DCE2 only have 2 crtc Signed-off-by:

[PATCH 2/2] drm/radeon: fix deadlock when bo is associated to different handle

From: Jerome Glisse jgli...@redhat.com There is a rare case, that seems to only happen accross suspend/resume cycle, where a bo is associated with several different handle. This lead to a deadlock in ttm buffer reservation path. This could only happen with flinked(globaly exported) object.

[PATCH] drm/radeon: track global bo name and always return the same

From: Jerome Glisse jgli...@redhat.com To avoid kernel rejecting cs if we return different global name for same bo keep track of global name and always return the same. Seems to fix issue with suspend/resume failing and repeatly printing following message : [drm:radeon_cs_ioctl] *ERROR* Failed to

[Bug 57567] 3.7 radeonfb broken on efivga screens

https://bugs.freedesktop.org/show_bug.cgi?id=57567 --- Comment #7 from Alexandre Demers alexandre.f.dem...@gmail.com --- Could this be related to bug 56139? Description is similar to what is shown in recorded boot process videos. -- You are receiving this mail because: You are the assignee for

[Bug 57567] 3.7 radeonfb broken on efivga screens

https://bugs.freedesktop.org/show_bug.cgi?id=57567 --- Comment #8 from Alexandre Demers alexandre.f.dem...@gmail.com --- In fact, Vladimir, could you edit your grub entry and see if there is set gfxpayload=keep. If so, change it to set gfxpayload=text or remove the line completely. If it solves

Re: [PATCH] drm: tegra: Use framebuffer pitch as line stride

On 11/28/2012 05:39 AM, Stephen Warren wrote: On 11/27/2012 11:17 AM, Stephen Warren wrote: On 11/26/2012 08:16 PM, Mark Zhang wrote: On 11/27/2012 06:37 AM, Stephen Warren wrote: On 11/22/2012 12:37 PM, Thierry Reding wrote: Instead of using the stride derived from the display mode, use the

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (boot/grub2 and suspend/resume) (CAYMAN)

https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #42 from Alexandre Demers alexandre.f.dem...@gmail.com --- Going fishing: Alex, you said you were unable to reproduce this bug with your cayman device. Could it be related to the display connector? I'm using the DVI connector from my

[RFC v2 8/8] drm: tegra: Add gr2d device

> static int tegra_drm_open(struct drm_device *drm, struct drm_file *filp) > { > - return 0; > + struct tegra_drm_fpriv *fpriv; > + int err = 0; > + > + fpriv = kzalloc(sizeof(*fpriv), GFP_KERNEL); > + if (!fpriv) > + return -ENOMEM; > + > +

[PATCH 1/1] drm/nouveau: remove duplicate inclusion of nouveau_ttm.h

On Tue, 2012-11-27 at 09:04 +0530, Sachin Kamat wrote: > ping > > On 20 November 2012 11:23, Sachin Kamat wrote: > > nouveau_ttm.h was included twice. I've queued it in my tree, thanks! Ben. > > > > Signed-off-by: Sachin Kamat > > --- > > drivers/gpu/drm/nouveau/nouveau_drm.c |2 -- > >

[RFC v2 5/8] ARM: tegra: Add auxiliary data for nvhost

On 27.11.2012 01:39, Stephen Warren wrote: > Clock names shouldn't be passed in platform data; instead, clk_get() > should be passed the device object and device-relative (i.e. not global) > clock name. I expect if the driver is fixed to make this change, the > changes to tegra*_clocks_data.c

[RFC v2 8/8] drm: tegra: Add gr2d device

On 27.11.2012 00:15, Dave Airlie wrote: >> static int tegra_drm_open(struct drm_device *drm, struct drm_file *filp) >> { >> - return 0; >> + struct tegra_drm_fpriv *fpriv; >> + int err = 0; >> + >> + fpriv = kzalloc(sizeof(*fpriv), GFP_KERNEL); >> + if (!fpriv) >> +

[RFC v2 8/8] drm: tegra: Add gr2d device

> > Third would be having a firewall in 2D driver checking the stream and > ensuring all registers that accept addresses are written by values > derived from dmabufs. I haven't tried implementing this, but it'd > involve a lookup table in kernel and CPU reading through the command > stream.

[RFC v2 8/8] drm: tegra: Add gr2d device

On 27.11.2012 09:33, Dave Airlie wrote: >> Third would be having a firewall in 2D driver checking the stream and >> ensuring all registers that accept addresses are written by values >> derived from dmabufs. I haven't tried implementing this, but it'd >> involve a lookup table in kernel and CPU

[RFC v2 8/8] drm: tegra: Add gr2d device

On Tue, Nov 27, 2012 at 8:16 AM, Terje Bergstr?m wrote: > On 27.11.2012 09:33, Dave Airlie wrote: >>> Third would be having a firewall in 2D driver checking the stream and >>> ensuring all registers that accept addresses are written by values >>> derived from dmabufs. I haven't tried

[RFC v2 8/8] drm: tegra: Add gr2d device

On 27.11.2012 10:32, Dave Airlie wrote: > On Tue, Nov 27, 2012 at 8:16 AM, Terje Bergstr?m > wrote: >> Thanks for the pointer, I looked at exynos code. It indeed checks the >> registers written to, but it doesn't prevent overrun by checking sizes >> of buffers and compare against requests. >

[Bug 57531] [GEM] RS780V allocation errors with piglit

vel/attachments/20121127/2ae15e66/attachment.html>

[PATCH 1/1] drm/nouveau: remove duplicate inclusion of nouveau_ttm.h

ping On 20 November 2012 11:23, Sachin Kamat wrote: > nouveau_ttm.h was included twice. > > Signed-off-by: Sachin Kamat > --- > drivers/gpu/drm/nouveau/nouveau_drm.c |2 -- > 1 files changed, 0 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c >

[PATCH 1/1] drm/nouveau/device: Remove duplicate inclusion of core/device.h

ping.. On 20 November 2012 11:35, Sachin Kamat wrote: > core/device.h was included twice. > > Signed-off-by: Sachin Kamat > --- > drivers/gpu/drm/nouveau/core/subdev/device/base.c |1 - > 1 files changed, 0 insertions(+), 1 deletions(-) > > diff --git

[PATCH 1/1] drm/nouveau: remove duplicate inclusion of nouveau_ttm.h

On 27 November 2012 09:09, Ben Skeggs wrote: > On Tue, 2012-11-27 at 09:04 +0530, Sachin Kamat wrote: >> ping >> >> On 20 November 2012 11:23, Sachin Kamat wrote: >> > nouveau_ttm.h was included twice. > I've queued it in my tree, thanks! Thanks Ben. There is also another patch for which I have

[RFC v2 8/8] drm: tegra: Add gr2d device

Am Dienstag, den 27.11.2012, 10:45 +0200 schrieb Terje Bergstr?m: > On 27.11.2012 10:32, Dave Airlie wrote: > > On Tue, Nov 27, 2012 at 8:16 AM, Terje Bergstr?m > > wrote: > >> Thanks for the pointer, I looked at exynos code. It indeed checks the > >> registers written to, but it doesn't prevent

[RFC v2 8/8] drm: tegra: Add gr2d device

datory at first until proper IOMMU support is enabled on Tegra30. Then it can be checked at driver probe time whether or not to enable the extra checks. That way we don't need a special Kconfig option and we still get all the security that we need, right? Thierry -- next part -

[Bug 51421] sin and cos is broken

ns((bla-0.5)*100.0))); works fine -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121127/439f074a/attachment.html>

[RFC v2 8/8] drm: tegra: Add gr2d device

On 27.11.2012 12:37, Thierry Reding wrote: > But in that case it should be made mandatory at first until proper IOMMU > support is enabled on Tegra30. Then it can be checked at driver probe > time whether or not to enable the extra checks. That way we don't need a > special Kconfig option and we

[RFC v2 1/8] video: tegra: Add nvhost driver

On Mon, Nov 26, 2012 at 02:19:07PM +0100, Terje Bergstrom wrote: > + > +struct nvhost_chip_support *nvhost_chip_ops; should be static? > +static int __devinit nvhost_alloc_resources(struct nvhost_master *host) > +{ > + int err; > + > + err = nvhost_init_chip_support(host); > +

[RFC v2 2/8] video: tegra: Add syncpoint wait and interrupts

On Mon, Nov 26, 2012 at 02:19:08PM +0100, Terje Bergstrom wrote: > +void nvhost_intr_stop(struct nvhost_intr *intr) > +{ > + unsigned int id; > + struct nvhost_intr_syncpt *syncpt; > + u32 nb_pts = nvhost_syncpt_nb_pts(_to_dev(intr)->syncpt); > + > + mutex_lock(>mutex); > +

[RFC v2 8/8] drm: tegra: Add gr2d device

Am Dienstag, den 27.11.2012, 13:31 +0200 schrieb Terje Bergstr?m: > On 27.11.2012 12:37, Thierry Reding wrote: > > But in that case it should be made mandatory at first until proper IOMMU > > support is enabled on Tegra30. Then it can be checked at driver probe > > time whether or not to enable

[PATCH 04/10] drm/ttm: change fence_lock to inner lock, v3

Op 22-11-12 21:29, Thomas Hellstrom schreef: > On 11/22/2012 04:51 PM, Maarten Lankhorst wrote: >> Op 21-11-12 14:27, Thomas Hellstrom schreef: >>> On 11/21/2012 02:12 PM, Maarten Lankhorst wrote: Op 21-11-12 13:42, Thomas Hellstrom schreef: > On 11/21/2012 12:38 PM, Maarten Lankhorst

[RFC v2 8/8] drm: tegra: Add gr2d device

On 27.11.2012 13:47, Lucas Stach wrote: > I guess we could change IOMMU address spaces for the graphics units > depending on the active channel. This would still be a bit of a > performance hit, because of the necessary TLB flushing and so on, but > should be much better than checking the whole

Abstracting buffer sharing mechanism from the drm drivers

On 11/16/2012 01:14 PM, Jerome Glisse wrote: > On Fri, Nov 16, 2012 at 12:05:40PM -0800, Aaron Plattner wrote: >> At the suggestion of a few drm developers, I'm looking at abstracting the >> buffer >> sharing mechanism away from the individual drm drivers and treating it as a >> low-level

[v3.7-rcx] drm/i915: *ERROR* Timed out waiting for forcewake old ack to clear

On Tue, 27 Nov 2012 17:29:36 +0100, J??rg Otte wrote: > At boot-up with newer kernels (at least v3.6.x, v3.7-rc) I always see > following on the bootup-display: > > 3.7-rcx: [drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out waiting > for forcewake old ack to clear. > 3.6.x:

[RFC v2 5/8] ARM: tegra: Add auxiliary data for nvhost

On 11/26/2012 11:33 PM, Terje Bergstr?m wrote: > On 27.11.2012 01:39, Stephen Warren wrote: >> Clock names shouldn't be passed in platform data; instead, clk_get() >> should be passed the device object and device-relative (i.e. not global) >> clock name. I expect if the driver is fixed to make

[Bug 56659] DRI_PRIME: triangle, rendering inside of which occurs with a noticeable delay

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121127/ffccb071/attachment-0001.html>

[PATCH] drm: tegra: Use framebuffer pitch as line stride

On 11/26/2012 08:16 PM, Mark Zhang wrote: > On 11/27/2012 06:37 AM, Stephen Warren wrote: >> On 11/22/2012 12:37 PM, Thierry Reding wrote: >>> Instead of using the stride derived from the display mode, use the pitch >>> associated with the currently active framebuffer. This fixes a bug where >>>

[Bug 47481] Random blank screen: radeon_cs_ib_chunk Failed to schedule IB on AMD PALM

https://bugzilla.kernel.org/show_bug.cgi?id=47481 --- Comment #13 from Andre 2012-11-27 20:17:53 --- I have to correct myself. The bug hits me again, this time only the HDMI output was active. Today after 4 hours the screen was blinking black and freezes except the mouse was movable. I'm

[PATCH] radeon: fix pll/ctrc mapping on dce2 and dce3 hardware

From: Jerome Glisse This fix black screen on resume issue that some people are experiencing. There is a bug in the atombios code regarding pll/crtc mapping. The atombios code reverse the logic for the pll and crtc mapping. Signed-off-by: Jerome Glisse ---

[PATCH] radeon: fix pll/ctrc mapping on dce2 and dce3 hardware

On Tue, Nov 27, 2012 at 4:12 PM, wrote: > From: Jerome Glisse > > This fix black screen on resume issue that some people are > experiencing. There is a bug in the atombios code regarding > pll/crtc mapping. The atombios code reverse the logic for > the pll and crtc mapping. > > Signed-off-by:

[PATCH] drm: tegra: Use framebuffer pitch as line stride

On 11/27/2012 11:17 AM, Stephen Warren wrote: > On 11/26/2012 08:16 PM, Mark Zhang wrote: >> On 11/27/2012 06:37 AM, Stephen Warren wrote: >>> On 11/22/2012 12:37 PM, Thierry Reding wrote: Instead of using the stride derived from the display mode, use the pitch associated with the

[PATCH] drm: tegra: Use framebuffer pitch as line stride

Am Dienstag, den 27.11.2012, 14:39 -0700 schrieb Stephen Warren: > > For your viewing pleasure (and playing with my new phone) :-) > > http://www.youtube.com/watch?v=ZJxJnONz7DA > > > > The external monitor is 1920x1200 I believe. > > Jon Mayo says the corruption in the video is display (memory

[pull] radeon drm-fixes-3.7

From: Alex Deucher Hi Dave, One last fix for 3.7 from Jerome. This fixes a display regression which results in blank displays in some cases. The following changes since commit 452f19201f35d20a1a6c9009acbcfa6799163c6a: Merge branch 'drm-fixes-3.7' of

[PATCH 1/2] radeon: fix pll/ctrc mapping on dce2 and dce3 hardware v2

From: Jerome Glisse This fix black screen on resume issue that some people are experiencing. There is a bug in the atombios code regarding pll/crtc mapping. The atombios code reverse the logic for the pll and crtc mapping. v2: DCE3 or DCE2 only have 2 crtc Signed-off-by:

[PATCH 2/2] drm/radeon: fix deadlock when bo is associated to different handle

From: Jerome Glisse There is a rare case, that seems to only happen accross suspend/resume cycle, where a bo is associated with several different handle. This lead to a deadlock in ttm buffer reservation path. This could only happen with flinked(globaly exported) object.

[PATCH] drm/radeon: track global bo name and always return the same

From: Jerome Glisse To avoid kernel rejecting cs if we return different global name for same bo keep track of global name and always return the same. Seems to fix issue with suspend/resume failing and repeatly printing following message : [drm:radeon_cs_ioctl] *ERROR* Failed

[RFC v2 2/5] video: panel: Add DPI panel support

use case... Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121127/4d1ae1de/attachment-0001.pgp>

[RFC v2 1/5] video: Add generic display entity core

EDID data, in addition to funcs like above? Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121127/dd2d3042/attachment-0001.pgp>

[v3.7-rcx] drm/i915: *ERROR* Timed out waiting for forcewake old ack to clear

At boot-up with newer kernels (at least v3.6.x, v3.7-rc) I always see following on the bootup-display: 3.7-rcx: [drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out waiting for forcewake old ack to clear. 3.6.x:[drm:__gen6_gt_force_wake_mt_get] *ERROR* Force wake wait timed out It's an Ivy