[PATCH] drm: fix new kernel-doc warnings

On 03/05/2013 11:08:16 AM, Randy Dunlap wrote: > From: Randy Dunlap > > Fix new kernel-doc warnings in drm_edid.c: convert doxygen(?) to > kernel-doc to match the rest of the file's documentation. I've been feeding this stuff through trivial at kernel.org. (I just got my kernel.org account

[PATCH] drm/tegra: drop "select DRM_HDMI"

Commit ac24c2204a76e5b42aa103bf963ae0eda1b827f3 ("drm/tegra: Use generic HDMI infoframe helpers") added "select DRM_HDMI" to the DRM_TEGRA Kconfig entry. But there is no Kconfig symbol named DRM_HDMI. The select statement for that symbol is a nop. Drop it. What was needed to use HDMI

[Bug 26345] [845G] CPU/GPU incoherency

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/20130305/7701a6b9/attachment.html>

[PATCH] drm/exynos: fimd: calculate the correct address offset

On 03/05/2013 09:04 PM, Leela Krishna Amudala wrote: > Hi, > > On Tue, Mar 5, 2013 at 5:24 PM, Joonyoung Shim > wrote: >> Hi Leela, >> >> >> On 03/05/2013 08:25 PM, Leela Krishna Amudala wrote: >>> Calculate the correct address offset values for alpha and color key >>> control registers >>> >>>

[Bug 61690] Graphic issue on PCSX2 with Gallium 0.4 on AMD RS780

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130305/1fbb94ab/attachment.html>

[PATCH] drm/exynos: fimd: calculate the correct address offset

Hi Leela, On 03/05/2013 08:25 PM, Leela Krishna Amudala wrote: > Calculate the correct address offset values for alpha and color key > control registers > > Signed-off-by: Leela Krishna Amudala > --- > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 9 + > 1 file changed, 5 insertions(+),

[Intel-gfx] [git pull] drm merge for 3.9-rc1

On Thu, 2013-02-28 at 11:31 -0300, Paulo Zanoni wrote: > Hi > > 2013/2/28 Chris Wilson : > > On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote: > >> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek > >> wrote: > >> > Hi, > >> > > >> > I am seeing this also on Linux-Next. > >> > > >> >

[git pull] drm merge for 3.9-rc1

On Tue, Feb 26, 2013 at 05:39:46PM -0800, Linus Torvalds wrote: > On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie wrote: > > > > Highlights: > > > > i915: all over the map, haswell power well enhancements, valleyview macro > > horrors cleaned up, killing lots of legacy GTT > > code, > > Lowlight:

[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 #21 from Konrad Rzeszutek Wilk 2013-03-05 20:16:12 --- Well not forever. Daniel (lets see if I can add him on this bug) is looking at getting the EFI parts working. The VGA part is on the list but we haven't yet touched it. --

[PATCH 4/4] omapdss: features: fixed supported outputs for OMAP4

The support outputs struct for overlay managers is incorrect for OMAP4. Make these changes: - DPI isn't supported via the LCD1 overlay manager, remove DPI as a supported output. - the TV manager can suppport DPI, but the omapdss driver doesn't support that yet, we require some muxing at the

[PATCH 3/4] drm/omap: Make fixed resolution panels work

The omapdrm driver requires omapdss panel drivers to expose ops like detect, set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI and SDI drivers. At some places, there are no checks to see if the panel driver has these ops or not, and that leads to a crash. The

[PATCH 2/4] drm/omap: Fix and improve crtc and overlay manager correlation

The omapdrm driver currently takes a config/module arg to figure out the number of crtcs it needs to create. We could create as many crtcs as there are overlay managers in the DSS hardware, but we don't do that because each crtc eats up one DSS overlay, and that reduces the number of planes we can

[PATCH 1/4] drm/omap: Don't return from modeset_init if a panel doesn't satisfy omapdrm requirements

modeset_init iterates through all the registered omapdss devices and has some initial checks to see if the panel has a driver and the required driver ops for it to be usable by omapdrm. The function bails out from modeset_init if a panel doesn't meet the requirements, and stops the registration

[PATCH 0/4] drm/omap: Misc fixes and improvements

These are misc fixes and improvements within omapdrm. There is one minor omapdss fix here too, we get problems in omapdrm without it. The fixes do the following: - Make omapdrm smarter to choose the right overlay managers as it's crtcs. This makes sure that omapdrm is functional for OMAP

[PATCH 3/4] drm/omap: Make fixed resolution panels work

On Tue, Mar 5, 2013 at 9:17 AM, Archit Taneja wrote: > The omapdrm driver requires omapdss panel drivers to expose ops like detect, > set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI > and SDI drivers. At some places, there are no checks to see if the panel > driver

[PATCH 1/4] drm/omap: Don't return from modeset_init if a panel doesn't satisfy omapdrm requirements

On Tue, Mar 5, 2013 at 9:17 AM, Archit Taneja wrote: > modeset_init iterates through all the registered omapdss devices and has some > initial checks to see if the panel has a driver and the required driver ops > for > it to be usable by omapdrm. > > The function bails out from modeset_init if a

[Bug 60802] Corruption with DMA ring on cayman

s 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/20130305/6e9362e7/attachment.html>

Radeon HDMI question

Hi, 2013-01-18 13:04 keltez?ssel, Christian K?nig ?rta: > Am 17.01.2013 20:35, schrieb Boszormenyi Zoltan: >> Hi, >> >> I experience a strange problem, I don't know whether >> it's a feature or a bug, and if it's a bug, where. >> >> I have a Radeon HD6570. A monitor via DVI and an LCD TV >> via

[PATCH] drm/nouveau: fix regression in vblanking

On Tue, Mar 05, 2013 at 02:59:26PM +0100, Maarten Lankhorst wrote: > nv50_vblank_enable/disable got switched from > NV50_PDISPLAY_INTR_EN_1_VBLANK_CRTC_0 (4) << head to 1 << head, which is > wrong. > > 4 << head is the correct value. > > Fixes regression with vblanking since 1d7c71a3e2f77

v3.9-rc1 instability on Chromebook Pixel with gmbus irq

Hi Daniel Vetter, I'm working on touch devices Chromium OS, and I've noticed a regression between 3.8 and 3.9-rc1, which was posted yesterday. The hardware in question is a Chromebook Pixel. For this device, we have i2c input devices: atmel mxt224s touchpad and atmel mxt1664s touchscreen. The

[PATCH] drm/exynos: fimd: calculate the correct address offset

Hi, On Tue, Mar 5, 2013 at 5:24 PM, Joonyoung Shim wrote: > Hi Leela, > > > On 03/05/2013 08:25 PM, Leela Krishna Amudala wrote: >> >> Calculate the correct address offset values for alpha and color key >> control registers >> >> Signed-off-by: Leela Krishna Amudala >> --- >>

nouveau lockdep splat

Dropping Tegra ML, it's not the place where Nouveau mails should go. Adding Nouveau ML and Maarten, who probably knows Lockdep+Nouveau best. Am Montag, den 04.03.2013, 22:16 +0100 schrieb Borislav Petkov: > New -rc1, so let the stabilization games begin. > > I see the following on rc1, let me

ThinkPad T420 + kernel 3.8.x + external VGA display == wrong resolution

On 03/05/2013 11:41 AM, Daniel Vetter wrote: > against DRI -> DRM(Intel) and attach the files there together with > your quick description of the regression above. > > Thanks, Daniel np : https://bugs.freedesktop.org/show_bug.cgi?id=61861 -- MfG/Sincerely Toralf F?rster pgp finger print: 7B1A

[Bug 60802] Corruption with DMA ring on cayman

part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130305/90695a7a/attachment.html>

[PATCH] drm/nouveau: fix regression in vblanking

nv50_vblank_enable/disable got switched from NV50_PDISPLAY_INTR_EN_1_VBLANK_CRTC_0 (4) << head to 1 << head, which is wrong. 4 << head is the correct value. Fixes regression with vblanking since 1d7c71a3e2f77 "drm/nouveau/disp: port vblank handling to event interface" Signed-off-by: Maarten

[Bug 52491] radeon massive screen corruption BARTS HD6870

https://bugzilla.kernel.org/show_bug.cgi?id=52491 Bruno Jacquet changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

nouveau bug in 3.7.9 -- unable to handle kernel paging request

While using chrome, I got the following. It was able to render the bug to the screen, so at least something was working (and it also made it to my logs). [223614.867297] BUG: unable to handle kernel paging request at c90013a0 [223614.867372] IP: [] iowrite32+0x12/0x33 [223614.867427] PGD

[PATCH] drm/nouveau: fix null pointer deref on init

My nv96 claims to have a DCB_OUTPUT_TV, which is currently not implemented for nv50, this triggers the following oops: [ 30.110017] nouveau W[ DRM] failed to create encoder 0/1/0: -19 [ 30.110020] nouveau W[ DRM] TV-1 has no encoders, removing [ 30.134089] BUG: unable to handle

nouveau shuts the machine down with v3.9-rc1 (temperature (72 C) hit the 'shutdown' threshold).

scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130305/36572fa6/attachment.html> -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-nv40-therm-improve-selection-between-the-old-and.patch Type: text/x-patch Size: 3038 bytes D

ThinkPad T420 + kernel 3.8.x + external VGA display == wrong resolution

On Mon, Mar 4, 2013 at 10:47 PM, Toralf F?rster wrote: > It is a (small) regression to 3.7.10 with intel integrated graphics i915 > - but nevertheless : > > With an external VGA display (1680x1050) and a closed internal LVDS1 > display (1440x900) the external display starts X11 with 1440x900 -

[git pull] drm merge for 3.9-rc1

On Tue, Mar 5, 2013 at 10:21 AM, Josh Boyer wrote: > On Thu, Feb 28, 2013 at 1:59 PM, Josh Boyer wrote: >> On Thu, Feb 28, 2013 at 10:15 AM, Josh Boyer wrote: >>> On Thu, Feb 28, 2013 at 10:09 AM, Alex Deucher >>> wrote: On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer wrote: > On Thu,

nouveau shuts the machine down with v3.9-rc1 (temperature (72 C) hit the 'shutdown' threshold).

On Tue, Mar 05, 2013 at 12:13:57PM +0100, Martin Peres wrote: > On 04/03/2013 22:41, Konrad Rzeszutek Wilk wrote: > >Pls CC me in case you would like me also to test them with the > >mdelay patch. > > Hi Konrad, > > Marcin proposed me another explanation for the issue you are seeing > and it

[PATCH v17 2/7] video: add display_timing and videomode

Hi! On Wed, Feb 27, 2013 at 06:13:49PM +0200, Tomi Valkeinen wrote: > On 2013-02-27 18:05, Steffen Trumtrar wrote: > > Ah, sorry. Forgot to answer this. > > > > On Wed, Feb 27, 2013 at 05:45:31PM +0200, Tomi Valkeinen wrote: > >> Ping. > >> > >> On 2013-02-18 16:09, Tomi Valkeinen wrote: > >>>

linux-next: manual merge of the drm-intel tree with Linus' tree

5; else intel_sdvo->color_range = 0; } -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130305/230b0145/attachment-0001.pgp>

[git pull] drm merge for 3.9-rc1

On Thu, Feb 28, 2013 at 1:59 PM, Josh Boyer wrote: > On Thu, Feb 28, 2013 at 10:15 AM, Josh Boyer wrote: >> On Thu, Feb 28, 2013 at 10:09 AM, Alex Deucher >> wrote: >>> On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer wrote: On Thu, Feb 28, 2013 at 8:38 AM, Alex Deucher wrote:

[PATCH] drm: fix new kernel-doc warnings

From: Randy Dunlap Fix new kernel-doc warnings in drm_edid.c: convert doxygen(?) to kernel-doc to match the rest of the file's documentation. Warning(drivers/gpu/drm/drm_edid.c:997): No description found for parameter 'adapter' Warning(drivers/gpu/drm/drm_edid.c:997): No

[PATCH] drm/exynos: fimd: calculate the correct address offset

Calculate the correct address offset values for alpha and color key control registers Signed-off-by: Leela Krishna Amudala --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c

[Intel-gfx] [PATCH 0/8] Enable eDP PSR functionality at HSW - v3

On Thu, Feb 28, 2013 at 08:02:18PM +0200, Ville Syrj?l? wrote: > On Thu, Feb 28, 2013 at 02:52:32PM -0300, Paulo Zanoni wrote: > > Hi > > > > 2013/2/25 Rodrigo Vivi : > > > PSR is an eDP feature that allows power saving even with static image at > > > eDP screen. > > > > > > v3: Accepted many

Re: [PATCH v17 2/7] video: add display_timing and videomode

Hi! On Wed, Feb 27, 2013 at 06:13:49PM +0200, Tomi Valkeinen wrote: On 2013-02-27 18:05, Steffen Trumtrar wrote: Ah, sorry. Forgot to answer this. On Wed, Feb 27, 2013 at 05:45:31PM +0200, Tomi Valkeinen wrote: Ping. On 2013-02-18 16:09, Tomi Valkeinen wrote: Hi Steffen, On

Re: ThinkPad T420 + kernel 3.8.x + external VGA display == wrong resolution

On Mon, Mar 4, 2013 at 10:47 PM, Toralf Förster toralf.foers...@gmx.de wrote: It is a (small) regression to 3.7.10 with intel integrated graphics i915 - but nevertheless : With an external VGA display (1680x1050) and a closed internal LVDS1 display (1440x900) the external display starts X11

[PATCH] drm/exynos: fimd: calculate the correct address offset

Calculate the correct address offset values for alpha and color key control registers Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git

Re: nouveau shuts the machine down with v3.9-rc1 (temperature (72 C) hit the 'shutdown' threshold).

On 04/03/2013 22:41, Konrad Rzeszutek Wilk wrote: Pls CC me in case you would like me also to test them with the mdelay patch. Hi Konrad, Marcin proposed me another explanation for the issue you are seeing and it made me look again at the code. I don't have enough nv4x hw to test all the

Re: [PATCH] drm/exynos: fimd: calculate the correct address offset

Hi Leela, On 03/05/2013 08:25 PM, Leela Krishna Amudala wrote: Calculate the correct address offset values for alpha and color key control registers Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 9 + 1 file changed, 5

[PATCH] drm/nouveau: fix null pointer deref on init

My nv96 claims to have a DCB_OUTPUT_TV, which is currently not implemented for nv50, this triggers the following oops: [ 30.110017] nouveau W[ DRM] failed to create encoder 0/1/0: -19 [ 30.110020] nouveau W[ DRM] TV-1 has no encoders, removing [ 30.134089] BUG: unable to handle

Re: [PATCH] drm/exynos: fimd: calculate the correct address offset

Hi, On Tue, Mar 5, 2013 at 5:24 PM, Joonyoung Shim jy0922.s...@samsung.com wrote: Hi Leela, On 03/05/2013 08:25 PM, Leela Krishna Amudala wrote: Calculate the correct address offset values for alpha and color key control registers Signed-off-by: Leela Krishna Amudala

Re: [PATCH] drm/exynos: fimd: calculate the correct address offset

On 03/05/2013 09:04 PM, Leela Krishna Amudala wrote: Hi, On Tue, Mar 5, 2013 at 5:24 PM, Joonyoung Shim jy0922.s...@samsung.com wrote: Hi Leela, On 03/05/2013 08:25 PM, Leela Krishna Amudala wrote: Calculate the correct address offset values for alpha and color key control registers

[PATCH] drm/nouveau: fix regression in vblanking

nv50_vblank_enable/disable got switched from NV50_PDISPLAY_INTR_EN_1_VBLANK_CRTC_0 (4) head to 1 head, which is wrong. 4 head is the correct value. Fixes regression with vblanking since 1d7c71a3e2f77 drm/nouveau/disp: port vblank handling to event interface Signed-off-by: Maarten Lankhorst

[PATCH 0/4] drm/omap: Misc fixes and improvements

These are misc fixes and improvements within omapdrm. There is one minor omapdss fix here too, we get problems in omapdrm without it. The fixes do the following: - Make omapdrm smarter to choose the right overlay managers as it's crtcs. This makes sure that omapdrm is functional for OMAP

[PATCH 1/4] drm/omap: Don't return from modeset_init if a panel doesn't satisfy omapdrm requirements

modeset_init iterates through all the registered omapdss devices and has some initial checks to see if the panel has a driver and the required driver ops for it to be usable by omapdrm. The function bails out from modeset_init if a panel doesn't meet the requirements, and stops the registration

[PATCH 3/4] drm/omap: Make fixed resolution panels work

The omapdrm driver requires omapdss panel drivers to expose ops like detect, set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI and SDI drivers. At some places, there are no checks to see if the panel driver has these ops or not, and that leads to a crash. The

[PATCH 4/4] omapdss: features: fixed supported outputs for OMAP4

The support outputs struct for overlay managers is incorrect for OMAP4. Make these changes: - DPI isn't supported via the LCD1 overlay manager, remove DPI as a supported output. - the TV manager can suppport DPI, but the omapdss driver doesn't support that yet, we require some muxing at the

[PATCH 2/4] drm/omap: Fix and improve crtc and overlay manager correlation

The omapdrm driver currently takes a config/module arg to figure out the number of crtcs it needs to create. We could create as many crtcs as there are overlay managers in the DSS hardware, but we don't do that because each crtc eats up one DSS overlay, and that reduces the number of planes we can

[Bug 52491] radeon massive screen corruption BARTS HD6870

https://bugzilla.kernel.org/show_bug.cgi?id=52491 Bruno Jacquet maxi...@free.fr changed: What|Removed |Added Status|NEW |RESOLVED

Re: ThinkPad T420 + kernel 3.8.x + external VGA display == wrong resolution

On 03/05/2013 11:41 AM, Daniel Vetter wrote: against DRI - DRM(Intel) and attach the files there together with your quick description of the regression above. Thanks, Daniel np : https://bugs.freedesktop.org/show_bug.cgi?id=61861 -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4

Re: [git pull] drm merge for 3.9-rc1

On Tue, Mar 5, 2013 at 10:21 AM, Josh Boyer jwbo...@gmail.com wrote: On Thu, Feb 28, 2013 at 1:59 PM, Josh Boyer jwbo...@gmail.com wrote: On Thu, Feb 28, 2013 at 10:15 AM, Josh Boyer jwbo...@gmail.com wrote: On Thu, Feb 28, 2013 at 10:09 AM, Alex Deucher alexdeuc...@gmail.com wrote: On Thu,

[Bug 60802] Corruption with DMA ring on cayman

https://bugs.freedesktop.org/show_bug.cgi?id=60802 --- Comment #41 from Jakob Nixdorf flo...@shadowice.org --- Just as information: I just built 3.9-rc1 and the corruption is still present and looking exactly the same. -- You are receiving this mail because: You are the assignee for the bug.

Re: nouveau lockdep splat

Dropping Tegra ML, it's not the place where Nouveau mails should go. Adding Nouveau ML and Maarten, who probably knows Lockdep+Nouveau best. Am Montag, den 04.03.2013, 22:16 +0100 schrieb Borislav Petkov: New -rc1, so let the stabilization games begin. I see the following on rc1, let me know

Re: [PATCH] drm/nouveau: fix regression in vblanking

On Tue, Mar 05, 2013 at 02:59:26PM +0100, Maarten Lankhorst wrote: nv50_vblank_enable/disable got switched from NV50_PDISPLAY_INTR_EN_1_VBLANK_CRTC_0 (4) head to 1 head, which is wrong. 4 head is the correct value. Fixes regression with vblanking since 1d7c71a3e2f77 drm/nouveau/disp:

Re: [Intel-gfx] [git pull] drm merge for 3.9-rc1

On Thu, 2013-02-28 at 11:31 -0300, Paulo Zanoni wrote: Hi 2013/2/28 Chris Wilson ch...@chris-wilson.co.uk: On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote: On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek sedat.di...@gmail.com wrote: Hi, I am seeing this also on

Re: Radeon HDMI question

Hi, 2013-01-18 13:04 keltezéssel, Christian König írta: Am 17.01.2013 20:35, schrieb Boszormenyi Zoltan: Hi, I experience a strange problem, I don't know whether it's a feature or a bug, and if it's a bug, where. I have a Radeon HD6570. A monitor via DVI and an LCD TV via HDMI are connected.

Re: [git pull] drm merge for 3.9-rc1

On Tue, Feb 26, 2013 at 05:39:46PM -0800, Linus Torvalds wrote: On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie airl...@linux.ie wrote: Highlights: i915: all over the map, haswell power well enhancements, valleyview macro horrors cleaned up, killing lots of legacy GTT code, Lowlight:

[Bug 60802] Corruption with DMA ring on cayman

https://bugs.freedesktop.org/show_bug.cgi?id=60802 --- Comment #42 from Alexandre Demers alexandre.f.dem...@gmail.com --- (In reply to comment #41) Just as information: I just built 3.9-rc1 and the corruption is still present and looking exactly the same. Same here, tested yesterday. -- You

nouveau bug in 3.7.9 -- unable to handle kernel paging request

While using chrome, I got the following. It was able to render the bug to the screen, so at least something was working (and it also made it to my logs). [223614.867297] BUG: unable to handle kernel paging request at c90013a0 [223614.867372] IP: [812eaf98] iowrite32+0x12/0x33

[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 #21 from Konrad Rzeszutek Wilk konrad.w...@oracle.com 2013-03-05 20:16:12 --- Well not forever. Daniel (lets see if I can add him on this bug) is looking at getting the EFI parts working. The VGA part is on the list but we

[Bug 61690] Graphic issue on PCSX2 with Gallium 0.4 on AMD RS780

https://bugs.freedesktop.org/show_bug.cgi?id=61690 LukK pablo11...@yahoo.com changed: What|Removed |Added Version|9.1 |9.0 --- Comment #5 from LukK

[PATCH] drm/tegra: drop select DRM_HDMI

Commit ac24c2204a76e5b42aa103bf963ae0eda1b827f3 (drm/tegra: Use generic HDMI infoframe helpers) added select DRM_HDMI to the DRM_TEGRA Kconfig entry. But there is no Kconfig symbol named DRM_HDMI. The select statement for that symbol is a nop. Drop it. What was needed to use HDMI functionality

[Bug 26345] [845G] CPU/GPU incoherency

https://bugs.freedesktop.org/show_bug.cgi?id=26345 --- Comment #157 from Trey Ramsay tram...@linux.vnet.ibm.com --- In regards to comment 145, is it recommended to use SNA? We are not using SNA and have seen GPU hangs on the 845G. Is it better to use SNA and apply the SNA patch to

Re: nouveau lockdep splat

On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote: Dropping Tegra ML, it's not the place where Nouveau mails should go. $ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c ... linux-te...@vger.kernel.org (open list:TEGRA SUPPORT) Maybe get_maintainer.pl patterns

v3.9-rc1 instability on Chromebook Pixel with gmbus irq

Hi Daniel Vetter, I'm working on touch devices Chromium OS, and I've noticed a regression between 3.8 and 3.9-rc1, which was posted yesterday. The hardware in question is a Chromebook Pixel. For this device, we have i2c input devices: atmel mxt224s touchpad and atmel mxt1664s touchscreen. The

[Bug 61419] r600g: No OpenGL Core 3.1 available on Cayman

https://bugs.freedesktop.org/show_bug.cgi?id=61419 Alexandre Demers alexandre.f.dem...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED

Re: [PATCH] drm/exynos: fimd: calculate the correct address offset

Hi On Tue, Mar 5, 2013 at 5:47 PM, Joonyoung Shim jy0922.s...@samsung.com wrote: On 03/05/2013 09:04 PM, Leela Krishna Amudala wrote: Hi, On Tue, Mar 5, 2013 at 5:24 PM, Joonyoung Shim jy0922.s...@samsung.com wrote: Hi Leela, On 03/05/2013 08:25 PM, Leela Krishna Amudala wrote:

Re: [git pull] drm merge for 3.9-rc1

On Thu, Feb 28, 2013 at 1:59 PM, Josh Boyer jwbo...@gmail.com wrote: On Thu, Feb 28, 2013 at 10:15 AM, Josh Boyer jwbo...@gmail.com wrote: On Thu, Feb 28, 2013 at 10:09 AM, Alex Deucher alexdeuc...@gmail.com wrote: On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer jwbo...@gmail.com wrote: On Thu,

[PATCH] drm: fix new kernel-doc warnings

From: Randy Dunlap rdun...@infradead.org Fix new kernel-doc warnings in drm_edid.c: convert doxygen(?) to kernel-doc to match the rest of the file's documentation. Warning(drivers/gpu/drm/drm_edid.c:997): No description found for parameter 'adapter' Warning(drivers/gpu/drm/drm_edid.c:997): No

[PATCH V2] drm/exynos: fimd: calculate the correct address offset

Calculate the correct address offset values for alpha and color key control registers and clear size control register for window 0 Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 16 ++-- 1 file changed, 10 insertions(+), 6

qemu qxl kms driver

Hi, This is a KMS driver for the QXL virtual hw device shipped in qemu. The first patch just adds some ttm symbol exports, the second contains the driver. Its also in my git repo here http://cgit.freedesktop.org/~airlied/linux/log/?h=qxl-upstream The userspace driver is here

[PATCH 1/2] ttm: export functions to allow qxl do its own iomapping

qxl wants to use io mapping like i915 gem does, for now just export the symbols so the driver can implement atomic page maps using io mapping. Signed-off-by: Dave Airlie airl...@redhat.com --- drivers/gpu/drm/ttm/ttm_bo_util.c | 13 + include/drm/ttm/ttm_bo_driver.h | 4 2

Re: [PATCH] drm/tegra: drop select DRM_HDMI

On Tue, Mar 05, 2013 at 10:07:36PM +0100, Paul Bolle wrote: Commit ac24c2204a76e5b42aa103bf963ae0eda1b827f3 (drm/tegra: Use generic HDMI infoframe helpers) added select DRM_HDMI to the DRM_TEGRA Kconfig entry. But there is no Kconfig symbol named DRM_HDMI. The select statement for that symbol

Re: [PATCH] libdrm/exynos: add test application for 2d gpu.

2013/3/3 Rob Clark robdcl...@gmail.com: On Sat, Mar 2, 2013 at 2:28 AM, Inki Dae inki@samsung.com wrote: Actually, we have already implemented the EXA part of X server and that has being used on our linux platform. But I think we could more improvement this. So are you writting user side