[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board

https://bugzilla.kernel.org/show_bug.cgi?id=52121 --- Comment #14 from Fernando Chaves 2013-01-03 22:13:05 --- I have recorded this video: http://www.youtube.com/watch?v=T0qHBxla5f8 Note the frame rate of the movie after reboot, with xen loaded. -- Configure bugmail:

[Bug 58667] Random crashes on CAYMAN

oogle it. "Is this a regression? Does it happen with older versions of mesa or kernel?" Yes. Previous kernel 3.7 doesn't show this problem. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL:

[Bug 58667] Random crashes on CAYMAN

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/20130103/041a1939/attachment.html>

[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics

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/20130103/17549b6d/attachment.html>

[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics

floods my logs. -- 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/20130103/d092047f/attachment.html>

[pull] radeon drm-fixes-3.8

From: Alex Deucher Hi Dave, A few fixes for radeon: - fix the crashes related to DMA on r6xx - properly reset DMA on GPU reset - fix monitor probing with some DP bridges - misc small bug fixes The following changes since commit

Resume regression with nouveau 3.8rc1 (bisected)

On Thu, Jan 03, 2013 at 01:58:10PM +0100, Marcin Slusarz wrote: > On Wed, Jan 02, 2013 at 04:19:35PM +0100, Pontus Fuchs wrote: > > Hi, > > > > Starting with 3.8rc1 I get a black screen when resuming after suspend. > > The kernel is alive because I can switch to VT1 and reboot with > >

[PATCHv4 5/8] drm: tegra: Remove redundant host1x

On 21.12.2012 16:36, Thierry Reding wrote: > On Fri, Dec 21, 2012 at 01:39:21PM +0200, Terje Bergstrom wrote: >> +static void tegra_drm_close(struct drm_device *drm, struct drm_file *filp) >> +{ >> + >> +} >> + > > This can be removed, right? Yes, done. > >> +static struct platform_driver

[PATCH 1/5] drm/radeon: add GPU reset flags

On Thu, Jan 3, 2013 at 1:16 PM, wrote: > From: Alex Deucher > > The idea here is to move to a finer grained reset. > In some cases we may not need reset every block, and > in other cases we may not need to re-init the entire > asic. > > Signed-off-by: Alex Deucher for the serie Reviewed-by:

[Bug 57842] r200: Culling is broken when rendering to an FBO

attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130103/f55b61bf/attachment.html>

[PATCH 7/8] drm/exynos: hdmi: add complete_scanout function

) > > + mixer_wait_for_vblank(ctx); > > +} > > + > > static void mixer_window_suspend(struct mixer_context *ctx) > > { > > struct hdmi_win_data *win_data; > > @@ -969,7 +1004,7 @@ static struct exynos_mixer_ops mixer_ops = { > > .iommu_on

[PATCH 8/8] drm/exynos: fimd: add complete_scanout function

(0xA4 + ((_buff) * 8)) > > #define VIDW_BUF_END(_buff) (0xD0 + ((_buff) * 8)) > > #define VIDW_BUF_END1(_buff) (0xD4 + ((_buff) * 8)) > > -- > > 1.8.0 > > > > ___ > > dri-devel mailing list > > dri-devel at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130103/8bd0cb88/attachment-0001.html>

"Hangcheck timer elapsed... GPU hung" in 3.8.0-rc2

On Thu, Jan 03, 2013 at 04:16:24PM -0500, Josh Boyer wrote: > On Thu, Jan 3, 2013 at 3:46 PM, J. Bruce Fields > wrote: > > I got a crash after a few minutes of running 3.8.0-rc2, was able to > > switch to a vt and look at dmesg: > > > > [ 490.962545] [drm:i915_hangcheck_hung] *ERROR*

[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board

https://bugzilla.kernel.org/show_bug.cgi?id=52121 --- Comment #13 from Konrad Rzeszutek Wilk 2013-01-03 18:04:34 --- So is it safe to safe that it does not work without Xen? Or do you see stuff on the screen in baremetal mode? -- Configure bugmail:

"Hangcheck timer elapsed... GPU hung" in 3.8.0-rc2

On Thu, Jan 3, 2013 at 3:46 PM, J. Bruce Fields wrote: > I got a crash after a few minutes of running 3.8.0-rc2, was able to > switch to a vt and look at dmesg: > > [ 490.962545] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... > GPU hung > [ 490.963019] [drm] capturing error

[PATCH] drm/exynos: Add device tree based discovery support for Exynos G2D

Hi Olof, On Sun, Dec 30, 2012 at 11:57 AM, Olof Johansson wrote: > Hi, > > On Thu, Dec 27, 2012 at 8:00 PM, Ajay Kumar > wrote: >> This patch adds device tree match table for Exynos G2D controller. >> >> Signed-off-by: Ajay Kumar >> --- >> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 10

"Hangcheck timer elapsed... GPU hung" in 3.8.0-rc2

I got a crash after a few minutes of running 3.8.0-rc2, was able to switch to a vt and look at dmesg: [ 490.962545] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung [ 490.963019] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state

radeon CS parser refactoring

On Fri, 4 Jan 2013, Dave Airlie wrote: > Did you run these with pre-kms userspace etc to make sure it doesn't > cause regressions there? > No, I didn't, but I can give it a quick whirl. I think I still have one or two machines with 6.14.x DDX that I can put in UMS mode and see what happens.

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130103/10a066f2/attachment-0001.html>

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

it's tricky doing so blind when on intel graphics). Any other suggestions? Thanks. -- 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/attac

[PATCH 01/12] drm/radeon: remove unecessary assignment

For the series: Reviewed-by: Marek Ol??k Marek On Thu, Jan 3, 2013 at 12:27 AM, Ilija Hadzic wrote: > length_dw field was assigned twice. While at it, move user_ptr > assignment together with all other assignments to p->chunks[i] > structure to make the code more readable. > > Signed-off-by:

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

es. -- 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/20130103/51a6dab5/attachment.html>

[PATCH v2] drm/exynos: consider buffer allocation without iommu

This patch fixes the issue that when buffer allocation is requested without iommu, the allocation is failed. Without iommu, dma_alloc_attrs function allocates some memory region and returns cpu address so this patch makes the cpu address to be set to buf->kvaddr correctly. Changelog v2: - fix

[Bug 57842] r200: Culling is broken when rendering to an FBO

for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130103/84410183/attachment.html>

radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

> -Original Message- > From: Boszormenyi Zoltan [mailto:zboszor at pr.hu] > Sent: Thursday, January 03, 2013 6:37 AM > To: Alex Deucher > Cc: Markus Trippelsdorf; lkml; dri-devel at lists.freedesktop.org; Deucher, > Alexander; Borislav Petkov; Shuah Khan > Subject: Re: radeon :02:00.0:

[PATCH 1/2] [RFC] video: exynos mipi dsi: Making Exynos MIPI Complaint with CDF

Hi Sachin, Thanks for the comments. On Thu, Jan 3, 2013 at 11:14 AM, Sachin Kamat wrote: > Hi Vikas, > > Some nitpicks inline > > Subject: s/Complaint/Compliant > Oops, nice catch. > On 2 January 2013 18:47, Vikas C Sajjan wrote: >> From: Vikas Sajjan >> > > Please add some description

Resume regression with nouveau 3.8rc1 (bisected)

On Wed, Jan 02, 2013 at 04:19:35PM +0100, Pontus Fuchs wrote: > Hi, > > Starting with 3.8rc1 I get a black screen when resuming after suspend. > The kernel is alive because I can switch to VT1 and reboot with > ctrl-alt-delete. > > I bisected the problem down to this commit: > > 186ecad21:

[PATCHv4 0/8] Support for Tegra 2D hardware

On 01/03/2013 01:50 PM, Terje Bergstr?m wrote: > On 03.01.2013 05:31, Mark Zhang wrote: >> Sorry I didn't get it. Yes, in current design, you can pin all mem >> handles in one time but I haven't found anything related with "locking >> only once per submit". >> >> My idea is: >> - remove

[PATCH 5/5] drm/radeon: switch to a finer grained reset for SI

From: Alex Deucher No change in functionality as we currently set all the reset flags. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/si.c | 98 --- 1 files changed, 64 insertions(+), 34 deletions(-) diff --git

[PATCH 4/5] drm/radeon: switch to a finer grained reset for cayman/TN

From: Alex Deucher No change in functionality as we currently set all the reset flags. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/ni.c | 109 +++--- 1 files changed, 70 insertions(+), 39 deletions(-) diff --git

[PATCH 3/5] drm/radeon: switch to a finer grained reset for evergreen

From: Alex Deucher No change in functionality as we currently set all the reset flags. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/evergreen.c | 80 --- drivers/gpu/drm/radeon/evergreend.h |1 + 2 files changed, 56

[PATCH 2/5] drm/radeon: switch to a finer grained reset for r6xx/7xx

From: Alex Deucher No change in functionality as we currently set all the reset flags. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/r600.c | 85 - 1 files changed, 58 insertions(+), 27 deletions(-) diff --git

[PATCH 1/5] drm/radeon: add GPU reset flags

From: Alex Deucher The idea here is to move to a finer grained reset. In some cases we may not need reset every block, and in other cases we may not need to re-init the entire asic. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/radeon.h |5 + 1

[Bug 52231] possible circular locking dependency detected in radeon driver

https://bugzilla.kernel.org/show_bug.cgi?id=52231 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk

[Bug 52231] New: possible circular locking dependency detected in radeon driver

https://bugzilla.kernel.org/show_bug.cgi?id=52231 Summary: possible circular locking dependency detected in radeon driver Product: Drivers Version: 2.5 Kernel Version: 3.8-rc2 Platform: All OS/Version: Linux

[Bug 36522] Caught 16-bit read from uninitialized memory in drm_fb_helper_setcmap

https://bugzilla.kernel.org/show_bug.cgi?id=36522 --- Comment #11 from Christian Casteyde 2013-01-03 12:55:07 --- Udpate: Still present in 3.8-rc2 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are

[PATCH 7/8] drm/exynos: hdmi: add complete_scanout function

On Thu, Jan 3, 2013 at 7:58 AM, Prathyush K wrote: > > > > On Wed, Jan 2, 2013 at 10:12 PM, Sean Paul wrote: >> >> On Wed, Dec 26, 2012 at 6:27 AM, Prathyush K >> wrote: >> > The wait_for_vblank interface is modified to the complete_scanout >> > function in hdmi. This inturn calls the

[PATCH 8/8] drm/exynos: fimd: add complete_scanout function

On Thu, Jan 3, 2013 at 7:56 AM, Prathyush K wrote: > > > > On Wed, Jan 2, 2013 at 10:24 PM, Sean Paul wrote: >> >> On Wed, Dec 26, 2012 at 6:27 AM, Prathyush K >> wrote: >> > The wait_for_vblank interface is modified to the complete_scanout >> > function in fimd. This patch adds the

radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

2013-01-03 00:37 keltez?ssel, Alex Deucher ?rta: > On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf > wrote: >> On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote: >>> Please affected people can you test if patch : >>>

[PATCH 2/2] [RFC] video: display: Adding frame related ops to MIPI DSI video source struct

Hi Vikas, On Wednesday 02 of January 2013 18:47:22 Vikas C Sajjan wrote: > From: Vikas Sajjan > > Signed-off-by: Vikas Sajjan > --- > include/video/display.h |6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/include/video/display.h b/include/video/display.h > index

[PATCH 2/2] drm/radeon: reset dma engine on gpu reset (v2)

From: Jerome Glisse This try to reset the dma engine when performing gpu reset. Hopefully bringing back the gpu dma engine in sane state. v2: agd5f: fix dma reset on cayman/TN, add support for SI Signed-off-by: Jerome Glisse Signed-off-by: Alex Deucher ---

[PATCH 1/2] drm/radeon: print dma status reg on lockup (v2)

From: Jerome Glisse To help debug dma related lockup. v2: agd5f: update SI as well Signed-off-by: Jerome Glisse Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/evergreen.c |4 drivers/gpu/drm/radeon/evergreend.h |3 +++ drivers/gpu/drm/radeon/ni.c

[Bug 58272] Rv670 AGP drm-next ttm errors

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130103/c263157e/attachment.html>

[PATCHv4 0/8] Support for Tegra 2D hardware

On 01/02/2013 05:42 PM, Terje Bergstr?m wrote: > On 28.12.2012 11:14, Mark Zhang wrote: >> diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c >> index a936902..c3ded60 100644 >> --- a/drivers/gpu/drm/tegra/gr2d.c >> +++ b/drivers/gpu/drm/tegra/gr2d.c >> @@ -131,6 +131,14 @@

[PATCH 1/2] [RFC] video: exynos mipi dsi: Making Exynos MIPI Complaint with CDF

Hi Vikas, Some nitpicks inline Subject: s/Complaint/Compliant On 2 January 2013 18:47, Vikas C Sajjan wrote: > From: Vikas Sajjan > Please add some description about this patch here. > Signed-off-by: Vikas Sajjan > --- > drivers/video/exynos/exynos_mipi_dsi.c| 46 >

[PATCHv4 0/8] Support for Tegra 2D hardware

On 01/02/2013 05:25 PM, Terje Bergstr?m wrote: > On 26.12.2012 11:42, Mark Zhang wrote: [...] > >> >> if (!de) >> diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c >> index 07e8813..01ed10d 100644 >> --- a/drivers/gpu/host1x/dev.c >> +++ b/drivers/gpu/host1x/dev.c >> @@

[Bug 58914] Cannot start Radeon driver: "drmOpenByBusid: drmGetBusid reports " no bus ID

re 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/20130103/cd65444f/attachment.html>

[PATCH 3/4] drm/exynos: mixer: set correct mode for range of resolutions

On Wed, Jan 2, 2013 at 10:46 PM, Sean Paul wrote: > On Thu, Dec 27, 2012 at 6:38 AM, Rahul Sharma > wrote: >> With this patch, mixer driver find the correct resolution mode for >> the range of resolutions, upto 1080 vertical lines. Resolution will >> be categorized to NTSC SD, PAL SD or HD and

[PATCH 2/4] drm/exynos: implement display-mode-check callback in mixer driver

On Wed, Jan 2, 2013 at 10:37 PM, Rahul Sharma wrote: > On Wed, Jan 2, 2013 at 10:45 PM, Sean Paul wrote: >> On Thu, Dec 27, 2012 at 6:38 AM, Rahul Sharma >> wrote: >>> This patch adds the implementation of check_mode callback in the mixer >>> driver. Based on the mixer version, correct set of

radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

On 2013.01.02 at 18:37 -0500, Alex Deucher wrote: > On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf > wrote: > > On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote: > >> Please affected people can you test if patch : > >>

[PATCH 2/4] drm/exynos: implement display-mode-check callback in mixer driver

On Wed, Jan 2, 2013 at 10:45 PM, Sean Paul wrote: > On Thu, Dec 27, 2012 at 6:38 AM, Rahul Sharma > wrote: >> This patch adds the implementation of check_mode callback in the mixer >> driver. Based on the mixer version, correct set of restrictions will be >> exposed by the mixer driver. A

[PATCH 4/8] drm/exynos: fimd: clear channel before enabling iommu

- > > + } > > return 0; > > } > > > > -- > > 1.8.0 > > > > ___ > > dri-devel mailing list > > dri-devel at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130103/56505ab7/attachment-0001.html>

[PATCH 1/4] drm/exynos: add display-mode-check operation to exynos_mixer_ops struct

On Wed, Jan 2, 2013 at 10:37 PM, Sean Paul wrote: > On Thu, Dec 27, 2012 at 6:38 AM, Rahul Sharma > wrote: >> This patch adds the display mode check operation to exynos_mixer_ops >> in drm-common-hdmi. In Exynos SoCs, mixer IP can put certain restrictions >> on the proposed display modes. These

radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

On Thu, Jan 3, 2013 at 7:12 AM, Deucher, Alexander wrote: >> -Original Message- >> From: Boszormenyi Zoltan [mailto:zboszor at pr.hu] >> Sent: Thursday, January 03, 2013 6:37 AM >> To: Alex Deucher >> Cc: Markus Trippelsdorf; lkml; dri-devel at lists.freedesktop.org; Deucher, >>

[PATCHv4 0/8] Support for Tegra 2D hardware

On 21.12.2012 15:50, Lucas Stach wrote: > Am Freitag, den 21.12.2012, 13:39 +0200 schrieb Terje Bergstrom: >> Some of the issues left open: >> * Register definitions still use static inline. There has been a >>debate about code style versus ability to use compiler type >>checking and code

[PATCHv4 0/8] Support for Tegra 2D hardware

On 03.01.2013 05:31, Mark Zhang wrote: > Sorry I didn't get it. Yes, in current design, you can pin all mem > handles in one time but I haven't found anything related with "locking > only once per submit". > > My idea is: > - remove "job->addr_phys" > - assign "job->reloc_addr_phys" &

[PATCH] drm/exynos: move finish page flip to a common place

This patch implements the exynos_drm_crtc_finish_pageflip in exynos_drm_crtc.c. This avoids the duplication of same code in mixer, fimd and vidi. Signed-off-by: Rahul Sharma Signed-off-by: Stephane Marchesin --- This patch is based on branch "exynos-drm-next" at

[Bug 57842] r200: Culling is broken when rendering to an FBO

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130103/51b63689/attachment.html>

[PATCH] drm/exynos: move finish page flip to a common place

This patch implements the exynos_drm_crtc_finish_pageflip in exynos_drm_crtc.c. This avoids the duplication of same code in mixer, fimd and vidi. Signed-off-by: Rahul Sharma --- This patch is based on branch "exynos-drm-next" at http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git

[Bug 58914] Cannot start Radeon driver: "drmOpenByBusid: drmGetBusid reports " no bus ID

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130103/c3df8ff9/attachment.html>

radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

On 01/03/2013 01:59 AM, Alex Deucher wrote: > On Wed, Jan 2, 2013 at 6:58 PM, Shuah Khan wrote: >> On Wed, Jan 2, 2013 at 4:37 PM, Alex Deucher >> wrote: >>> On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf >>> wrote: On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote: > Please

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

Is the BusID line in the intel device section not needed? What is needed for X to automatically detect multiple GPUs properly and show some video output from the correct card? -- 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/20130103/ec9282af/attachment.html>

[Bug 58959] kernel 3.6.4 and r600_dri.so from mesa 8.0.5 are incompatible

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130103/033addc2/attachment.html>

[PATCH v3] drm/exynos: let drm handle edid allocations

There's no need to allocate edid twice and do a memcpy when drm helpers exist to do just that. This patch cleans that interaction up, and doesn't keep the edid hanging around in the connector. v3: - removed MAX_EDID as it is not used anymore. v2: - changed vidi_get_edid callback inside vidi

[PATCH 0/2] Making Exynos MIPI Complaint with Common Display Framework

From: Vikas Sajjan vikas.saj...@linaro.org This patchset contains 2 RFCs, 1st RFC has modiifications in exynos MIPI DSI driver. 2nd RFC has additions done to video source struct as per exynos requirements. I have NOT tested the patch yet, as i am yet recieve the MIPI DSI panel. This based on

[PATCH 1/2] [RFC] video: exynos mipi dsi: Making Exynos MIPI Complaint with CDF

From: Vikas Sajjan vikas.saj...@linaro.org Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org --- drivers/video/exynos/exynos_mipi_dsi.c| 46 ++--- drivers/video/exynos/exynos_mipi_dsi_common.c | 22 drivers/video/exynos/exynos_mipi_dsi_common.h |

[PATCH 2/2] [RFC] video: display: Adding frame related ops to MIPI DSI video source struct

From: Vikas Sajjan vikas.saj...@linaro.org Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org --- include/video/display.h |6 ++ 1 file changed, 6 insertions(+) diff --git a/include/video/display.h b/include/video/display.h index b639fd0..fb2f437 100644 --- a/include/video/display.h

Resume regression with nouveau 3.8rc1 (bisected)

Hi, Starting with 3.8rc1 I get a black screen when resuming after suspend. The kernel is alive because I can switch to VT1 and reboot with ctrl-alt-delete. I bisected the problem down to this commit: 186ecad21: drm/nv50/disp: move remaining interrupt handling into core Hardware is 8400M GS

Re: [PATCH 1/4] drm/exynos: add display-mode-check operation to exynos_mixer_ops struct

On Thu, Dec 27, 2012 at 6:38 AM, Rahul Sharma rahul.sha...@samsung.com wrote: This patch adds the display mode check operation to exynos_mixer_ops in drm-common-hdmi. In Exynos SoCs, mixer IP can put certain restrictions on the proposed display modes. These restriction needs to be considered

Re: [PATCH 2/4] drm/exynos: implement display-mode-check callback in mixer driver

On Thu, Dec 27, 2012 at 6:38 AM, Rahul Sharma rahul.sha...@samsung.com wrote: This patch adds the implementation of check_mode callback in the mixer driver. Based on the mixer version, correct set of restrictions will be exposed by the mixer driver. A resolution will be acceptable only if

Re: [PATCH 3/4] drm/exynos: mixer: set correct mode for range of resolutions

On Thu, Dec 27, 2012 at 6:38 AM, Rahul Sharma rahul.sha...@samsung.com wrote: With this patch, mixer driver find the correct resolution mode for the range of resolutions, upto 1080 vertical lines. Resolution will be categorized to NTSC SD, PAL SD or HD and the correct mode is set to the mixer

Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

On Wed, Jan 2, 2013 at 4:37 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote: Please affected people can you test if patch :

Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

On Wed, Jan 2, 2013 at 4:59 PM, Alex Deucher alexdeuc...@gmail.com wrote: Catching up with this thread. I reverted the drm/radeon: use async dma for ttm buffer moves on 6xx-SI commit id: 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2 Do I need to apply this patch without reverting

Re: [PATCH 1/2] [RFC] video: exynos mipi dsi: Making Exynos MIPI Complaint with CDF

Hi Vikas, Some nitpicks inline Subject: s/Complaint/Compliant On 2 January 2013 18:47, Vikas C Sajjan vikas.saj...@linaro.org wrote: From: Vikas Sajjan vikas.saj...@linaro.org Please add some description about this patch here. Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org ---

Re: [PATCH 1/2] [RFC] video: exynos mipi dsi: Making Exynos MIPI Complaint with CDF

Hi Sachin, Thanks for the comments. On Thu, Jan 3, 2013 at 11:14 AM, Sachin Kamat sachin.ka...@linaro.org wrote: Hi Vikas, Some nitpicks inline Subject: s/Complaint/Compliant Oops, nice catch. On 2 January 2013 18:47, Vikas C Sajjan vikas.saj...@linaro.org wrote: From: Vikas Sajjan

Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

On 2013.01.02 at 18:37 -0500, Alex Deucher wrote: On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote: Please affected people can you test if patch :

[Bug 58914] Cannot start Radeon driver: drmOpenByBusid: drmGetBusid reports no bus ID

https://bugs.freedesktop.org/show_bug.cgi?id=58914 --- Comment #5 from Michel Dänzer mic...@daenzer.net --- (In reply to comment #4) But if you can suggest a version to test I can start. I haven't seen any other similar reports, so if it happens with 3.7 kernels, it's probably not a (recent)

Re: [PATCH 2/2] [RFC] video: display: Adding frame related ops to MIPI DSI video source struct

Hi Vikas, On Wednesday 02 of January 2013 18:47:22 Vikas C Sajjan wrote: From: Vikas Sajjan vikas.saj...@linaro.org Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org --- include/video/display.h |6 ++ 1 file changed, 6 insertions(+) diff --git a/include/video/display.h

[Bug 58272] Rv670 AGP drm-next ttm errors

https://bugs.freedesktop.org/show_bug.cgi?id=58272 --- Comment #14 from Andy Furniss li...@andyfurniss.entadsl.com --- (In reply to comment #13) (In reply to comment #12) Make sure your kernel has this patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;

Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

2013-01-03 00:37 keltezéssel, Alex Deucher írta: On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote: Please affected people can you test if patch :

Re: [PATCH 8/8] drm/exynos: fimd: add complete_scanout function

On Wed, Jan 2, 2013 at 10:24 PM, Sean Paul seanp...@chromium.org wrote: On Wed, Dec 26, 2012 at 6:27 AM, Prathyush K prathyus...@samsung.com wrote: The wait_for_vblank interface is modified to the complete_scanout function in fimd. This patch adds the fimd_complete_scanout function

Re: [PATCH 7/8] drm/exynos: hdmi: add complete_scanout function

On Wed, Jan 2, 2013 at 10:12 PM, Sean Paul seanp...@chromium.org wrote: On Wed, Dec 26, 2012 at 6:27 AM, Prathyush K prathyus...@samsung.com wrote: The wait_for_vblank interface is modified to the complete_scanout function in hdmi. This inturn calls the complete_scanout mixer op. This

Re: Resume regression with nouveau 3.8rc1 (bisected)

On Wed, Jan 02, 2013 at 04:19:35PM +0100, Pontus Fuchs wrote: Hi, Starting with 3.8rc1 I get a black screen when resuming after suspend. The kernel is alive because I can switch to VT1 and reboot with ctrl-alt-delete. I bisected the problem down to this commit: 186ecad21:

[Bug 52231] New: possible circular locking dependency detected in radeon driver

https://bugzilla.kernel.org/show_bug.cgi?id=52231 Summary: possible circular locking dependency detected in radeon driver Product: Drivers Version: 2.5 Kernel Version: 3.8-rc2 Platform: All OS/Version: Linux

[Bug 52231] possible circular locking dependency detected in radeon driver

https://bugzilla.kernel.org/show_bug.cgi?id=52231 Alan a...@lxorguk.ukuu.org.uk changed: What|Removed |Added CC||a...@lxorguk.ukuu.org.uk

Re: [PATCH 01/12] drm/radeon: remove unecessary assignment

For the series: Reviewed-by: Marek Olšák mar...@gmail.com Marek On Thu, Jan 3, 2013 at 12:27 AM, Ilija Hadzic ihad...@research.bell-labs.com wrote: length_dw field was assigned twice. While at it, move user_ptr assignment together with all other assignments to p-chunks[i] structure to make

[Bug 57842] r200: Culling is broken when rendering to an FBO

https://bugs.freedesktop.org/show_bug.cgi?id=57842 --- Comment #16 from Stefan Dösinger stefandoesin...@gmx.at --- Commit it to Git and use git send-email to send it to mesa-...@lists.freedesktop.org . Google finds many tutorials on how to do this. -- You are receiving this mail because: You

RE: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

-Original Message- From: Boszormenyi Zoltan [mailto:zbos...@pr.hu] Sent: Thursday, January 03, 2013 6:37 AM To: Alex Deucher Cc: Markus Trippelsdorf; lkml; dri-devel@lists.freedesktop.org; Deucher, Alexander; Borislav Petkov; Shuah Khan Subject: Re: radeon :02:00.0: GPU lockup

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #50 from Alex Deucher ag...@yahoo.com --- (In reply to comment #49) Is the BusID line in the intel device section not needed? What is needed for X to automatically detect multiple GPUs properly and show some video output from the

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #51 from Anonymous Helper anonym...@dodgeit.com --- (In reply to comment #50) You'll need to use vga-switcheroo to select the card you want to use. Then you should be able to start X without any config and it will start on the

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #52 from Alex Deucher ag...@yahoo.com --- (In reply to comment #51) Any other suggestions? Thanks. You might ask on the dri-devel mailing list. This is getting off topic for this bug. -- You are receiving this mail because: You

[PATCH 1/2] drm/radeon: print dma status reg on lockup (v2)

From: Jerome Glisse jgli...@redhat.com To help debug dma related lockup. v2: agd5f: update SI as well Signed-off-by: Jerome Glisse jgli...@redhat.com Signed-off-by: Alex Deucher alexander.deuc...@amd.com --- drivers/gpu/drm/radeon/evergreen.c |4 drivers/gpu/drm/radeon/evergreend.h |

[PATCH 2/2] drm/radeon: reset dma engine on gpu reset (v2)

From: Jerome Glisse jgli...@redhat.com This try to reset the dma engine when performing gpu reset. Hopefully bringing back the gpu dma engine in sane state. v2: agd5f: fix dma reset on cayman/TN, add support for SI Signed-off-by: Jerome Glisse jgli...@redhat.com Signed-off-by: Alex Deucher

Re: [PATCH 8/8] drm/exynos: fimd: add complete_scanout function

On Thu, Jan 3, 2013 at 7:56 AM, Prathyush K prathy...@chromium.org wrote: On Wed, Jan 2, 2013 at 10:24 PM, Sean Paul seanp...@chromium.org wrote: On Wed, Dec 26, 2012 at 6:27 AM, Prathyush K prathyus...@samsung.com wrote: The wait_for_vblank interface is modified to the complete_scanout

Re: [PATCH 7/8] drm/exynos: hdmi: add complete_scanout function

On Thu, Jan 3, 2013 at 7:58 AM, Prathyush K prathy...@chromium.org wrote: On Wed, Jan 2, 2013 at 10:12 PM, Sean Paul seanp...@chromium.org wrote: On Wed, Dec 26, 2012 at 6:27 AM, Prathyush K prathyus...@samsung.com wrote: The wait_for_vblank interface is modified to the complete_scanout

Re: [PATCHv4 5/8] drm: tegra: Remove redundant host1x

On 21.12.2012 16:36, Thierry Reding wrote: On Fri, Dec 21, 2012 at 01:39:21PM +0200, Terje Bergstrom wrote: +static void tegra_drm_close(struct drm_device *drm, struct drm_file *filp) +{ + +} + This can be removed, right? Yes, done. +static struct platform_driver

[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board

https://bugzilla.kernel.org/show_bug.cgi?id=52121 --- Comment #13 from Konrad Rzeszutek Wilk konrad.w...@oracle.com 2013-01-03 18:04:34 --- So is it safe to safe that it does not work without Xen? Or do you see stuff on the screen in baremetal mode? -- Configure bugmail:

[PATCH 1/5] drm/radeon: add GPU reset flags

From: Alex Deucher alexander.deuc...@amd.com The idea here is to move to a finer grained reset. In some cases we may not need reset every block, and in other cases we may not need to re-init the entire asic. Signed-off-by: Alex Deucher alexander.deuc...@amd.com ---

[PATCH 2/5] drm/radeon: switch to a finer grained reset for r6xx/7xx

From: Alex Deucher alexander.deuc...@amd.com No change in functionality as we currently set all the reset flags. Signed-off-by: Alex Deucher alexander.deuc...@amd.com --- drivers/gpu/drm/radeon/r600.c | 85 - 1 files changed, 58 insertions(+), 27

[PATCH 3/5] drm/radeon: switch to a finer grained reset for evergreen

From: Alex Deucher alexander.deuc...@amd.com No change in functionality as we currently set all the reset flags. Signed-off-by: Alex Deucher alexander.deuc...@amd.com --- drivers/gpu/drm/radeon/evergreen.c | 80 --- drivers/gpu/drm/radeon/evergreend.h |1 +

  1   2   >