BUG: kworker hangs the GPU on drm and i915 since 3.8.x under X11

Two things: - Please always cc relevant mailing lists when reporting a bug. - With lockdep enabled (CONFIG_PROVE_LOCKING) you should get detailed backtraces and lists of held lock when the kworker gets stuck. Can you please reproduce with that option enabled and then attach the dmesg? Thanks,

[PATCH v3 1/4] drm: Add struct drm_rect and assorted utility functions

On Thu, Apr 04, 2013 at 06:38:15PM +0200, Laurent Pinchart wrote: > Hi Ville, > > Thanks for the patch. > > On Wednesday 27 March 2013 17:46:22 ville.syrjala at linux.intel.com wrote: > > From: Ville Syrj?l? > > > > struct drm_rect represents a simple rectangle. The utility > > functions are

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Thu, Apr 4, 2013 at 6:49 PM, Peter Zijlstra wrote: > On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote: >> We've discussed this approach of using (rt-prio, age) instead of just >> age >> to determine the the "oldness" of a task for deadlock-breaking with >> -EAGAIN. The problem is that

[Bug 57567] 3.7 radeonfb broken on efivga screens

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130404/4a13f135/attachment.html>

[Bug 57567] 3.7 radeonfb broken on efivga screens

3.9 with your first patch with all cases. -- 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/20130404/13faff58/attachment-0001.html>

[Bug 62976] UEFI + SUMO [6550D] freeze after loading radeon

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130404/9fae972f/attachment.html>

[Bug 43655] Latest radeon dri driver on HD6950 with GRUB set "GRUB_GFXPAYLOAD_LINUX=keep" put the display in a flickering state

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130404/80d0a157/attachment.html>

[Bug 57567] 3.7 radeonfb broken on efivga screens

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

[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130404/7ec6bcc6/attachment.html>

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Thu, Apr 4, 2013 at 6:38 PM, Peter Zijlstra wrote: > On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote: >> Hm, I guess your aim with the TASK_DEADLOCK wakeup is to bound the >> wait >> times of older task. > > No, imagine the following: > > struct ww_mutex A, B; > struct mutex C; > >

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Thu, Apr 4, 2013 at 3:31 PM, Daniel Vetter wrote: >> In this case when O blocks Y isn't actually blocked, so our >> TASK_DEADLOCK wakeup doesn't actually achieve anything. >> >> This means we also have to track (task) state so that once Y tries to >> acquire A (creating the actual deadlock)

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote: > Well, it was a good read and I'm rather happy that we agree on the > ww_ctx > thing (whatever it's called in the end), even though we have slightly > different reasons for it. Yeah, I tried various weirdness to get out from under it, but

[Bug 57567] 3.7 radeonfb broken on efivga screens

ubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130404/13a245c8/attachment.html>

[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system

what I saw. Are they already reported? If so, this bug may be a duplicate then. -- 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/20130404/e80326a0/attachment.html>

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote: > We've discussed this approach of using (rt-prio, age) instead of just > age > to determine the the "oldness" of a task for deadlock-breaking with > -EAGAIN. The problem is that through PI boosting or normal rt-prio > changes > while tasks

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote: > I'm a bit confused about the different classes you're talking about. > Since > the ticket queue is currently a global counter there's only one class > of > ww_mutexes. Right, so that's not something that's going to fly.. we need to

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote: > Another big reason for having a start/end marker like you've describe > is > lockdep support. Yeah, I saw how you did that.. but there's other ways of making it work too, you could for instance create a new validation state for this type

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote: > The thing is now that you're not expected to hold these locks for a > long > time - if you need to synchronously stall while holding a lock > performance > will go down the gutters anyway. And since most current > gpus/co-processors > still

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote: > The trick with the current code is that the oldest task > will never see an -EAGAIN ever and hence is guaranteed to make forward > progress. If the task is really unlucky though it might be forced to > wait > for a younger task for every

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote: > Hm, I guess your aim with the TASK_DEADLOCK wakeup is to bound the > wait > times of older task. No, imagine the following: struct ww_mutex A, B; struct mutex C; task-O task-Y task-X A B

[PATCH v3 1/4] drm: Add struct drm_rect and assorted utility functions

Hi Ville, Thanks for the patch. On Wednesday 27 March 2013 17:46:22 ville.syrjala at linux.intel.com wrote: > From: Ville Syrj?l? > > struct drm_rect represents a simple rectangle. The utility > functions are there to help driver writers. > > v2: Moved the region stuff into its own file, made

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote: > We do add some form of owner tracking by storing the reservation > ticket > of the current holder into every ww_mutex. So when task-Y in your > above > example tries to acquire lock A it notices that it's behind in the > global > queue and

[PATCH v4 09/21] modetest: Allow specifying plane position

Hi Ville, On Wednesday 27 March 2013 19:15:31 Ville Syrj?l? wrote: > On Wed, Mar 27, 2013 at 05:57:20PM +0200, Ville Syrj?l? wrote: > > On Tue, Mar 19, 2013 at 03:55:50PM +0100, Laurent Pinchart wrote: > > > Extend the -P option to allow specifying the plane x and y offsets. The > > > position is

[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system

attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130404/06136cac/attachment-0001.html>

[Bug 57567] 3.7 radeonfb broken on efivga screens

a patch. -- 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/20130404/06fc510d/attachment.html>

[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system

ext couple of days. -- 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/20130404/fefa24aa/attachment.html>

[RFC 0/3] drm/tegra: Add 3D support

ate-driver Thanks Rob for pointing this out! Thierry -- 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/20130404/2f

UVD on RV770/RV790

Hi everyone, Sorry to disappoint you but I've made a mistake in classifying the different UVD hardware generations. RV770 and RV790 have the same UVD block as on RS780 and RS880 and not the same as RV710, so it's currently NOT supported. It's may fault because of the strange chipset numbering

[Bug 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130404/db8e8726/attachment.html>

[RFC 3/3] drm/tegra: Add support for tiled buffer objects

The gr2d and gr3d engines work more efficiently on buffers with a tiled memory layout. Allow created buffers to be marked as tiled so that the display controller can scan them out properly. Signed-off-by: Thierry Reding --- drivers/gpu/host1x/drm/dc.c | 11 +++

[RFC 2/3] drm/tegra: Support the XBGR8888 pixelformat

While at it, also include the RGB565 pixelformat in the list of formats supported by overlays. Signed-off-by: Thierry Reding --- drivers/gpu/host1x/drm/dc.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/host1x/drm/dc.c b/drivers/gpu/host1x/drm/dc.c index edfe0ee..14a09a4

[RFC 1/3] WIP: drm/tegra: Add 3D support

This is a preliminary patch that adds support for 3D support on top of Terje's and Arto's host1x and gr2d patches. There are a few things that still need to be resolved before this can be applied. I haven't been able to test Tegra30 support so it'd be good if somebody with hardware could give it

[RFC 0/3] drm/tegra: Add 3D support

This small series of patches adds support for the 3D engine found on NVIDIA Tegra SoCs. It builds on top of Terje's and Arto's host1x and gr2d patches. A couple of things still need to be done before this can be merged, though. Patch 1 is the central piece of the series. It adds support for using

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Thu, Apr 04, 2013 at 02:01:48PM +0200, Peter Zijlstra wrote: > > I'm sorry, this email ended up quite a bit longer than I had hoped for; > please bear with me. > > On Tue, 2013-04-02 at 18:59 +0200, Peter Zijlstra wrote: > > struct ww_mutex; /* wound/wait */ > > > > int

[PATCH 02/10] drm/radeon: UVD bringup v7

Am 03.04.2013 19:10, schrieb Jerome Glisse: > On Wed, Apr 03, 2013 at 05:53:55PM +0200, Christian K?nig wrote: >> Am 03.04.2013 16:53, schrieb Jerome Glisse: >>> On Wed, Apr 03, 2013 at 01:18:31AM +0200, Christian K?nig wrote: [SNIP] /* hardcode those limit for now */

[PATCH v4 04/21] modetest: Add a command line parameter to select the driver

Hi Ville, On Wednesday 03 April 2013 13:06:30 Ville Syrj?l? wrote: > On Tue, Mar 19, 2013 at 03:55:45PM +0100, Laurent Pinchart wrote: > > If the -M parameter is specified, modetest will use the requested device > > name instead of trying its builtin list of device names. > > > > Signed-off-by:

[Bug 63124] [r600g] HyperZ lockup on REDWOOD in Half Life 2 Deathmatch

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130404/6102bbb6/attachment.html>

[Bug 63124] [r600g] HyperZ lockup on REDWOOD in Half Life 2 Deathmatch

-1-ARCH #1 SMP PREEMPT Fri Mar 29 19:18:14 CET 2013 x86_64 GNU/Linux -- 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/20130

[Bug 63124] New: [r600g] HyperZ lockup on REDWOOD in Half Life 2 Deathmatch

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

BUG: kworker hangs the GPU on drm and i915 since 3.8.x under X11

Compiled und run the kernel as you instructed. Although the GPU did hang momentarily the dmesg showed no abnormalities. dmesg: [??? 0.00] Initializing cgroup subsys cpuset [??? 0.00] Initializing cgroup subsys cpu [??? 0.00] Linux version 3.8.4-1-mine (root at x3200) (gcc version

[PATCHv2 0/5] videomode patches

--- 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/20130404/9b8fc72d/attachment-0001.pgp>

[PATCH] drm/radeon: UVD support for RV710-SI

lists.freedesktop.org/archives/mesa-dev/2013-April/037049.html -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archiv

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

I'm sorry, this email ended up quite a bit longer than I had hoped for; please bear with me. On Tue, 2013-04-02 at 18:59 +0200, Peter Zijlstra wrote: > struct ww_mutex; /* wound/wait */ > > int mutex_wound_lock(struct ww_mutex *); /* returns -EDEADLK */ > int mutex_wait_lock(struct

[PATCH 02/10] drm/radeon: UVD bringup v7

On Tue, Apr 2, 2013 at 7:18 PM, Christian K?nig wrote: > Just everything needed to decode videos using UVD. > > v6: just all the bugfixes and support for R7xx-SI merged in one patch > v7: UVD_CGC_GATE is a write only register, lockup detection fix > > Signed-off-by: Christian K?nig > --- >

[Bug 57567] 3.7 radeonfb broken on efivga screens

|| -- 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/20130404/9469a60f/attachment.html>

[PATCH v3 2/2] dma-buf: Add debugfs support

Add debugfs support to make it easier to print debug information about the dma-buf buffers. Cc: Dave Airlie [minor fixes on init and warning fix] Signed-off-by: Sumit Semwal --- changes since v2: (based on review comments from Laurent Pinchart) - reordered functions to avoid forward

[PATCH v3 1/2] dma-buf: replace dma_buf_export() with dma_buf_export_named()

For debugging purposes, it is useful to have a name-string added while exporting buffers. Hence, dma_buf_export() is replaced with dma_buf_export_named(), which additionally takes 'exp_name' as a parameter. For backward compatibility, and for lazy exporters who don't wish to name themselves, a

[PATCH v3 0/2] dma-buf: Add support for debugfs

The patch series adds a much-missed support for debugfs to dma-buf framework. Based on the feedback received on v1 of this patch series, support is also added to allow exporters to provide name-strings that will prove useful while debugging. Some more magic can be added for more advanced

[PATCH v2 03/20] x86, ACPI, mm: Kill max_low_pfn_mapped

On Thu, Apr 4, 2013 at 10:36 AM, Tejun Heo wrote: > Hello, > > On Sat, Mar 09, 2013 at 10:44:30PM -0800, Yinghai Lu wrote: >> Now we have arch_pfn_mapped array, and max_low_pfn_mapped should not >> be used anymore. >> >> User should use arch_pfn_mapped or just 1UL<<(32-PAGE_SHIFT) instead. >> >>

radeonsi tiling dilema

Am 03.04.2013 17:57, schrieb Alex Deucher: > On Wed, Apr 3, 2013 at 11:48 AM, Christian K?nig > wrote: >> Am 03.04.2013 15:57, schrieb Jerome Glisse: >> >> On Wed, Apr 3, 2013 at 5:37 AM, Michel D?nzer wrote: >> >> On Die, 2013-04-02 at 14:13 -0400, Jerome Glisse wrote: >> >> So i am facing a

[PATCH] drm/radeon: UVD support for RV710-SI

Am 03.04.2013 19:57, schrieb Andreas Boll: > Could you bump drm minor version? Not necessary, submitting an UVD create messages while creating the driver object should just result in an error code when UVD is not available. When handled like this it doesn't matter if the kernel has no UVD

[PATCH v2 03/20] x86, ACPI, mm: Kill max_low_pfn_mapped

Hello, On Sat, Mar 09, 2013 at 10:44:30PM -0800, Yinghai Lu wrote: > Now we have arch_pfn_mapped array, and max_low_pfn_mapped should not > be used anymore. > > User should use arch_pfn_mapped or just 1UL<<(32-PAGE_SHIFT) instead. > > Only user is ACPI_INITRD_TABLE_OVERRIDE, and it should not

[PATCH] drm/radeon: add si tile mode array query

On Mit, 2013-04-03 at 17:22 -0400, j.glisse at gmail.com wrote: > From: Jerome Glisse > > Allow userspace to query for the tile mode array so userspace can properly > compute surface pitch and alignment requirement depending on tiling. > > Signed-off-by: Jerome Glisse [...] > diff --git

[PATCH] radeon: add si tiling support

On Mit, 2013-04-03 at 17:22 -0400, j.glisse at gmail.com wrote: > From: Jerome Glisse > > Signed-off-by: Jerome Glisse > --- > include/drm/radeon_drm.h | 61 + > radeon/radeon_surface.c | 663 > +++ > radeon/radeon_surface.h | 30 +++ > 3

[PATCH] radeon: add si tiling support v2

From: Jerome Glisse v2: Only writte tile index if flags for it is set Signed-off-by: Jerome Glisse --- include/drm/radeon_drm.h | 61 + radeon/radeon_surface.c | 664 +++ radeon/radeon_surface.h | 31 +++ 3 files changed,

flushing uninitialized work item in radeon init failure path

Hello, The following happens on my test machine which has an on-board VGA which is not connected. The failure is expected but, in the failure path, it calls radeon_irq_kms_fini() which flushes @rdev->*_work when @rdev seemingly hasn't gone through radeon_irq_kms_init(), ending up trying to flush

[PATCHv9 0/9] Support Tegra 2D hardware

On 22.03.2013 16:54, Thierry Reding wrote: > On Fri, Mar 22, 2013 at 04:34:00PM +0200, Terje Bergstrom wrote: >> This set of patches adds support for Tegra20 and Tegra30 host1x and >> 2D. It is based on linux-next-20130322 with RTC fixes applied. (...) > For the series: > > Reviewed-by: Thierry

radeonsi tiling dilema

On Mit, 2013-04-03 at 13:04 -0400, Jerome Glisse wrote: > On Wed, Apr 03, 2013 at 06:11:26PM +0200, Michel D?nzer wrote: > > On Mit, 2013-04-03 at 09:57 -0400, Jerome Glisse wrote: > > > On Wed, Apr 3, 2013 at 5:37 AM, Michel D?nzer > > > wrote: > > > > The information we loose is what

[Bug 57567] 3.7 radeonfb broken on efivga screens

bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130404/60433d19/attachment.html>

[Bug 57567] 3.7 radeonfb broken on efivga screens

t;http://lists.freedesktop.org/archives/dri-devel/attachments/20130404/d7b369aa/attachment.html>

UVD fails to init on rv790

nit() failed. [h264_vdpau @ 0x8b3db80]decode_slice_header error [h264_vdpau @ 0x8b3db80]no frame! Error while decoding frame! Too many audio packets in the buffer: (4096 in 1401092 bytes). Maybe you are playing a non-interleaved stream/file or the codec failed? For AVI files, try to force non-interleaved mode with the -ni option. FATAL: Could not initialize video filters (-vf) or video output (-vo). Exiting... (End of file) => See log file Any further hint? -Dieter -- next part -- A non-text attachment was scrubbed... Name: mplayer.log.bz2 Type: application/x-bzip2 Size: 3647 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130404/840de867/attachment.bin>

UVD fails to init on rv790

FYI I get the same errors on rv770 (HD4870) Andreas. 2013/4/3 Christian K?nig > Hi Andy, > > crap! I feared that something like this would happen. IIRC we never tested > UVD on an rv790, and this hardware isn't easy to get any more. > > RV770/RV790 have a separate UVD hardware generation

Re: [PATCH] drivers/gpu/drm/nouveau: remove erroneous semicolon

Hello maintainers: when you have time, please help to check this patch whether is OK. thanks. gchen. On 2013年03月27日 15:23, Chen Gang wrote: need remove semicolon, or always return true. Signed-off-by: Chen Gang gang.c...@asianux.com --- drivers/gpu/drm/nouveau/nv50_display.c |

Re: UVD fails to init on rv790

Thanks AMD for getting this out :-) +1 I have an issue, though. ;( +1 Exactly the same problem but on a RV770! Noticed that the RV710_uvd.bin is some 20kb bigger than the RV770 one so maybe that is the problem? lspci -nnv: 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices

[PATCH] drm/i915: Add no-lvds quirk for Fujitsu Esprimo Q900

The Mobile Sandy Bridge CPUs in the Fujitsu Esprimo Q900 mini desktop PCs are probably misleading the LVDS detection code in intel_lvds_supported. Nothing is connected to the LVDS ports in these systems. Signed-off-by: Christian Lamparter chunk...@googlemail.com ---

gma500: Other things that I could work on

Hi, I would not mind improving use of my Asus EeePC X101CH with Cedar View / gma3600 a bit more. But a barrier is knowledge of the hardware. Meddling with existing (initialization) code is possible, but for point 1 and 3 below that is not going to cut, it, I expect. Does anyone have pointers?

[v3.8 Regression] Merge tag 'v3.7-rc2' into drm-intel-next-queued

Hi Daniel, A bug was opened against the Ubuntu kernel[0]. After a kernel bisect, it was found the following was the first bad commit: commit c2fb7916927e989ea424e61ce5fe617e54878827 Merge: 29de6ce 6f0c058 Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Mon Oct 22 14:34:51 2012 +0200

Re: [v3.8 Regression] Merge tag 'v3.7-rc2' into drm-intel-next-queued

On 04/03/2013 03:16 PM, Daniel Vetter wrote: On Wed, Apr 3, 2013 at 9:08 PM, Joseph Salisbury joseph.salisb...@canonical.com mailto:joseph.salisb...@canonical.com wrote: Hi Daniel, A bug was opened against the Ubuntu kernel[0]. After a kernel bisect, it was found the following

[PATCH v3 0/2] dma-buf: Add support for debugfs

The patch series adds a much-missed support for debugfs to dma-buf framework. Based on the feedback received on v1 of this patch series, support is also added to allow exporters to provide name-strings that will prove useful while debugging. Some more magic can be added for more advanced

[PATCH v3 1/2] dma-buf: replace dma_buf_export() with dma_buf_export_named()

For debugging purposes, it is useful to have a name-string added while exporting buffers. Hence, dma_buf_export() is replaced with dma_buf_export_named(), which additionally takes 'exp_name' as a parameter. For backward compatibility, and for lazy exporters who don't wish to name themselves, a

[PATCH v3 2/2] dma-buf: Add debugfs support

Add debugfs support to make it easier to print debug information about the dma-buf buffers. Cc: Dave Airlie airl...@redhat.com [minor fixes on init and warning fix] Signed-off-by: Sumit Semwal sumit.sem...@linaro.org --- changes since v2: (based on review comments from Laurent Pinchart) -

Re: [PATCHv9 0/9] Support Tegra 2D hardware

On 22.03.2013 16:54, Thierry Reding wrote: On Fri, Mar 22, 2013 at 04:34:00PM +0200, Terje Bergstrom wrote: This set of patches adds support for Tegra20 and Tegra30 host1x and 2D. It is based on linux-next-20130322 with RTC fixes applied. (...) For the series: Reviewed-by: Thierry Reding

[Bug 57567] 3.7 radeonfb broken on efivga screens

https://bugs.freedesktop.org/show_bug.cgi?id=57567 --- Comment #20 from Vladimir boba...@gmail.com --- Created attachment 77406 -- https://bugs.freedesktop.org/attachment.cgi?id=77406action=edit new dmesg with drm.debug=14 It's a little bit better now, framebuffer is always shifted.

[Bug 57567] 3.7 radeonfb broken on efivga screens

https://bugs.freedesktop.org/show_bug.cgi?id=57567 --- Comment #21 from Vladimir boba...@gmail.com --- Created attachment 77407 -- https://bugs.freedesktop.org/attachment.cgi?id=77407action=edit screenshot of 3.9 screenshot of what happens -- You are receiving this mail because: You are the

Re: radeonsi tiling dilema

On Mit, 2013-04-03 at 13:04 -0400, Jerome Glisse wrote: On Wed, Apr 03, 2013 at 06:11:26PM +0200, Michel Dänzer wrote: On Mit, 2013-04-03 at 09:57 -0400, Jerome Glisse wrote: On Wed, Apr 3, 2013 at 5:37 AM, Michel Dänzer mic...@daenzer.net wrote: The information we loose is

Re: [PATCH] radeon: add si tiling support

On Mit, 2013-04-03 at 17:22 -0400, j.gli...@gmail.com wrote: From: Jerome Glisse jgli...@redhat.com Signed-off-by: Jerome Glisse jgli...@redhat.com --- include/drm/radeon_drm.h | 61 + radeon/radeon_surface.c | 663 +++

Re: [PATCH] drm/radeon: add si tile mode array query

On Mit, 2013-04-03 at 17:22 -0400, j.gli...@gmail.com wrote: From: Jerome Glisse jgli...@redhat.com Allow userspace to query for the tile mode array so userspace can properly compute surface pitch and alignment requirement depending on tiling. Signed-off-by: Jerome Glisse

Re: [PATCH] drm/radeon: UVD support for RV710-SI

Am 03.04.2013 19:57, schrieb Andreas Boll: Could you bump drm minor version? Not necessary, submitting an UVD create messages while creating the driver object should just result in an error code when UVD is not available. When handled like this it doesn't matter if the kernel has no UVD

Re: radeonsi tiling dilema

Am 03.04.2013 17:57, schrieb Alex Deucher: On Wed, Apr 3, 2013 at 11:48 AM, Christian König deathsim...@vodafone.de wrote: Am 03.04.2013 15:57, schrieb Jerome Glisse: On Wed, Apr 3, 2013 at 5:37 AM, Michel Dänzer mic...@daenzer.net wrote: On Die, 2013-04-02 at 14:13 -0400, Jerome Glisse

Re: [PATCH v2 2/3] mutex: add support for reservation style locks, v2

I'm sorry, this email ended up quite a bit longer than I had hoped for; please bear with me. On Tue, 2013-04-02 at 18:59 +0200, Peter Zijlstra wrote: struct ww_mutex; /* wound/wait */ int mutex_wound_lock(struct ww_mutex *); /* returns -EDEADLK */ int mutex_wait_lock(struct ww_mutex

Re: [PATCH] drm/radeon: UVD support for RV710-SI

Dear Christian, dear AMD developers, Am Mittwoch, den 03.04.2013, 01:18 +0200 schrieb Christian König: the following patchset implements the kernel side of UVD support for the radeon hardware generations RV710-SI. thank you very much for getting these patches out! The R6xx and RS780/RS880

[Bug 57567] 3.7 radeonfb broken on efivga screens

https://bugs.freedesktop.org/show_bug.cgi?id=57567 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Attachment #77407|text/plain |image/jpeg mime

Re: [PATCH v4 04/21] modetest: Add a command line parameter to select the driver

Hi Ville, On Wednesday 03 April 2013 13:06:30 Ville Syrjälä wrote: On Tue, Mar 19, 2013 at 03:55:45PM +0100, Laurent Pinchart wrote: If the -M parameter is specified, modetest will use the requested device name instead of trying its builtin list of device names. Signed-off-by: Laurent

Re: [PATCH 02/10] drm/radeon: UVD bringup v7

Am 03.04.2013 19:10, schrieb Jerome Glisse: On Wed, Apr 03, 2013 at 05:53:55PM +0200, Christian König wrote: Am 03.04.2013 16:53, schrieb Jerome Glisse: On Wed, Apr 03, 2013 at 01:18:31AM +0200, Christian König wrote: [SNIP] /* hardcode those limit for now */ #define RADEON_VA_IB_OFFSET

Re: [PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Thu, Apr 04, 2013 at 02:01:48PM +0200, Peter Zijlstra wrote: I'm sorry, this email ended up quite a bit longer than I had hoped for; please bear with me. On Tue, 2013-04-02 at 18:59 +0200, Peter Zijlstra wrote: struct ww_mutex; /* wound/wait */ int mutex_wound_lock(struct

[PATCH] radeon: add si tiling support v2

From: Jerome Glisse jgli...@redhat.com v2: Only writte tile index if flags for it is set Signed-off-by: Jerome Glisse jgli...@redhat.com --- include/drm/radeon_drm.h | 61 + radeon/radeon_surface.c | 664 +++ radeon/radeon_surface.h | 31 +++

[RFC 0/3] drm/tegra: Add 3D support

This small series of patches adds support for the 3D engine found on NVIDIA Tegra SoCs. It builds on top of Terje's and Arto's host1x and gr2d patches. A couple of things still need to be done before this can be merged, though. Patch 1 is the central piece of the series. It adds support for using

[RFC 1/3] WIP: drm/tegra: Add 3D support

This is a preliminary patch that adds support for 3D support on top of Terje's and Arto's host1x and gr2d patches. There are a few things that still need to be resolved before this can be applied. I haven't been able to test Tegra30 support so it'd be good if somebody with hardware could give it

[RFC 2/3] drm/tegra: Support the XBGR8888 pixelformat

While at it, also include the RGB565 pixelformat in the list of formats supported by overlays. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de --- drivers/gpu/host1x/drm/dc.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/host1x/drm/dc.c

[RFC 3/3] drm/tegra: Add support for tiled buffer objects

The gr2d and gr3d engines work more efficiently on buffers with a tiled memory layout. Allow created buffers to be marked as tiled so that the display controller can scan them out properly. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de --- drivers/gpu/host1x/drm/dc.c | 11

UVD on RV770/RV790

Hi everyone, Sorry to disappoint you but I've made a mistake in classifying the different UVD hardware generations. RV770 and RV790 have the same UVD block as on RS780 and RS880 and not the same as RV710, so it's currently NOT supported. It's may fault because of the strange chipset

[Bug 63124] New: [r600g] HyperZ lockup on REDWOOD in Half Life 2 Deathmatch

https://bugs.freedesktop.org/show_bug.cgi?id=63124 Priority: medium Bug ID: 63124 Assignee: dri-devel@lists.freedesktop.org Summary: [r600g] HyperZ lockup on REDWOOD in Half Life 2 Deathmatch Severity: major

Re: [RFC 0/3] drm/tegra: Add 3D support

On Thu, Apr 04, 2013 at 04:09:17PM +0200, Thierry Reding wrote: [...] [0]: https://github.com/organizations/grate-driver This apparently redirects to github.com unless you're a member of the grate-driver organization. So the correct link should actually be:

[Bug 63124] [r600g] HyperZ lockup on REDWOOD in Half Life 2 Deathmatch

https://bugs.freedesktop.org/show_bug.cgi?id=63124 --- Comment #1 from abortretryf...@gmail.com --- Silly me, i forgot to include versions! OpenGL renderer string: Gallium 0.4 on AMD REDWOOD OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2.0 (git-450950c) Linux Brimstone

[Bug 63124] [r600g] HyperZ lockup on REDWOOD in Half Life 2 Deathmatch

https://bugs.freedesktop.org/show_bug.cgi?id=63124 --- Comment #2 from abortretryf...@gmail.com --- Also silly me, I typo'd that bug. I meant to say this may be related to bug #62721 -- You are receiving this mail because: You are the assignee for the bug.

[Bug 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor

https://bugs.freedesktop.org/show_bug.cgi?id=62889 --- Comment #14 from Alexander von Gluck kallis...@unixzen.com --- lol. http://www.phoronix.com/scan.php?page=news_itempx=MTM0Mjk It looks like Jerome Glisse is adding it :) -- You are receiving this mail because: You are the assignee for the

Re: [PATCH v4 09/21] modetest: Allow specifying plane position

Hi Ville, On Wednesday 27 March 2013 19:15:31 Ville Syrjälä wrote: On Wed, Mar 27, 2013 at 05:57:20PM +0200, Ville Syrjälä wrote: On Tue, Mar 19, 2013 at 03:55:50PM +0100, Laurent Pinchart wrote: Extend the -P option to allow specifying the plane x and y offsets. The position is

Re: [PATCH v3 1/4] drm: Add struct drm_rect and assorted utility functions

Hi Ville, Thanks for the patch. On Wednesday 27 March 2013 17:46:22 ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com struct drm_rect represents a simple rectangle. The utility functions are there to help driver writers. v2: Moved the region stuff

Re: [PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote: Hm, I guess your aim with the TASK_DEADLOCK wakeup is to bound the wait times of older task. No, imagine the following: struct ww_mutex A, B; struct mutex C; task-O task-Y task-X A B

Re: [PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote: The trick with the current code is that the oldest task will never see an -EAGAIN ever and hence is guaranteed to make forward progress. If the task is really unlucky though it might be forced to wait for a younger task for every

  1   2   >