date:20130404

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, Daniel

On Thu, Apr 4, 2013 at 10:42 PM, George Amanakis  
wrote:
> 1. kworker hangs the GPU on drm and i915 since 3.8.x under X11
>
> 2. On Archlinux since the 3.8.x releases (vanilla kernels) the drm in
> combination with i915 hangs the GPU unter X11 periodically.
>
> 3. irq hpd i915 kworker
>
> 4. /proc/version
> Linux version 3.8.4-1-ARCH (tobias at T-POWA-LX) (gcc version 4.7.2 (GCC) ) #1
> SMP PREEMPT Wed Mar 20 22:10:25 CET 2013
>
>
> 5. no OOPS
>
> 6. no shell script until now
>
> 7. Archlinux/GNOME
>
> 7.1. ver_linux
> Linux scythe-thinkpad 3.8.4-1-ARCH #1 SMP PREEMPT Wed Mar 20 22:10:25 CET
> 2013 x86_64 GNU/Linux
>
> Gnu C  4.8.0
> Gnu make   3.82
> binutils   2.23.2
> util-linux 2.22.2
> mount  debug
> module-init-tools  12
> e2fsprogs  1.42.7
> jfsutils   1.1.15
> reiserfsprogs  3.6.21
> xfsprogs   3.1.10
> pcmciautils018
> PPP2.4.5
> Linux C Library2.17
> Dynamic linker (ldd)   2.17
> Linux C++ Library  6.0.18
> Procps 3.3.7
> Net-tools  1.60
> Kbd1.15.5
> Sh-utils   8.21
> wireless-tools 29
> Modules Loaded fuse rfcomm bnep zpios zfs zunicode zcommon znvpair
> zavl splat spl zlib_deflate btusb bluetooth snd_hda_codec_conexant arc4
> iwldvm mac80211 phc_intel iwlwifi snd_hda_intel i915 snd_hda_codec cfg80211
> drm_kms_helper iTCO_wdt snd_hwdep thinkpad_acpi nvram drm snd_pcm
> iTCO_vendor_support rfkill snd_page_alloc e1000e snd_timer snd soundcore mei
> lpc_ich intel_agp intel_gtt i2c_i801 i2c_algo_bit i2c_core coretemp
> kvm_intel mperf processor wmi pcspkr button ac battery thermal video evdev
> tpm_tis tpm tpm_bios psmouse serio_raw kvm microcode tp_smapi thinkpad_ec
> ext4 crc16 jbd2 mbcache dm_mod sd_mod ahci libahci libata scsi_mod uhci_hcd
> ehci_pci ehci_hcd usbcore usb_common
>
>
> 7.2. /proc/cpuinfo
> processor: 0
> vendor_id: GenuineIntel
> cpu family: 6
> model: 23
> model name: Intel(R) Core(TM)2 Duo CPU P8400  @ 2.26GHz
> stepping: 6
> microcode: 0x610
> cpu MHz: 800.000
> cache size: 3072 KB
> physical id: 0
> siblings: 2
> core id: 0
> cpu cores: 2
> apicid: 0
> initial apicid: 0
> fpu: yes
> fpu_exception: yes
> cpuid level: 10
> wp: yes
> flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
> pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
> constant_tsc arch_perfmon pebs bts nopl aperfmperf pni dtes64 monitor ds_cpl
> vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm dtherm tpr_shadow vnmi
> flexpriority
> bogomips: 4523.27
> clflush size: 64
> cache_alignment: 64
> address sizes: 36 bits physical, 48 bits virtual
> power management:
>
> processor: 1
> vendor_id: GenuineIntel
> cpu family: 6
> model: 23
> model name: Intel(R) Core(TM)2 Duo CPU P8400  @ 2.26GHz
> stepping: 6
> microcode: 0x610
> cpu MHz: 800.000
> cache size: 3072 KB
> physical id: 0
> siblings: 2
> core id: 1
> cpu cores: 2
> apicid: 1
> initial apicid: 1
> fpu: yes
> fpu_exception: yes
> cpuid level: 10
> wp: yes
> flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
> pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
> constant_tsc arch_perfmon pebs bts nopl aperfmperf pni dtes64 monitor ds_cpl
> vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm dtherm tpr_shadow vnmi
> flexpriority
> bogomips: 4523.27
> clflush size: 64
> cache_alignment: 64
> address sizes: 36 bits physical, 48 bits virtual
> power management:
>
>
> 7.3. /proc/modules
> fuse 69290 3 - Live 0xa09d1000
> rfcomm 52472 0 - Live 0xa09c3000
> bnep 11289 2 - Live 0xa0218000
> zpios 17710 0 - Live 0xa02af000 (O)
> zfs 1035790 1 zpios, Live 0xa0883000 (PO)
> zunicode 321003 1 zfs, Live 0xa0833000 (PO)
> zcommon 32500 1 zfs, Live 0xa01f3000 (PO)
> znvpair 50600 2 zfs,zcommon, Live 0xa04fc000 (PO)
> zavl 4979 1 zfs, Live 0xa0148000 (PO)
> splat 183567 0 - Live 0xa0805000 (O)
> spl 125278 7 zpios,zfs,zunicode,zcommon,znvpair,zavl,splat, Live
> 0xa056e000 (O)
> zlib_deflate 20436 1 spl, Live 0xa015c000
> btusb 14804 0 - Live 0xa00b1000
> bluetooth 301098 11 rfcomm,bnep,btusb, Live 0xa06d9000
> snd_hda_codec_conexant 47663 1 - Live 0xa0023000
> arc4 2007 2 - Live

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

2013-04-04 Thread Ville Syrjälä

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 there to help driver writers.
> > 
> > v2: Moved the region stuff into its own file, made the smaller funcs
> > static inline, used 64bit maths in the scaled clipping function to
> > avoid overflows (instead it will saturate to INT_MIN or INT_MAX).
> > v3: Renamed drm_region to drm_rect, drm_region_clip to
> > drm_rect_intersect, and drm_region_subsample to drm_rect_downscale.
> > 
> > Signed-off-by: Ville Syrj?l? 
> > ---
> >  drivers/gpu/drm/Makefile   |   3 +-
> >  drivers/gpu/drm/drm_rect.c |  96 +
> >  include/drm/drm_rect.h | 132 ++
> >  3 files changed, 230 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/gpu/drm/drm_rect.c
> >  create mode 100644 include/drm/drm_rect.h
> > 
> 
> [snip]
> 
> > diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
> > new file mode 100644
> > index 000..1ad4f5e
> > --- /dev/null
> > +++ b/drivers/gpu/drm/drm_rect.c
> > @@ -0,0 +1,96 @@
> 
> [snip]
> 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/**
> > + * drm_rect_intersect - intersect two rectangles
> > + * @r1: first rectangle
> > + * @r2: second rectangle
> > + *
> > + * Calculate the intersection of rectangles @r1 and @r2.
> > + * @r1 will be overwritten with the intersection.
> > + *
> > + * RETURNS:
> > + * @true if rectangle @r1 is still visible after the operation,
> > + * @false otherwise.
> 
> Isn't @ used for function parameters only ?

Not sure. It's been a while since I wrote these, and I guess I thought
that the @ was there just for higlighting purposes. Looks like the
documentation for the documentation system isn't that great :) so I
guess I'll need to try building the docs and see what happens.

> 
> > + */
> > +bool drm_rect_intersect(struct drm_rect *r1, const struct drm_rect *r2)
> > +{
> > +   r1->x1 = max(r1->x1, r2->x1);
> > +   r1->y1 = max(r1->y1, r2->y1);
> > +   r1->x2 = min(r1->x2, r2->x2);
> > +   r1->y2 = min(r1->y2, r2->y2);
> > +
> > +   return drm_rect_visible(r1);
> 
> Do callers always need that information, or should they instead call 
> drm_rect_visible() explicitly when they need it ?

I suppose someone might call it w/o checking the visibility right away.
In my current use case I do use the return value, so it saves one line
of code :) But I don't mind changing it if you think that would be
better w/o the implicit drm_rect_visible() call.

> 
> > +}
> > +EXPORT_SYMBOL(drm_rect_intersect);
> > +
> > +/**
> > + * drm_rect_clip_scaled - perform a scaled clip operation
> > + * @src: source window rectangle
> > + * @dst: destination window rectangle
> > + * @clip: clip rectangle
> > + * @hscale: horizontal scaling factor
> > + * @vscale: vertical scaling factor
> > + *
> > + * Clip rectangle @dst by rectangle @clip. Clip rectangle @src by the
> > + * same amounts multiplied by @hscale and @vscale.
> > + *
> > + * RETUTRNS:
> > + * @true if rectangle @dst is still visible after being clipped,
> > + * @false otherwise
> > + */
> > +bool drm_rect_clip_scaled(struct drm_rect *src, struct drm_rect *dst,
> > + const struct drm_rect *clip,
> > + int hscale, int vscale)
> > +{
> > +   int diff;
> > +
> > +   diff = clip->x1 - dst->x1;
> > +   if (diff > 0) {
> > +   int64_t tmp = src->x1 + (int64_t) diff * hscale;
> > +   src->x1 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
> > +   }
> > +   diff = clip->y1 - dst->y1;
> > +   if (diff > 0) {
> > +   int64_t tmp = src->y1 + (int64_t) diff * vscale;
> > +   src->y1 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
> > +   }
> > +   diff = dst->x2 - clip->x2;
> > +   if (diff > 0) {
> > +   int64_t tmp = src->x2 - (int64_t) diff * hscale;
> > +   src->x2 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
> > +   }
> > +   diff = dst->y2 - clip->y2;
> > +   if (diff > 0) {
> > +   int64_t tmp = src->y2 - (int64_t) diff * vscale;
> > +   src->y2 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
> > +   }
> > +
> > +   return drm_rect_intersect(dst, clip);
> > +}
> > +EXPORT_SYMBOL(drm_rect_clip_scaled);
> > diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
> > new file mode 100644
> > index 000..40b09a4
> > --- /dev/null
> > +++ b/include/drm/drm_rect.h
> > @@ -0,0 +1,132 @@
> 
> [snip]
> 
> > +/**
> > + * drm_rect - two dimensional rect
> > + * @x1: horizontal starting coordinate (inclusive)
> > + * @x2: horizontal ending coordinate (exclusive)
> > + * @y1: vertical starting coordinate (inclusive)
> > + * @y2: vertical ending coordinate (exclusive)
> 
> What's the rationale for making x2 and y2 exclusive ?

I think

[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 through PI boosting or normal rt-prio
>> changes
>> while tasks are trying to acquire ww_mutexes you can create acyclic
>> loops
>> in the blocked-on graph of ww_mutexes after the fact and so cause
>> deadlocks. So we've convinced ourselves that this approche doesn't
>> work.
>
> Could you pretty please draw me a picture, I'm having trouble seeing
> what you mean.
>
> AFAICT as long as you boost Y while its the lock owner things should
> work out, no?

So this one here took a bit of pondering. But I think you'll like the
conclusion.

Now the deadlock detection works because it impose a dag onto all
lockers which clearly denotes who'll wait and who will get wounded.
The problem with using (rt_prio, ww_age/ticket) instead of just the
ticket si that it's ambigous in the face of PI boosting. E.g.
- rt_prio of A > rt_prio of B, but
- task A is younger than task B

Before boosting task A wins, but after boosting (when only the age
matters) task B wins, since it's now older. So now when B comes around
and tries to grab a lock A currently holds, it'll also block.

Now the cool thing with TASK_KILLABLE (hey, I start to appreciate it,
bear with me!) is that this is no problem - it limits the length of
any chain of blocked tasks to just one link of blocked tasks:
- If the length is currently one it cannot be extended - the blocked
task will set the PF_GTFO flag on the current holder, and since that
would be checked before blocking on another ww_mutex the chain can't
grow past one blocked task.
- If the current holder itself is blocked on another ww_mutex it'll be
in TASK_DEADLOCK state and get woken up.

In both case the current holder of the lock will either continue with
what it's been doing (PI-boosted ofc) until it unlocks everything or
hits the PF_GTFO check and backs off from all currently held locks. RT
mission accomplished I think since the wait time for the highest-prio
task for grabbing a lock is bounded by the lock hold time for the
completely uncontended case. And within a given rt-prio the normal
wait/wound algorithm will resolve conflicts (and ensure forward
progress).

So I'm now rather convinced that with the TASK_DEADLOCK implementation
we can make (rt_prio, age) lock ordering work. But it's not an
artifact of consistent PI boosting (I've raced down that alley first
trying to prove it to no avail), but the fact that lock holder kicking
through PF_GTFO naturally limits blocked task chains on ww_mutexes to
just one link. That in turn makes any post-PI-boosted considerations
moot and so can't result in havoc due to a PI-boost having flipped an
edge in the lock_er_ ordering DAG (we sort tasks with wait/wound, not
locks, hence it's not a lock ordering DAG).

Please poke holes into this argument, I've probably missed a sublety
somewhere ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 57567] 3.7 radeonfb broken on efivga screens

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.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130404/4a13f135/attachment.html>

[Bug 57567] 3.7 radeonfb broken on efivga screens

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 all results:

1) cold boot, boot 3.9-rc5_patched - same screen as with 3.8 (bad)
2) boot macosx, reboot, boot 3.9-rc5_patched - same screen as with 3.8
3) boot 3.8-ati, reboot, boot 3.9-rc5_patched - result like on previous
screenshot I've posted, horizontal shift is always different 

I didnt test 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

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.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://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

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.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130404/80d0a157/attachment.html>

[Bug 57567] 3.7 radeonfb broken on efivga screens

https://bugs.freedesktop.org/show_bug.cgi?id=57567

Alex Deucher  changed:

   What|Removed |Added

  Attachment #77383|0   |1
is obsolete||

--- Comment #24 from Alex Deucher  ---
Created attachment 77441
  --> https://bugs.freedesktop.org/attachment.cgi?id=77441=edit
updated patch

Does this patch work any better?

-- 
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/59e59042/attachment.html>

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

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.
-- next part --
An HTML attachment 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;
>
> task-O  task-Y  task-X
> A
> B
> C
> C
> B
>
> At this point O finds that Y owns B and thus we want to make Y 'yield'
> B to make allow B progress. Since Y is blocked, we'll send a wakeup.
> However Y is blocked on a different locking primitive; one that doesn't
> collaborate in the -EDEADLK scheme therefore we don't want the wakeup to
> succeed.

Yeah, I've thought about this some more and the special sleep state
seems to be only required to ensure we don't cause spurious wakeups
for other any other reasons a task blocks. But I think we can use that
kick-current-holder approach to ensure that older tasks get the lock
in a more timely fashion than the current code. I've tried to detail
it a bit with another 3 task example - that seems to be the point
where the fun starts ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[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) we'll not wait so our
>> TASK_DEADLOCK wakeup doesn't actually achieve anything.
>>
>> Note that Y doesn't need to acquire A in order to return -EDEADLK, any
>> acquisition from the same set (see below) would return -EDEADLK even if
>> there isn't an actual deadlock. This is the cost of heuristic; we could
>> walk the actual block graph but that would be prohibitively expensive
>> since we'd have to do this on every acquire.
>
> Hm, I guess your aim with the TASK_DEADLOCK wakeup is to bound the wait
> times of older task. This could be interesting for RT, but I'm unsure of
> the implications. 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_mutex it tries to acquire.

[Aside: I'm writing this while your replies trickle in, but I think
it's not yet answered already.]

Ok, I've discussed this a lot with Maarten on irc and I think I see a
bit clearer now what's the aim with the new sleep state. Or at least I
have an illusion about it ;-) So let me try to recap my understanding
to check whether we're talking roughly about the same idea.

I think for starters we need to have a slightly more interesting example:

3 threads O, M, Y: O has the oldest ww_age/ticket, Y the youngest, M
is in between.
2 ww_mutexes: A, B

Y has already acquired ww_mutex A, M has already acquired ww_mutex B.

Now O wants to acquire B and M wants to acquire A (let's ignore
detailed ordering for now), resulting in O blocking on M (M holds B
already, but O is older) and M blocking on Y (same for lock B).

Now first question to check my understanding: Your aim with that
special wakeup is to kick M so that it backs off and drops B? That way
O does not need to wait for Y to complete whatever it's currently
doing, unlock A and then in turn M to complete whatever it's doing so
that it can unlock A and finally allows O to grab the lock.

Presuming I'm still following we should be able to fix this with the
new sleep state TASK_DEADLOCK and a flag somewhere in the thread info
(let's call it PF_GTFO for simplicity). Then every time a task does a
blocking wait on a ww_mutex it would set this special sleep state and
also check the PF_GTFO bit. If the later is set, it bails out with
-EAGAIN (so that all locks are dropped).

Now if a task wants to take a lock and notices that it's held by a
younger locker it can set that flag and wake the thread up (need to
think about all the races a bit, but we should be able to make this
work). Then it can do the normal blocking mutex slowpath and wait for
the unlock.

Now if O and M race a bit against each another M should either get
woken (if it's already blocked on Y) and back off, or notice that the
thread flag is set before it even tries to grab another mutex (and so
before the block tree can extend further to Y). And the special sleep
state is to make sure we don't cause any other spurious interrupts.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[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 the whole
progress/fairness thing made it rather hard. Ideally you'd be able to
use some existing scheduler state since its the same goal, but the
whole wakeup-retry muck makes that hard.

> I don't really have a useful idea to make the retry handling for users
> more rusty-compliant though, and I'm still unhappy with all current
> naming
> proposals ;-)

Ah, naming,.. yeah I'm not too terribly attached to most of them. I
just want to avoid something that's reasonably well known to mean
something different.

Furthermore, since we use the wound/wait symmetry breaking it would
make sense for that to appear somewhere in the name.

[Bug 57567] 3.7 radeonfb broken on efivga screens

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 display is flickering after the first few vertical lines (only the first
few lines are stable, but they are still shifted as in your screenshot).

-- 
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/13a245c8/attachment.html>

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

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/initialized-fbo
> ARB_framebuffer_object/fbo-blit-stretch
> 
> 
> These tests hang for a different reason:
> 
> EXT_transform_feedback/order *
> - incorrect UMAD implementation causing an infinite loop, it's been
> discussed on mesa-dev

I confirm (since I remember them particularly) at least for:
glean/polygonOffset
glean/pointAtten
security/initialized-fbo
ARB_framebuffer_object/fbo-blit-stretch (which was the last one I was able to
start)

And I think I also encountered:
EXT_transform_feedback/order *

In other words, Marek, you pretty much summed up 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 are trying to acquire ww_mutexes you can create acyclic
> loops
> in the blocked-on graph of ww_mutexes after the fact and so cause
> deadlocks. So we've convinced ourselves that this approche doesn't
> work.

Could you pretty please draw me a picture, I'm having trouble seeing
what you mean.

AFAICT as long as you boost Y while its the lock owner things should
work out, no?

[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 support
multiple users, including nesting of those. Again, you're adding
something to the generic kernel infrastructure, it had better be usable
:-)

> I guess we could change that once a second user shows up

No, we fix that before it all goes in. I would _so_ hate to find out it
cannot be 'fixed' and be stuck with a half-arsed sync primitive in the
core kernel that's only every usable by the one existent user.

So for now, forget all about TTM, DMA-BUF and other such coolness
except to verify that whatever we end up with does indeed work for the
case you need it for ;-)

[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
of lock.

That said, I didn't consider lockdep too much, I first want the regular
semantics clear.

[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 can't really preempt fairness isn't that high a priority,
> either.
> So we didn't think too much about that.

Yeah but you're proposing a new synchronization primitive for the core
kernel.. all such 'fun' details need to be considered, not only those
few that bear on the one usecase.

[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 ww_mutex it tries to acquire.

Agreed on that.. while I didn't state this my proposed thing should
behave the same. It follows from the symmetry breaking in that only
younger tasks can get 'kill'ed.

[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
C
C
B

At this point O finds that Y owns B and thus we want to make Y 'yield'
B to make allow B progress. Since Y is blocked, we'll send a wakeup.
However Y is blocked on a different locking primitive; one that doesn't
collaborate in the -EDEADLK scheme therefore we don't want the wakeup to
succeed.

[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 the smaller funcs
> static inline, used 64bit maths in the scaled clipping function to
> avoid overflows (instead it will saturate to INT_MIN or INT_MAX).
> v3: Renamed drm_region to drm_rect, drm_region_clip to
> drm_rect_intersect, and drm_region_subsample to drm_rect_downscale.
> 
> Signed-off-by: Ville Syrj?l? 
> ---
>  drivers/gpu/drm/Makefile   |   3 +-
>  drivers/gpu/drm/drm_rect.c |  96 +
>  include/drm/drm_rect.h | 132 ++
>  3 files changed, 230 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/drm_rect.c
>  create mode 100644 include/drm/drm_rect.h
> 

[snip]

> diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
> new file mode 100644
> index 000..1ad4f5e
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_rect.c
> @@ -0,0 +1,96 @@

[snip]

> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * drm_rect_intersect - intersect two rectangles
> + * @r1: first rectangle
> + * @r2: second rectangle
> + *
> + * Calculate the intersection of rectangles @r1 and @r2.
> + * @r1 will be overwritten with the intersection.
> + *
> + * RETURNS:
> + * @true if rectangle @r1 is still visible after the operation,
> + * @false otherwise.

Isn't @ used for function parameters only ?

> + */
> +bool drm_rect_intersect(struct drm_rect *r1, const struct drm_rect *r2)
> +{
> + r1->x1 = max(r1->x1, r2->x1);
> + r1->y1 = max(r1->y1, r2->y1);
> + r1->x2 = min(r1->x2, r2->x2);
> + r1->y2 = min(r1->y2, r2->y2);
> +
> + return drm_rect_visible(r1);

Do callers always need that information, or should they instead call 
drm_rect_visible() explicitly when they need it ?

> +}
> +EXPORT_SYMBOL(drm_rect_intersect);
> +
> +/**
> + * drm_rect_clip_scaled - perform a scaled clip operation
> + * @src: source window rectangle
> + * @dst: destination window rectangle
> + * @clip: clip rectangle
> + * @hscale: horizontal scaling factor
> + * @vscale: vertical scaling factor
> + *
> + * Clip rectangle @dst by rectangle @clip. Clip rectangle @src by the
> + * same amounts multiplied by @hscale and @vscale.
> + *
> + * RETUTRNS:
> + * @true if rectangle @dst is still visible after being clipped,
> + * @false otherwise
> + */
> +bool drm_rect_clip_scaled(struct drm_rect *src, struct drm_rect *dst,
> +   const struct drm_rect *clip,
> +   int hscale, int vscale)
> +{
> + int diff;
> +
> + diff = clip->x1 - dst->x1;
> + if (diff > 0) {
> + int64_t tmp = src->x1 + (int64_t) diff * hscale;
> + src->x1 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
> + }
> + diff = clip->y1 - dst->y1;
> + if (diff > 0) {
> + int64_t tmp = src->y1 + (int64_t) diff * vscale;
> + src->y1 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
> + }
> + diff = dst->x2 - clip->x2;
> + if (diff > 0) {
> + int64_t tmp = src->x2 - (int64_t) diff * hscale;
> + src->x2 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
> + }
> + diff = dst->y2 - clip->y2;
> + if (diff > 0) {
> + int64_t tmp = src->y2 - (int64_t) diff * vscale;
> + src->y2 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
> + }
> +
> + return drm_rect_intersect(dst, clip);
> +}
> +EXPORT_SYMBOL(drm_rect_clip_scaled);
> diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
> new file mode 100644
> index 000..40b09a4
> --- /dev/null
> +++ b/include/drm/drm_rect.h
> @@ -0,0 +1,132 @@

[snip]

> +/**
> + * drm_rect - two dimensional rect
> + * @x1: horizontal starting coordinate (inclusive)
> + * @x2: horizontal ending coordinate (exclusive)
> + * @y1: vertical starting coordinate (inclusive)
> + * @y2: vertical ending coordinate (exclusive)

What's the rationale for making x2 and y2 exclusive ?

> + */
> +struct drm_rect {
> + int x1, y1, x2, y2;
> +};
> +
> +/**
> + * drm_rect_adjust_size - adjust the size of the rect
> + * @r: rect to be adjusted
> + * @x: horizontal adjustment
> + * @y: vertical adjustment

What about renaming x and y to dx and dy ? It would make it more explicit that 
the adjustements are incremental and not absolute values.

> + * Change the size of rect @r by @x in the horizontal direction,
> + * and by @y in the vertical direction, while keeping the center
> + * of @r stationary.
> + *
> + * Positive @x and @y increase the size, negative values decrease it.
> + */
> +static inline void drm_rect_adjust_size(struct drm_rect *r, int x, int y)
> +{
> + r->x1 -= x >> 1;
> + r->y1 -= y >> 1;
> + r->x2 += (x + 1) >> 1;
> + r->y2 += (y + 1) >> 1;
> +}
> +
> +/**

[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 immedieately returns -EAGAIN to indicate the deadlock.
> 
> Aside, there's a bit of fun in that ttm uses -EDEADLCK for when you
> try to
> reserve the same buffer twice - it can easily detect that by comparing
> the
> lock owner ticket with the provided one and if it matches bail out. 

Sure, but this should bear no influence on the design of the mutex
primitive. At most we should ensure this situation is recognizable.

> Hence we've kept the special -EDEADLCK semantics even for the ww_mutex
> stuff.

There's EDEADLK and EDEADLOCK, EDEADLCK does alas not exist :-)

> > Now this gets a little more interesting if we change the scenario a
> > little:
> > 
> >   task-O  task-Y
> > A
> >   B
> > B <-- blocks on Y
> >   * <-- could be A
> 
> The current code at least simple blocks task-O on B until task-Y
> unlocks
> B. Deadlocks cannot happen since if task-Y ever tries to acquire a
> lock
> which is held by an older task (e.g. lock A) it will bail out with
> -EAGAIN.

Agreed, O would have to wait until Y unlocks B. It was a 'detail' I
skimped over for the sake of brevity. I was merely trying to illustrate
the ways in which we must bring Y to return -EDEADLK (or -EAGAIN in
your version).

[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 optional, if not specified the plane will be positioned at
> > > the center of the screen as before.
> > > 
> > > Signed-off-by: Laurent Pinchart 
> > > ---
> > > 
> > >  tests/modetest/modetest.c | 72 ++--
> > >  1 file changed, 57 insertions(+), 15 deletions(-)
> > > 
> > > diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> > > index 7153a40..f95efe6 100644
> > > --- a/tests/modetest/modetest.c
> > > +++ b/tests/modetest/modetest.c
> > > @@ -645,6 +645,7 @@ struct connector_arg {
> > > 
> > >  struct plane_arg {
> > >  
> > >   uint32_t con_id;  /* the id of connector to bind to */
> > > 
> > > + uint32_t x, y;
> > 
> > I'd like the coordinates to allow negative values too.
> 
> Tested it and it actually works w/ negative values thanks to the way
> strtoul() works :) The only real obstacle is the magic '-1' handling.
> I guess you should just give up on magic values and add some flag to
> indicate whether the user provided the coords or not.

Done :-) I'll post a new version.

> Also I must say that I don't like the syntax you used for specifying the
> coords. '(' and ')' need to be escaped or the shell eats them. I've been
> using the x11 -geometry syntax whenever I have to deal with the x/y/w/h
> combination. It's a reasonably well known syntax and doesn't have these
> shell issues. Maybe you could use it here as well.

Given that negative coordinates in the X geometry syntax don't match we what 
need, should I keep the current syntax, abuse the X geometry syntax, or use 
something else ?

-- 
Regards,

Laurent Pinchart

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

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-stretch


These tests hang for a different reason:

EXT_transform_feedback/order *
- incorrect UMAD implementation causing an infinite loop, it's been discussed
on mesa-dev

-- 
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/06136cac/attachment-0001.html>

[Bug 57567] 3.7 radeonfb broken on efivga screens

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 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

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 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

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-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/2ff4c308/attachment.pgp>

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 (RV770/RV790 is 
earlier than RV710). I'm working on it and the difference isn't so big 
so it might be possible to handle those as well.

Cheers,
Christian.

[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  ---
lol.

http://www.phoronix.com/scan.php?page=news_item=MTM0Mjk

It looks like Jerome Glisse is adding it :)

-- 
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/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 +++
 drivers/gpu/host1x/drm/dc.h  |  4 
 drivers/gpu/host1x/drm/drm.c |  2 +-
 drivers/gpu/host1x/drm/drm.h |  2 ++
 drivers/gpu/host1x/drm/fb.c  | 12 +++-
 drivers/gpu/host1x/drm/gem.c | 20 +---
 drivers/gpu/host1x/drm/gem.h | 13 +
 include/uapi/drm/tegra_drm.h |  2 ++
 8 files changed, 53 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/host1x/drm/dc.c b/drivers/gpu/host1x/drm/dc.c
index 14a09a4..5a0d111 100644
--- a/drivers/gpu/host1x/drm/dc.c
+++ b/drivers/gpu/host1x/drm/dc.c
@@ -51,6 +51,7 @@ static int tegra_plane_update(struct drm_plane *plane, struct 
drm_crtc *crtc,
window.dst.h = crtc_h;
window.format = tegra_dc_format(fb->pixel_format);
window.bits_per_pixel = fb->bits_per_pixel;
+   window.tiled = tegra_fb_is_tiled(fb);

for (i = 0; i < drm_format_num_planes(fb->pixel_format); i++) {
struct tegra_bo *bo = tegra_fb_get_plane(fb, i);
@@ -492,6 +493,16 @@ int tegra_dc_setup_window(struct tegra_dc *dc, unsigned 
int index,
tegra_dc_writel(dc, h_offset, DC_WINBUF_ADDR_H_OFFSET);
tegra_dc_writel(dc, v_offset, DC_WINBUF_ADDR_V_OFFSET);

+   if (window->tiled) {
+   value = DC_WIN_BUFFER_ADDR_MODE_TILE_UV |
+   DC_WIN_BUFFER_ADDR_MODE_TILE;
+   } else {
+   value = DC_WIN_BUFFER_ADDR_MODE_LINEAR_UV |
+   DC_WIN_BUFFER_ADDR_MODE_LINEAR;
+   }
+
+   tegra_dc_writel(dc, value, DC_WIN_BUFFER_ADDR_MODE);
+
value = WIN_ENABLE;

if (yuv) {
diff --git a/drivers/gpu/host1x/drm/dc.h b/drivers/gpu/host1x/drm/dc.h
index 79eaec9..e8da0ba 100644
--- a/drivers/gpu/host1x/drm/dc.h
+++ b/drivers/gpu/host1x/drm/dc.h
@@ -365,6 +365,10 @@
 #define DC_WIN_BUF_STRIDE  0x70b
 #define DC_WIN_UV_BUF_STRIDE   0x70c
 #define DC_WIN_BUFFER_ADDR_MODE0x70d
+#define DC_WIN_BUFFER_ADDR_MODE_LINEAR(0 <<  0)
+#define DC_WIN_BUFFER_ADDR_MODE_TILE  (1 <<  0)
+#define DC_WIN_BUFFER_ADDR_MODE_LINEAR_UV (0 << 16)
+#define DC_WIN_BUFFER_ADDR_MODE_TILE_UV   (1 << 16)
 #define DC_WIN_DV_CONTROL  0x70e

 #define DC_WIN_BLEND_NOKEY 0x70f
diff --git a/drivers/gpu/host1x/drm/drm.c b/drivers/gpu/host1x/drm/drm.c
index 298c5f0..33d04c3 100644
--- a/drivers/gpu/host1x/drm/drm.c
+++ b/drivers/gpu/host1x/drm/drm.c
@@ -328,7 +328,7 @@ static int tegra_gem_create(struct drm_device *drm, void 
*data,
struct drm_tegra_gem_create *args = data;
struct tegra_bo *bo;

-   bo = tegra_bo_create_with_handle(file, drm, args->size,
+   bo = tegra_bo_create_with_handle(file, drm, args->size, args->flags,
 >handle);
if (IS_ERR(bo))
return PTR_ERR(bo);
diff --git a/drivers/gpu/host1x/drm/drm.h b/drivers/gpu/host1x/drm/drm.h
index 02ce020..fd1f373 100644
--- a/drivers/gpu/host1x/drm/drm.h
+++ b/drivers/gpu/host1x/drm/drm.h
@@ -162,6 +162,7 @@ struct tegra_dc_window {
unsigned int format;
unsigned int stride[2];
unsigned long base[3];
+   bool tiled;
 };

 /* from dc.c */
@@ -262,6 +263,7 @@ extern int tegra_output_exit(struct tegra_output *output);
 /* from fb.c */
 struct tegra_bo *tegra_fb_get_plane(struct drm_framebuffer *framebuffer,
unsigned int index);
+bool tegra_fb_is_tiled(struct drm_framebuffer *framebuffer);
 extern int tegra_drm_fb_init(struct drm_device *drm);
 extern void tegra_drm_fb_exit(struct drm_device *drm);
 extern void tegra_fbdev_restore_mode(struct tegra_fbdev *fbdev);
diff --git a/drivers/gpu/host1x/drm/fb.c b/drivers/gpu/host1x/drm/fb.c
index 953e418..b8b3c21 100644
--- a/drivers/gpu/host1x/drm/fb.c
+++ b/drivers/gpu/host1x/drm/fb.c
@@ -34,6 +34,16 @@ struct tegra_bo *tegra_fb_get_plane(struct drm_framebuffer 
*framebuffer,
return fb->planes[index];
 }

+bool tegra_fb_is_tiled(struct drm_framebuffer *framebuffer)
+{
+   struct tegra_fb *fb = to_tegra_fb(framebuffer);
+
+   if (fb->planes[0]->flags & TEGRA_BO_TILED)
+   return true;
+
+   return false;
+}
+
 static void tegra_fb_destroy(struct drm_framebuffer *framebuffer)
 {
struct tegra_fb *fb = to_tegra_fb(framebuffer);
@@ -188,7 +198,7 @@ static int tegra_fbdev_probe(struct drm_fb_helper *helper,

size = cmd.pitches[0] * cmd.height;

-   bo = tegra_bo_create(drm, size);
+   bo = tegra_bo_create(drm, size, 0);
if (IS_ERR(bo))
return PTR_ERR(bo);

diff --git a/drivers/gpu/host1x/drm/gem.c b/drivers/gpu/host1x/drm/gem.c
index c5e9a9b..0bdbb50 100644
--- a/drivers/gpu/host1x/drm/gem.c
+++

[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 100644
--- a/drivers/gpu/host1x/drm/dc.c
+++ b/drivers/gpu/host1x/drm/dc.c
@@ -108,7 +108,9 @@ static const struct drm_plane_funcs tegra_plane_funcs = {
 };

 static const uint32_t plane_formats[] = {
+   DRM_FORMAT_XBGR,
DRM_FORMAT_XRGB,
+   DRM_FORMAT_RGB565,
DRM_FORMAT_UYVY,
DRM_FORMAT_YUV420,
DRM_FORMAT_YUV422,
@@ -546,6 +548,9 @@ int tegra_dc_setup_window(struct tegra_dc *dc, unsigned int 
index,
 unsigned int tegra_dc_format(uint32_t format)
 {
switch (format) {
+   case DRM_FORMAT_XBGR:
+   return WIN_COLOR_DEPTH_R8G8B8A8;
+
case DRM_FORMAT_XRGB:
return WIN_COLOR_DEPTH_B8G8R8A8;

-- 
1.8.2

[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 a try. I can probably arrange to
test it on a CardHu if nobody else steps up, but it'll take a while
until I get that setup. Looking at the downstream kernels indicates that
Tegra30 has a second clock and powergate domain and if those really are
required then this patch won't work on Tegra30.

One other important piece that is missing is a list of address registers
to feed to the firewall so that submitted command streams can be checked
for validity. I've already talked to Terje about that, but it seems like
it may turn out to be problematic. What with NVIDIA not wanting to
provide the register descriptions and all that. We'll need to resolve
this in some way before this patch can be merged.

Finally I want to refactor some of the commonalities between gr2d and
gr3d so that they can share more code.

If people want to give this a spin, there are some very basic test
programs available here[0]. The tests from the grate repository are
probably the most useful right now since they test both the gr2d and
gr3d modules and therefore can be used to verify that this patch
actually works.

[0]: https://github.com/organizations/grate-driver

Signed-off-by: Thierry Reding 
---
 drivers/gpu/host1x/Makefile   |   1 +
 drivers/gpu/host1x/dev.c  |   7 +
 drivers/gpu/host1x/dev.h  |   1 +
 drivers/gpu/host1x/drm/drm.c  |   2 +
 drivers/gpu/host1x/drm/gr3d.c | 289 ++
 drivers/gpu/host1x/host1x.h   |   3 +-
 6 files changed, 302 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/host1x/drm/gr3d.c

diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
index 3b037b6..5802e1b 100644
--- a/drivers/gpu/host1x/Makefile
+++ b/drivers/gpu/host1x/Makefile
@@ -17,4 +17,5 @@ host1x-$(CONFIG_DRM_TEGRA) += drm/drm.o drm/fb.o drm/dc.o
 host1x-$(CONFIG_DRM_TEGRA) += drm/output.o drm/rgb.o drm/hdmi.o
 host1x-$(CONFIG_DRM_TEGRA) += drm/gem.o
 host1x-$(CONFIG_DRM_TEGRA) += drm/gr2d.o
+host1x-$(CONFIG_DRM_TEGRA) += drm/gr3d.o
 obj-$(CONFIG_TEGRA_HOST1X) += host1x.o
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index 28e28a2..6daa3be 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -213,11 +213,17 @@ static int __init tegra_host1x_init(void)
err = platform_driver_register(_gr2d_driver);
if (err < 0)
goto unregister_hdmi;
+
+   err = platform_driver_register(_gr3d_driver);
+   if (err < 0)
+   goto unregister_gr2d;
 #endif

return 0;

 #ifdef CONFIG_DRM_TEGRA
+unregister_gr2d:
+   platform_driver_unregister(_gr2d_driver);
 unregister_hdmi:
platform_driver_unregister(_hdmi_driver);
 unregister_dc:
@@ -232,6 +238,7 @@ module_init(tegra_host1x_init);
 static void __exit tegra_host1x_exit(void)
 {
 #ifdef CONFIG_DRM_TEGRA
+   platform_driver_unregister(_gr3d_driver);
platform_driver_unregister(_gr2d_driver);
platform_driver_unregister(_hdmi_driver);
platform_driver_unregister(_dc_driver);
diff --git a/drivers/gpu/host1x/dev.h b/drivers/gpu/host1x/dev.h
index a1607d6..406237a 100644
--- a/drivers/gpu/host1x/dev.h
+++ b/drivers/gpu/host1x/dev.h
@@ -304,5 +304,6 @@ static inline void host1x_hw_show_mlocks(struct host1x 
*host, struct output *o)
 extern struct platform_driver tegra_hdmi_driver;
 extern struct platform_driver tegra_dc_driver;
 extern struct platform_driver tegra_gr2d_driver;
+extern struct platform_driver tegra_gr3d_driver;

 #endif
diff --git a/drivers/gpu/host1x/drm/drm.c b/drivers/gpu/host1x/drm/drm.c
index 2b561c9..298c5f0 100644
--- a/drivers/gpu/host1x/drm/drm.c
+++ b/drivers/gpu/host1x/drm/drm.c
@@ -85,9 +85,11 @@ static int host1x_parse_dt(struct host1x_drm *host1x)
"nvidia,tegra20-dc",
"nvidia,tegra20-hdmi",
"nvidia,tegra20-gr2d",
+   "nvidia,tegra20-gr3d",
"nvidia,tegra30-dc",
"nvidia,tegra30-hdmi",
"nvidia,tegra30-gr2d",
+   "nvidia,tegra30-gr3d",
};
unsigned int i;
int err;
diff --git a/drivers/gpu/host1x/drm/gr3d.c b/drivers/gpu/host1x/drm/gr3d.c
new file mode 100644
index 000..58fe791
--- /dev/null
+++ b/drivers/gpu/host1x/drm/gr3d.c
@@ -0,0 +1,289 @@
+/*
+ * Copyright (C) 2013 Avionic Design GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "host1x_client.h"
+#include "channel.h"
+#include "drm.h"
+#include "gem.h"
+#include "job.h"
+#include "syncpt.h"
+
+struct

[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
the gr3d engine via the same DRM IOCTLs that gr2d uses. A very basic
set of programs to test this can be found here[0].

Patch 2 adds support for the XBGR format, which seems to be what
most gr3d programs use. It also adds the RGB565 as a format supported
by planes. This latter part could be moved to a separate patch, but I
didn't think that was necessary.

Patch 3 finally allows buffer objects to be marked as tiled so that
the display controller can scan them out appropriately.

Thierry

[0]: https://github.com/organizations/grate-driver

Thierry Reding (3):
  WIP: drm/tegra: Add 3D support
  drm/tegra: Support the XBGR pixelformat
  drm/tegra: Add support for tiled buffer objects

 drivers/gpu/host1x/Makefile   |   1 +
 drivers/gpu/host1x/dev.c  |   7 +
 drivers/gpu/host1x/dev.h  |   1 +
 drivers/gpu/host1x/drm/dc.c   |  16 +++
 drivers/gpu/host1x/drm/dc.h   |   4 +
 drivers/gpu/host1x/drm/drm.c  |   4 +-
 drivers/gpu/host1x/drm/drm.h  |   2 +
 drivers/gpu/host1x/drm/fb.c   |  12 +-
 drivers/gpu/host1x/drm/gem.c  |  20 ++-
 drivers/gpu/host1x/drm/gem.h  |  13 +-
 drivers/gpu/host1x/drm/gr3d.c | 289 ++
 drivers/gpu/host1x/host1x.h   |   3 +-
 include/uapi/drm/tegra_drm.h  |   2 +
 13 files changed, 360 insertions(+), 14 deletions(-)
 create mode 100644 drivers/gpu/host1x/drm/gr3d.c

-- 
1.8.2

[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 ww_mutex *); /* returns -EDEADLK */
> >   int mutex_wait_lock(struct ww_mutex *);  /* does not fail */
> > 
> > Hmm.. thinking about that,.. you only need that second variant because
> > you don't have a clear lock to wait for the 'older' process to
> > complete; but having the unconditional wait makes the entire thing
> > prone to accidents and deadlocks when the 'user' (read your fellow
> > programmers) make a mistake.
> > 
> > Ideally we'd only have the one primitive that returns -EDEADLK and use
> > a 'proper' mutex to wait on or somesuch.. let me ponder this a bit
> > more.
> 
> So I had me a little ponder..

I need to chew some more through this, but figured some early comments to
clarify a few things would be good.

> Its all really about breaking the symmetry (equivalence of both sides)
> of the deadlock. Lets start with the simplest AB-BA deadlock:
> 
>   task-O  task-Y
> A
>   B
>   A <-- blocks on O
> B <-- blocks on Y
> 
> In this case the wound-wait algorithm says that the older task (O) has
> precedence over the younger task (Y) and we'll 'kill' Y to allow
> progress for O.
> 
> Now clearly we don't really want to kill Y, instead we'll allow its
> lock operation to return -EDEADLK.
> 
> This would suggest that our 'new' mutex implementation (ww_mutex
> henceforth) has owner tracking -- so O acquiring B can find Y to 'kill'
> -- and that we have a new wakeup state TASK_DEADLOCK similar to
> TASK_WAKEKILL (can we avoid this by using the extra state required
> below? I don't think so since we'd have the risk of waking Y while it
> would be blocked on a !ww_mutex)

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 immedieately returns -EAGAIN to indicate the deadlock.

Aside, there's a bit of fun in that ttm uses -EDEADLCK for when you try to
reserve the same buffer twice - it can easily detect that by comparing the
lock owner ticket with the provided one and if it matches bail out. The
special error code is useful since userspace could prepare a gpu
batch command submission which lists a buffer twice, which is a userspace
bug with the current drm/gem apis. But since userspace usually doesn't try
to trick the kernel it's better to detect this lazily, and due to the
retry logic we have all the relevant error bail-out code anyway.

Hence we've kept the special -EDEADLCK semantics even for the ww_mutex
stuff.

> Now this gets a little more interesting if we change the scenario a
> little:
> 
>   task-O  task-Y
> A
>   B
> B <-- blocks on Y
>   * <-- could be A

The current code at least simple blocks task-O on B until task-Y unlocks
B. Deadlocks cannot happen since if task-Y ever tries to acquire a lock
which is held by an older task (e.g. lock A) it will bail out with
-EAGAIN.

> 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'll not wait so our
> TASK_DEADLOCK wakeup doesn't actually achieve anything.
> 
> Note that Y doesn't need to acquire A in order to return -EDEADLK, any
> acquisition from the same set (see below) would return -EDEADLK even if
> there isn't an actual deadlock. This is the cost of heuristic; we could
> walk the actual block graph but that would be prohibitively expensive
> since we'd have to do this on every acquire.

Hm, I guess your aim with the TASK_DEADLOCK wakeup is to bound the wait
times of older task. This could be interesting for RT, but I'm unsure of
the implications. 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_mutex it tries to acquire.

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 can't really preempt fairness isn't that high a priority, either.
So we didn't think too much about that.

> This raises the point of what would happen if Y were to acquire a
> 'regular' mutex in between the series of ww_mutexes. In this case we'd
> clearly have an actual deadlock scenario. However lockdep would catch
> this for we'd clearly invert the lock class order:
> 
>

[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  (1 << 20)
   #define RADEON_VA_RESERVED_SIZE  (8 << 20)
 @@ -357,8 +360,9 @@ struct radeon_bo_list {
struct ttm_validate_buffer tv;
struct radeon_bo*bo;
uint64_tgpu_offset;
 -  unsignedrdomain;
 -  unsignedwdomain;
 +  boolwritten;
 +  unsigneddomain;
 +  unsignedalt_domain;
u32 tiling_flags;
   };
>>> I think that the change to the rdomain/wdomain should be in a patch
>>> of its own. I think the change is fine but we had issue with change
>>> that touched that part previously, would make bisecting and
>>> understanding the change implication easier.
>> Agree, I actually planed to do so, but for the whole IP review stuff
>> we needed to maintain a more or less stable patch base. Long story,
>> but I'm going to change it.
>>
 @@ -826,7 +830,6 @@ struct radeon_cs_reloc {
struct radeon_bo*robj;
struct radeon_bo_list   lobj;
uint32_thandle;
 -  uint32_tflags;
   };
>>> Why removing the flags ? iirc it's not really use right now but i
>>> remember plan to use it.
>> Ups, just a rebasing artifact. But when it's unused we should remove
>> it, probably just not in this patch.
>>
 [SNIP]

 +static int radeon_uvd_cs_reloc(struct radeon_cs_parser *p, int data0, int 
 data1)
 +{
 +  struct radeon_cs_chunk *relocs_chunk;
 +  struct radeon_cs_reloc *reloc;
 +  unsigned idx, cmd;
 +  uint64_t start, end;
 +
 +  relocs_chunk = >chunks[p->chunk_relocs_idx];
 +  idx = radeon_get_ib_value(p, data1);
 +  if (idx >= relocs_chunk->length_dw) {
 +  DRM_ERROR("Relocs at %d after relocations chunk end %d !\n",
 +idx, relocs_chunk->length_dw);
 +  return -EINVAL;
 +  }
 +
 +  reloc = p->relocs_ptr[(idx / 4)];
 +  start = reloc->lobj.gpu_offset;
 +  end = start + radeon_bo_size(reloc->robj);
 +  start += radeon_get_ib_value(p, data0);
>>> I am assuming there is no way for you to know the size that the uvd engine 
>>> will write to ?
>>> You are not checking anything on uvd possibly overwritting after the bo end.
>> Yeah that gave me headache for a quite long time, too. The problem
>> is to figure out how much is actually written you need to keep track
>> of the whole lot of informations including the UVD session,
>> create/decode/destroy messages and allot of fiddling with the codec
>> specific parameters.
>>
>> And if I understand the UVD internals correctly even if we check
>> everything there is no guarantee that a special crafted bitstream
>> could not let UVD to write over the end of the buffer
>>
>> Is it ok if we but a big TODO on it for the initial patch?
>>
>> Cheers,
>> Christian.
> I think i only need one assurance and i think for uvd this will be the case.
> If UVD block write past bo end can you be sure that no matter what it will
> overwritte to address > start ie it could not overwritte to begining of VRAM.
>
> I have big doubt on that given the 256M window, i fear that it might go back
> to writting to begining of memory where the page table is.

Crafting an attack from it would still be a bit tricky because it is 
compressed image data that gets written, but never less it is indeed 
possible.

> Note that i think that now that we have cp dma pagetable entry update we can
> probably just move the pagetable to end of vram on 90% GPU with UVD this will
> be > 256M which seems like a zone where UVD can never write.

Well not exactly, it is planned that the 256M limit goes away with some 
of the next hw generations. And at least at this point we need to make 
sure that UVD never writes somewhere it shouldn't. Anyway moving the 
page table to not CPU accessible VRAM sounds like a pretty good idea.

> If we can have such assurance i guess we can make uvd as an option and make
> a very explicit comment stating that UVD engine can be use as an exploit
> vector path.

I think I will just sit down and implement size checking, at least for 
the destination buffer, cause after all that's just a texture. And for 
the reference buffer I maybe just use what userspace send to the 
hardware as buffer size, and make a sanity check on that one also.

Ok, need to think about it a bit more.

> Jerome
>

[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 Pinchart 
> > Reviewed-by: Jani Nikula 
> > ---
> > 
> >  tests/modetest/modetest.c | 41 -
> >  1 file changed, 28 insertions(+), 13 deletions(-)
> > 
> > diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> > index 1d1f49d..91dabfc 100644
> > --- a/tests/modetest/modetest.c
> > +++ b/tests/modetest/modetest.c
> > @@ -908,6 +908,9 @@ static void usage(char *name)
> > 
> > fprintf(stderr, "\t-s 
[@]:[@]\tset
> > a mode\n"); fprintf(stderr, "\t-v\ttest vsynced page flipping\n");
> > 
> > +   fprintf(stderr, "\n Generic options:\n\n");
> > +   fprintf(stderr, "\t-M module\tuse the given driver\n");
> 
> You didn't add it to the "usage: ..." line. Same goes for patch 05/21.

Good catch, thanks. I'll fix that.

-- 
Regards,

Laurent Pinchart

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

https://bugs.freedesktop.org/show_bug.cgi?id=63124

--- Comment #2 from abortretryfail at 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.
-- next part --
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

https://bugs.freedesktop.org/show_bug.cgi?id=63124

--- Comment #1 from abortretryfail at 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-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/20130404/29e0fa56/attachment.html>

[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 at lists.freedesktop.org
   Summary: [r600g] HyperZ lockup on REDWOOD in Half Life 2
Deathmatch
  Severity: major
Classification: Unclassified
OS: Linux (All)
  Reporter: abortretryfail at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/DRI/R600
   Product: Mesa

Created attachment 77426
  --> https://bugs.freedesktop.org/attachment.cgi?id=77426=edit
dmesg output from when the GPU resets. This keeps happening until the game is
killed or you look away from whatever is causing the lockup.

This might be related to bug #61721, as it also occurs on my machine.

When playing Half Life 2 Deathmatch, the game runs great until certain scenes
cause a GPU lockup.

When run with R600_DEBUG=nohyperz there's no lockup, but performance is much
slower. (from ~85fps vsync 1400x1050 down to ~45fps w/o HyperZ)

I'll see if I can get an apitrace tonight.

-- 
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/9ef83b4d/attachment.html>

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

2013-04-04 Thread George Amanakis

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 4.7.2 
(GCC) ) #1 SMP PREEMPT Thu Apr 4 23:09:36 CEST 2013
[??? 0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-linux-mine 
root=/dev/mapper/lvmvolume-root ro init=/usr/lib/systemd/systemd acpi_osi=Linux
[??? 0.00] Disabled fast string operations
[??? 0.00] e820: BIOS-provided physical RAM map:
[??? 0.00] BIOS-e820: [mem 0x-0x0009abff] usable
[??? 0.00] BIOS-e820: [mem 0x0009ac00-0x0009] reserved
[??? 0.00] BIOS-e820: [mem 0x000d6000-0x000d7fff] reserved
[??? 0.00] BIOS-e820: [mem 0x000dc000-0x000f] reserved
[??? 0.00] BIOS-e820: [mem 0x0010-0x794a0fff] usable
[??? 0.00] BIOS-e820: [mem 0x794a1000-0x794a6fff] reserved
[??? 0.00] BIOS-e820: [mem 0x794a7000-0x795b6fff] usable
[??? 0.00] BIOS-e820: [mem 0x795b7000-0x7960efff] reserved
[??? 0.00] BIOS-e820: [mem 0x7960f000-0x796c5fff] usable
[??? 0.00] BIOS-e820: [mem 0x796c6000-0x796d0fff] ACPI NVS
[??? 0.00] BIOS-e820: [mem 0x796d1000-0x796d3fff] ACPI data
[??? 0.00] BIOS-e820: [mem 0x796d4000-0x796d7fff] reserved
[??? 0.00] BIOS-e820: [mem 0x796d8000-0x796dbfff] ACPI NVS
[??? 0.00] BIOS-e820: [mem 0x796dc000-0x796defff] reserved
[??? 0.00] BIOS-e820: [mem 0x796df000-0x79705fff] ACPI NVS
[??? 0.00] BIOS-e820: [mem 0x79706000-0x79707fff] ACPI data
[??? 0.00] BIOS-e820: [mem 0x79708000-0x7990efff] reserved
[??? 0.00] BIOS-e820: [mem 0x7990f000-0x7999efff] ACPI NVS
[??? 0.00] BIOS-e820: [mem 0x7999f000-0x799fefff] ACPI data
[??? 0.00] BIOS-e820: [mem 0x799ff000-0x799f] usable
[??? 0.00] BIOS-e820: [mem 0x79c0-0x7bff] reserved
[??? 0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[??? 0.00] BIOS-e820: [mem 0xfec0-0xfec0] reserved
[??? 0.00] BIOS-e820: [mem 0xfed0-0xfed003ff] reserved
[??? 0.00] BIOS-e820: [mem 0xfed1-0xfed13fff] reserved
[??? 0.00] BIOS-e820: [mem 0xfed18000-0xfed19fff] reserved
[??? 0.00] BIOS-e820: [mem 0xfed1c000-0xfed8] reserved
[??? 0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[??? 0.00] BIOS-e820: [mem 0xff80-0x] reserved
[??? 0.00] NX (Execute Disable) protection: active
[??? 0.00] SMBIOS 2.4 present.
[??? 0.00] DMI: LENOVO 74585LG/74585LG, BIOS 6DET72WW (3.22 ) 10/25/2012
[??? 0.00] e820: update [mem 0x-0x] usable ==> reserved
[??? 0.00] e820: remove [mem 0x000a-0x000f] usable
[??? 0.00] No AGP bridge found
[??? 0.00] e820: last_pfn = 0x79a00 max_arch_pfn = 0x4
[??? 0.00] MTRR default type: uncachable
[??? 0.00] MTRR fixed ranges enabled:
[??? 0.00]?? 0-9 write-back
[??? 0.00]?? A-B uncachable
[??? 0.00]?? C-D7FFF write-protect
[??? 0.00]?? D8000-DBFFF uncachable
[??? 0.00]?? DC000-F write-protect
[??? 0.00] MTRR variable ranges enabled:
[??? 0.00]?? 0 base 07D00 mask FFF00 uncachable
[??? 0.00]?? 1 base 07E00 mask FFE00 uncachable
[??? 0.00]?? 2 base 0 mask F8000 write-back
[??? 0.00]?? 3 base 079E0 mask FFFE0 uncachable
[??? 0.00]?? 4 disabled
[??? 0.00]?? 5 disabled
[??? 0.00]?? 6 disabled
[??? 0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[??? 0.00] e820: update [mem 0x79e0-0x79ff] usable ==> reserved
[??? 0.00] found SMP MP-table at [mem 0x000f72d0-0x000f72df] mapped at 
[880f72d0]
[??? 0.00] initial memory mapped: [mem 0x-0x1fff]
[??? 0.00] Base memory trampoline at [88094000] 94000 size 24576
[??? 0.00] init_memory_mapping: [mem 0x-0x799f]
[??? 0.00]? [mem 0x-0x799f] page 2M
[??? 0.00] kernel direct mapping tables up to 0x799f @ [mem 
0x1fffd000-0x1fff]
[??? 0.00] RAMDISK: [mem 0x378aa000-0x37c4cfff]
[??? 0.00] ACPI: RSDP 000f7290 00024 (v02 LENOVO)
[??? 0.00] ACPI: XSDT 7995b712 0009C (v01 LENOVO TP-6D??? 3220? 
LTP )
[??? 0.00] ACPI: FACP 7995b800 000F4 (v03 LENOVO TP-6D??? 3220 
LNVO 0001)
[??? 0.00] ACPI: DSDT 7995bbf4 0DF43 (v01 LENOVO TP-6D??? 3220 
MSFT 0300)
[??? 0.00] ACPI: FACS 7998e000

[PATCHv2 0/5] videomode patches

2013-04-04 Thread Tomi Valkeinen

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
> 
> Tomi Valkeinen (5):
>   videomode: simplify videomode Kconfig and Makefile
>   videomode: combine videomode dmt_flags and data_flags
>   videomode: create enum for videomode's display flags
>   videomode: remove timing_entry_index
>   videomode: videomode_from_timing work
> 
>  drivers/gpu/drm/drm_modes.c   |   20 ++--
>  drivers/gpu/drm/tilcdc/Kconfig|3 +-
>  drivers/gpu/drm/tilcdc/tilcdc_panel.c |2 +-
>  drivers/video/Kconfig |   22 ++---
>  drivers/video/Makefile|8 ++---
>  drivers/video/fbmon.c |   16 -
>  drivers/video/of_display_timing.c |   19 ++-
>  drivers/video/of_videomode.c  |2 +-
>  drivers/video/videomode.c |   36 -
>  include/video/display_timing.h|   57 
> ++---
>  include/video/videomode.h |   18 ---
>  11 files changed, 88 insertions(+), 115 deletions(-)
> 

If there are no objections, I can merge this through fbdev tree.

 Tomi


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

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

2013-04-04 Thread Paul Menzel

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 chipset generations are currently not supported, but 
> might be added in the future.
> 
> The newest firmware can be found here: from 
> http://people.freedesktop.org/~agd5f/radeon_ucode/
> 
> A matching patch implementing the necessary userspace side will follow in 
> just a minute on the mesa devel list.

The patches for Mesa 3D can be found at [1]. Thanks!

Christian, could you add instructions how to best test these patches,
please.

Additionally could you contact distributions to provide testing packages
for easy testing.


Thanks,

Paul


[1] http://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/archives/dri-devel/attachments/20130404/443a0192/attachment.pgp>

[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 *);  /* does not fail */
> 
> Hmm.. thinking about that,.. you only need that second variant because
> you don't have a clear lock to wait for the 'older' process to
> complete; but having the unconditional wait makes the entire thing
> prone to accidents and deadlocks when the 'user' (read your fellow
> programmers) make a mistake.
> 
> Ideally we'd only have the one primitive that returns -EDEADLK and use
> a 'proper' mutex to wait on or somesuch.. let me ponder this a bit
> more.

So I had me a little ponder..

Its all really about breaking the symmetry (equivalence of both sides)
of the deadlock. Lets start with the simplest AB-BA deadlock:

task-O  task-Y
  A
B
A <-- blocks on O
  B <-- blocks on Y

In this case the wound-wait algorithm says that the older task (O) has
precedence over the younger task (Y) and we'll 'kill' Y to allow
progress for O.

Now clearly we don't really want to kill Y, instead we'll allow its
lock operation to return -EDEADLK.

This would suggest that our 'new' mutex implementation (ww_mutex
henceforth) has owner tracking -- so O acquiring B can find Y to 'kill'
-- and that we have a new wakeup state TASK_DEADLOCK similar to
TASK_WAKEKILL (can we avoid this by using the extra state required
below? I don't think so since we'd have the risk of waking Y while it
would be blocked on a !ww_mutex)

Now this gets a little more interesting if we change the scenario a
little:

task-O  task-Y
  A
B
  B <-- blocks on Y
* <-- could be A

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'll not wait so our
TASK_DEADLOCK wakeup doesn't actually achieve anything.

Note that Y doesn't need to acquire A in order to return -EDEADLK, any
acquisition from the same set (see below) would return -EDEADLK even if
there isn't an actual deadlock. This is the cost of heuristic; we could
walk the actual block graph but that would be prohibitively expensive
since we'd have to do this on every acquire.

This raises the point of what would happen if Y were to acquire a
'regular' mutex in between the series of ww_mutexes. In this case we'd
clearly have an actual deadlock scenario. However lockdep would catch
this for we'd clearly invert the lock class order:

ww_mutex -> other -> ww_mutex

For the more complex scenarios there's the case of multiple waiters. In
this case its desirable to order the waiters in age order so that we
don't introduce age inversion -- this minimizes the amount of -EDEADLK
occurrences, but also allows doing away with the unconditional wait.

With the lock queue ordering we can simply immediately re-try the lock
acquisition sequence. Since the older task is already queued it will
obtain the lock, even if we re-queue ourselves before the lock is
assigned.

Now the one thing I've so far 'ignored' is how to assign age. Forward
progress guarantees demand that the age doesn't get reset on retries;
doing so would mean you're always pushing yourself fwd, decreasing your
'priority', never getting to be the most eligible. However it also
means that we should (re)set the time every time we start a 'new'
acquisition sequence. If we'd use a static (per task) age the task with
the lowest age would be able to 'starve' all other.

This means we need means to mark the start of an acquisition sequence;
one that is not included in the restart loop.

Having a start suggests having an end marker too, and indeed we can
find a reason for having one; suppose our second scenario above, where
Y has already acquired all locks it needs to proceed. In this case we
would have marked Y to fail on another acquisition. This doesn't seem
like a problem until you consider the case where we nest different
mm_mutex sets. In this case Y would -EDEADLK on the first of the second
(nested) set, even though re-trying that set is pointless, O doesn't
care.

Furthermore, considering the first scenario, O could block on a lock of
the first set when Y is blocked on a lock of the second (nested) set;
we need means of discerning the different lock sets. This cannot be
done by local means, that is, any context created by the start/end
markers would be local to that task and would not be recognizable by
another as to belong to the same group.

Instead we'd need to create a set-class, much like lockdep has and
somehow ensure all locks in a set are of that class.

One thing I'm not entirely sure of is the strict need for a local
context it

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

2013-04-04 Thread Alex Deucher

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 
> ---



> diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
> b/drivers/gpu/drm/radeon/radeon_uvd.c
> new file mode 100644
> index 000..8ab7bb9
> --- /dev/null
> +++ b/drivers/gpu/drm/radeon/radeon_uvd.c
> @@ -0,0 +1,521 @@
> +/*
> + * Copyright 2011 Advanced Micro Devices, Inc.
> + * All Rights Reserved.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the
> + * "Software"), to deal in the Software without restriction, including
> + * without limitation the rights to use, copy, modify, merge, publish,
> + * distribute, sub license, and/or sell copies of the Software, and to
> + * permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
> + * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY 
> CLAIM,
> + * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> + * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
> + * USE OR OTHER DEALINGS IN THE SOFTWARE.
> + *
> + * The above copyright notice and this permission notice (including the
> + * next paragraph) shall be included in all copies or substantial portions
> + * of the Software.
> + *
> + */
> +/*
> + * Authors:
> + *Christian K?nig 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "radeon.h"
> +#include "r600d.h"
> +
> +/* Firmware Names */
> +#define FIRMWARE_RV770 "radeon/RV770_uvd.bin"
> +#define FIRMWARE_RV710 "radeon/RV710_uvd.bin"
> +#define FIRMWARE_CYPRESS   "radeon/CYPRESS_uvd.bin"
> +#define FIRMWARE_SUMO  "radeon/SUMO_uvd.bin"
> +#define FIRMWARE_TAHITI"radeon/TAHITI_uvd.bin"
> +
> +MODULE_FIRMWARE(FIRMWARE_RV770);
> +MODULE_FIRMWARE(FIRMWARE_RV710);
> +MODULE_FIRMWARE(FIRMWARE_CYPRESS);
> +MODULE_FIRMWARE(FIRMWARE_SUMO);
> +MODULE_FIRMWARE(FIRMWARE_TAHITI);
> +
> +int radeon_uvd_init(struct radeon_device *rdev)
> +{
> +   struct platform_device *pdev;
> +   unsigned long bo_size;
> +   const char *fw_name;
> +   int i, r;
> +
> +   pdev = platform_device_register_simple("radeon_uvd", 0, NULL, 0);
> +   r = IS_ERR(pdev);
> +   if (r) {
> +   dev_err(rdev->dev, "radeon_uvd: Failed to register 
> firmware\n");
> +   return -EINVAL;
> +   }
> +
> +   switch (rdev->family) {
> +   case CHIP_RV770:
> +   fw_name = FIRMWARE_RV770;
> +   break;
> +
> +   case CHIP_RV710:
> +   case CHIP_RV730:
> +   case CHIP_RV740:
> +   fw_name = FIRMWARE_RV710;
> +   break;
> +
> +   case CHIP_CYPRESS:

We are missing CHIP_HEMLOCK here.

Alex

> +   case CHIP_JUNIPER:
> +   case CHIP_REDWOOD:
> +   case CHIP_CEDAR:
> +   fw_name = FIRMWARE_CYPRESS;
> +   break;
> +
> +   case CHIP_SUMO:
> +   case CHIP_SUMO2:
> +   case CHIP_PALM:
> +   case CHIP_CAYMAN:
> +   case CHIP_BARTS:
> +   case CHIP_TURKS:
> +   case CHIP_CAICOS:
> +   fw_name = FIRMWARE_SUMO;
> +   break;
> +
> +   case CHIP_TAHITI:
> +   case CHIP_VERDE:
> +   case CHIP_PITCAIRN:
> +   case CHIP_ARUBA:
> +   fw_name = FIRMWARE_TAHITI;
> +   break;
> +
> +   default:
> +   return -EINVAL;
> +   }

[Bug 57567] 3.7 radeonfb broken on efivga screens

https://bugs.freedesktop.org/show_bug.cgi?id=57567

Alex Deucher  changed:

   What|Removed |Added

  Attachment #77407|text/plain  |image/jpeg
  mime type||

-- 
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 declaration
 - added __exitcall for dma_buf_deinit()

changes since v1:
 - fixes on init and warnings as reported and corrected by Dave Airlie.
 - add locking while walking attachment list - reported by Daniel Vetter.
---
 drivers/base/dma-buf.c  |  159 +++
 include/linux/dma-buf.h |5 +-
 2 files changed, 163 insertions(+), 1 deletion(-)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index d89102a..466476f 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -27,9 +27,18 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 static inline int is_dma_buf_file(struct file *);

+struct dma_buf_list {
+   struct list_head head;
+   struct mutex lock;
+};
+
+static struct dma_buf_list db_list;
+
 static int dma_buf_release(struct inode *inode, struct file *file)
 {
struct dma_buf *dmabuf;
@@ -42,6 +51,11 @@ static int dma_buf_release(struct inode *inode, struct file 
*file)
BUG_ON(dmabuf->vmapping_counter);

dmabuf->ops->release(dmabuf);
+
+   mutex_lock(_list.lock);
+   list_del(>list_node);
+   mutex_unlock(_list.lock);
+
kfree(dmabuf);
return 0;
 }
@@ -125,6 +139,10 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
struct dma_buf_ops *ops,
mutex_init(>lock);
INIT_LIST_HEAD(>attachments);

+   mutex_lock(_list.lock);
+   list_add(>list_node, _list.head);
+   mutex_unlock(_list.lock);
+
return dmabuf;
 }
 EXPORT_SYMBOL_GPL(dma_buf_export_named);
@@ -551,3 +569,144 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
mutex_unlock(>lock);
 }
 EXPORT_SYMBOL_GPL(dma_buf_vunmap);
+
+#ifdef CONFIG_DEBUG_FS
+static int dma_buf_describe(struct seq_file *s)
+{
+   int ret;
+   struct dma_buf *buf_obj;
+   struct dma_buf_attachment *attach_obj;
+   int count = 0, attach_count;
+   size_t size = 0;
+
+   ret = mutex_lock_interruptible(_list.lock);
+
+   if (ret)
+   return ret;
+
+   seq_printf(s, "\nDma-buf Objects:\n");
+   seq_printf(s, "\texp_name\tsize\tflags\tmode\tcount\n");
+
+   list_for_each_entry(buf_obj, _list.head, list_node) {
+   ret = mutex_lock_interruptible(_obj->lock);
+
+   if (ret) {
+   seq_printf(s,
+ "\tERROR locking buffer object: skipping\n");
+   goto skip_buffer;
+   }
+
+   seq_printf(s, "\t");
+
+   seq_printf(s, "\t%s\t%08zu\t%08x\t%08x\t%08d\n",
+   buf_obj->exp_name, buf_obj->size,
+   buf_obj->file->f_flags, buf_obj->file->f_mode,
+   buf_obj->file->f_count.counter);
+
+   seq_printf(s, "\t\tAttached Devices:\n");
+   attach_count = 0;
+
+   list_for_each_entry(attach_obj, _obj->attachments, node) {
+   seq_printf(s, "\t\t");
+
+   seq_printf(s, "%s\n", attach_obj->dev->init_name);
+   attach_count++;
+   }
+
+   seq_printf(s, "\n\t\tTotal %d devices attached\n",
+   attach_count);
+
+   count++;
+   size += buf_obj->size;
+skip_buffer:
+   mutex_unlock(_obj->lock);
+   }
+
+   seq_printf(s, "\nTotal %d objects, %zu bytes\n", count, size);
+
+   mutex_unlock(_list.lock);
+   return 0;
+}
+
+static int dma_buf_show(struct seq_file *s, void *unused)
+{
+   void (*func)(struct seq_file *) = s->private;
+   func(s);
+   return 0;
+}
+
+static int dma_buf_debug_open(struct inode *inode, struct file *file)
+{
+   return single_open(file, dma_buf_show, inode->i_private);
+}
+
+static const struct file_operations dma_buf_debug_fops = {
+   .open   = dma_buf_debug_open,
+   .read   = seq_read,
+   .llseek = seq_lseek,
+   .release= single_release,
+};
+
+static struct dentry *dma_buf_debugfs_dir;
+
+static int dma_buf_init_debugfs(void)
+{
+   int err = 0;
+   dma_buf_debugfs_dir = debugfs_create_dir("dma_buf", NULL);
+   if (IS_ERR(dma_buf_debugfs_dir)) {
+   err = PTR_ERR(dma_buf_debugfs_dir);
+   dma_buf_debugfs_dir = NULL;
+   return err;
+   }
+
+   err = dma_buf_debugfs_create_file("bufinfo", dma_buf_describe);
+
+   if (err)
+   pr_debug("dma_buf: debugfs: failed to create node bufinfo\n");
+
+   return err;
+}
+
+static void dma_buf_uninit_debugfs(void)
+{
+   if (dma_buf_debugfs_dir)
+

[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 #define dma_buf_export() is also made available,
which adds a __FILE__ instead of 'exp_name'.

Cc: Daniel Vetter 
  [Thanks for the idea!]
Reviewed-by: Daniel Vetter 
Signed-off-by: Sumit Semwal 
---
 Documentation/dma-buf-sharing.txt |   13 +++--
 drivers/base/dma-buf.c|   11 +++
 include/linux/dma-buf.h   |   11 +--
 3 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/Documentation/dma-buf-sharing.txt 
b/Documentation/dma-buf-sharing.txt
index 4966b1b..0b23261 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -52,14 +52,23 @@ The dma_buf buffer sharing API usage contains the following 
steps:
associated with this buffer.

Interface:
-  struct dma_buf *dma_buf_export(void *priv, struct dma_buf_ops *ops,
-size_t size, int flags)
+  struct dma_buf *dma_buf_export_named(void *priv, struct dma_buf_ops *ops,
+size_t size, int flags,
+const char *exp_name)

If this succeeds, dma_buf_export allocates a dma_buf structure, and returns 
a
pointer to the same. It also associates an anonymous file with this buffer,
so it can be exported. On failure to allocate the dma_buf object, it returns
NULL.

+   'exp_name' is the name of exporter - to facilitate information while
+   debugging.
+
+   Exporting modules which do not wish to provide any specific name may use the
+   helper define 'dma_buf_export()', with the same arguments as above, but
+   without the last argument; a __FILE__ pre-processor directive will be
+   inserted in place of 'exp_name' instead.
+
 2. Userspace gets a handle to pass around to potential buffer-users

Userspace entity requests for a file-descriptor (fd) which is a handle to 
the
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 2a7cb0d..d89102a 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -77,22 +77,24 @@ static inline int is_dma_buf_file(struct file *file)
 }

 /**
- * dma_buf_export - Creates a new dma_buf, and associates an anon file
+ * dma_buf_export_named - Creates a new dma_buf, and associates an anon file
  * with this buffer, so it can be exported.
  * Also connect the allocator specific data and ops to the buffer.
+ * Additionally, provide a name string for exporter; useful in debugging.
  *
  * @priv:  [in]Attach private data of allocator to this buffer
  * @ops:   [in]Attach allocator-defined dma buf ops to the new buffer.
  * @size:  [in]Size of the buffer
  * @flags: [in]mode flags for the file.
+ * @exp_name:  [in]name of the exporting module - useful for debugging.
  *
  * Returns, on success, a newly created dma_buf object, which wraps the
  * supplied private data and operations for dma_buf_ops. On either missing
  * ops, or error in allocating struct dma_buf, will return negative error.
  *
  */
-struct dma_buf *dma_buf_export(void *priv, const struct dma_buf_ops *ops,
-   size_t size, int flags)
+struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops *ops,
+   size_t size, int flags, const char *exp_name)
 {
struct dma_buf *dmabuf;
struct file *file;
@@ -114,6 +116,7 @@ struct dma_buf *dma_buf_export(void *priv, const struct 
dma_buf_ops *ops,
dmabuf->priv = priv;
dmabuf->ops = ops;
dmabuf->size = size;
+   dmabuf->exp_name = exp_name;

file = anon_inode_getfile("dmabuf", _buf_fops, dmabuf, flags);

@@ -124,7 +127,7 @@ struct dma_buf *dma_buf_export(void *priv, const struct 
dma_buf_ops *ops,

return dmabuf;
 }
-EXPORT_SYMBOL_GPL(dma_buf_export);
+EXPORT_SYMBOL_GPL(dma_buf_export_named);


 /**
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 9978b61..6f55c04 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -112,6 +112,7 @@ struct dma_buf_ops {
  * @file: file pointer used for sharing buffers across, and for refcounting.
  * @attachments: list of dma_buf_attachment that denotes all devices attached.
  * @ops: dma_buf_ops associated with this buffer object.
+ * @exp_name: name of the exporter; useful for debugging.
  * @priv: exporter specific private data for this buffer object.
  */
 struct dma_buf {
@@ -123,6 +124,7 @@ struct dma_buf {
struct mutex lock;
unsigned vmapping_counter;
void *vmap_ptr;
+   const char *exp_name;
void *priv;
 };

@@ -162,8 +164,13 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
*dmabuf,

[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 debugging, but we'll leave that
for the time being.

Best regards,
~Sumit.

---
changes since v2: (based on review comments from Laurent Pinchart)
 - reordered functions to avoid forward declaration
 - added __exitcall for dma_buf_deinit()

changes since v1:
 - added patch to replace dma_buf_export() with dma_buf_export_named(), per
suggestion from Daniel Vetter.
 - fixes on init and warnings as reported and corrected by Dave Airlie.
 - added locking while walking attachment list - reported by Daniel Vetter.

Sumit Semwal (2):
  dma-buf: replace dma_buf_export() with dma_buf_export_named()
  dma-buf: Add debugfs support

 Documentation/dma-buf-sharing.txt |   13 ++-
 drivers/base/dma-buf.c|  170 -
 include/linux/dma-buf.h   |   16 +++-
 3 files changed, 190 insertions(+), 9 deletions(-)

-- 
1.7.10.4

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

2013-04-04 Thread Yinghai Lu

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.
>>
>> Only user is ACPI_INITRD_TABLE_OVERRIDE, and it should not use that,
>> as later accessing is using early_ioremap(). Change to try to 4G below
>> and then 4G above.
> ...
>> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
>> index 586e7e9..c08cdb6 100644
>> --- a/drivers/acpi/osl.c
>> +++ b/drivers/acpi/osl.c
>> @@ -624,9 +624,13 @@ void __init acpi_initrd_override(void *data, size_t 
>> size)
>>   if (table_nr == 0)
>>   return;
>>
>> - acpi_tables_addr =
>> - memblock_find_in_range(0, max_low_pfn_mapped << PAGE_SHIFT,
>> -all_tables_size, PAGE_SIZE);
>> + /* under 4G at first, then above 4G */
>> + acpi_tables_addr = memblock_find_in_range(0, (1ULL<<32) - 1,
>> + all_tables_size, PAGE_SIZE);
>> + if (!acpi_tables_addr)
>> + acpi_tables_addr = memblock_find_in_range(0,
>> + ~(phys_addr_t)0,
>> + all_tables_size, PAGE_SIZE);
>
> So, it's changing the allocation from <=4G to <=4G first and then >4G.
> The only explanation given is "as later accessing is using
> early_ioremap()", but I can't see why that can be a reason for that.
> early_ioremap() doesn't care whether the given physaddr is under 4G or
> not, it unconditionally maps it into fixmap, so whether the allocated
> address is below or above 4G doesn't make any difference.
>
> Changing the allowed range of the allocation should be a separate
> patch.  It has some chance of its own breakage and the change itself
> isn't really related to this one.

Ok, will separate that  "try above 4G" to another patch.

>
> Please try to elaborate the reasoning behind "why", so that readers of
> the description don't have to deduce (oh well, guess) your intentions
> behind the changes.  As much as it would help the readers, it'd also
> help you even more as you would have had to explicitly write something
> like "the table is accessed with early_ioremap() so the address
> doesn't need to be restricted under 4G; however, to avoid unnecessary
> remappings, first try <= 4G and then > 4G."  Then, you would be
> compelled to check whether the statement you explicitly wrote is true,
> which isn't in this case and you would also realize that the change
> isn't trivial and doesn't really belong with this patch.  By not doing
> the due diligence, you're offloading what you should have done to
> others, which isn't very nice.
>
> I think the descriptions are better in this posting than the last time
> but it's still lacking, so, please putfff more effort into describing
> the changes and reasoning behind them.

ok.

Thanks a lot.

Yinghai

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 dilema regarding tiling on radeonsi. Given that we
>> now have a fixed table of tiling mode this put more pressure on the
>> kernel userspace api. I see either 2 solutions.
>>
>>
>> Enforce kernel to set at fixed index in the table best tiling mode for
>> given gpu for given format, such as DEPTH32_2D_4AA at index 4, or
>> COLOR_SCANOUT_2D at index 13 ... that way kernel can still adapt the
>> tile mode array value. Note that this match the design behind the tile
>> mode index being that there is a limited number of useful tile mode
>> combination and for each surface format  (depth/color/macro
>> tile/micro/tile) there is a best one.
>>
>>
>> Second solution is to add an ioctl to compute mipmap information in
>> kernel (pitch alignment slice size ...) based on format, size of the
>> surface.
>>
>>
>> Some might argue that we could just export the table content to
>> userspace, but that would loose information and possibly froze the
>> tile mode table forever as API. The information we loose is what index
>> match to prefered surface format/type combination. And the tile mode
>> might be considered API as if kernel ever change what userspace expect
>> then we might break some userspace.
>>
>> Maybe I'm missing the problem, but if libdrm_radeon were to get the
>> tiling mode index chosen by radeonsi, and could retrieve the tiling
>> parameters for each index from the kernel, it should be able to
>> calculate things properly, shouldn't it?
>>
>>
>> Let's not discuss about who/where the index is pick. No matter where it
>> happens the question is do we want to hardcode tile index and make it api
>> or do we want to hide it behind symbolic name allowing change in tile array
>> (given that right now 4 value are already frozen). You can look at my
>> kernel patch to see what i mean.
>>
>>
>> Just as a side node: If I understood it correctly the hardware isn't
>> completely capable to use those indexes interchangeable, e.g. only a certain
>> range can be used for the DB, and another rule matters for AA indexes etc
>>
>> I don't know those rules exactly and I don't know how strict they are, but
>> as far as I understood it even the closed source driver didn't need to mess
>> with it. So I'm something like 90% sure that hardcoding them is ok, but well
>> on the other hand it just doesn't feels good to do so...
> The DB_[Z|STENCIL]_INFO.TILE_MODE_INDEX is only 3 bits so all of the
> depth formats have to be within the first 8 slots.  The CB and texture
> blocks support 5 bits for the index.  That's why the indices are laid
> out like they are with the depth formats first.

Well, that makes sense. I just read on some internal docs that the DB 
unit can only use certain indexes, but they not mentioned why.

Thanks for the explanation,
Christian.

> Alex
>
>> Christian.
>>
>> Cheers,
>> Jerome
>>
>>
>>
>> ___
>> 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
>>

[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 
support at all, no UVD support for this hardware generation or UVD just 
failed to initialize.

Currently we just don't handle the return code so well in mesa (feel 
free to fix that).

Christian.


> Then we could check for UVD in userspace [1]
>
> Thanks for the great work!
>
> Andreas.
>
> [1] http://lists.freedesktop.org/archives/mesa-dev/2013-April/037089.html
>
>
> 2013/4/3 Christian K?nig 
>
>> Hi everyone,
>>
>> the following patchset implements the kernel side of UVD support for the
>> radeon hardware generations RV710-SI.
>>
>> The R6xx and RS780/RS880 chipset generations are currently not supported,
>> but might be added in the future.
>>
>> The newest firmware can be found here: from
>> http://people.freedesktop.org/~agd5f/radeon_ucode/
>>
>> A matching patch implementing the necessary userspace side will follow in
>> just a minute on the mesa devel list.
>>
>> Cheers,
>> Christian.
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>

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

2013-04-04 Thread Tejun Heo

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 use that,
> as later accessing is using early_ioremap(). Change to try to 4G below
> and then 4G above.
...
> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> index 586e7e9..c08cdb6 100644
> --- a/drivers/acpi/osl.c
> +++ b/drivers/acpi/osl.c
> @@ -624,9 +624,13 @@ void __init acpi_initrd_override(void *data, size_t size)
>   if (table_nr == 0)
>   return;
>  
> - acpi_tables_addr =
> - memblock_find_in_range(0, max_low_pfn_mapped << PAGE_SHIFT,
> -all_tables_size, PAGE_SIZE);
> + /* under 4G at first, then above 4G */
> + acpi_tables_addr = memblock_find_in_range(0, (1ULL<<32) - 1,
> + all_tables_size, PAGE_SIZE);
> + if (!acpi_tables_addr)
> + acpi_tables_addr = memblock_find_in_range(0,
> + ~(phys_addr_t)0,
> + all_tables_size, PAGE_SIZE);

So, it's changing the allocation from <=4G to <=4G first and then >4G.
The only explanation given is "as later accessing is using
early_ioremap()", but I can't see why that can be a reason for that.
early_ioremap() doesn't care whether the given physaddr is under 4G or
not, it unconditionally maps it into fixmap, so whether the allocated
address is below or above 4G doesn't make any difference.

Changing the allowed range of the allocation should be a separate
patch.  It has some chance of its own breakage and the change itself
isn't really related to this one.

Please try to elaborate the reasoning behind "why", so that readers of
the description don't have to deduce (oh well, guess) your intentions
behind the changes.  As much as it would help the readers, it'd also
help you even more as you would have had to explicitly write something
like "the table is accessed with early_ioremap() so the address
doesn't need to be restricted under 4G; however, to avoid unnecessary
remappings, first try <= 4G and then > 4G."  Then, you would be
compelled to check whether the statement you explicitly wrote is true,
which isn't in this case and you would also realize that the change
isn't trivial and doesn't really belong with this patch.  By not doing
the due diligence, you're offloading what you should have done to
others, which isn't very nice.

I think the descriptions are better in this posting than the last time
but it's still lacking, so, please putfff more effort into describing
the changes and reasoning behind them.

Thanks.

-- 
tejun

[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 a/drivers/gpu/drm/radeon/radeon_kms.c 
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index c75cb2c..8076434 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -176,80 +176,65 @@ int radeon_info_ioctl(struct drm_device *dev, void 
> *data, struct drm_file *filp)
> struct radeon_device *rdev = dev->dev_private;
> struct drm_radeon_info *info = data;
> struct radeon_mode_info *minfo = >mode_info;
> -   uint32_t value, *value_ptr;
> -   uint64_t value64, *value_ptr64;
> +   uint32_t *value, value_tmp, *value_ptr, value_size;
> +   uint64_t value64;
> struct drm_crtc *crtc;
> int i, found;
>  
> -   /* TIMESTAMP is a 64-bit value, needs special handling. */
> -   if (info->request == RADEON_INFO_TIMESTAMP) {
> -   if (rdev->family >= CHIP_R600) {
> -   value_ptr64 = (uint64_t*)((unsigned long)info->value);
> -   value64 = radeon_get_gpu_clock_counter(rdev);
> -
> -   if (DRM_COPY_TO_USER(value_ptr64, , 
> sizeof(value64))) {
> -   DRM_ERROR("copy_to_user %s:%u\n", __func__, 
> __LINE__);
> -   return -EFAULT;
> -   }
> -   return 0;
> -   } else {
> -   DRM_DEBUG_KMS("timestamp is r6xx+ only!\n");
> -   return -EINVAL;
> -   }
> -   }
> -
> value_ptr = (uint32_t *)((unsigned long)info->value);
> -   if (DRM_COPY_FROM_USER(, value_ptr, sizeof(value))) {
> -   DRM_ERROR("copy_from_user %s:%u\n", __func__, __LINE__);
> -   return -EFAULT;
> -   }
> +   value = _tmp;
> +   value_size = sizeof(uint32_t);

[...]

> +   case RADEON_INFO_TIMESTAMP:
> +   if (rdev->family < CHIP_R600) {
> +   DRM_DEBUG_KMS("timestamp is r6xx+ only!\n");
> +   return -EINVAL;
> +   }
> +   value = (uint32_t*)
> +   value_size = sizeof(uint64_t);
> +   value64 = radeon_get_gpu_clock_counter(rdev);
> +   break;

[...]

> -   if (DRM_COPY_TO_USER(value_ptr, , sizeof(uint32_t))) {
> +   if (DRM_COPY_TO_USER(value_ptr, value, value_size)) {
> DRM_ERROR("copy_to_user %s:%u\n", __func__, __LINE__);
> return -EFAULT;
> }

Are these changes safe wrt strict aliasing? Might be safer to use char*
for the second argument passed to DRM_COPY_TO_USER. 

-- 
Earthling Michel D?nzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer

[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 files changed, 709 insertions(+), 45 deletions(-)
> 
> diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
> index 00d66b3..ff3ce3a 100644
> --- a/include/drm/radeon_drm.h
> +++ b/include/drm/radeon_drm.h
> @@ -509,6 +509,7 @@ typedef struct {
>  #define DRM_RADEON_GEM_SET_TILING  0x28
>  #define DRM_RADEON_GEM_GET_TILING  0x29
>  #define DRM_RADEON_GEM_BUSY0x2a
> +#define DRM_RADEON_GEM_VA  0x2b
>  
>  #define DRM_IOCTL_RADEON_CP_INITDRM_IOW( DRM_COMMAND_BASE + 
> DRM_RADEON_CP_INIT, drm_radeon_init_t)
>  #define DRM_IOCTL_RADEON_CP_START   DRM_IO(  DRM_COMMAND_BASE + 
> DRM_RADEON_CP_START)

Changes which aren't related to SI tiling should go in separate patches.


> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
> index 5935c23..dfdcbbc 100644
> --- a/radeon/radeon_surface.c
> +++ b/radeon/radeon_surface.c
> [...]
> @@ -1198,6 +1742,33 @@ static int si_surface_init(struct 
> radeon_surface_manager *surf_man,
>  return r;
>  }
>  
> +/*
> + * depending on surface
> + */
> +static int si_surface_best(struct radeon_surface_manager *surf_man,
> +   struct radeon_surface *surf)
> +{
> +unsigned mode, tile_mode, stencil_tile_mode;
> +
> +/* tiling mode */
> +mode = (surf->flags >> RADEON_SURF_MODE_SHIFT) & RADEON_SURF_MODE_MASK;
> +
> +if (surf->flags & RADEON_SURF_SBUFFER) {
> +/* stencil force 2d tiling */
> +surf->flags = RADEON_SURF_CLR(surf->flags, MODE);
> +surf->flags |= RADEON_SURF_SET(RADEON_SURF_MODE_1D, MODE);
> +}
> +
> +if (surf->flags & (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) {
> +/* depth force 2d tiling */
> +surf->flags = RADEON_SURF_CLR(surf->flags, MODE);
> +surf->flags |= RADEON_SURF_SET(RADEON_SURF_MODE_1D, MODE);
> +}

The comments say 2D, but the code says 1D.


> @@ -104,6 +132,8 @@ struct radeon_surface {
>  uint64_tstencil_offset;
>  struct radeon_surface_level level[RADEON_SURF_MAX_LEVEL];
>  struct radeon_surface_level stencil_level[RADEON_SURF_MAX_LEVEL];
> +uint32_ttiling_index[RADEON_SURF_MAX_LEVEL];
> +uint32_t
> stencil_tiling_index[RADEON_SURF_MAX_LEVEL];
>  };

Either these new fields need to be guarded the same way stencil_level is
guarded by RADEON_SURF_SBUFFER, or the libdrm_radeon SONAME needs to be
bumped. Otherwise, radeonsi built against libdrm_radeon without this
patch will probably crash when running against libdrm_radeon with it.


-- 
Earthling Michel D?nzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer

[PATCH] radeon: add si tiling support v2

2013-04-04 Thread j.gli...@gmail.com

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(+), 45 deletions(-)

diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index 00d66b3..ff3ce3a 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -509,6 +509,7 @@ typedef struct {
 #define DRM_RADEON_GEM_SET_TILING  0x28
 #define DRM_RADEON_GEM_GET_TILING  0x29
 #define DRM_RADEON_GEM_BUSY0x2a
+#define DRM_RADEON_GEM_VA  0x2b

 #define DRM_IOCTL_RADEON_CP_INITDRM_IOW( DRM_COMMAND_BASE + 
DRM_RADEON_CP_INIT, drm_radeon_init_t)
 #define DRM_IOCTL_RADEON_CP_START   DRM_IO(  DRM_COMMAND_BASE + 
DRM_RADEON_CP_START)
@@ -550,6 +551,7 @@ typedef struct {
 #define DRM_IOCTL_RADEON_SET_TILINGDRM_IOWR(DRM_COMMAND_BASE + 
DRM_RADEON_GEM_SET_TILING, struct drm_radeon_gem_set_tiling)
 #define DRM_IOCTL_RADEON_GET_TILINGDRM_IOWR(DRM_COMMAND_BASE + 
DRM_RADEON_GEM_GET_TILING, struct drm_radeon_gem_get_tiling)
 #define DRM_IOCTL_RADEON_GEM_BUSY  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_RADEON_GEM_BUSY, struct drm_radeon_gem_busy)
+#define DRM_IOCTL_RADEON_GEM_VADRM_IOWR(DRM_COMMAND_BASE + 
DRM_RADEON_GEM_VA, struct drm_radeon_gem_va)

 typedef struct drm_radeon_init {
enum {
@@ -882,6 +884,27 @@ struct drm_radeon_gem_pwrite {
uint64_t data_ptr;
 };

+#define RADEON_VA_MAP  1
+#define RADEON_VA_UNMAP2
+
+#define RADEON_VA_RESULT_OK0
+#define RADEON_VA_RESULT_ERROR 1
+#define RADEON_VA_RESULT_VA_EXIST  2
+
+#define RADEON_VM_PAGE_VALID   (1 << 0)
+#define RADEON_VM_PAGE_READABLE(1 << 1)
+#define RADEON_VM_PAGE_WRITEABLE   (1 << 2)
+#define RADEON_VM_PAGE_SYSTEM  (1 << 3)
+#define RADEON_VM_PAGE_SNOOPED (1 << 4)
+
+struct drm_radeon_gem_va {
+   uint32_thandle;
+   uint32_toperation;
+   uint32_tvm_id;
+   uint32_tflags;
+   uint64_toffset;
+};
+
 #define RADEON_CHUNK_ID_RELOCS 0x01
 #define RADEON_CHUNK_ID_IB 0x02

@@ -916,6 +939,26 @@ struct drm_radeon_cs {
 #define RADEON_INFO_ACCEL_WORKING2 0x05
 #define RADEON_INFO_TILING_CONFIG  0x06
 #define RADEON_INFO_WANT_HYPERZ0x07
+#define RADEON_INFO_WANT_CMASK 0x08 /* get access to CMASK on r300 */
+#define RADEON_INFO_CLOCK_CRYSTAL_FREQ 0x09 /* clock crystal frequency */
+#define RADEON_INFO_NUM_BACKENDS   0x0a /* DB/backends for r600+ - need 
for OQ */
+#define RADEON_INFO_NUM_TILE_PIPES 0x0b /* tile pipes for r600+ */
+#define RADEON_INFO_FUSION_GART_WORKING0x0c /* fusion writes to GTT 
were broken before this */
+#define RADEON_INFO_BACKEND_MAP0x0d /* pipe to backend map, 
needed by mesa */
+/* virtual address start, va < start are reserved by the kernel */
+#define RADEON_INFO_VA_START   0x0e
+/* maximum size of ib using the virtual memory cs */
+#define RADEON_INFO_IB_VM_MAX_SIZE 0x0f
+/* max pipes - needed for compute shaders */
+#define RADEON_INFO_MAX_PIPES  0x10
+/* timestamp for GL_ARB_timer_query (OpenGL), returns the current GPU clock */
+#define RADEON_INFO_TIMESTAMP  0x11
+/* max shader engines (SE) - needed for geometry shaders, etc. */
+#define RADEON_INFO_MAX_SE 0x12
+/* max SH per SE */
+#define RADEON_INFO_MAX_SH_PER_SE  0x13
+/* SI tile mode array */
+#define RADEON_INFO_SI_TILE_MODE_ARRAY 0x14

 struct drm_radeon_info {
uint32_trequest;
@@ -923,4 +966,22 @@ struct drm_radeon_info {
uint64_tvalue;
 };

+/* Those correspond to the tile index to use, this is to explicitly state
+ * the API that is implicitly defined by the tile mode array.
+ */
+#define SI_TILE_MODE_COLOR_LINEAR_ALIGNED  8
+#define SI_TILE_MODE_COLOR_1D  13
+#define SI_TILE_MODE_COLOR_1D_SCANOUT  9
+#define SI_TILE_MODE_COLOR_2D_8BPP 14
+#define SI_TILE_MODE_COLOR_2D_16BPP15
+#define SI_TILE_MODE_COLOR_2D_32BPP16
+#define SI_TILE_MODE_COLOR_2D_64BPP17
+#define SI_TILE_MODE_COLOR_2D_SCANOUT_16BPP11
+#define SI_TILE_MODE_COLOR_2D_SCANOUT_32BPP12
+#define SI_TILE_MODE_DEPTH_STENCIL_1D  4
+#define SI_TILE_MODE_DEPTH_STENCIL_2D  0
+#define SI_TILE_MODE_DEPTH_STENCIL_2D_2AA  3
+#define SI_TILE_MODE_DEPTH_STENCIL_2D_4AA  3
+#define SI_TILE_MODE_DEPTH_STENCIL_2D_8AA  2
+
 #endif
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 5935c23..2056899 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -83,12 +83,15 @@ typedef int (*hw_best_surface_t)(struct 
radeon_surface_manager

flushing uninitialized work item in radeon init failure path

2013-04-04 Thread Tejun Heo

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 uninitialized work items triggering the following
lockdep warning.  Well, at least, that's what I think is happening.

 [drm] Initialized drm 1.1.0 20060810
 [drm] radeon kernel modesetting enabled.
 radeon :00:0c.0: enabling device (0080 -> 0083)
 [drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x1002:0x515E).
 [drm] register mmio base: 0xFEBE
 [drm] register mmio size: 65536
 radeon :00:0c.0: Invalid ROM contents
 radeon :00:0c.0: Invalid ROM contents
 [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM
 radeon :00:0c.0: Card not posted and no BIOS - ignoring
 radeon :00:0c.0: Fatal error during GPU init
 [drm] radeon: finishing device.
 [TTM] Memory type 2 has not been initialized
 [drm] radeon: cp finalized
 INFO: trying to register non-static key.
 the code is fine but needs lockdep annotation.
 turning off the locking correctness validator.
 Pid: 50, comm: kworker/0:1 Not tainted 3.9.0-rc5-work+ #1
 Call Trace:
  [] __lock_acquire+0x1840/0x1c50
  [] ? mark_held_locks+0x86/0x110
  [] ? retint_restore_args+0xe/0xe
  [] ? trace_hardirqs_on_caller+0x115/0x1a0
  [] ? trace_hardirqs_on_thunk+0x3a/0x3f
  [] lock_acquire+0x95/0x1e0
  [] ? flush_work+0x5/0x270
  [] flush_work+0x4c/0x270
  [] ? flush_work+0x5/0x270
  [] ? printk+0x4d/0x4f
  [] radeon_irq_kms_fini+0x2f/0x70
  [] r100_fini+0x4f/0x90
  [] radeon_device_fini+0x42/0x100
  [] radeon_driver_unload_kms+0x3c/0x60
  [] radeon_driver_load_kms+0xbd/0x160
  [] drm_get_pci_dev+0x17e/0x2a0
  [] radeon_pci_probe+0xab/0xd0
  [] local_pci_probe+0x23/0x40
  [] work_for_cpu_fn+0x18/0x30
  [] process_one_work+0x1f6/0x670
  [] ? process_one_work+0x18a/0x670
  [] process_scheduled_works+0x2c/0x40
  [] worker_thread+0x2b2/0x380
  [] ? rescuer_thread+0x250/0x250
  [] kthread+0xea/0xf0
  [] ? __init_kthread_worker+0x70/0x70
  [] ret_from_fork+0x7c/0xb0
  [] ? __init_kthread_worker+0x70/0x70
 radeon: probe of :00:0c.0 failed with error -22

Thanks.

-- 
tejun

[PATCHv9 0/9] Support Tegra 2D hardware

2013-04-04 Thread Terje Bergström

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 
> Tested-by: Thierry Reding 
> 
> For the Tegra DRM bits:
> 
> Acked-by: Thierry Reding 

Dave,

What's the status of this patch? The patch set is not yet merged in your
tree. Did I forget to do some step?

Terje

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 index
> > > > match to prefered surface format/type combination.
> > 
> > How so? We can add descriptive names for the existing indices.
> 
> Look at my kernel patch, for instance i define :
> RADEON_TILE_MODE_COLOR_2D_32BPP
> 
> You can then query the kernel with RADEON_TILE_MODE_COLOR_2D_32BPP which
> gave you corresponding tile index and also correspond gb tile config.
> 
> http://people.freedesktop.org/~glisse/si2d-sol1/0001-drm-radeon-add-tile-mode-ioctl.patch

I did look at your patches. That's the layer of indirection I'm
referring to. 


> > > Maybe I'm missing the problem, but if libdrm_radeon were to
> > > get the
> > > tiling mode index chosen by radeonsi, and could retrieve the
> > > tiling
> > > parameters for each index from the kernel, it should be able
> > > to
> > > calculate things properly, shouldn't it?
> > > 
> > > 
> > > 
> > > Let's not discuss about who/where the index is pick. No matter where
> > > it happens the question is do we want to hardcode tile index and make
> > > it api or do we want to hide it behind symbolic name allowing change
> > > in tile array (given that right now 4 value are already frozen). You
> > > can look at my kernel patch to see what i mean.
> > 
> > The layer of indirection for the indices seems like overengineering at
> > this point. Even if the fixed indices stop being good enough for some
> > reason in the future, how can we be sure now the layer of indirection
> > will be good enough? So I think we shouldn't worry about that until that
> > day may come.
> 
> Well i am fine with that but i just want to make sure everybody understand
> the implications.

I think it should be fine. If necessary, we can add another query for
the index mapping. But as Alex explained, the indices should be fixed at
least within one HW generation. 

Thanks for working on this BTW!


-- 
Earthling Michel D?nzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer

[Bug 57567] 3.7 radeonfb broken on efivga screens

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #21 from Vladimir  ---
Created attachment 77407
  --> https://bugs.freedesktop.org/attachment.cgi?id=77407=edit
screenshot of 3.9

screenshot of what happens

-- 
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/60433d19/attachment.html>

[Bug 57567] 3.7 radeonfb broken on efivga screens

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #20 from Vladimir  ---
Created attachment 77406
  --> https://bugs.freedesktop.org/attachment.cgi?id=77406=edit
new dmesg with drm.debug=14

It's a little bit better now, framebuffer is always shifted. (previously
framebuffer usualy was lost, or messed up). it's 3.9-rc5 + patch

I've also tried 3.8.5+patch, and saw no difference to just 3.8.5, just saying.

-- 
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/d7b369aa/attachment.html>

UVD fails to init on rv790

2013-04-04 Thread Dieter Nützel

ct:  0.011   0/  0 58% 69%  1.0% 156 0

Exiting... (Quit)


> The adobe flash vdpau implementation
> reverses the channels.  IIRC, newer versions of libvdpau have a
> workaround for it.

I know, but I can't use this crappy stupid software since summer 2012, 
'cause they do NOT offer any current linux player (even with their 
hardware acceleration) without SSE2...

...Duron/AthlonMP => AMD could you help, PLEASE?!

In the meantime I use an older libflash taken from Chrome without 
hardware acceleration, too. But it is compiled without SSE2. Due to this 
the Duron is on it's limits with flash stuff 8-(((

lib/browser-plugins> l *flash*
lrwxrwxrwx 1 root root   19 14. M?r 22:07 libflashplayer.so -> 
libgcflashplayer.so
-rwxr-xr-x 1 root root 17351000  7. Jun 2012  libgcflashplayer.so
lib/browser-plugins> l SSE2/
insgesamt 17029
drwxr-xr-x 2 root root   88 14. M?r 22:06 .
drwxr-xr-x 3 root root  328 22. M?r 01:47 ..
-rwxr-xr-x 1 root root 17418724  1. M?r 01:30 libflashplayer.so

Why can't everybody use runtime CPU detection like Mesa (;-) or 
mplayer?

OpenCV with OpenCL (digikam) would be my next disaster.
But former can I recompile without SSE2 to use it with digikam, today.

>  I've generally been testing with mplayer.  mplayer
> -vo vdpau -vc ffh264vdpau 

Tried that:

/home/dieter> mplayer -vo vdpau -vc ffh264vdpau /data/Filme/Serenity\ 
-\ HD\ DVD\ Trailer.mp4

[-]
[VD_FFMPEG] Trying pixfmt=0.
[vdpau] Failed creating VDPAU decoder: An invalid/unsupported 
VdpDecoderProfile value was supplied.
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
The selected video_out device is incompatible with this codec.
Try appending the scale filter to your filter list,
e.g. -vf spp,scale instead of -vf spp.
[h264_vdpau @ 0x8b3db80]decoding 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>

UVD fails to init on rv790

2013-04-04 Thread Andreas Boll

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 (that's why they have
> their own firmware) and there possible is some bug or something like this
> that we haven't implemented. You couldn't give me SSH access to that system?
>
> Christian.
>
> Am 03.04.2013 11:51, schrieb Andy Furniss:
>
>  Thanks AMD for getting this out :-)
>>
>> I have an issue, though.
>>
>> On HD4890 drm-fixes kernel (before yesterdays updates) got the new
>>
>> R700_rlc.bin
>> RV770_uvd.bin
>>
>> but on boot I get -
>>
>> [drm] radeon kernel modesetting enabled.
>> [drm] initializing kernel modesetting (RV770 0x1002:0x9460 0x1682:0x2700).
>> [drm] register mmio base: 0xFE6F
>> [drm] register mmio size: 65536
>> ATOM BIOS: Wekiva
>> radeon :01:00.0: VRAM: 1024M 0x - 0x3FFF
>> (1024M used)
>> radeon :01:00.0: GTT: 512M 0x4000 - 0x5FFF
>> [drm] Detected VRAM RAM=1024M, BAR=256M
>> [drm] RAM width 256bits DDR
>> [TTM] Zone  kernel: Available graphics memory: 436936 kiB
>> [TTM] Zone highmem: Available graphics memory: 1685484 kiB
>> [TTM] Initializing pool allocator
>> [drm] radeon: 1024M of VRAM memory ready
>> [drm] radeon: 512M of GTT memory ready.
>> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
>> [drm] Driver supports precise vblank timestamp query.
>> radeon :01:00.0: irq 51 for MSI/MSI-X
>> radeon :01:00.0: radeon: using MSI.
>> [drm] radeon: irq initialized.
>> [drm] GART: num cpu pages 131072, num gpu pages 131072
>> [drm] probing gen 2 caps for device 1022:9603 = 300d02/0
>> [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
>> [drm] Loading RV770 Microcode
>> [drm] PCIE GART of 512M enabled (table at 0x00257000).
>> radeon :01:00.0: WB enabled
>> radeon :01:00.0: fence driver on ring 0 use gpu addr
>> 0x4c00 and cpu addr 0xff893c00
>> radeon :01:00.0: fence driver on ring 3 use gpu addr
>> 0x4c0c and cpu addr 0xff893c0c
>> radeon :01:00.0: fence driver on ring 5 use gpu addr
>> 0x0005632c and cpu addr 0xfbb9632c
>> [drm] ring test on 0 succeeded in 1 usecs
>> [drm] ring test on 3 succeeded in 1 usecs
>> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
>> VCPU!!!
>> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
>> VCPU!!!
>> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
>> VCPU!!!
>> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
>> VCPU!!!
>> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
>> VCPU!!!
>> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
>> VCPU!!!
>> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
>> VCPU!!!
>> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
>> VCPU!!!
>> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
>> VCPU!!!
>> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the
>> VCPU!!!
>> [drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!!
>> [drm:rv770_startup] *ERROR* radeon: failed initializing UVD (-1).
>> [drm] Enabling audio support
>> [drm] ib test on ring 0 succeeded in 0 usecs
>> [drm] ib test on ring 3 succeeded in 0 usecs
>> ALSA sound/pci/hda/hda_eld.c:334 HDMI: ELD buf size is 0, force 128
>> ALSA sound/pci/hda/hda_eld.c:351 HDMI: invalid ELD data byte 0
>> [drm] Radeon Display Connectors
>> [drm] Connector 0:
>> [drm]   DVI-I-1
>> [drm]   HPD2
>> [drm]   DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
>> [drm]   Encoders:
>> [drm] DFP1: INTERNAL_UNIPHY
>> [drm] CRT2: INTERNAL_KLDSCP_DAC2
>> [drm] Connector 1:
>> [drm]   DIN-1
>> [drm]   Encoders:
>> [drm] TV1: INTERNAL_KLDSCP_DAC2
>> [drm] Connector 2:
>> [drm]   DVI-I-2
>> [drm]   HPD1
>> [drm]   DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 0x7e2c
>> [drm]   Encoders:
>> [drm] CRT1: INTERNAL_KLDSCP_DAC1
>> [drm] DFP2: INTERNAL_KLDSCP_LVTMA
>> [drm] Internal thermal controller with fan control
>> [drm] radeon: power management initialized
>> [drm] fb mappable at 0xD0359000
>> [drm] vram apper at 0xD000
>> [drm] size 8294400
>> [drm] fb depth is 24
>> [drm]pitch is 7680
>> fbcon: radeondrmfb (fb0) is primary device
>> Console: switching to colour frame buffer device 240x67
>> radeon :01:00.0: fb0: radeondrmfb frame buffer device
>> radeon :01:00.0: registered panic notifier
>> [drm] Initialized radeon 2.30.0 20080528 for :01:00.0 on minor 0
>> __**_
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.**org 
>> http://lists.freedesktop.org/**mailman/listinfo/dri-devel

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

2013-04-04 Thread Chen Gang

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 |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
 b/drivers/gpu/drm/nouveau/nv50_display.c
 index 7f0e6c3..1ddc03e 100644
 --- a/drivers/gpu/drm/nouveau/nv50_display.c
 +++ b/drivers/gpu/drm/nouveau/nv50_display.c
 @@ -479,7 +479,7 @@ nv50_display_flip_wait(void *data)
  {
   struct nv50_display_flip *flip = data;
   if (nouveau_bo_rd32(flip-disp-sync, flip-chan-addr / 4) ==
 -   flip-chan-data);
 +   flip-chan-data)
   return true;
   usleep_range(1, 2);
   return false;
 


-- 
Chen Gang

Asianux Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: UVD fails to init on rv790

2013-04-04 Thread K. Schnass

 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 [AMD] nee ATI 
RV770 [Radeon HD 4850] [1002:9442] (prog-if 00 [VGA controller])
Subsystem: PC Partner Limited Device [174b:e104]
Flags: bus master, fast devsel, latency 0, IRQ 43
Memory at d000 (64-bit, prefetchable) [size=256M]
Memory at feaf (64-bit, non-prefetchable) [size=64K]
I/O ports at d000 [size=256]
Expansion ROM at feac [disabled] [size=128K]
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Legacy Endpoint, MSI 00
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 
?
Kernel driver in use: radeon
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

2013-04-04 Thread Christian Lamparter

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
---
 drivers/gpu/drm/i915/intel_lvds.c |8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index 3d1d974..65893b0 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -850,6 +850,14 @@ static const struct dmi_system_id intel_no_lvds[] = {
DMI_MATCH(DMI_PRODUCT_NAME, X7SPA-H),
},
},
+   {
+   .callback = intel_no_lvds_dmi_callback,
+   .ident = Fujitsu Esprimo Q900,
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, FUJITSU),
+   DMI_MATCH(DMI_PRODUCT_NAME, ESPRIMO Q900),
+   },
+   },
 
{ } /* terminating entry */
 };
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

gma500: Other things that I could work on

2013-04-04 Thread Kero

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? Who should I talk to about specifications?
I know Intel is not forthcoming with documentation, yet several people have
made contributions for poulsbo and later versions of the hardware.
How did you get the required knowledge?

Things I might, in order of personal preference, in due time (after holiday), 
take a look at:
1) would be nice to have the full 1024x600 on the external VGA and HDMI
   I had a chance to try another monitor over HDMI, same result: only 800x600 
visible.
2) booting with either VGA or HDMI plugged in, yields two black screens: both 
the laptop
   and the monitor. Un- + re-plugging has no visible effect.
3) the Fn keys for the backlight induce a response in the backlight, but only 
with
   tiny results; /sys/class/backlight/psb-bl/brightness works fine, though
4) when using modules, initialization from hibernation is not good enough:
   my screen stays black; without using modules, the kernel boots normally, and 
everything is fine.
5) initialization from suspend is not good enough: my Asus stays in
   some text mode (80x25?), but shows garbage (possibly data from the desired 
console or
   graphics mode, since sometimes there are reactions correlated to actions)
   Switching tty or using `chvt` do not improve anything.
   NB: hibernating and booting solves this.

 Your patch has been applied to:
 https://github.com/patjak/drm-gma500.git gma500-next

Thanks!

 We might also consider polling if this causes problems for people, but for now
 this is fine.

Agreed;
The Display Port was already hotpluggable; the Asus has no such connector,
but is not bothered by polling (status is and remains 'disconnected').
That makes me hopeful that hardware without VGA or HDMI connectors will not be
negatively affected. But given the 5 points above, there's no guarantee.

 No biggie, but your tabs where converted to spaces so I recommend
 running checkpatch.pl before submitting.

woops, my mistake. will run checkpatch.pl next time.

Bye,
Kero.

-- 
Are you master of your time here?
Are you master of your own fate?
   -- Deep Inside -- Exile -- To-Mera
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

2013-04-04 Thread Joseph Salisbury


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

Merge tag 'v3.7-rc2' into drm-intel-next-queued



The regression was introduced as of v3.8-rc1.  However, further testing 
also shows this bug is now fixed in v3.9-rc4.


I see that you are the author of this patch, so I wanted see if I can 
get your feedback.  Do you happen to have an idea what may have fixed 
this in v3.9-rc4, so we can send a request to stable, if not already 
done?  Otherwise, I can perform a reverse bisect to see which commit 
fixed this.



Thanks,

Joe

[0] http://pad.lv/1109309
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

2013-04-04 Thread Joseph Salisbury


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 was the first bad commit:


commit c2fb7916927e989ea424e61ce5fe617e54878827
Merge: 29de6ce 6f0c058
Author: Daniel Vetter daniel.vet...@ffwll.ch
mailto:daniel.vet...@ffwll.ch
Date:   Mon Oct 22 14:34:51 2012 +0200

Merge tag 'v3.7-rc2' into drm-intel-next-queued



The regression was introduced as of v3.8-rc1.  However, further
testing also shows this bug is now fixed in v3.9-rc4.

I see that you are the author of this patch, so I wanted see if I
can get your feedback.  Do you happen to have an idea what may
have fixed this in v3.9-rc4, so we can send a request to stable,
if not already done?  Otherwise, I can perform a reverse bisect to
see which commit fixed this.


So apparently it's an oops somewhere in the nouveau setup code, which 
bisected to a backmerge which has _only_ conflicts in drm/i915 driver 
code.


I have no idea what blew up here, sorry.
-Daniel


Thanks for the info, Daniel.  I'll go the reverse bisect route.






Thanks,

Joe

[0] http://pad.lv/1109309




--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[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 debugging, but we'll leave that
for the time being.

Best regards,
~Sumit.

---
changes since v2: (based on review comments from Laurent Pinchart)
 - reordered functions to avoid forward declaration
 - added __exitcall for dma_buf_deinit()

changes since v1:
 - added patch to replace dma_buf_export() with dma_buf_export_named(), per
suggestion from Daniel Vetter.
 - fixes on init and warnings as reported and corrected by Dave Airlie.
 - added locking while walking attachment list - reported by Daniel Vetter.

Sumit Semwal (2):
  dma-buf: replace dma_buf_export() with dma_buf_export_named()
  dma-buf: Add debugfs support

 Documentation/dma-buf-sharing.txt |   13 ++-
 drivers/base/dma-buf.c|  170 -
 include/linux/dma-buf.h   |   16 +++-
 3 files changed, 190 insertions(+), 9 deletions(-)

-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[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 #define dma_buf_export() is also made available,
which adds a __FILE__ instead of 'exp_name'.

Cc: Daniel Vetter daniel.vet...@ffwll.ch
  [Thanks for the idea!]
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
---
 Documentation/dma-buf-sharing.txt |   13 +++--
 drivers/base/dma-buf.c|   11 +++
 include/linux/dma-buf.h   |   11 +--
 3 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/Documentation/dma-buf-sharing.txt 
b/Documentation/dma-buf-sharing.txt
index 4966b1b..0b23261 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -52,14 +52,23 @@ The dma_buf buffer sharing API usage contains the following 
steps:
associated with this buffer.
 
Interface:
-  struct dma_buf *dma_buf_export(void *priv, struct dma_buf_ops *ops,
-size_t size, int flags)
+  struct dma_buf *dma_buf_export_named(void *priv, struct dma_buf_ops *ops,
+size_t size, int flags,
+const char *exp_name)
 
If this succeeds, dma_buf_export allocates a dma_buf structure, and returns 
a
pointer to the same. It also associates an anonymous file with this buffer,
so it can be exported. On failure to allocate the dma_buf object, it returns
NULL.
 
+   'exp_name' is the name of exporter - to facilitate information while
+   debugging.
+
+   Exporting modules which do not wish to provide any specific name may use the
+   helper define 'dma_buf_export()', with the same arguments as above, but
+   without the last argument; a __FILE__ pre-processor directive will be
+   inserted in place of 'exp_name' instead.
+
 2. Userspace gets a handle to pass around to potential buffer-users
 
Userspace entity requests for a file-descriptor (fd) which is a handle to 
the
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 2a7cb0d..d89102a 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -77,22 +77,24 @@ static inline int is_dma_buf_file(struct file *file)
 }
 
 /**
- * dma_buf_export - Creates a new dma_buf, and associates an anon file
+ * dma_buf_export_named - Creates a new dma_buf, and associates an anon file
  * with this buffer, so it can be exported.
  * Also connect the allocator specific data and ops to the buffer.
+ * Additionally, provide a name string for exporter; useful in debugging.
  *
  * @priv:  [in]Attach private data of allocator to this buffer
  * @ops:   [in]Attach allocator-defined dma buf ops to the new buffer.
  * @size:  [in]Size of the buffer
  * @flags: [in]mode flags for the file.
+ * @exp_name:  [in]name of the exporting module - useful for debugging.
  *
  * Returns, on success, a newly created dma_buf object, which wraps the
  * supplied private data and operations for dma_buf_ops. On either missing
  * ops, or error in allocating struct dma_buf, will return negative error.
  *
  */
-struct dma_buf *dma_buf_export(void *priv, const struct dma_buf_ops *ops,
-   size_t size, int flags)
+struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops *ops,
+   size_t size, int flags, const char *exp_name)
 {
struct dma_buf *dmabuf;
struct file *file;
@@ -114,6 +116,7 @@ struct dma_buf *dma_buf_export(void *priv, const struct 
dma_buf_ops *ops,
dmabuf-priv = priv;
dmabuf-ops = ops;
dmabuf-size = size;
+   dmabuf-exp_name = exp_name;
 
file = anon_inode_getfile(dmabuf, dma_buf_fops, dmabuf, flags);
 
@@ -124,7 +127,7 @@ struct dma_buf *dma_buf_export(void *priv, const struct 
dma_buf_ops *ops,
 
return dmabuf;
 }
-EXPORT_SYMBOL_GPL(dma_buf_export);
+EXPORT_SYMBOL_GPL(dma_buf_export_named);
 
 
 /**
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 9978b61..6f55c04 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -112,6 +112,7 @@ struct dma_buf_ops {
  * @file: file pointer used for sharing buffers across, and for refcounting.
  * @attachments: list of dma_buf_attachment that denotes all devices attached.
  * @ops: dma_buf_ops associated with this buffer object.
+ * @exp_name: name of the exporter; useful for debugging.
  * @priv: exporter specific private data for this buffer object.
  */
 struct dma_buf {
@@ -123,6 +124,7 @@ struct dma_buf {
struct mutex lock;
unsigned vmapping_counter;
void *vmap_ptr;
+   const char *exp_name;
void *priv;
 };
 
@@ -162,8 +164,13 @@ struct dma_buf_attachment

[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)
 - reordered functions to avoid forward declaration
 - added __exitcall for dma_buf_deinit()

changes since v1:
 - fixes on init and warnings as reported and corrected by Dave Airlie.
 - add locking while walking attachment list - reported by Daniel Vetter.
---
 drivers/base/dma-buf.c  |  159 +++
 include/linux/dma-buf.h |5 +-
 2 files changed, 163 insertions(+), 1 deletion(-)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index d89102a..466476f 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -27,9 +27,18 @@
 #include linux/dma-buf.h
 #include linux/anon_inodes.h
 #include linux/export.h
+#include linux/debugfs.h
+#include linux/seq_file.h
 
 static inline int is_dma_buf_file(struct file *);
 
+struct dma_buf_list {
+   struct list_head head;
+   struct mutex lock;
+};
+
+static struct dma_buf_list db_list;
+
 static int dma_buf_release(struct inode *inode, struct file *file)
 {
struct dma_buf *dmabuf;
@@ -42,6 +51,11 @@ static int dma_buf_release(struct inode *inode, struct file 
*file)
BUG_ON(dmabuf-vmapping_counter);
 
dmabuf-ops-release(dmabuf);
+
+   mutex_lock(db_list.lock);
+   list_del(dmabuf-list_node);
+   mutex_unlock(db_list.lock);
+
kfree(dmabuf);
return 0;
 }
@@ -125,6 +139,10 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
struct dma_buf_ops *ops,
mutex_init(dmabuf-lock);
INIT_LIST_HEAD(dmabuf-attachments);
 
+   mutex_lock(db_list.lock);
+   list_add(dmabuf-list_node, db_list.head);
+   mutex_unlock(db_list.lock);
+
return dmabuf;
 }
 EXPORT_SYMBOL_GPL(dma_buf_export_named);
@@ -551,3 +569,144 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
mutex_unlock(dmabuf-lock);
 }
 EXPORT_SYMBOL_GPL(dma_buf_vunmap);
+
+#ifdef CONFIG_DEBUG_FS
+static int dma_buf_describe(struct seq_file *s)
+{
+   int ret;
+   struct dma_buf *buf_obj;
+   struct dma_buf_attachment *attach_obj;
+   int count = 0, attach_count;
+   size_t size = 0;
+
+   ret = mutex_lock_interruptible(db_list.lock);
+
+   if (ret)
+   return ret;
+
+   seq_printf(s, \nDma-buf Objects:\n);
+   seq_printf(s, \texp_name\tsize\tflags\tmode\tcount\n);
+
+   list_for_each_entry(buf_obj, db_list.head, list_node) {
+   ret = mutex_lock_interruptible(buf_obj-lock);
+
+   if (ret) {
+   seq_printf(s,
+ \tERROR locking buffer object: skipping\n);
+   goto skip_buffer;
+   }
+
+   seq_printf(s, \t);
+
+   seq_printf(s, \t%s\t%08zu\t%08x\t%08x\t%08d\n,
+   buf_obj-exp_name, buf_obj-size,
+   buf_obj-file-f_flags, buf_obj-file-f_mode,
+   buf_obj-file-f_count.counter);
+
+   seq_printf(s, \t\tAttached Devices:\n);
+   attach_count = 0;
+
+   list_for_each_entry(attach_obj, buf_obj-attachments, node) {
+   seq_printf(s, \t\t);
+
+   seq_printf(s, %s\n, attach_obj-dev-init_name);
+   attach_count++;
+   }
+
+   seq_printf(s, \n\t\tTotal %d devices attached\n,
+   attach_count);
+
+   count++;
+   size += buf_obj-size;
+skip_buffer:
+   mutex_unlock(buf_obj-lock);
+   }
+
+   seq_printf(s, \nTotal %d objects, %zu bytes\n, count, size);
+
+   mutex_unlock(db_list.lock);
+   return 0;
+}
+
+static int dma_buf_show(struct seq_file *s, void *unused)
+{
+   void (*func)(struct seq_file *) = s-private;
+   func(s);
+   return 0;
+}
+
+static int dma_buf_debug_open(struct inode *inode, struct file *file)
+{
+   return single_open(file, dma_buf_show, inode-i_private);
+}
+
+static const struct file_operations dma_buf_debug_fops = {
+   .open   = dma_buf_debug_open,
+   .read   = seq_read,
+   .llseek = seq_lseek,
+   .release= single_release,
+};
+
+static struct dentry *dma_buf_debugfs_dir;
+
+static int dma_buf_init_debugfs(void)
+{
+   int err = 0;
+   dma_buf_debugfs_dir = debugfs_create_dir(dma_buf, NULL);
+   if (IS_ERR(dma_buf_debugfs_dir)) {
+   err = PTR_ERR(dma_buf_debugfs_dir);
+   dma_buf_debugfs_dir = NULL;
+   return err;
+   }
+
+   err = dma_buf_debugfs_create_file(bufinfo, dma_buf_describe);
+
+   if (err)
+   pr_debug(dma_buf: debugfs: failed to create node

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

2013-04-04 Thread Terje Bergström

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 thierry.red...@avionic-design.de
 Tested-by: Thierry Reding thierry.red...@avionic-design.de
 
 For the Tegra DRM bits:
 
 Acked-by: Thierry Reding thierry.red...@avionic-design.de

Dave,

What's the status of this patch? The patch set is not yet merged in your
tree. Did I forget to do some step?

Terje
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[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. (previously
framebuffer usualy was lost, or messed up). it's 3.9-rc5 + patch

I've also tried 3.8.5+patch, and saw no difference to just 3.8.5, just saying.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[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 assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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 what index
match to prefered surface format/type combination.

How so? We can add descriptive names for the existing indices.

Look at my kernel patch, for instance i define :
RADEON_TILE_MODE_COLOR_2D_32BPP

You can then query the kernel with RADEON_TILE_MODE_COLOR_2D_32BPP which
gave you corresponding tile index and also correspond gb tile config.

http://people.freedesktop.org/~glisse/si2d-sol1/0001-drm-radeon-add-tile-mode-ioctl.patch

I did look at your patches. That's the layer of indirection I'm
referring to.

Maybe I'm missing the problem, but if libdrm_radeon were to
get the
tiling mode index chosen by radeonsi, and could retrieve the
tiling
parameters for each index from the kernel, it should be able
to
calculate things properly, shouldn't it?

Let's not discuss about who/where the index is pick. No matter where
it happens the question is do we want to hardcode tile index and make
it api or do we want to hide it behind symbolic name allowing change
in tile array (given that right now 4 value are already frozen). You
can look at my kernel patch to see what i mean.

The layer of indirection for the indices seems like overengineering at
this point. Even if the fixed indices stop being good enough for some
reason in the future, how can we be sure now the layer of indirection
will be good enough? So I think we shouldn't worry about that until that
day may come.

Well i am fine with that but i just want to make sure everybody understand
the implications.

I think it should be fine. If necessary, we can add another query for
the index mapping. But as Alex explained, the indices should be fixed at
least within one HW generation.

Thanks for working on this BTW!

--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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 
 +++
  radeon/radeon_surface.h  |  30 +++
  3 files changed, 709 insertions(+), 45 deletions(-)
 
 diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
 index 00d66b3..ff3ce3a 100644
 --- a/include/drm/radeon_drm.h
 +++ b/include/drm/radeon_drm.h
 @@ -509,6 +509,7 @@ typedef struct {
  #define DRM_RADEON_GEM_SET_TILING  0x28
  #define DRM_RADEON_GEM_GET_TILING  0x29
  #define DRM_RADEON_GEM_BUSY0x2a
 +#define DRM_RADEON_GEM_VA  0x2b
  
  #define DRM_IOCTL_RADEON_CP_INITDRM_IOW( DRM_COMMAND_BASE + 
 DRM_RADEON_CP_INIT, drm_radeon_init_t)
  #define DRM_IOCTL_RADEON_CP_START   DRM_IO(  DRM_COMMAND_BASE + 
 DRM_RADEON_CP_START)

Changes which aren't related to SI tiling should go in separate patches.


 diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
 index 5935c23..dfdcbbc 100644
 --- a/radeon/radeon_surface.c
 +++ b/radeon/radeon_surface.c
 [...]
 @@ -1198,6 +1742,33 @@ static int si_surface_init(struct 
 radeon_surface_manager *surf_man,
  return r;
  }
  
 +/*
 + * depending on surface
 + */
 +static int si_surface_best(struct radeon_surface_manager *surf_man,
 +   struct radeon_surface *surf)
 +{
 +unsigned mode, tile_mode, stencil_tile_mode;
 +
 +/* tiling mode */
 +mode = (surf-flags  RADEON_SURF_MODE_SHIFT)  RADEON_SURF_MODE_MASK;
 +
 +if (surf-flags  RADEON_SURF_SBUFFER) {
 +/* stencil force 2d tiling */
 +surf-flags = RADEON_SURF_CLR(surf-flags, MODE);
 +surf-flags |= RADEON_SURF_SET(RADEON_SURF_MODE_1D, MODE);
 +}
 +
 +if (surf-flags  (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) {
 +/* depth force 2d tiling */
 +surf-flags = RADEON_SURF_CLR(surf-flags, MODE);
 +surf-flags |= RADEON_SURF_SET(RADEON_SURF_MODE_1D, MODE);
 +}

The comments say 2D, but the code says 1D.


 @@ -104,6 +132,8 @@ struct radeon_surface {
  uint64_tstencil_offset;
  struct radeon_surface_level level[RADEON_SURF_MAX_LEVEL];
  struct radeon_surface_level stencil_level[RADEON_SURF_MAX_LEVEL];
 +uint32_ttiling_index[RADEON_SURF_MAX_LEVEL];
 +uint32_t
 stencil_tiling_index[RADEON_SURF_MAX_LEVEL];
  };

Either these new fields need to be guarded the same way stencil_level is
guarded by RADEON_SURF_SBUFFER, or the libdrm_radeon SONAME needs to be
bumped. Otherwise, radeonsi built against libdrm_radeon without this
patch will probably crash when running against libdrm_radeon with it.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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 jgli...@redhat.com

[...]

 diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
 b/drivers/gpu/drm/radeon/radeon_kms.c
 index c75cb2c..8076434 100644
 --- a/drivers/gpu/drm/radeon/radeon_kms.c
 +++ b/drivers/gpu/drm/radeon/radeon_kms.c
 @@ -176,80 +176,65 @@ int radeon_info_ioctl(struct drm_device *dev, void 
 *data, struct drm_file *filp)
 struct radeon_device *rdev = dev-dev_private;
 struct drm_radeon_info *info = data;
 struct radeon_mode_info *minfo = rdev-mode_info;
 -   uint32_t value, *value_ptr;
 -   uint64_t value64, *value_ptr64;
 +   uint32_t *value, value_tmp, *value_ptr, value_size;
 +   uint64_t value64;
 struct drm_crtc *crtc;
 int i, found;
  
 -   /* TIMESTAMP is a 64-bit value, needs special handling. */
 -   if (info-request == RADEON_INFO_TIMESTAMP) {
 -   if (rdev-family = CHIP_R600) {
 -   value_ptr64 = (uint64_t*)((unsigned long)info-value);
 -   value64 = radeon_get_gpu_clock_counter(rdev);
 -
 -   if (DRM_COPY_TO_USER(value_ptr64, value64, 
 sizeof(value64))) {
 -   DRM_ERROR(copy_to_user %s:%u\n, __func__, 
 __LINE__);
 -   return -EFAULT;
 -   }
 -   return 0;
 -   } else {
 -   DRM_DEBUG_KMS(timestamp is r6xx+ only!\n);
 -   return -EINVAL;
 -   }
 -   }
 -
 value_ptr = (uint32_t *)((unsigned long)info-value);
 -   if (DRM_COPY_FROM_USER(value, value_ptr, sizeof(value))) {
 -   DRM_ERROR(copy_from_user %s:%u\n, __func__, __LINE__);
 -   return -EFAULT;
 -   }
 +   value = value_tmp;
 +   value_size = sizeof(uint32_t);

[...]

 +   case RADEON_INFO_TIMESTAMP:
 +   if (rdev-family  CHIP_R600) {
 +   DRM_DEBUG_KMS(timestamp is r6xx+ only!\n);
 +   return -EINVAL;
 +   }
 +   value = (uint32_t*)value64;
 +   value_size = sizeof(uint64_t);
 +   value64 = radeon_get_gpu_clock_counter(rdev);
 +   break;

[...]

 -   if (DRM_COPY_TO_USER(value_ptr, value, sizeof(uint32_t))) {
 +   if (DRM_COPY_TO_USER(value_ptr, value, value_size)) {
 DRM_ERROR(copy_to_user %s:%u\n, __func__, __LINE__);
 return -EFAULT;
 }

Are these changes safe wrt strict aliasing? Might be safer to use char*
for the second argument passed to DRM_COPY_TO_USER. 

-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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 
support at all, no UVD support for this hardware generation or UVD just 
failed to initialize.


Currently we just don't handle the return code so well in mesa (feel 
free to fix that).


Christian.



Then we could check for UVD in userspace [1]

Thanks for the great work!

Andreas.

[1] http://lists.freedesktop.org/archives/mesa-dev/2013-April/037089.html


2013/4/3 Christian König deathsim...@vodafone.de


Hi everyone,

the following patchset implements the kernel side of UVD support for the
radeon hardware generations RV710-SI.

The R6xx and RS780/RS880 chipset generations are currently not supported,
but might be added in the future.

The newest firmware can be found here: from
http://people.freedesktop.org/~agd5f/radeon_ucode/

A matching patch implementing the necessary userspace side will follow in
just a minute on the mesa devel list.

Cheers,
Christian.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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 wrote:

So i am facing a dilema regarding tiling on radeonsi. Given that we
now have a fixed table of tiling mode this put more pressure on the
kernel userspace api. I see either 2 solutions.


Enforce kernel to set at fixed index in the table best tiling mode for
given gpu for given format, such as DEPTH32_2D_4AA at index 4, or
COLOR_SCANOUT_2D at index 13 ... that way kernel can still adapt the
tile mode array value. Note that this match the design behind the tile
mode index being that there is a limited number of useful tile mode
combination and for each surface format  (depth/color/macro
tile/micro/tile) there is a best one.


Second solution is to add an ioctl to compute mipmap information in
kernel (pitch alignment slice size ...) based on format, size of the
surface.


Some might argue that we could just export the table content to
userspace, but that would loose information and possibly froze the
tile mode table forever as API. The information we loose is what index
match to prefered surface format/type combination. And the tile mode
might be considered API as if kernel ever change what userspace expect
then we might break some userspace.

Maybe I'm missing the problem, but if libdrm_radeon were to get the
tiling mode index chosen by radeonsi, and could retrieve the tiling
parameters for each index from the kernel, it should be able to
calculate things properly, shouldn't it?


Let's not discuss about who/where the index is pick. No matter where it
happens the question is do we want to hardcode tile index and make it api
or do we want to hide it behind symbolic name allowing change in tile array
(given that right now 4 value are already frozen). You can look at my
kernel patch to see what i mean.


Just as a side node: If I understood it correctly the hardware isn't
completely capable to use those indexes interchangeable, e.g. only a certain
range can be used for the DB, and another rule matters for AA indexes etc

I don't know those rules exactly and I don't know how strict they are, but
as far as I understood it even the closed source driver didn't need to mess
with it. So I'm something like 90% sure that hardcoding them is ok, but well
on the other hand it just doesn't feels good to do so...

The DB_[Z|STENCIL]_INFO.TILE_MODE_INDEX is only 3 bits so all of the
depth formats have to be within the first 8 slots.  The CB and texture
blocks support 5 bits for the index.  That's why the indices are laid
out like they are with the depth formats first.


Well, that makes sense. I just read on some internal docs that the DB 
unit can only use certain indexes, but they not mentioned why.


Thanks for the explanation,
Christian.


Alex


Christian.

Cheers,
Jerome



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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 *);  /* does not fail */
 
 Hmm.. thinking about that,.. you only need that second variant because
 you don't have a clear lock to wait for the 'older' process to
 complete; but having the unconditional wait makes the entire thing
 prone to accidents and deadlocks when the 'user' (read your fellow
 programmers) make a mistake.
 
 Ideally we'd only have the one primitive that returns -EDEADLK and use
 a 'proper' mutex to wait on or somesuch.. let me ponder this a bit
 more.

So I had me a little ponder..

Its all really about breaking the symmetry (equivalence of both sides)
of the deadlock. Lets start with the simplest AB-BA deadlock:

task-O  task-Y
  A
B
A -- blocks on O
  B -- blocks on Y

In this case the wound-wait algorithm says that the older task (O) has
precedence over the younger task (Y) and we'll 'kill' Y to allow
progress for O.

Now clearly we don't really want to kill Y, instead we'll allow its
lock operation to return -EDEADLK.

This would suggest that our 'new' mutex implementation (ww_mutex
henceforth) has owner tracking -- so O acquiring B can find Y to 'kill'
-- and that we have a new wakeup state TASK_DEADLOCK similar to
TASK_WAKEKILL (can we avoid this by using the extra state required
below? I don't think so since we'd have the risk of waking Y while it
would be blocked on a !ww_mutex)

Now this gets a little more interesting if we change the scenario a
little:

task-O  task-Y
  A
B
  B -- blocks on Y
* -- could be A

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'll not wait so our
TASK_DEADLOCK wakeup doesn't actually achieve anything.

Note that Y doesn't need to acquire A in order to return -EDEADLK, any
acquisition from the same set (see below) would return -EDEADLK even if
there isn't an actual deadlock. This is the cost of heuristic; we could
walk the actual block graph but that would be prohibitively expensive
since we'd have to do this on every acquire.

This raises the point of what would happen if Y were to acquire a
'regular' mutex in between the series of ww_mutexes. In this case we'd
clearly have an actual deadlock scenario. However lockdep would catch
this for we'd clearly invert the lock class order:

ww_mutex - other - ww_mutex

For the more complex scenarios there's the case of multiple waiters. In
this case its desirable to order the waiters in age order so that we
don't introduce age inversion -- this minimizes the amount of -EDEADLK
occurrences, but also allows doing away with the unconditional wait.

With the lock queue ordering we can simply immediately re-try the lock
acquisition sequence. Since the older task is already queued it will
obtain the lock, even if we re-queue ourselves before the lock is
assigned.

Now the one thing I've so far 'ignored' is how to assign age. Forward
progress guarantees demand that the age doesn't get reset on retries;
doing so would mean you're always pushing yourself fwd, decreasing your
'priority', never getting to be the most eligible. However it also
means that we should (re)set the time every time we start a 'new'
acquisition sequence. If we'd use a static (per task) age the task with
the lowest age would be able to 'starve' all other.

This means we need means to mark the start of an acquisition sequence;
one that is not included in the restart loop.

Having a start suggests having an end marker too, and indeed we can
find a reason for having one; suppose our second scenario above, where
Y has already acquired all locks it needs to proceed. In this case we
would have marked Y to fail on another acquisition. This doesn't seem
like a problem until you consider the case where we nest different
mm_mutex sets. In this case Y would -EDEADLK on the first of the second
(nested) set, even though re-trying that set is pointless, O doesn't
care.

Furthermore, considering the first scenario, O could block on a lock of
the first set when Y is blocked on a lock of the second (nested) set;
we need means of discerning the different lock sets. This cannot be
done by local means, that is, any context created by the start/end
markers would be local to that task and would not be recognizable by
another as to belong to the same group.

Instead we'd need to create a set-class, much like lockdep has and
somehow ensure all locks in a set are of that class.

One thing I'm not entirely sure of is the strict need for a local
context it could be used to track

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

2013-04-04 Thread Paul Menzel

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 chipset generations are currently not supported, but 
 might be added in the future.
 
 The newest firmware can be found here: from 
 http://people.freedesktop.org/~agd5f/radeon_ucode/
 
 A matching patch implementing the necessary userspace side will follow in 
 just a minute on the mesa devel list.

The patches for Mesa 3D can be found at [1]. Thanks!

Christian, could you add instructions how to best test these patches,
please.

Additionally could you contact distributions to provide testing packages
for easy testing.


Thanks,

Paul


[1] http://lists.freedesktop.org/archives/mesa-dev/2013-April/037049.html


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[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 type||

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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 Pinchart laurent.pinch...@ideasonboard.com
  Reviewed-by: Jani Nikula jani.nik...@intel.com
  ---
  
   tests/modetest/modetest.c | 41 -
   1 file changed, 28 insertions(+), 13 deletions(-)
  
  diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
  index 1d1f49d..91dabfc 100644
  --- a/tests/modetest/modetest.c
  +++ b/tests/modetest/modetest.c
  @@ -908,6 +908,9 @@ static void usage(char *name)
  
  fprintf(stderr, \t-s 
connector_id[@crtc_id]:mode[@format]\tset
  a mode\n); fprintf(stderr, \t-v\ttest vsynced page flipping\n);
  
  +   fprintf(stderr, \n Generic options:\n\n);
  +   fprintf(stderr, \t-M module\tuse the given driver\n);
 
 You didn't add it to the usage: ... line. Same goes for patch 05/21.

Good catch, thanks. I'll fix that.

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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   (1  20)
  #define RADEON_VA_RESERVED_SIZE   (8  20)
@@ -357,8 +360,9 @@ struct radeon_bo_list {
struct ttm_validate_buffer tv;
struct radeon_bo*bo;
uint64_tgpu_offset;
-   unsignedrdomain;
-   unsignedwdomain;
+   boolwritten;
+   unsigneddomain;
+   unsignedalt_domain;
u32 tiling_flags;
  };

I think that the change to the rdomain/wdomain should be in a patch
of its own. I think the change is fine but we had issue with change
that touched that part previously, would make bisecting and
understanding the change implication easier.

Agree, I actually planed to do so, but for the whole IP review stuff
we needed to maintain a more or less stable patch base. Long story,
but I'm going to change it.


@@ -826,7 +830,6 @@ struct radeon_cs_reloc {
struct radeon_bo*robj;
struct radeon_bo_list   lobj;
uint32_thandle;
-   uint32_tflags;
  };

Why removing the flags ? iirc it's not really use right now but i
remember plan to use it.

Ups, just a rebasing artifact. But when it's unused we should remove
it, probably just not in this patch.


[SNIP]

+static int radeon_uvd_cs_reloc(struct radeon_cs_parser *p, int data0, int 
data1)
+{
+   struct radeon_cs_chunk *relocs_chunk;
+   struct radeon_cs_reloc *reloc;
+   unsigned idx, cmd;
+   uint64_t start, end;
+
+   relocs_chunk = p-chunks[p-chunk_relocs_idx];
+   idx = radeon_get_ib_value(p, data1);
+   if (idx = relocs_chunk-length_dw) {
+   DRM_ERROR(Relocs at %d after relocations chunk end %d !\n,
+ idx, relocs_chunk-length_dw);
+   return -EINVAL;
+   }
+
+   reloc = p-relocs_ptr[(idx / 4)];
+   start = reloc-lobj.gpu_offset;
+   end = start + radeon_bo_size(reloc-robj);
+   start += radeon_get_ib_value(p, data0);

I am assuming there is no way for you to know the size that the uvd engine will 
write to ?
You are not checking anything on uvd possibly overwritting after the bo end.

Yeah that gave me headache for a quite long time, too. The problem
is to figure out how much is actually written you need to keep track
of the whole lot of informations including the UVD session,
create/decode/destroy messages and allot of fiddling with the codec
specific parameters.

And if I understand the UVD internals correctly even if we check
everything there is no guarantee that a special crafted bitstream
could not let UVD to write over the end of the buffer

Is it ok if we but a big TODO on it for the initial patch?

Cheers,
Christian.

I think i only need one assurance and i think for uvd this will be the case.
If UVD block write past bo end can you be sure that no matter what it will
overwritte to address  start ie it could not overwritte to begining of VRAM.

I have big doubt on that given the 256M window, i fear that it might go back
to writting to begining of memory where the page table is.


Crafting an attack from it would still be a bit tricky because it is 
compressed image data that gets written, but never less it is indeed 
possible.



Note that i think that now that we have cp dma pagetable entry update we can
probably just move the pagetable to end of vram on 90% GPU with UVD this will
be  256M which seems like a zone where UVD can never write.


Well not exactly, it is planned that the 256M limit goes away with some 
of the next hw generations. And at least at this point we need to make 
sure that UVD never writes somewhere it shouldn't. Anyway moving the 
page table to not CPU accessible VRAM sounds like a pretty good idea.



If we can have such assurance i guess we can make uvd as an option and make
a very explicit comment stating that UVD engine can be use as an exploit
vector path.


I think I will just sit down and implement size checking, at least for 
the destination buffer, cause after all that's just a texture. And for 
the reference buffer I maybe just use what userspace send to the 
hardware as buffer size, and make a sanity check on that one also.


Ok, need to think about it a bit more.


Jerome



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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 ww_mutex *); /* returns -EDEADLK */
int mutex_wait_lock(struct ww_mutex *);  /* does not fail */
  
  Hmm.. thinking about that,.. you only need that second variant because
  you don't have a clear lock to wait for the 'older' process to
  complete; but having the unconditional wait makes the entire thing
  prone to accidents and deadlocks when the 'user' (read your fellow
  programmers) make a mistake.
  
  Ideally we'd only have the one primitive that returns -EDEADLK and use
  a 'proper' mutex to wait on or somesuch.. let me ponder this a bit
  more.
 
 So I had me a little ponder..

I need to chew some more through this, but figured some early comments to
clarify a few things would be good.

 Its all really about breaking the symmetry (equivalence of both sides)
 of the deadlock. Lets start with the simplest AB-BA deadlock:
 
   task-O  task-Y
 A
   B
   A -- blocks on O
 B -- blocks on Y
 
 In this case the wound-wait algorithm says that the older task (O) has
 precedence over the younger task (Y) and we'll 'kill' Y to allow
 progress for O.
 
 Now clearly we don't really want to kill Y, instead we'll allow its
 lock operation to return -EDEADLK.
 
 This would suggest that our 'new' mutex implementation (ww_mutex
 henceforth) has owner tracking -- so O acquiring B can find Y to 'kill'
 -- and that we have a new wakeup state TASK_DEADLOCK similar to
 TASK_WAKEKILL (can we avoid this by using the extra state required
 below? I don't think so since we'd have the risk of waking Y while it
 would be blocked on a !ww_mutex)

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 immedieately returns -EAGAIN to indicate the deadlock.

Aside, there's a bit of fun in that ttm uses -EDEADLCK for when you try to
reserve the same buffer twice - it can easily detect that by comparing the
lock owner ticket with the provided one and if it matches bail out. The
special error code is useful since userspace could prepare a gpu
batch command submission which lists a buffer twice, which is a userspace
bug with the current drm/gem apis. But since userspace usually doesn't try
to trick the kernel it's better to detect this lazily, and due to the
retry logic we have all the relevant error bail-out code anyway.

Hence we've kept the special -EDEADLCK semantics even for the ww_mutex
stuff.

 Now this gets a little more interesting if we change the scenario a
 little:
 
   task-O  task-Y
 A
   B
 B -- blocks on Y
   * -- could be A

The current code at least simple blocks task-O on B until task-Y unlocks
B. Deadlocks cannot happen since if task-Y ever tries to acquire a lock
which is held by an older task (e.g. lock A) it will bail out with
-EAGAIN.

 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'll not wait so our
 TASK_DEADLOCK wakeup doesn't actually achieve anything.
 
 Note that Y doesn't need to acquire A in order to return -EDEADLK, any
 acquisition from the same set (see below) would return -EDEADLK even if
 there isn't an actual deadlock. This is the cost of heuristic; we could
 walk the actual block graph but that would be prohibitively expensive
 since we'd have to do this on every acquire.

Hm, I guess your aim with the TASK_DEADLOCK wakeup is to bound the wait
times of older task. This could be interesting for RT, but I'm unsure of
the implications. 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_mutex it tries to acquire.

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 can't really preempt fairness isn't that high a priority, either.
So we didn't think too much about that.

 This raises the point of what would happen if Y were to acquire a
 'regular' mutex in between the series of ww_mutexes. In this case we'd
 clearly have an actual deadlock scenario. However lockdep would catch
 this for we'd clearly invert the lock class order:
 
   ww_mutex - other - ww_mutex
 
 For the more complex scenarios there's the case

[PATCH] radeon: add si tiling support v2

2013-04-04 Thread j . glisse

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 +++
 3 files changed, 711 insertions(+), 45 deletions(-)

diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index 00d66b3..ff3ce3a 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -509,6 +509,7 @@ typedef struct {
 #define DRM_RADEON_GEM_SET_TILING  0x28
 #define DRM_RADEON_GEM_GET_TILING  0x29
 #define DRM_RADEON_GEM_BUSY0x2a
+#define DRM_RADEON_GEM_VA  0x2b
 
 #define DRM_IOCTL_RADEON_CP_INITDRM_IOW( DRM_COMMAND_BASE + 
DRM_RADEON_CP_INIT, drm_radeon_init_t)
 #define DRM_IOCTL_RADEON_CP_START   DRM_IO(  DRM_COMMAND_BASE + 
DRM_RADEON_CP_START)
@@ -550,6 +551,7 @@ typedef struct {
 #define DRM_IOCTL_RADEON_SET_TILINGDRM_IOWR(DRM_COMMAND_BASE + 
DRM_RADEON_GEM_SET_TILING, struct drm_radeon_gem_set_tiling)
 #define DRM_IOCTL_RADEON_GET_TILINGDRM_IOWR(DRM_COMMAND_BASE + 
DRM_RADEON_GEM_GET_TILING, struct drm_radeon_gem_get_tiling)
 #define DRM_IOCTL_RADEON_GEM_BUSY  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_RADEON_GEM_BUSY, struct drm_radeon_gem_busy)
+#define DRM_IOCTL_RADEON_GEM_VADRM_IOWR(DRM_COMMAND_BASE + 
DRM_RADEON_GEM_VA, struct drm_radeon_gem_va)
 
 typedef struct drm_radeon_init {
enum {
@@ -882,6 +884,27 @@ struct drm_radeon_gem_pwrite {
uint64_t data_ptr;
 };
 
+#define RADEON_VA_MAP  1
+#define RADEON_VA_UNMAP2
+
+#define RADEON_VA_RESULT_OK0
+#define RADEON_VA_RESULT_ERROR 1
+#define RADEON_VA_RESULT_VA_EXIST  2
+
+#define RADEON_VM_PAGE_VALID   (1  0)
+#define RADEON_VM_PAGE_READABLE(1  1)
+#define RADEON_VM_PAGE_WRITEABLE   (1  2)
+#define RADEON_VM_PAGE_SYSTEM  (1  3)
+#define RADEON_VM_PAGE_SNOOPED (1  4)
+
+struct drm_radeon_gem_va {
+   uint32_thandle;
+   uint32_toperation;
+   uint32_tvm_id;
+   uint32_tflags;
+   uint64_toffset;
+};
+
 #define RADEON_CHUNK_ID_RELOCS 0x01
 #define RADEON_CHUNK_ID_IB 0x02
 
@@ -916,6 +939,26 @@ struct drm_radeon_cs {
 #define RADEON_INFO_ACCEL_WORKING2 0x05
 #define RADEON_INFO_TILING_CONFIG  0x06
 #define RADEON_INFO_WANT_HYPERZ0x07
+#define RADEON_INFO_WANT_CMASK 0x08 /* get access to CMASK on r300 */
+#define RADEON_INFO_CLOCK_CRYSTAL_FREQ 0x09 /* clock crystal frequency */
+#define RADEON_INFO_NUM_BACKENDS   0x0a /* DB/backends for r600+ - need 
for OQ */
+#define RADEON_INFO_NUM_TILE_PIPES 0x0b /* tile pipes for r600+ */
+#define RADEON_INFO_FUSION_GART_WORKING0x0c /* fusion writes to GTT 
were broken before this */
+#define RADEON_INFO_BACKEND_MAP0x0d /* pipe to backend map, 
needed by mesa */
+/* virtual address start, va  start are reserved by the kernel */
+#define RADEON_INFO_VA_START   0x0e
+/* maximum size of ib using the virtual memory cs */
+#define RADEON_INFO_IB_VM_MAX_SIZE 0x0f
+/* max pipes - needed for compute shaders */
+#define RADEON_INFO_MAX_PIPES  0x10
+/* timestamp for GL_ARB_timer_query (OpenGL), returns the current GPU clock */
+#define RADEON_INFO_TIMESTAMP  0x11
+/* max shader engines (SE) - needed for geometry shaders, etc. */
+#define RADEON_INFO_MAX_SE 0x12
+/* max SH per SE */
+#define RADEON_INFO_MAX_SH_PER_SE  0x13
+/* SI tile mode array */
+#define RADEON_INFO_SI_TILE_MODE_ARRAY 0x14
 
 struct drm_radeon_info {
uint32_trequest;
@@ -923,4 +966,22 @@ struct drm_radeon_info {
uint64_tvalue;
 };
 
+/* Those correspond to the tile index to use, this is to explicitly state
+ * the API that is implicitly defined by the tile mode array.
+ */
+#define SI_TILE_MODE_COLOR_LINEAR_ALIGNED  8
+#define SI_TILE_MODE_COLOR_1D  13
+#define SI_TILE_MODE_COLOR_1D_SCANOUT  9
+#define SI_TILE_MODE_COLOR_2D_8BPP 14
+#define SI_TILE_MODE_COLOR_2D_16BPP15
+#define SI_TILE_MODE_COLOR_2D_32BPP16
+#define SI_TILE_MODE_COLOR_2D_64BPP17
+#define SI_TILE_MODE_COLOR_2D_SCANOUT_16BPP11
+#define SI_TILE_MODE_COLOR_2D_SCANOUT_32BPP12
+#define SI_TILE_MODE_DEPTH_STENCIL_1D  4
+#define SI_TILE_MODE_DEPTH_STENCIL_2D  0
+#define SI_TILE_MODE_DEPTH_STENCIL_2D_2AA  3
+#define SI_TILE_MODE_DEPTH_STENCIL_2D_4AA  3
+#define SI_TILE_MODE_DEPTH_STENCIL_2D_8AA  2
+
 #endif
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 5935c23..2056899 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -83,12 +83,15 @@ typedef int (*hw_best_surface_t)(struct

[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
the gr3d engine via the same DRM IOCTLs that gr2d uses. A very basic
set of programs to test this can be found here[0].

Patch 2 adds support for the XBGR format, which seems to be what
most gr3d programs use. It also adds the RGB565 as a format supported
by planes. This latter part could be moved to a separate patch, but I
didn't think that was necessary.

Patch 3 finally allows buffer objects to be marked as tiled so that
the display controller can scan them out appropriately.

Thierry

[0]: https://github.com/organizations/grate-driver

Thierry Reding (3):
  WIP: drm/tegra: Add 3D support
  drm/tegra: Support the XBGR pixelformat
  drm/tegra: Add support for tiled buffer objects

 drivers/gpu/host1x/Makefile   |   1 +
 drivers/gpu/host1x/dev.c  |   7 +
 drivers/gpu/host1x/dev.h  |   1 +
 drivers/gpu/host1x/drm/dc.c   |  16 +++
 drivers/gpu/host1x/drm/dc.h   |   4 +
 drivers/gpu/host1x/drm/drm.c  |   4 +-
 drivers/gpu/host1x/drm/drm.h  |   2 +
 drivers/gpu/host1x/drm/fb.c   |  12 +-
 drivers/gpu/host1x/drm/gem.c  |  20 ++-
 drivers/gpu/host1x/drm/gem.h  |  13 +-
 drivers/gpu/host1x/drm/gr3d.c | 289 ++
 drivers/gpu/host1x/host1x.h   |   3 +-
 include/uapi/drm/tegra_drm.h  |   2 +
 13 files changed, 360 insertions(+), 14 deletions(-)
 create mode 100644 drivers/gpu/host1x/drm/gr3d.c

-- 
1.8.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[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 a try. I can probably arrange to
test it on a CardHu if nobody else steps up, but it'll take a while
until I get that setup. Looking at the downstream kernels indicates that
Tegra30 has a second clock and powergate domain and if those really are
required then this patch won't work on Tegra30.

One other important piece that is missing is a list of address registers
to feed to the firewall so that submitted command streams can be checked
for validity. I've already talked to Terje about that, but it seems like
it may turn out to be problematic. What with NVIDIA not wanting to
provide the register descriptions and all that. We'll need to resolve
this in some way before this patch can be merged.

Finally I want to refactor some of the commonalities between gr2d and
gr3d so that they can share more code.

If people want to give this a spin, there are some very basic test
programs available here[0]. The tests from the grate repository are
probably the most useful right now since they test both the gr2d and
gr3d modules and therefore can be used to verify that this patch
actually works.

[0]: https://github.com/organizations/grate-driver

Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
 drivers/gpu/host1x/Makefile   |   1 +
 drivers/gpu/host1x/dev.c  |   7 +
 drivers/gpu/host1x/dev.h  |   1 +
 drivers/gpu/host1x/drm/drm.c  |   2 +
 drivers/gpu/host1x/drm/gr3d.c | 289 ++
 drivers/gpu/host1x/host1x.h   |   3 +-
 6 files changed, 302 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/host1x/drm/gr3d.c

diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
index 3b037b6..5802e1b 100644
--- a/drivers/gpu/host1x/Makefile
+++ b/drivers/gpu/host1x/Makefile
@@ -17,4 +17,5 @@ host1x-$(CONFIG_DRM_TEGRA) += drm/drm.o drm/fb.o drm/dc.o
 host1x-$(CONFIG_DRM_TEGRA) += drm/output.o drm/rgb.o drm/hdmi.o
 host1x-$(CONFIG_DRM_TEGRA) += drm/gem.o
 host1x-$(CONFIG_DRM_TEGRA) += drm/gr2d.o
+host1x-$(CONFIG_DRM_TEGRA) += drm/gr3d.o
 obj-$(CONFIG_TEGRA_HOST1X) += host1x.o
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index 28e28a2..6daa3be 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -213,11 +213,17 @@ static int __init tegra_host1x_init(void)
err = platform_driver_register(tegra_gr2d_driver);
if (err  0)
goto unregister_hdmi;
+
+   err = platform_driver_register(tegra_gr3d_driver);
+   if (err  0)
+   goto unregister_gr2d;
 #endif
 
return 0;
 
 #ifdef CONFIG_DRM_TEGRA
+unregister_gr2d:
+   platform_driver_unregister(tegra_gr2d_driver);
 unregister_hdmi:
platform_driver_unregister(tegra_hdmi_driver);
 unregister_dc:
@@ -232,6 +238,7 @@ module_init(tegra_host1x_init);
 static void __exit tegra_host1x_exit(void)
 {
 #ifdef CONFIG_DRM_TEGRA
+   platform_driver_unregister(tegra_gr3d_driver);
platform_driver_unregister(tegra_gr2d_driver);
platform_driver_unregister(tegra_hdmi_driver);
platform_driver_unregister(tegra_dc_driver);
diff --git a/drivers/gpu/host1x/dev.h b/drivers/gpu/host1x/dev.h
index a1607d6..406237a 100644
--- a/drivers/gpu/host1x/dev.h
+++ b/drivers/gpu/host1x/dev.h
@@ -304,5 +304,6 @@ static inline void host1x_hw_show_mlocks(struct host1x 
*host, struct output *o)
 extern struct platform_driver tegra_hdmi_driver;
 extern struct platform_driver tegra_dc_driver;
 extern struct platform_driver tegra_gr2d_driver;
+extern struct platform_driver tegra_gr3d_driver;
 
 #endif
diff --git a/drivers/gpu/host1x/drm/drm.c b/drivers/gpu/host1x/drm/drm.c
index 2b561c9..298c5f0 100644
--- a/drivers/gpu/host1x/drm/drm.c
+++ b/drivers/gpu/host1x/drm/drm.c
@@ -85,9 +85,11 @@ static int host1x_parse_dt(struct host1x_drm *host1x)
nvidia,tegra20-dc,
nvidia,tegra20-hdmi,
nvidia,tegra20-gr2d,
+   nvidia,tegra20-gr3d,
nvidia,tegra30-dc,
nvidia,tegra30-hdmi,
nvidia,tegra30-gr2d,
+   nvidia,tegra30-gr3d,
};
unsigned int i;
int err;
diff --git a/drivers/gpu/host1x/drm/gr3d.c b/drivers/gpu/host1x/drm/gr3d.c
new file mode 100644
index 000..58fe791
--- /dev/null
+++ b/drivers/gpu/host1x/drm/gr3d.c
@@ -0,0 +1,289 @@
+/*
+ * Copyright (C) 2013 Avionic Design GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/clk.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/tegra-powergate.h
+

[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 b/drivers/gpu/host1x/drm/dc.c
index edfe0ee..14a09a4 100644
--- a/drivers/gpu/host1x/drm/dc.c
+++ b/drivers/gpu/host1x/drm/dc.c
@@ -108,7 +108,9 @@ static const struct drm_plane_funcs tegra_plane_funcs = {
 };
 
 static const uint32_t plane_formats[] = {
+   DRM_FORMAT_XBGR,
DRM_FORMAT_XRGB,
+   DRM_FORMAT_RGB565,
DRM_FORMAT_UYVY,
DRM_FORMAT_YUV420,
DRM_FORMAT_YUV422,
@@ -546,6 +548,9 @@ int tegra_dc_setup_window(struct tegra_dc *dc, unsigned int 
index,
 unsigned int tegra_dc_format(uint32_t format)
 {
switch (format) {
+   case DRM_FORMAT_XBGR:
+   return WIN_COLOR_DEPTH_R8G8B8A8;
+
case DRM_FORMAT_XRGB:
return WIN_COLOR_DEPTH_B8G8R8A8;
 
-- 
1.8.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[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 +++
 drivers/gpu/host1x/drm/dc.h  |  4 
 drivers/gpu/host1x/drm/drm.c |  2 +-
 drivers/gpu/host1x/drm/drm.h |  2 ++
 drivers/gpu/host1x/drm/fb.c  | 12 +++-
 drivers/gpu/host1x/drm/gem.c | 20 +---
 drivers/gpu/host1x/drm/gem.h | 13 +
 include/uapi/drm/tegra_drm.h |  2 ++
 8 files changed, 53 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/host1x/drm/dc.c b/drivers/gpu/host1x/drm/dc.c
index 14a09a4..5a0d111 100644
--- a/drivers/gpu/host1x/drm/dc.c
+++ b/drivers/gpu/host1x/drm/dc.c
@@ -51,6 +51,7 @@ static int tegra_plane_update(struct drm_plane *plane, struct 
drm_crtc *crtc,
window.dst.h = crtc_h;
window.format = tegra_dc_format(fb-pixel_format);
window.bits_per_pixel = fb-bits_per_pixel;
+   window.tiled = tegra_fb_is_tiled(fb);
 
for (i = 0; i  drm_format_num_planes(fb-pixel_format); i++) {
struct tegra_bo *bo = tegra_fb_get_plane(fb, i);
@@ -492,6 +493,16 @@ int tegra_dc_setup_window(struct tegra_dc *dc, unsigned 
int index,
tegra_dc_writel(dc, h_offset, DC_WINBUF_ADDR_H_OFFSET);
tegra_dc_writel(dc, v_offset, DC_WINBUF_ADDR_V_OFFSET);
 
+   if (window-tiled) {
+   value = DC_WIN_BUFFER_ADDR_MODE_TILE_UV |
+   DC_WIN_BUFFER_ADDR_MODE_TILE;
+   } else {
+   value = DC_WIN_BUFFER_ADDR_MODE_LINEAR_UV |
+   DC_WIN_BUFFER_ADDR_MODE_LINEAR;
+   }
+
+   tegra_dc_writel(dc, value, DC_WIN_BUFFER_ADDR_MODE);
+
value = WIN_ENABLE;
 
if (yuv) {
diff --git a/drivers/gpu/host1x/drm/dc.h b/drivers/gpu/host1x/drm/dc.h
index 79eaec9..e8da0ba 100644
--- a/drivers/gpu/host1x/drm/dc.h
+++ b/drivers/gpu/host1x/drm/dc.h
@@ -365,6 +365,10 @@
 #define DC_WIN_BUF_STRIDE  0x70b
 #define DC_WIN_UV_BUF_STRIDE   0x70c
 #define DC_WIN_BUFFER_ADDR_MODE0x70d
+#define DC_WIN_BUFFER_ADDR_MODE_LINEAR(0   0)
+#define DC_WIN_BUFFER_ADDR_MODE_TILE  (1   0)
+#define DC_WIN_BUFFER_ADDR_MODE_LINEAR_UV (0  16)
+#define DC_WIN_BUFFER_ADDR_MODE_TILE_UV   (1  16)
 #define DC_WIN_DV_CONTROL  0x70e
 
 #define DC_WIN_BLEND_NOKEY 0x70f
diff --git a/drivers/gpu/host1x/drm/drm.c b/drivers/gpu/host1x/drm/drm.c
index 298c5f0..33d04c3 100644
--- a/drivers/gpu/host1x/drm/drm.c
+++ b/drivers/gpu/host1x/drm/drm.c
@@ -328,7 +328,7 @@ static int tegra_gem_create(struct drm_device *drm, void 
*data,
struct drm_tegra_gem_create *args = data;
struct tegra_bo *bo;
 
-   bo = tegra_bo_create_with_handle(file, drm, args-size,
+   bo = tegra_bo_create_with_handle(file, drm, args-size, args-flags,
 args-handle);
if (IS_ERR(bo))
return PTR_ERR(bo);
diff --git a/drivers/gpu/host1x/drm/drm.h b/drivers/gpu/host1x/drm/drm.h
index 02ce020..fd1f373 100644
--- a/drivers/gpu/host1x/drm/drm.h
+++ b/drivers/gpu/host1x/drm/drm.h
@@ -162,6 +162,7 @@ struct tegra_dc_window {
unsigned int format;
unsigned int stride[2];
unsigned long base[3];
+   bool tiled;
 };
 
 /* from dc.c */
@@ -262,6 +263,7 @@ extern int tegra_output_exit(struct tegra_output *output);
 /* from fb.c */
 struct tegra_bo *tegra_fb_get_plane(struct drm_framebuffer *framebuffer,
unsigned int index);
+bool tegra_fb_is_tiled(struct drm_framebuffer *framebuffer);
 extern int tegra_drm_fb_init(struct drm_device *drm);
 extern void tegra_drm_fb_exit(struct drm_device *drm);
 extern void tegra_fbdev_restore_mode(struct tegra_fbdev *fbdev);
diff --git a/drivers/gpu/host1x/drm/fb.c b/drivers/gpu/host1x/drm/fb.c
index 953e418..b8b3c21 100644
--- a/drivers/gpu/host1x/drm/fb.c
+++ b/drivers/gpu/host1x/drm/fb.c
@@ -34,6 +34,16 @@ struct tegra_bo *tegra_fb_get_plane(struct drm_framebuffer 
*framebuffer,
return fb-planes[index];
 }
 
+bool tegra_fb_is_tiled(struct drm_framebuffer *framebuffer)
+{
+   struct tegra_fb *fb = to_tegra_fb(framebuffer);
+
+   if (fb-planes[0]-flags  TEGRA_BO_TILED)
+   return true;
+
+   return false;
+}
+
 static void tegra_fb_destroy(struct drm_framebuffer *framebuffer)
 {
struct tegra_fb *fb = to_tegra_fb(framebuffer);
@@ -188,7 +198,7 @@ static int tegra_fbdev_probe(struct drm_fb_helper *helper,
 
size = cmd.pitches[0] * cmd.height;
 
-   bo = tegra_bo_create(drm, size);
+   bo = tegra_bo_create(drm, size, 0);
if (IS_ERR(bo))
return PTR_ERR(bo);
 
diff --git a/drivers/gpu/host1x/drm/gem.c b/drivers/gpu/host1x/drm/gem.c
index c5e9a9b..0bdbb50 100644
---

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 (RV770/RV790 is 
earlier than RV710). I'm working on it and the difference isn't so big 
so it might be possible to handle those as well.


Cheers,
Christian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[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
Classification: Unclassified
OS: Linux (All)
  Reporter: abortretryf...@gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/DRI/R600
   Product: Mesa

Created attachment 77426
  -- https://bugs.freedesktop.org/attachment.cgi?id=77426action=edit
dmesg output from when the GPU resets. This keeps happening until the game is
killed or you look away from whatever is causing the lockup.

This might be related to bug #61721, as it also occurs on my machine.

When playing Half Life 2 Deathmatch, the game runs great until certain scenes
cause a GPU lockup.

When run with R600_DEBUG=nohyperz there's no lockup, but performance is much
slower. (from ~85fps vsync 1400x1050 down to ~45fps w/o HyperZ)

I'll see if I can get an apitrace tonight.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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:

https://github.com/grate-driver

Thanks Rob for pointing this out!

Thierry


pgpWd1C6JYE_W.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[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 3.8.5-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.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[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.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[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 bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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 optional, if not specified the plane will be positioned at
   the center of the screen as before.
   
   Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
   ---
   
tests/modetest/modetest.c | 72 ++--
1 file changed, 57 insertions(+), 15 deletions(-)
   
   diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
   index 7153a40..f95efe6 100644
   --- a/tests/modetest/modetest.c
   +++ b/tests/modetest/modetest.c
   @@ -645,6 +645,7 @@ struct connector_arg {
   
struct plane_arg {

 uint32_t con_id;  /* the id of connector to bind to */
   
   + uint32_t x, y;
  
  I'd like the coordinates to allow negative values too.
 
 Tested it and it actually works w/ negative values thanks to the way
 strtoul() works :) The only real obstacle is the magic '-1' handling.
 I guess you should just give up on magic values and add some flag to
 indicate whether the user provided the coords or not.

Done :-) I'll post a new version.

 Also I must say that I don't like the syntax you used for specifying the
 coords. '(' and ')' need to be escaped or the shell eats them. I've been
 using the x11 -geometry syntax whenever I have to deal with the x/y/w/h
 combination. It's a reasonably well known syntax and doesn't have these
 shell issues. Maybe you could use it here as well.

Given that negative coordinates in the X geometry syntax don't match we what 
need, should I keep the current syntax, abuse the X geometry syntax, or use 
something else ?

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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 into its own file, made the smaller funcs
 static inline, used 64bit maths in the scaled clipping function to
 avoid overflows (instead it will saturate to INT_MIN or INT_MAX).
 v3: Renamed drm_region to drm_rect, drm_region_clip to
 drm_rect_intersect, and drm_region_subsample to drm_rect_downscale.
 
 Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
 ---
  drivers/gpu/drm/Makefile   |   3 +-
  drivers/gpu/drm/drm_rect.c |  96 +
  include/drm/drm_rect.h | 132 ++
  3 files changed, 230 insertions(+), 1 deletion(-)
  create mode 100644 drivers/gpu/drm/drm_rect.c
  create mode 100644 include/drm/drm_rect.h
 

[snip]

 diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
 new file mode 100644
 index 000..1ad4f5e
 --- /dev/null
 +++ b/drivers/gpu/drm/drm_rect.c
 @@ -0,0 +1,96 @@

[snip]

 +#include linux/errno.h
 +#include linux/export.h
 +#include linux/kernel.h
 +#include drm/drm_rect.h
 +
 +/**
 + * drm_rect_intersect - intersect two rectangles
 + * @r1: first rectangle
 + * @r2: second rectangle
 + *
 + * Calculate the intersection of rectangles @r1 and @r2.
 + * @r1 will be overwritten with the intersection.
 + *
 + * RETURNS:
 + * @true if rectangle @r1 is still visible after the operation,
 + * @false otherwise.

Isn't @ used for function parameters only ?

 + */
 +bool drm_rect_intersect(struct drm_rect *r1, const struct drm_rect *r2)
 +{
 + r1-x1 = max(r1-x1, r2-x1);
 + r1-y1 = max(r1-y1, r2-y1);
 + r1-x2 = min(r1-x2, r2-x2);
 + r1-y2 = min(r1-y2, r2-y2);
 +
 + return drm_rect_visible(r1);

Do callers always need that information, or should they instead call 
drm_rect_visible() explicitly when they need it ?

 +}
 +EXPORT_SYMBOL(drm_rect_intersect);
 +
 +/**
 + * drm_rect_clip_scaled - perform a scaled clip operation
 + * @src: source window rectangle
 + * @dst: destination window rectangle
 + * @clip: clip rectangle
 + * @hscale: horizontal scaling factor
 + * @vscale: vertical scaling factor
 + *
 + * Clip rectangle @dst by rectangle @clip. Clip rectangle @src by the
 + * same amounts multiplied by @hscale and @vscale.
 + *
 + * RETUTRNS:
 + * @true if rectangle @dst is still visible after being clipped,
 + * @false otherwise
 + */
 +bool drm_rect_clip_scaled(struct drm_rect *src, struct drm_rect *dst,
 +   const struct drm_rect *clip,
 +   int hscale, int vscale)
 +{
 + int diff;
 +
 + diff = clip-x1 - dst-x1;
 + if (diff  0) {
 + int64_t tmp = src-x1 + (int64_t) diff * hscale;
 + src-x1 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
 + }
 + diff = clip-y1 - dst-y1;
 + if (diff  0) {
 + int64_t tmp = src-y1 + (int64_t) diff * vscale;
 + src-y1 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
 + }
 + diff = dst-x2 - clip-x2;
 + if (diff  0) {
 + int64_t tmp = src-x2 - (int64_t) diff * hscale;
 + src-x2 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
 + }
 + diff = dst-y2 - clip-y2;
 + if (diff  0) {
 + int64_t tmp = src-y2 - (int64_t) diff * vscale;
 + src-y2 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
 + }
 +
 + return drm_rect_intersect(dst, clip);
 +}
 +EXPORT_SYMBOL(drm_rect_clip_scaled);
 diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
 new file mode 100644
 index 000..40b09a4
 --- /dev/null
 +++ b/include/drm/drm_rect.h
 @@ -0,0 +1,132 @@

[snip]

 +/**
 + * drm_rect - two dimensional rect
 + * @x1: horizontal starting coordinate (inclusive)
 + * @x2: horizontal ending coordinate (exclusive)
 + * @y1: vertical starting coordinate (inclusive)
 + * @y2: vertical ending coordinate (exclusive)

What's the rationale for making x2 and y2 exclusive ?

 + */
 +struct drm_rect {
 + int x1, y1, x2, y2;
 +};
 +
 +/**
 + * drm_rect_adjust_size - adjust the size of the rect
 + * @r: rect to be adjusted
 + * @x: horizontal adjustment
 + * @y: vertical adjustment

What about renaming x and y to dx and dy ? It would make it more explicit that 
the adjustements are incremental and not absolute values.

 + * Change the size of rect @r by @x in the horizontal direction,
 + * and by @y in the vertical direction, while keeping the center
 + * of @r stationary.
 + *
 + * Positive @x and @y increase the size, negative values decrease it.
 + */
 +static inline void drm_rect_adjust_size(struct drm_rect *r, int x, int y)
 +{
 + r-x1 -= x  1;
 + r-y1 -= y  1;
 + r-x2 += (x + 1)  1;
 + r-y2 += (y + 1)  1;
 +}
 +
 +/**
 + * drm_rect_translate - translate the rect
 + * @r: rect to be

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
C
C
B

At this point O finds that Y owns B and thus we want to make Y 'yield'
B to make allow B progress. Since Y is blocked, we'll send a wakeup.
However Y is blocked on a different locking primitive; one that doesn't
collaborate in the -EDEADLK scheme therefore we don't want the wakeup to
succeed.



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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