https://bugs.freedesktop.org/show_bug.cgi?id=57567
--- Comment #20 from Vladimir ---
Created attachment 77406
--> https://bugs.freedesktop.org/attachment.cgi?id=77406&action=edit
new dmesg with drm.debug=14
It's a little bit better now, framebuffer is always shifted. (previously
framebuffer us
https://bugs.freedesktop.org/show_bug.cgi?id=57567
--- Comment #21 from Vladimir ---
Created attachment 77407
--> https://bugs.freedesktop.org/attachment.cgi?id=77407&action=edit
screenshot of 3.9
screenshot of what happens
--
You are receiving this mail because:
You are the assignee for the
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
On Mit, 2013-04-03 at 17:22 -0400, j.gli...@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 files
On Mit, 2013-04-03 at 17:22 -0400, j.gli...@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 a/drive
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
sup
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 dilema regarding tilin
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_mute
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/RS8
https://bugs.freedesktop.org/show_bug.cgi?id=57567
Alex Deucher changed:
What|Removed |Added
Attachment #77407|text/plain |image/jpeg
mime type|
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: L
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
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(s
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, 711 insertions(+), 4
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
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 a
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 1
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 +++
drivers/gpu/host1x/drm/dc
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 numberin
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
Classificatio
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:
https://github.com/grate-driv
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 3.8.5-1-A
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.
___
https://bugs.freedesktop.org/show_bug.cgi?id=62889
--- Comment #14 from Alexander von Gluck ---
lol.
http://www.phoronix.com/scan.php?page=news_item&px=MTM0Mjk
It looks like Jerome Glisse is adding it :)
--
You are receiving this mail because:
You are the assignee for the bug.
___
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
Hi Ville,
Thanks for the patch.
On Wednesday 27 March 2013 17:46:22 ville.syrj...@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 the
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
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 ww_
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
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
of
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 support
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 ar
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
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 th
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) we'
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
> ---
> dif
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;
>
>
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 i
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 us
https://bugs.freedesktop.org/show_bug.cgi?id=62959
--- Comment #9 from Alexandre Demers ---
I was able to run it as supposed. I was missing the "DISPLAY=:0". I think I
have identified which test fails first. I'll double-check and I'll tell you
more as soon as I have time in the next couple of day
https://bugs.freedesktop.org/show_bug.cgi?id=57567
--- Comment #22 from Vladimir ---
I've just tested vanilla 3.9-rc5, to be sure that it's actually your patch that
make things a little bit better, not 3.9 kernel itself.
unpatched 3.9-rc5 - same ersult as 3.7/3.8 kernel, so yeah, it's definetly
https://bugs.freedesktop.org/show_bug.cgi?id=62959
--- Comment #10 from Marek Olšák ---
These tests hang if virtual memory is enabled. Some of them may hang randomly:
glean/polygonOffset
glean/pointAtten
security/initialized-texmemory
security/initialized-fbo
ARB_framebuffer_object/fbo-blit-stre
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.
>>
>> O
https://bugs.freedesktop.org/show_bug.cgi?id=62959
--- Comment #11 from Alexandre Demers ---
(In reply to comment #10)
> These tests hang if virtual memory is enabled. Some of them may hang
> randomly:
>
> glean/polygonOffset
> glean/pointAtten
> security/initialized-texmemory
> security/initial
https://bugs.freedesktop.org/show_bug.cgi?id=57567
--- Comment #23 from Alexandre Demers ---
(In reply to comment #21)
> Created attachment 77407 [details]
> screenshot of 3.9
>
> screenshot of what happens
I don't have a picture as neat as yours. I also saw a change in the display,
but my disp
https://bugs.freedesktop.org/show_bug.cgi?id=62959
--- Comment #12 from Marek Olšák ---
No, I just made the list today by watching piglit logs over ssh.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing li
https://bugs.freedesktop.org/show_bug.cgi?id=57567
Alex Deucher changed:
What|Removed |Added
Attachment #77383|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=43655
--- Comment #30 from Alex Deucher ---
does attachment 77441 help?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
h
https://bugs.freedesktop.org/show_bug.cgi?id=62976
--- Comment #6 from Alex Deucher ---
Can you try attachment 77441 as well?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesk
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.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > struct drm_rect represents a simple rectangle. The utility
> > functions are there
https://bugs.freedesktop.org/show_bug.cgi?id=57567
--- Comment #25 from Vladimir ---
I have strange results
few notes first, 3.8-ati is 3.8.5 kernel + reverted
62444b7462a2b98bc78d68736c03a7c4e66ba7e2
3.9-rc5_patched is 3.9-rc5 with your latest patch
3.8 - ubuntu vanilla 3.8.5
so, here is al
https://bugs.freedesktop.org/show_bug.cgi?id=57567
--- Comment #26 from Vladimir ---
Ah, and without patch it is always same as with 3.8.
So patch matters.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing
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 thr
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, Dani
Hi Ville,
On Thursday 04 April 2013 22:52:37 Ville Syrjälä wrote:
> On Thu, Apr 04, 2013 at 06:38:15PM +0200, Laurent Pinchart wrote:
> > On Wednesday 27 March 2013 17:46:22 ville.syrj...@linux.intel.com wrote:
> > > From: Ville Syrjälä
> > >
> > > struct drm_rect represents a simple rectangle.
https://bugs.freedesktop.org/show_bug.cgi?id=43655
--- Comment #31 from Alexandre Demers ---
(In reply to comment #30)
> does attachment 77441 [details] [review] help?
Still the same. 1 boot on 4 was OK, the three others were showing the same kind
of corruptions as before.
--
You are receiving
On 2013-03-27 08:58, Tomi Valkeinen wrote:
> Hi,
>
> Here's a v2 of the videomode series. The changes compared to v1:
>
> * Dropped "videomode: rename fields", as it received only negative comments
> * New patch: "videomode: videomode_from_timing work"
>
> Patches 1-4 are unchanged.
>
> Tomi
>
coding to PIX_FMT_NONE is not supported.
[h264_vdpau @ 0x8b3db80]ff_MPV_common_init() 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>
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 debuggin
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 #de
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 declaratio
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 Re
crubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130404/d7b369aa/attachment.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130404/60433d19/attachment.html>
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
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 fi
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 a/dr
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
suppo
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 dil
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_mute
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
||
--
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>
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: L
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 */
#defin
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(s
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, 711 insertions(+), 4
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
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 a
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 1
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 +++
drivers/gpu/host1x/drm/dc
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
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130404/9ef83b4d/attachment.html>
om/grate-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/201304
-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
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130404/6102bbb6/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130404/db8e8726/attachment.html>
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
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
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
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 ww_
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
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
of
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 support
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 ar
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
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 th
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) we'
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
> ---
> di
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;
>
>
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 i
1 - 100 of 118 matches
Mail list logo
