[Bug 70706] Regression in fbconfig
https://bugs.freedesktop.org/show_bug.cgi?id=70706 --- Comment #19 from Emil Velikov --- Might be worth testing these two patches [1] [2] [1] http://patchwork.freedesktop.org/patch/20458/ [2] http://patchwork.freedesktop.org/patch/20464/ -- You are receiving this mail because: You are on the CC list for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140217/0d4026bf/attachment.html>
GeForce 6100 (NV4E) & nouveau regression in 3.12
On Sun, Feb 16, 2014 at 2:15 PM, Rafa? Mi?ecki wrote: > 2014-02-16 19:55 GMT+01:00 Ilia Mirkin : >> On Sun, Feb 16, 2014 at 10:17 AM, Rafa? Mi?ecki wrote: >>> 2014-02-11 11:41 GMT+01:00 Ilia Mirkin : (b) bisect. you can (almost) definitely restrict the bisect to drivers/gpu/drm/nouveau. if you have additional computational power, i would recommend looking into distcc for speeding up the compiles. it may be interesting to also try 3.6.x since 3.7 received a pretty big rewrite. but a git bisect is a lot more direct in figuring these things out :) After I watched your video, it definitely brought back memories of another bug or perhaps email on this list a while back (definitely within the past year), but unfortunately I can't quite place it :( >>> >>> I've finally bisected between 3.10 and 3.11: >>> >>> 78ae0ad403daf11cf63da86923d2b5dbeda3af8f is the first bad commit >>> commit 78ae0ad403daf11cf63da86923d2b5dbeda3af8f >>> Author: Ben Skeggs >>> Date: Wed Aug 21 11:30:36 2013 +1000 >>> >>> drm/nv04/disp: fix framebuffer pin refcounting >>> >>> I've booted that commit and one commit older few times. Every time I >>> booted 78ae0ad I got corruption. Every time I booted 6ff8c76 (it's the >>> earlier commit), it was OK. >> >> But I bet if you restart X, you get a backtrace, right? > > That's right. > > 78ae0ad: > Corruptions > > 6ff8c76: > WARNING: at drivers/gpu/drm/nouveau/nouveau_bo.c:151 > nouveau_bo_del_ttm+0x80/0x90 [nouveau]() > (after quiting X by "init 3") OK, as expected. And those backtraces are the fallout from a boatload of ttm changes that went into 3.10. So 3.9 should be safe for you :) So that these findings don't get lost/forgotten, mind filing a bug with your various findings as per http://nouveau.freedesktop.org/wiki/Bugs/ ? Unfortunately I have never observed your particular issue on any of my pre-nv50 cards (nv05/18/34/42/44), so there must be some special component. Perhaps it's the IGP-ness. Although others with IGP's haven't complained about this. -ilia
[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=75112 Alex Deucher changed: What|Removed |Added Depends on||74784 -- 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/20140217/6deaca0d/attachment.html>
[Bug 74784] [hyperz] Strange artifacts when rendering trees in Dota 2
https://bugs.freedesktop.org/show_bug.cgi?id=74784 Alex Deucher changed: What|Removed |Added Summary|Strange artifacts when |[hyperz] Strange artifacts |rendering trees in Dota 2 |when rendering trees in ||Dota 2 Blocks||75112 -- 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/20140217/e936a881/attachment.html>
[radeonsi] si_populate_sq_ramping_values
Hi, In si_dpm.c, si_populate_sq_ramping_values function, It should be SISLANDS_DPM2_SQ_RAMP_LTI_RATIO instead of NISLANDS_DPM2_SQ_RAMP_LTI_RATIO. Moreover should it be: if (SISLANDS_DPM2_SQ_RAMP_LTI_RATIO > (LTI_RATIO_MASK >> LTI_RATIO_SHIFT)) instead of: if (NISLANDS_DPM2_SQ_RAMP_LTI_RATIO <= (LTI_RATIO_MASK >> LTI_RATIO_SHIFT)) The previous does disable "sq ramping" for good on all SI, expected? regards, -- Sylvain
[patch] drm/radeon: delete a stray tab
Static checkers complain that probably curly braces were intended here, but actually it makes more sense to remove the extra tab. Signed-off-by: Dan Carpenter diff --git a/drivers/gpu/drm/radeon/evergreen.c b/drivers/gpu/drm/radeon/evergreen.c index f2b9e21ce4da..5623e7542d99 100644 --- a/drivers/gpu/drm/radeon/evergreen.c +++ b/drivers/gpu/drm/radeon/evergreen.c @@ -1680,7 +1680,7 @@ bool evergreen_hpd_sense(struct radeon_device *rdev, enum radeon_hpd_id hpd) case RADEON_HPD_6: if (RREG32(DC_HPD6_INT_STATUS) & DC_HPDx_SENSE) connected = true; - break; + break; default: break; }
[PATCH 4/5] drm/i915: Add rotation support for the cursor plane
On Fri, 2014-02-14 at 13:39 +0200, Ville Syrj?l? wrote: > On Fri, Feb 14, 2014 at 04:31:17PM +0530, Sagar Arun Kamble wrote: > > On Wed, 2014-02-12 at 23:15 +0200, ville.syrjala at linux.intel.com wrote: > > > From: Ville Syrj?l? > > > > > > The cursor plane also supports 180 degree rotation. Add a new > > > "cursor-rotation" property on the crtc which controls this. > > > > > > Unlike sprites, the cursor has a fixed size, so if you have a small > > > cursor image with the rest of the bo filled by transparent pixels, > > > simply flipping the rotation property will cause the visible part > > > of the cursor to shift. This is something to keep in mind when > > > using cursor rotation. > > By flipping you meant setting 180 degree rotation? > > Yes. > > > Don't we have to adjust the cursor base as well to the lower right > > corner apart from setting the control bit? > > No, the hardware does that automagically. Hmm. Except on gen4 > apparently. Looks like I need to test on gen4, and fix it if it's > really the case. I tried on BYT system and 180 rotation on cursor plane is showing garbage data in cursor plane. We might need to adjust the cursor base. Another thing, pipe rotation somehow did not work for me when I do this: echo 0x4 > /sys/kernel/debug/dri/0/i915_pipe_rotation Only cursor plane had impact. Need to debug this as well. >
[Bug 74784] Strange artifacts when rendering trees in Dota 2
https://bugs.freedesktop.org/show_bug.cgi?id=74784 --- Comment #9 from Bruno Jim?nez --- With 'R600_DEBUG=hyperz' the problem happens again, so I'm afraid that it's something related to the hyperz. If I can help with anything else, just ask. -- 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/20140217/137c5522/attachment.html>
[Bug 64471] Radeon HD6570 lockup in Brütal Legend with HyperZ
https://bugs.freedesktop.org/show_bug.cgi?id=64471 --- Comment #18 from Hamish Wilson --- Is everyone that is having issues using x86_64? The main difference between my Arch system and the Fedora 20 system is that I am using i386 instead. -- 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/20140217/83345d97/attachment.html>
[Bug 71488] RadeonSI :Regression: Massive Desktop corruption observed on starting the X server
https://bugs.freedesktop.org/show_bug.cgi?id=71488 --- Comment #16 from glphvgacs --- (In reply to comment #14) fixed on OLAND. thanks. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140217/6396e561/attachment.html>
[PATCH 4/5] drm/i915: Add rotation support for the cursor plane
On Mon, Feb 17, 2014 at 10:53:50PM +0530, Sagar Arun Kamble wrote: > On Fri, 2014-02-14 at 13:39 +0200, Ville Syrj?l? wrote: > > On Fri, Feb 14, 2014 at 04:31:17PM +0530, Sagar Arun Kamble wrote: > > > On Wed, 2014-02-12 at 23:15 +0200, ville.syrjala at linux.intel.com wrote: > > > > From: Ville Syrj?l? > > > > > > > > The cursor plane also supports 180 degree rotation. Add a new > > > > "cursor-rotation" property on the crtc which controls this. > > > > > > > > Unlike sprites, the cursor has a fixed size, so if you have a small > > > > cursor image with the rest of the bo filled by transparent pixels, > > > > simply flipping the rotation property will cause the visible part > > > > of the cursor to shift. This is something to keep in mind when > > > > using cursor rotation. > > > By flipping you meant setting 180 degree rotation? > > > > Yes. > > > > > Don't we have to adjust the cursor base as well to the lower right > > > corner apart from setting the control bit? > > > > No, the hardware does that automagically. Hmm. Except on gen4 > > apparently. Looks like I need to test on gen4, and fix it if it's > > really the case. > I tried on BYT system and 180 rotation on cursor plane is showing > garbage data in cursor plane. We might need to adjust the cursor base. Yeah it's the same on gen4. I already have a fixed patch, but didn't repost it yet. > Another thing, pipe rotation somehow did not work for me when I do this: > echo 0x4 > /sys/kernel/debug/dri/0/i915_pipe_rotation > Only cursor plane had impact. Need to debug this as well. That's expected. It doesn't actually call the set_property codepath, instead it just sets the value directly and excpects a subsequent modeset to do the actual work. It was anyway just a hack to try things out a bit, so I didn't implement it properly. But it should be trivial to make it work correctly, so I might as well do it... -- Ville Syrj?l? Intel OTC
[PATCH 2/6] seqno-fence: Hardware dma-buf implementation of fencing (v4)
Am 17.02.2014 19:24, schrieb Rob Clark:
> On Mon, Feb 17, 2014 at 12:36 PM, Christian K?nig
> wrote:
>> Am 17.02.2014 18:27, schrieb Rob Clark:
>>
>>> On Mon, Feb 17, 2014 at 11:56 AM, Christian K?nig
>>> wrote:
Am 17.02.2014 16:56, schrieb Maarten Lankhorst:
> This type of fence can be used with hardware synchronization for simple
> hardware that can block execution until the condition
> (dma_buf[offset] - value) >= 0 has been met.
Can't we make that just "dma_buf[offset] != 0" instead? As far as I know
this way it would match the definition M$ uses in their WDDM
specification
and so make it much more likely that hardware supports it.
>>> well 'buf[offset] >= value' at least means the same slot can be used
>>> for multiple operations (with increasing values of 'value').. not sure
>>> if that is something people care about.
>>>
=value seems to be possible with adreno and radeon. I'm not really sure
about others (although I presume it as least supported for nv desktop
stuff). For hw that cannot do >=value, we can either have a different
fence
implementation which uses the !=0 approach. Or change seqno-fence
implementation later if needed. But if someone has hw that can do !=0 but
not >=value, speak up now ;-)
>>
>> Here! Radeon can only do >=value on the DMA and 3D engine, but not with UVD
>> or VCE. And for the 3D engine it means draining the pipe, which isn't really
>> a good idea.
> hmm, ok.. forgot you have a few extra rings compared to me. Is UVD
> re-ordering from decode-order to display-order for you in hw? If not,
> I guess you need sw intervention anyways when a frame is done for
> frame re-ordering, so maybe hw->hw sync doesn't really matter as much
> as compared to gpu/3d->display. For dma<->3d interactions, seems like
> you would care more about hw<->hw sync, but I guess you aren't likely
> to use GPU A to do a resolve blit for GPU B..
No UVD isn't reordering, but since frame reordering is predictable you
usually end up with pipelining everything to the hardware. E.g. you send
the decode commands in decode order to the UVD block and if you have
overlay active one of the frames are going to be the first to display
and then you want to wait for it on the display side.
> For 3D ring, I assume you probably want a CP_WAIT_FOR_IDLE before a
> CP_MEM_WRITE to update fence value in memory (for the one signalling
> the fence). But why would you need that before a CP_WAIT_REG_MEM (for
> the one waiting for the fence)? I don't exactly have documentation
> for adreno version of CP_WAIT_REG_{MEM,EQ,GTE}.. but PFP and ME
> appear to be same instruction set as r600, so I'm pretty sure they
> should have similar capabilities.. CP_WAIT_REG_MEM appears to be same
> but with 32bit gpu addresses vs 64b.
You shouldn't use any of the CP commands for engine synchronization
(neither for wait nor for signal). The PFP and ME are just the top of a
quite deep pipeline and when you use any of the CP_WAIT functions you
block them for something and that's draining the pipeline.
With the semaphore and fence commands the values are just attached as
prerequisite to the draw command, e.g. the CP setups the draw
environment and issues the command, but the actual execution of it is
delayed until the "!= 0" condition hits. And in the meantime the CP
already prepares the next draw operation.
But at least for compute queues wait semaphore aren't the perfect
solution either. What you need then is a GPU scheduler that uses a
kernel task for setting up the command submission for you when all
prerequisites are meet.
Christian.
> BR,
> -R
>
>> Christian.
>>
>>
Apart from that I still don't like the idea of leaking a drivers IRQ
context
outside of the driver, but without a proper GPU scheduler there probably
isn't much alternative.
>>> I guess it will be not uncommon scenario for gpu device to just need
>>> to kick display device to write a few registers for a page flip..
>>> probably best not to schedule a worker just for this (unless the
>>> signalled device otherwise needs to). I think it is better in this
>>> case to give the signalee some rope to hang themselves, and make it
>>> the responsibility of the callback to kick things off to a worker if
>>> needed.
>>>
>>> BR,
>>> -R
>>>
Christian.
> A software fallback still has to be provided in case the fence is used
> with a device that doesn't support this mechanism. It is useful to
> expose
> this for graphics cards that have an op to support this.
>
> Some cards like i915 can export those, but don't have an option to wait,
> so they need the software fallback.
>
> I extended the original patch by Rob Clark.
>
> v1: Original
> v2: Renamed from bikeshed to seqno, moved into dma-fence.c since
>not much was left of the file. Lots of documentation added.
> v3: Use fence_ops instead o
[Bug 71488] RadeonSI :Regression: Massive Desktop corruption observed on starting the X server
https://bugs.freedesktop.org/show_bug.cgi?id=71488 Alex Deucher changed: What|Removed |Added CC||darwinskernel at gmail.com --- Comment #15 from Alex Deucher --- *** Bug 73946 has been marked as a duplicate of this bug. *** -- 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/20140217/50e3082b/attachment.html>
[Bug 71488] RadeonSI :Regression: Massive Desktop corruption observed on starting the X server
https://bugs.freedesktop.org/show_bug.cgi?id=71488 --- Comment #14 from Alex Deucher --- Created attachment 94233 --> https://bugs.freedesktop.org/attachment.cgi?id=94233&action=edit possible fix This patch should fix the issues. -- 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/20140217/5a1e6fa7/attachment.html>
[Bug 74927] Screen corruption on Ubuntu 14.04, Kernel 3.13 with Radeon R7 240 (OLAND PRO)
https://bugs.freedesktop.org/show_bug.cgi?id=74927 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #12 from Alex Deucher --- *** This bug has been marked as a duplicate of bug 71488 *** -- 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/20140217/d71209ee/attachment.html>
[Bug 71488] RadeonSI :Regression: Massive Desktop corruption observed on starting the X server
https://bugs.freedesktop.org/show_bug.cgi?id=71488 Alex Deucher changed: What|Removed |Added CC||bz at yotm.com --- Comment #13 from Alex Deucher --- *** Bug 74927 has been marked as a duplicate of this bug. *** -- 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/20140217/b1219208/attachment.html>
[Bug 74927] Screen corruption on Ubuntu 14.04, Kernel 3.13 with Radeon R7 240 (OLAND PRO)
https://bugs.freedesktop.org/show_bug.cgi?id=74927 --- Comment #11 from Alex Deucher --- Created attachment 94230 --> https://bugs.freedesktop.org/attachment.cgi?id=94230&action=edit possible fix This attached kernel patch should fix the issue. -- 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/20140217/82bbb977/attachment.html>
[Bug 75011] [hyperz] Performance drop since git-01e6371 (disable hyperz by default) with radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=75011 --- Comment #4 from Benjamin Bellec --- Yes I confirm too. HyperZ gives a serious boost. In the Counter Strike: Source Video Stress Test I was at 46,65 FPS with a RV770, and now at 37,90 FPS without HyperZ. -- 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/20140217/4a4b5533/attachment-0001.html>
[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=75112 Andreas Boll changed: What|Removed |Added See Also||https://bugzilla.kernel.org ||/show_bug.cgi?id=70411 Depends on||58660, 64471, 66352, 68799, ||72685, 73088, 73785, 74428, ||74803, 74863, 74892 Blocks||75011 -- 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/20140217/2460172b/attachment.html>
[Bug 58660] CAYMAN broken with HyperZ on
https://bugs.freedesktop.org/show_bug.cgi?id=58660 Andreas Boll changed: What|Removed |Added Blocks||75112 -- 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/20140217/1a24973c/attachment.html>
[Bug 64471] Radeon HD6570 lockup in Brütal Legend with HyperZ
https://bugs.freedesktop.org/show_bug.cgi?id=64471 Andreas Boll changed: What|Removed |Added Blocks||75112 -- 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/20140217/eabd404f/attachment.html>
[Bug 68799] [APITRACE] Hyper-Z lockup with Falcon BMS 4.32u6 on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=68799 Andreas Boll changed: What|Removed |Added Blocks||75112 -- 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/20140217/772f9f09/attachment.html>
[Bug 73088] [HyperZ] Juniper (6770): Gone Home / Unigine Heaven 4.0 lock up system after several minutes of use
https://bugs.freedesktop.org/show_bug.cgi?id=73088 Andreas Boll changed: What|Removed |Added Blocks||75112 -- 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/20140217/68550089/attachment.html>
[Bug 74892] HyperZ GPU lockup with radeonsi 7970M PITCAIRN and Distance Alpha game
https://bugs.freedesktop.org/show_bug.cgi?id=74892 Andreas Boll changed: What|Removed |Added Blocks||75112 -- 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/20140217/84ba9b4f/attachment-0001.html>
[Bug 66352] GPU lockup in L4D2 on TURKS with HyperZ
https://bugs.freedesktop.org/show_bug.cgi?id=66352 Andreas Boll changed: What|Removed |Added Blocks||75112 -- 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/20140217/ac475ac5/attachment.html>
[Bug 72685] [radeonsi hyperz] Artifacts in Unigine Sanctuary
https://bugs.freedesktop.org/show_bug.cgi?id=72685 Andreas Boll changed: What|Removed |Added Blocks||75112 -- 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/20140217/44cdacc8/attachment.html>
[Bug 73785] [HyperZ] Team Fortress 2 causes random GPU stalls on radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=73785 Andreas Boll changed: What|Removed |Added Blocks||75112 -- 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/20140217/2edd6465/attachment.html>
[Bug 74863] [r600g] HyperZ broken on RV770 and CYPRESS (Left 4 Dead 2 trees corruption) bisected!
https://bugs.freedesktop.org/show_bug.cgi?id=74863 Andreas Boll changed: What|Removed |Added Blocks||75112 -- 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/20140217/9a935245/attachment.html>
[Bug 75011] [hyperz] Performance drop since git-01e6371 (disable hyperz by default) with radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=75011 Andreas Boll changed: What|Removed |Added Depends on||75112 -- 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/20140217/1d577de7/attachment.html>
[Bug 74803] [r600g] HyperZ broken on RV630 (Cogs shadows are broken)
https://bugs.freedesktop.org/show_bug.cgi?id=74803 Andreas Boll changed: What|Removed |Added Blocks||75112 -- 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/20140217/77e35b20/attachment.html>
[Bug 74428] hyperz causes gpu hang in Counter-strike: Source
https://bugs.freedesktop.org/show_bug.cgi?id=74428 Andreas Boll changed: What|Removed |Added Blocks||75112 -- 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/20140217/d41caeb5/attachment.html>
[Bug 75112] New: Meta Bug for HyperZ issues on r600g and radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=75112 Priority: medium Bug ID: 75112 Assignee: dri-devel at lists.freedesktop.org Summary: Meta Bug for HyperZ issues on r600g and radeonsi Severity: normal Classification: Unclassified OS: All Reporter: andreas.boll.dev at gmail.com Hardware: All Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa This bug is for tracking all the outstanding HyperZ issues on r600g and radeonsi. -- 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/20140217/e772e040/attachment.html>
[Bug 73088] [HyperZ] Juniper (6770): Gone Home / Unigine Heaven 4.0 lock up system after several minutes of use
https://bugs.freedesktop.org/show_bug.cgi?id=73088 Andreas Boll changed: What|Removed |Added Summary|Juniper (6770): Gone Home / |[HyperZ] Juniper (6770): |Unigine Heaven 4.0 lock up |Gone Home / Unigine Heaven |system after several|4.0 lock up system after |minutes of use |several minutes of use -- 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/20140217/7ba5abbc/attachment.html>
[PATCH 2/6] seqno-fence: Hardware dma-buf implementation of fencing (v4)
Am 17.02.2014 18:27, schrieb Rob Clark:
> On Mon, Feb 17, 2014 at 11:56 AM, Christian K?nig
> wrote:
>> Am 17.02.2014 16:56, schrieb Maarten Lankhorst:
>>
>>> This type of fence can be used with hardware synchronization for simple
>>> hardware that can block execution until the condition
>>> (dma_buf[offset] - value) >= 0 has been met.
>>
>> Can't we make that just "dma_buf[offset] != 0" instead? As far as I know
>> this way it would match the definition M$ uses in their WDDM specification
>> and so make it much more likely that hardware supports it.
> well 'buf[offset] >= value' at least means the same slot can be used
> for multiple operations (with increasing values of 'value').. not sure
> if that is something people care about.
>
>> =value seems to be possible with adreno and radeon. I'm not really sure
>> about others (although I presume it as least supported for nv desktop
>> stuff). For hw that cannot do >=value, we can either have a different fence
>> implementation which uses the !=0 approach. Or change seqno-fence
>> implementation later if needed. But if someone has hw that can do !=0 but
>> not >=value, speak up now ;-)
Here! Radeon can only do >=value on the DMA and 3D engine, but not with
UVD or VCE. And for the 3D engine it means draining the pipe, which
isn't really a good idea.
Christian.
>
>> Apart from that I still don't like the idea of leaking a drivers IRQ context
>> outside of the driver, but without a proper GPU scheduler there probably
>> isn't much alternative.
> I guess it will be not uncommon scenario for gpu device to just need
> to kick display device to write a few registers for a page flip..
> probably best not to schedule a worker just for this (unless the
> signalled device otherwise needs to). I think it is better in this
> case to give the signalee some rope to hang themselves, and make it
> the responsibility of the callback to kick things off to a worker if
> needed.
>
> BR,
> -R
>
>> Christian.
>>
>>> A software fallback still has to be provided in case the fence is used
>>> with a device that doesn't support this mechanism. It is useful to expose
>>> this for graphics cards that have an op to support this.
>>>
>>> Some cards like i915 can export those, but don't have an option to wait,
>>> so they need the software fallback.
>>>
>>> I extended the original patch by Rob Clark.
>>>
>>> v1: Original
>>> v2: Renamed from bikeshed to seqno, moved into dma-fence.c since
>>> not much was left of the file. Lots of documentation added.
>>> v3: Use fence_ops instead of custom callbacks. Moved to own file
>>> to avoid circular dependency between dma-buf.h and fence.h
>>> v4: Add spinlock pointer to seqno_fence_init
>>>
>>> Signed-off-by: Maarten Lankhorst
>>> ---
>>>Documentation/DocBook/device-drivers.tmpl |1
>>>drivers/base/fence.c | 50 +
>>>include/linux/seqno-fence.h | 109
>>> +
>>>3 files changed, 160 insertions(+)
>>>create mode 100644 include/linux/seqno-fence.h
>>>
>>> diff --git a/Documentation/DocBook/device-drivers.tmpl
>>> b/Documentation/DocBook/device-drivers.tmpl
>>> index 7a0c9ddb4818..8c85c20942c2 100644
>>> --- a/Documentation/DocBook/device-drivers.tmpl
>>> +++ b/Documentation/DocBook/device-drivers.tmpl
>>> @@ -131,6 +131,7 @@ X!Edrivers/base/interface.c
>>>!Edrivers/base/dma-buf.c
>>>!Edrivers/base/fence.c
>>>!Iinclude/linux/fence.h
>>> +!Iinclude/linux/seqno-fence.h
>>>!Edrivers/base/reservation.c
>>>!Iinclude/linux/reservation.h
>>>!Edrivers/base/dma-coherent.c
>>> diff --git a/drivers/base/fence.c b/drivers/base/fence.c
>>> index 12df2bf62034..cd0937127a89 100644
>>> --- a/drivers/base/fence.c
>>> +++ b/drivers/base/fence.c
>>> @@ -25,6 +25,7 @@
>>>#include
>>>#include
>>>#include
>>> +#include
>>> #define CREATE_TRACE_POINTS
>>>#include
>>> @@ -413,3 +414,52 @@ __fence_init(struct fence *fence, const struct
>>> fence_ops *ops,
>>> trace_fence_init(fence);
>>>}
>>>EXPORT_SYMBOL(__fence_init);
>>> +
>>> +static const char *seqno_fence_get_driver_name(struct fence *fence) {
>>> + struct seqno_fence *seqno_fence = to_seqno_fence(fence);
>>> + return seqno_fence->ops->get_driver_name(fence);
>>> +}
>>> +
>>> +static const char *seqno_fence_get_timeline_name(struct fence *fence) {
>>> + struct seqno_fence *seqno_fence = to_seqno_fence(fence);
>>> + return seqno_fence->ops->get_timeline_name(fence);
>>> +}
>>> +
>>> +static bool seqno_enable_signaling(struct fence *fence)
>>> +{
>>> + struct seqno_fence *seqno_fence = to_seqno_fence(fence);
>>> + return seqno_fence->ops->enable_signaling(fence);
>>> +}
>>> +
>>> +static bool seqno_signaled(struct fence *fence)
>>> +{
>>> + struct seqno_fence *seqno_fence = to_seqno_fence(fence);
>>> + return seqno_fence->ops->signaled &&
>>> seqno_fence->ops->signaled(fence);
>>> +}
>
[GIT PULL]: dma-buf updates for 3.14
Hi Linus, Here's another tiny pull request for dma-buf framework updates; just some debugfs output updates. (There's another patch related to dma-buf, but it'll get upstreamed via Greg-kh's pull request). Could you please pull? The following changes since commit 45f7fdc2ffb9d5af4dab593843e89da70d1259e3: Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc (2014-02-11 22:28:47 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf.git tags/dma-buf-for-3.14 for you to fetch changes up to c0b00a525c127d0055c1df6283300e17f601a1a1: dma-buf: update debugfs output (2014-02-13 10:08:52 +0530) Small dma-buf pull request for 3.14 Sumit Semwal (1): dma-buf: update debugfs output drivers/base/dma-buf.c | 25 - include/linux/dma-buf.h | 2 +- 2 files changed, 13 insertions(+), 14 deletions(-)
[Bug 75011] [hyperz] Performance drop since git-01e6371 (disable hyperz by default) with radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=75011 Andreas Boll changed: What|Removed |Added Status|REOPENED|NEW --- Comment #3 from Andreas Boll --- We keep this bug open until hyperz gets re-enabled by default. -- 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/20140217/7badcf95/attachment.html>
[Bug 75011] [hyperz] Performance drop since git-01e6371 (disable hyperz by default) with radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=75011 Andreas Boll changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|NOTABUG |--- Summary|Performance drop since |[hyperz] Performance drop |git-6d1cecb with radeonsi |since git-01e6371 (disable ||hyperz by default) with ||radeonsi -- 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/20140217/4748f6fd/attachment.html>
[Bug 70711] Audio hdmi
https://bugzilla.kernel.org/show_bug.cgi?id=70711 --- Comment #4 from Vincenzo --- when I select hdmi audio, video freezes -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 70711] Audio hdmi
https://bugzilla.kernel.org/show_bug.cgi?id=70711 --- Comment #3 from Vincenzo --- [0.00] DMA32[mem 0x0100-0x] [0.00] Normal [mem 0x1-0x42fff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x1000-0x0009dfff] [0.00] node 0: [mem 0x0010-0xcff9] [0.00] node 0: [mem 0x1-0x42fff] [0.00] On node 0 totalpages: 4194109 [0.00] DMA zone: 64 pages used for memmap [0.00] DMA zone: 21 pages reserved [0.00] DMA zone: 3997 pages, LIFO batch:0 [0.00] DMA32 zone: 13247 pages used for memmap [0.00] DMA32 zone: 847776 pages, LIFO batch:31 [0.00] Normal zone: 52224 pages used for memmap [0.00] Normal zone: 3342336 pages, LIFO batch:31 [0.00] ACPI: PM-Timer IO Port: 0x808 [0.00] ACPI: Local APIC address 0xfee0 [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [0.00] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) [0.00] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) [0.00] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) [0.00] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x84] disabled) [0.00] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x85] disabled) [0.00] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x86] disabled) [0.00] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x87] disabled) [0.00] ACPI: IOAPIC (id[0x04] address[0xfec0] gsi_base[0]) [0.00] IOAPIC[0]: apic_id 4, version 33, address 0xfec0, GSI 0-23 [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) [0.00] ACPI: IRQ0 used by override. [0.00] ACPI: IRQ2 used by override. [0.00] ACPI: IRQ9 used by override. [0.00] Using ACPI (MADT) for SMP configuration information [0.00] ACPI: HPET id: 0x8300 base: 0xfed0 [0.00] smpboot: Allowing 8 CPUs, 4 hotplug CPUs [0.00] nr_irqs_gsi: 40 [0.00] PM: Registered nosave memory: [mem 0x0009e000-0x0009efff] [0.00] PM: Registered nosave memory: [mem 0x0009f000-0x0009] [0.00] PM: Registered nosave memory: [mem 0x000a-0x000e5fff] [0.00] PM: Registered nosave memory: [mem 0x000e6000-0x000f] [0.00] PM: Registered nosave memory: [mem 0xcffa-0xcffa] [0.00] PM: Registered nosave memory: [mem 0xcffb-0xcffd] [0.00] PM: Registered nosave memory: [mem 0xcffe-0xcfff] [0.00] PM: Registered nosave memory: [mem 0xd000-0xffef] [0.00] PM: Registered nosave memory: [mem 0xfff0-0x] [0.00] e820: [mem 0xd000-0xffef] available for PCI devices [0.00] Booting paravirtualized kernel on bare hardware [0.00] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:8 nr_node_ids:1 [0.00] PERCPU: Embedded 29 pages/cpu @88042fc0 s86528 r8192 d24064 u262144 [0.00] pcpu-alloc: s86528 r8192 d24064 u262144 alloc=1*2097152 [0.00] pcpu-alloc: [0] 0 1 2 3 4 5 6 7 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 4128553 [0.00] Policy zone: Normal [0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.14.0-rc3 root=UUID=fb4bee82-f698-44f0-b919-af1ebc821958 ro crashkernel=384M-2G:64M,2G-:128M quiet splash radeon.dpm=1 radeon.audio=1 vt.handoff=7 [0.00] PID hash table entries: 4096 (order: 3, 32768 bytes) [0.00] Checking aperture... [0.00] No AGP bridge found [0.00] Node 0: aperture @ 0 size 32 MB [0.00] Your BIOS doesn't leave a aperture memory hole [0.00] Please enable the IOMMU option in the BIOS setup [0.00] This costs you 64 MB of RAM [0.00] Mapping aperture over 65536 KB of RAM @ c400 [0.00] PM: Registered nosave memory: [mem 0xc400-0xc7ff] [0.00] Memory: 16209932K/16776436K available (7463K kernel code, 1119K rwdata, 3476K rodata, 1344K init, 1428K bss, 566504K reserved) [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1 [0.00] Hierarchical RCU implementation. [0.00] RCU dyntick-idle grace-period acceleration is enabled. [0.00] RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=8. [0.00] Offload RCU callbacks from all CPUs [0.00] Offload RCU callbacks from CPUs: 0-7. [0.00] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=8 [0.00] NR_IRQS:16640 nr_irqs:744 16 [0.00] ACPI: Core revision 20131218 [0.00] ACPI: All ACPI Tables successfully acquired [0.00] spurious 8259A interrupt: IRQ7. [0.00] Console: colour dummy device 80x25 [0.00] console [tty0] enabled [0.00] allocated 67108864 bytes of page_cgroup [0.00]
[Bug 74784] Strange artifacts when rendering trees in Dota 2
https://bugs.freedesktop.org/show_bug.cgi?id=74784 --- Comment #8 from Andreas Boll --- (In reply to comment #7) > With mesa at commit 6d1cecb (Friday evening) this problem is fixed. > > Thanks! > > P.D: Maybe it was related to the hyperz problem of r600g drivers, as I am > using a revision that is after this commit > http://cgit.freedesktop.org/mesa/mesa/commit/ > ?id=01e637114914453451becc0dc8afe60faff48d84 Could you set the following environment variable to re-enable hyperz? R600_DEBUG=hyperz -- 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/20140217/03da0a6b/attachment.html>
[PATCH 2/6] seqno-fence: Hardware dma-buf implementation of fencing (v4)
Am 17.02.2014 16:56, schrieb Maarten Lankhorst:
> This type of fence can be used with hardware synchronization for simple
> hardware that can block execution until the condition
> (dma_buf[offset] - value) >= 0 has been met.
Can't we make that just "dma_buf[offset] != 0" instead? As far as I know
this way it would match the definition M$ uses in their WDDM
specification and so make it much more likely that hardware supports it.
Apart from that I still don't like the idea of leaking a drivers IRQ
context outside of the driver, but without a proper GPU scheduler there
probably isn't much alternative.
Christian.
>
> A software fallback still has to be provided in case the fence is used
> with a device that doesn't support this mechanism. It is useful to expose
> this for graphics cards that have an op to support this.
>
> Some cards like i915 can export those, but don't have an option to wait,
> so they need the software fallback.
>
> I extended the original patch by Rob Clark.
>
> v1: Original
> v2: Renamed from bikeshed to seqno, moved into dma-fence.c since
> not much was left of the file. Lots of documentation added.
> v3: Use fence_ops instead of custom callbacks. Moved to own file
> to avoid circular dependency between dma-buf.h and fence.h
> v4: Add spinlock pointer to seqno_fence_init
>
> Signed-off-by: Maarten Lankhorst
> ---
> Documentation/DocBook/device-drivers.tmpl |1
> drivers/base/fence.c | 50 +
> include/linux/seqno-fence.h | 109
> +
> 3 files changed, 160 insertions(+)
> create mode 100644 include/linux/seqno-fence.h
>
> diff --git a/Documentation/DocBook/device-drivers.tmpl
> b/Documentation/DocBook/device-drivers.tmpl
> index 7a0c9ddb4818..8c85c20942c2 100644
> --- a/Documentation/DocBook/device-drivers.tmpl
> +++ b/Documentation/DocBook/device-drivers.tmpl
> @@ -131,6 +131,7 @@ X!Edrivers/base/interface.c
> !Edrivers/base/dma-buf.c
> !Edrivers/base/fence.c
> !Iinclude/linux/fence.h
> +!Iinclude/linux/seqno-fence.h
> !Edrivers/base/reservation.c
> !Iinclude/linux/reservation.h
> !Edrivers/base/dma-coherent.c
> diff --git a/drivers/base/fence.c b/drivers/base/fence.c
> index 12df2bf62034..cd0937127a89 100644
> --- a/drivers/base/fence.c
> +++ b/drivers/base/fence.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
>
> #define CREATE_TRACE_POINTS
> #include
> @@ -413,3 +414,52 @@ __fence_init(struct fence *fence, const struct fence_ops
> *ops,
> trace_fence_init(fence);
> }
> EXPORT_SYMBOL(__fence_init);
> +
> +static const char *seqno_fence_get_driver_name(struct fence *fence) {
> + struct seqno_fence *seqno_fence = to_seqno_fence(fence);
> + return seqno_fence->ops->get_driver_name(fence);
> +}
> +
> +static const char *seqno_fence_get_timeline_name(struct fence *fence) {
> + struct seqno_fence *seqno_fence = to_seqno_fence(fence);
> + return seqno_fence->ops->get_timeline_name(fence);
> +}
> +
> +static bool seqno_enable_signaling(struct fence *fence)
> +{
> + struct seqno_fence *seqno_fence = to_seqno_fence(fence);
> + return seqno_fence->ops->enable_signaling(fence);
> +}
> +
> +static bool seqno_signaled(struct fence *fence)
> +{
> + struct seqno_fence *seqno_fence = to_seqno_fence(fence);
> + return seqno_fence->ops->signaled && seqno_fence->ops->signaled(fence);
> +}
> +
> +static void seqno_release(struct fence *fence)
> +{
> + struct seqno_fence *f = to_seqno_fence(fence);
> +
> + dma_buf_put(f->sync_buf);
> + if (f->ops->release)
> + f->ops->release(fence);
> + else
> + kfree(f);
> +}
> +
> +static long seqno_wait(struct fence *fence, bool intr, signed long timeout)
> +{
> + struct seqno_fence *f = to_seqno_fence(fence);
> + return f->ops->wait(fence, intr, timeout);
> +}
> +
> +const struct fence_ops seqno_fence_ops = {
> + .get_driver_name = seqno_fence_get_driver_name,
> + .get_timeline_name = seqno_fence_get_timeline_name,
> + .enable_signaling = seqno_enable_signaling,
> + .signaled = seqno_signaled,
> + .wait = seqno_wait,
> + .release = seqno_release,
> +};
> +EXPORT_SYMBOL(seqno_fence_ops);
> diff --git a/include/linux/seqno-fence.h b/include/linux/seqno-fence.h
> new file mode 100644
> index ..952f7909128c
> --- /dev/null
> +++ b/include/linux/seqno-fence.h
> @@ -0,0 +1,109 @@
> +/*
> + * seqno-fence, using a dma-buf to synchronize fencing
> + *
> + * Copyright (C) 2012 Texas Instruments
> + * Copyright (C) 2012 Canonical Ltd
> + * Authors:
> + * Rob Clark
> + * Maarten Lankhorst
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful, but
> WITHOUT
> + * ANY WARRANTY;
[Bug 70701] With DPM enabled, Radeon 4570 (R710) doesn't remain in Single_Disp state
https://bugzilla.kernel.org/show_bug.cgi?id=70701 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1 from Alex Deucher --- Created attachment 126461 --> https://bugzilla.kernel.org/attachment.cgi?id=126461&action=edit possible fix Does the attached patch help? Can you attach the dmesg output with this patch applied? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 75102] Radeon 4890 getting a blank screen and fans go up to 100% (kernel 3.13.3)
https://bugs.freedesktop.org/show_bug.cgi?id=75102 --- Comment #1 from Alex Deucher --- Please attach your xorg log and dmesg output. Since this appears to be a regression can you bisect? -- 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/20140217/2d86a471/attachment.html>
[Bug 73067] RV770 - screen flicker with radeon.dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=73067 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Alex Deucher --- Fixed in: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8097d94116d0c17e774ba4c8256e774018dc2a46 -- 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/20140217/cfcae6ae/attachment.html>
[Bug 70711] Audio hdmi
https://bugzilla.kernel.org/show_bug.cgi?id=70711 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #2 from Alex Deucher --- Please attach your full dmesg output. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #198 from Thierry Vignaud --- AFAIC I still see hang black screen with 3.14-rc2 + attachment #91947 from comment 183 -- 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/20140217/cc475d6b/attachment.html>
[Bug 71239] Metro Last Light quits(?) on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=71239 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #26 from Alex Deucher --- *** This bug has been marked as a duplicate of bug 71870 *** -- 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/20140217/53f0039e/attachment.html>
[Bug 65761] HD 7970M Hybrid - hangs and errors and rmmod causes crash
https://bugzilla.kernel.org/show_bug.cgi?id=65761 --- Comment #46 from Alex Deucher --- Created attachment 126451 --> https://bugzilla.kernel.org/attachment.cgi?id=126451&action=edit report 0 for temp when dGPU is powered off (In reply to Christoph Haag from comment #45) > Yes, this is working pretty good, haven't noticed anything bad with it. > > Even suspending works great, manual vgaswitcheroo was always a bit buggy > after waking up, but this is working great. > > Maybe a minor thing: When the GPU is off lm_sensors displays > radeon-pci-0100 > Adapter: PCI adapter > temp1: +511.0?C > Should maybe be 0 or -1 or the last detected temperature or something, 511?C > could throw some tools off. > Attached patch should report 0. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 6/6] dma-buf: add poll support, v2
Thanks to Fengguang Wu for spotting a missing static cast.
v2:
- Kill unused variable need_shared.
Signed-off-by: Maarten Lankhorst
---
drivers/base/dma-buf.c | 101 +++
include/linux/dma-buf.h | 12 ++
2 files changed, 113 insertions(+)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 85e792c2c909..77ea621ab59d 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
static inline int is_dma_buf_file(struct file *);
@@ -52,6 +53,13 @@ static int dma_buf_release(struct inode *inode, struct file
*file)
BUG_ON(dmabuf->vmapping_counter);
+ /*
+* Any fences that a dma-buf poll can wait on should be signaled
+* before releasing dma-buf. This is the responsibility of each
+* driver that uses the reservation objects.
+*/
+ BUG_ON(dmabuf->cb_shared.active || dmabuf->cb_excl.active);
+
dmabuf->ops->release(dmabuf);
mutex_lock(&db_list.lock);
@@ -108,10 +116,99 @@ static loff_t dma_buf_llseek(struct file *file, loff_t
offset, int whence)
return base + offset;
}
+static void dma_buf_poll_cb(struct fence *fence, struct fence_cb *cb)
+{
+ struct dma_buf_poll_cb_t *dcb = (struct dma_buf_poll_cb_t*) cb;
+ unsigned long flags;
+
+ spin_lock_irqsave(&dcb->poll->lock, flags);
+ wake_up_locked_poll(dcb->poll, dcb->active);
+ dcb->active = 0;
+ spin_unlock_irqrestore(&dcb->poll->lock, flags);
+}
+
+static unsigned int dma_buf_poll(struct file *file, poll_table *poll)
+{
+ struct dma_buf *dmabuf;
+ struct reservation_object *resv;
+ unsigned long events;
+
+ dmabuf = file->private_data;
+ if (!dmabuf || !dmabuf->resv)
+ return POLLERR;
+
+ resv = dmabuf->resv;
+
+ poll_wait(file, &dmabuf->poll, poll);
+
+ events = poll_requested_events(poll) & (POLLIN | POLLOUT);
+ if (!events)
+ return 0;
+
+ ww_mutex_lock(&resv->lock, NULL);
+
+ if (resv->fence_excl && (!(events & POLLOUT) ||
resv->fence_shared_count == 0)) {
+ struct dma_buf_poll_cb_t *dcb = &dmabuf->cb_excl;
+ unsigned long pevents = POLLIN;
+
+ if (resv->fence_shared_count == 0)
+ pevents |= POLLOUT;
+
+ spin_lock_irq(&dmabuf->poll.lock);
+ if (dcb->active) {
+ dcb->active |= pevents;
+ events &= ~pevents;
+ } else
+ dcb->active = pevents;
+ spin_unlock_irq(&dmabuf->poll.lock);
+
+ if (events & pevents) {
+ if (!fence_add_callback(resv->fence_excl,
+ &dcb->cb, dma_buf_poll_cb))
+ events &= ~pevents;
+ else
+ // No callback queued, wake up any additional waiters.
+ dma_buf_poll_cb(NULL, &dcb->cb);
+ }
+ }
+
+ if ((events & POLLOUT) && resv->fence_shared_count > 0) {
+ struct dma_buf_poll_cb_t *dcb = &dmabuf->cb_shared;
+ int i;
+
+ /* Only queue a new callback if no event has fired yet */
+ spin_lock_irq(&dmabuf->poll.lock);
+ if (dcb->active)
+ events &= ~POLLOUT;
+ else
+ dcb->active = POLLOUT;
+ spin_unlock_irq(&dmabuf->poll.lock);
+
+ if (!(events & POLLOUT))
+ goto out;
+
+ for (i = 0; i < resv->fence_shared_count; ++i)
+ if (!fence_add_callback(resv->fence_shared[i],
+ &dcb->cb, dma_buf_poll_cb)) {
+ events &= ~POLLOUT;
+ break;
+ }
+
+ // No callback queued, wake up any additional waiters.
+ if (i == resv->fence_shared_count)
+ dma_buf_poll_cb(NULL, &dcb->cb);
+ }
+
+out:
+ ww_mutex_unlock(&resv->lock);
+ return events;
+}
+
static const struct file_operations dma_buf_fops = {
.release= dma_buf_release,
.mmap = dma_buf_mmap_internal,
.llseek = dma_buf_llseek,
+ .poll = dma_buf_poll,
};
/*
@@ -171,6 +268,10 @@ struct dma_buf *dma_buf_export_named(void *priv, const
struct dma_buf_ops *ops,
dmabuf->ops = ops;
dmabuf->size = size;
dmabuf->exp_name = exp_name;
+ init_waitqueue_head(&dmabuf->poll);
+ dmabuf->cb_excl.poll = dmabuf->cb_shared.poll = &dmabuf->poll;
+ dmabuf->cb_excl.active = dmabuf->cb_shared.active = 0;
+
if (!resv) {
resv = (struct reservation_object*)&dmabuf[1];
[PATCH 5/6] reservation: add support for fences to enable cross-device synchronisation
Signed-off-by: Maarten Lankhorst
---
include/linux/reservation.h | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index 813dae960ebd..92c4851b5a39 100644
--- a/include/linux/reservation.h
+++ b/include/linux/reservation.h
@@ -6,7 +6,7 @@
* Copyright (C) 2012 Texas Instruments
*
* Authors:
- * Rob Clark
+ * Rob Clark
* Maarten Lankhorst
* Thomas Hellstrom
*
@@ -40,22 +40,38 @@
#define _LINUX_RESERVATION_H
#include
+#include
extern struct ww_class reservation_ww_class;
struct reservation_object {
struct ww_mutex lock;
+
+ struct fence *fence_excl;
+ struct fence **fence_shared;
+ u32 fence_shared_count, fence_shared_max;
};
static inline void
reservation_object_init(struct reservation_object *obj)
{
ww_mutex_init(&obj->lock, &reservation_ww_class);
+
+ obj->fence_shared_count = obj->fence_shared_max = 0;
+ obj->fence_shared = NULL;
+ obj->fence_excl = NULL;
}
static inline void
reservation_object_fini(struct reservation_object *obj)
{
+ int i;
+
+ if (obj->fence_excl)
+ fence_put(obj->fence_excl);
+ for (i = 0; i < obj->fence_shared_count; ++i)
+ fence_put(obj->fence_shared[i]);
+
ww_mutex_destroy(&obj->lock);
}
[PATCH 4/6] android: convert sync to fence api, v4
Android syncpoints can be mapped to a timeline. This removes the need
to maintain a separate api for synchronization. I've left the android
trace events in place, but the core fence events should already be
sufficient for debugging.
v2:
- Call fence_remove_callback in sync_fence_free if not all fences have fired.
v3:
- Merge Colin Cross' bugfixes, and the android fence merge optimization.
v4:
- Merge with the upstream fixes.
Signed-off-by: Maarten Lankhorst
---
drivers/staging/android/Kconfig |1
drivers/staging/android/Makefile |2
drivers/staging/android/sw_sync.c|4
drivers/staging/android/sync.c | 892 +++---
drivers/staging/android/sync.h | 80 ++-
drivers/staging/android/sync_debug.c | 245 +
drivers/staging/android/trace/sync.h | 12
7 files changed, 592 insertions(+), 644 deletions(-)
create mode 100644 drivers/staging/android/sync_debug.c
diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig
index b91c758883bf..ecc8194242b5 100644
--- a/drivers/staging/android/Kconfig
+++ b/drivers/staging/android/Kconfig
@@ -77,6 +77,7 @@ config SYNC
bool "Synchronization framework"
default n
select ANON_INODES
+ select DMA_SHARED_BUFFER
---help---
This option enables the framework for synchronization between multiple
drivers. Sync implementations can take advantage of hardware
diff --git a/drivers/staging/android/Makefile b/drivers/staging/android/Makefile
index 0a01e1914905..517ad5ffa429 100644
--- a/drivers/staging/android/Makefile
+++ b/drivers/staging/android/Makefile
@@ -9,5 +9,5 @@ obj-$(CONFIG_ANDROID_TIMED_OUTPUT) += timed_output.o
obj-$(CONFIG_ANDROID_TIMED_GPIO) += timed_gpio.o
obj-$(CONFIG_ANDROID_LOW_MEMORY_KILLER)+= lowmemorykiller.o
obj-$(CONFIG_ANDROID_INTF_ALARM_DEV) += alarm-dev.o
-obj-$(CONFIG_SYNC) += sync.o
+obj-$(CONFIG_SYNC) += sync.o sync_debug.o
obj-$(CONFIG_SW_SYNC) += sw_sync.o
diff --git a/drivers/staging/android/sw_sync.c
b/drivers/staging/android/sw_sync.c
index f24493ac65e3..a76db3ff87cb 100644
--- a/drivers/staging/android/sw_sync.c
+++ b/drivers/staging/android/sw_sync.c
@@ -50,7 +50,7 @@ static struct sync_pt *sw_sync_pt_dup(struct sync_pt *sync_pt)
{
struct sw_sync_pt *pt = (struct sw_sync_pt *) sync_pt;
struct sw_sync_timeline *obj =
- (struct sw_sync_timeline *)sync_pt->parent;
+ (struct sw_sync_timeline *)sync_pt_parent(sync_pt);
return (struct sync_pt *) sw_sync_pt_create(obj, pt->value);
}
@@ -59,7 +59,7 @@ static int sw_sync_pt_has_signaled(struct sync_pt *sync_pt)
{
struct sw_sync_pt *pt = (struct sw_sync_pt *)sync_pt;
struct sw_sync_timeline *obj =
- (struct sw_sync_timeline *)sync_pt->parent;
+ (struct sw_sync_timeline *)sync_pt_parent(sync_pt);
return sw_sync_cmp(obj->value, pt->value) >= 0;
}
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 3d05f662110b..8e77cd73b739 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -31,22 +31,13 @@
#define CREATE_TRACE_POINTS
#include "trace/sync.h"
-static void sync_fence_signal_pt(struct sync_pt *pt);
-static int _sync_pt_has_signaled(struct sync_pt *pt);
-static void sync_fence_free(struct kref *kref);
-static void sync_dump(void);
-
-static LIST_HEAD(sync_timeline_list_head);
-static DEFINE_SPINLOCK(sync_timeline_list_lock);
-
-static LIST_HEAD(sync_fence_list_head);
-static DEFINE_SPINLOCK(sync_fence_list_lock);
+static const struct fence_ops android_fence_ops;
+static const struct file_operations sync_fence_fops;
struct sync_timeline *sync_timeline_create(const struct sync_timeline_ops *ops,
int size, const char *name)
{
struct sync_timeline *obj;
- unsigned long flags;
if (size < sizeof(struct sync_timeline))
return NULL;
@@ -57,17 +48,14 @@ struct sync_timeline *sync_timeline_create(const struct
sync_timeline_ops *ops,
kref_init(&obj->kref);
obj->ops = ops;
+ obj->context = fence_context_alloc(1);
strlcpy(obj->name, name, sizeof(obj->name));
INIT_LIST_HEAD(&obj->child_list_head);
- spin_lock_init(&obj->child_list_lock);
-
INIT_LIST_HEAD(&obj->active_list_head);
- spin_lock_init(&obj->active_list_lock);
+ spin_lock_init(&obj->child_list_lock);
- spin_lock_irqsave(&sync_timeline_list_lock, flags);
- list_add_tail(&obj->sync_timeline_list, &sync_timeline_list_head);
- spin_unlock_irqrestore(&sync_timeline_list_lock, flags);
+ sync_timeline_debug_add(obj);
return obj;
}
@@ -77,11 +65,8 @@ static void sync_timeline_free(struct kref *kref)
{
struct sync_timeline *obj =
container_of(kref, struct
[PATCH 3/6] dma-buf: use reservation objects
This allows reservation objects to be used in dma-buf. it's required
for implementing polling support on the fences that belong to a dma-buf.
Signed-off-by: Maarten Lankhorst
Acked-by: Mauro Carvalho Chehab
#drivers/media/v4l2-core/
---
drivers/base/dma-buf.c | 22 --
drivers/gpu/drm/drm_prime.c|8 +++-
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |2 +-
drivers/gpu/drm/i915/i915_gem_dmabuf.c |2 +-
drivers/gpu/drm/nouveau/nouveau_drm.c |1 +
drivers/gpu/drm/nouveau/nouveau_gem.h |1 +
drivers/gpu/drm/nouveau/nouveau_prime.c|7 +++
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c |2 +-
drivers/gpu/drm/radeon/radeon_drv.c|2 ++
drivers/gpu/drm/radeon/radeon_prime.c |8
drivers/gpu/drm/ttm/ttm_object.c |2 +-
drivers/media/v4l2-core/videobuf2-dma-contig.c |2 +-
include/drm/drmP.h |2 ++
include/linux/dma-buf.h|9 ++---
14 files changed, 59 insertions(+), 11 deletions(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 1e16cbd61da2..85e792c2c909 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -25,10 +25,12 @@
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
static inline int is_dma_buf_file(struct file *);
@@ -56,6 +58,9 @@ static int dma_buf_release(struct inode *inode, struct file
*file)
list_del(&dmabuf->list_node);
mutex_unlock(&db_list.lock);
+ if (dmabuf->resv == (struct reservation_object*)&dmabuf[1])
+ reservation_object_fini(dmabuf->resv);
+
kfree(dmabuf);
return 0;
}
@@ -128,6 +133,7 @@ static inline int is_dma_buf_file(struct file *file)
* @size: [in]Size of the buffer
* @flags: [in]mode flags for the file.
* @exp_name: [in]name of the exporting module - useful for debugging.
+ * @resv: [in]reservation-object, NULL to allocate default one.
*
* Returns, on success, a newly created dma_buf object, which wraps the
* supplied private data and operations for dma_buf_ops. On either missing
@@ -135,10 +141,17 @@ static inline int is_dma_buf_file(struct file *file)
*
*/
struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops *ops,
- size_t size, int flags, const char *exp_name)
+ size_t size, int flags, const char *exp_name,
+ struct reservation_object *resv)
{
struct dma_buf *dmabuf;
struct file *file;
+ size_t alloc_size = sizeof(struct dma_buf);
+ if (!resv)
+ alloc_size += sizeof(struct reservation_object);
+ else
+ /* prevent &dma_buf[1] == dma_buf->resv */
+ alloc_size += 1;
if (WARN_ON(!priv || !ops
|| !ops->map_dma_buf
@@ -150,7 +163,7 @@ struct dma_buf *dma_buf_export_named(void *priv, const
struct dma_buf_ops *ops,
return ERR_PTR(-EINVAL);
}
- dmabuf = kzalloc(sizeof(struct dma_buf), GFP_KERNEL);
+ dmabuf = kzalloc(alloc_size, GFP_KERNEL);
if (dmabuf == NULL)
return ERR_PTR(-ENOMEM);
@@ -158,6 +171,11 @@ struct dma_buf *dma_buf_export_named(void *priv, const
struct dma_buf_ops *ops,
dmabuf->ops = ops;
dmabuf->size = size;
dmabuf->exp_name = exp_name;
+ if (!resv) {
+ resv = (struct reservation_object*)&dmabuf[1];
+ reservation_object_init(resv);
+ }
+ dmabuf->resv = resv;
file = anon_inode_getfile("dmabuf", &dma_buf_fops, dmabuf, flags);
if (IS_ERR(file)) {
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 56805c39c906..a13e90245adf 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -318,7 +318,13 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =
{
struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
struct drm_gem_object *obj, int flags)
{
- return dma_buf_export(obj, &drm_gem_prime_dmabuf_ops, obj->size, flags);
+ struct reservation_object *robj = NULL;
+
+ if (dev->driver->gem_prime_res_obj)
+ robj = dev->driver->gem_prime_res_obj(obj);
+
+ return dma_buf_export(obj, &drm_gem_prime_dmabuf_ops, obj->size,
+ flags, robj);
}
EXPORT_SYMBOL(drm_gem_prime_export);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 59827cc5e770..b5e89f46326e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -187,7 +187,7 @@ struct dma_buf *exynos_dmabuf_prime_export(struct
drm_device *drm_dev,
stru
[PATCH 2/6] seqno-fence: Hardware dma-buf implementation of fencing (v4)
This type of fence can be used with hardware synchronization for simple
hardware that can block execution until the condition
(dma_buf[offset] - value) >= 0 has been met.
A software fallback still has to be provided in case the fence is used
with a device that doesn't support this mechanism. It is useful to expose
this for graphics cards that have an op to support this.
Some cards like i915 can export those, but don't have an option to wait,
so they need the software fallback.
I extended the original patch by Rob Clark.
v1: Original
v2: Renamed from bikeshed to seqno, moved into dma-fence.c since
not much was left of the file. Lots of documentation added.
v3: Use fence_ops instead of custom callbacks. Moved to own file
to avoid circular dependency between dma-buf.h and fence.h
v4: Add spinlock pointer to seqno_fence_init
Signed-off-by: Maarten Lankhorst
---
Documentation/DocBook/device-drivers.tmpl |1
drivers/base/fence.c | 50 +
include/linux/seqno-fence.h | 109 +
3 files changed, 160 insertions(+)
create mode 100644 include/linux/seqno-fence.h
diff --git a/Documentation/DocBook/device-drivers.tmpl
b/Documentation/DocBook/device-drivers.tmpl
index 7a0c9ddb4818..8c85c20942c2 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -131,6 +131,7 @@ X!Edrivers/base/interface.c
!Edrivers/base/dma-buf.c
!Edrivers/base/fence.c
!Iinclude/linux/fence.h
+!Iinclude/linux/seqno-fence.h
!Edrivers/base/reservation.c
!Iinclude/linux/reservation.h
!Edrivers/base/dma-coherent.c
diff --git a/drivers/base/fence.c b/drivers/base/fence.c
index 12df2bf62034..cd0937127a89 100644
--- a/drivers/base/fence.c
+++ b/drivers/base/fence.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#define CREATE_TRACE_POINTS
#include
@@ -413,3 +414,52 @@ __fence_init(struct fence *fence, const struct fence_ops
*ops,
trace_fence_init(fence);
}
EXPORT_SYMBOL(__fence_init);
+
+static const char *seqno_fence_get_driver_name(struct fence *fence) {
+ struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+ return seqno_fence->ops->get_driver_name(fence);
+}
+
+static const char *seqno_fence_get_timeline_name(struct fence *fence) {
+ struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+ return seqno_fence->ops->get_timeline_name(fence);
+}
+
+static bool seqno_enable_signaling(struct fence *fence)
+{
+ struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+ return seqno_fence->ops->enable_signaling(fence);
+}
+
+static bool seqno_signaled(struct fence *fence)
+{
+ struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+ return seqno_fence->ops->signaled && seqno_fence->ops->signaled(fence);
+}
+
+static void seqno_release(struct fence *fence)
+{
+ struct seqno_fence *f = to_seqno_fence(fence);
+
+ dma_buf_put(f->sync_buf);
+ if (f->ops->release)
+ f->ops->release(fence);
+ else
+ kfree(f);
+}
+
+static long seqno_wait(struct fence *fence, bool intr, signed long timeout)
+{
+ struct seqno_fence *f = to_seqno_fence(fence);
+ return f->ops->wait(fence, intr, timeout);
+}
+
+const struct fence_ops seqno_fence_ops = {
+ .get_driver_name = seqno_fence_get_driver_name,
+ .get_timeline_name = seqno_fence_get_timeline_name,
+ .enable_signaling = seqno_enable_signaling,
+ .signaled = seqno_signaled,
+ .wait = seqno_wait,
+ .release = seqno_release,
+};
+EXPORT_SYMBOL(seqno_fence_ops);
diff --git a/include/linux/seqno-fence.h b/include/linux/seqno-fence.h
new file mode 100644
index ..952f7909128c
--- /dev/null
+++ b/include/linux/seqno-fence.h
@@ -0,0 +1,109 @@
+/*
+ * seqno-fence, using a dma-buf to synchronize fencing
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Copyright (C) 2012 Canonical Ltd
+ * Authors:
+ * Rob Clark
+ * Maarten Lankhorst
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see
[PATCH 1/6] fence: dma-buf cross-device synchronization (v17)
A fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device. For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU is still
rendering. The display device sharing the buffer with the GPU would
attach a callback to get notified when the GPU's rendering-complete IRQ
fires, to update the scan-out address of the display, without having to
wake up userspace.
A driver must allocate a fence context for each execution ring that can
run in parallel. The function for this takes an argument with how many
contexts to allocate:
+ fence_context_alloc()
A fence is transient, one-shot deal. It is allocated and attached
to one or more dma-buf's. When the one that attached it is done, with
the pending operation, it can signal the fence:
+ fence_signal()
To have a rough approximation whether a fence is fired, call:
+ fence_is_signaled()
The dma-buf-mgr handles tracking, and waiting on, the fences associated
with a dma-buf.
The one pending on the fence can add an async callback:
+ fence_add_callback()
The callback can optionally be cancelled with:
+ fence_remove_callback()
To wait synchronously, optionally with a timeout:
+ fence_wait()
+ fence_wait_timeout()
When emitting a fence, call:
+ trace_fence_emit()
To annotate that a fence is blocking on another fence, call:
+ trace_fence_annotate_wait_on(fence, on_fence)
A default software-only implementation is provided, which can be used
by drivers attaching a fence to a buffer when they have no other means
for hw sync. But a memory backed fence is also envisioned, because it
is common that GPU's can write to, or poll on some memory location for
synchronization. For example:
fence = custom_get_fence(...);
if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
dma_buf *fence_buf = seqno_fence->sync_buf;
get_dma_buf(fence_buf);
... tell the hw the memory location to wait ...
custom_wait_on(fence_buf, seqno_fence->seqno_ofs, fence->seqno);
} else {
/* fall-back to sw sync * /
fence_add_callback(fence, my_cb);
}
On SoC platforms, if some other hw mechanism is provided for synchronizing
between IP blocks, it could be supported as an alternate implementation
with it's own fence ops in a similar way.
enable_signaling callback is used to provide sw signaling in case a cpu
waiter is requested or no compatible hardware signaling could be used.
The intention is to provide a userspace interface (presumably via eventfd)
later, to be used in conjunction with dma-buf's mmap support for sw access
to buffers (or for userspace apps that would prefer to do their own
synchronization).
v1: Original
v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
that dma-fence didn't need to care about the sw->hw signaling path
(it can be handled same as sw->sw case), and therefore the fence->ops
can be simplified and more handled in the core. So remove the signal,
add_callback, cancel_callback, and wait ops, and replace with a simple
enable_signaling() op which can be used to inform a fence supporting
hw->hw signaling that one or more devices which do not support hw
signaling are waiting (and therefore it should enable an irq or do
whatever is necessary in order that the CPU is notified when the
fence is passed).
v3: Fix locking fail in attach_fence() and get_fence()
v4: Remove tie-in w/ dma-buf.. after discussion w/ danvet and mlankorst
we decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some comments
about checking if fence fired or not. This is broken by design.
waitqueue_active during destruction is now fatal, since the signaller
should be holding a reference in enable_signalling until it signalled
the fence. Pass the original dma_fence_cb along, and call __remove_wait
in the dma_fence_callback handler, so that no cleanup needs to be
performed.
v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
fence wasn't signaled yet, for example for hardware fences that may
choose to signal blindly.
v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
header and fixed include mess. dma-fence.h now includes dma-buf.h
All members are now initialized, so kmalloc can be used for
allocating a dma-fence. More documentation added.
v9: Change compiler bitfields to flags, change return type of
enable_signaling to bool. Rework dma_fence_wait. Added
dma_fence_is_signaled and dma_fence_wait_timeout.
s/dma// and change exports to non GPL. Added fence_is_signaled and
fence_enable_sw_signaling calls, add ability to override
[PATCH 0/6] dma-buf synchronization patches
The following series implements fence and converts dma-buf and android sync to use it. Patch 6 and 7 add support for polling to dma-buf, blocking until all fences are signaled. I've dropped the extra patch to copy an export from the core, and instead use the public version of it. I've had to fix some fallout from the rebase, hopefully everything's clean now, and ready for -next. --- Maarten Lankhorst (6): fence: dma-buf cross-device synchronization (v17) seqno-fence: Hardware dma-buf implementation of fencing (v4) dma-buf: use reservation objects android: convert sync to fence api, v3 reservation: add support for fences to enable cross-device synchronisation dma-buf: add poll support, v2 Documentation/DocBook/device-drivers.tmpl |3 drivers/base/Kconfig |9 drivers/base/Makefile |2 drivers/base/dma-buf.c | 123 +++ drivers/base/fence.c | 465 + drivers/gpu/drm/drm_prime.c|8 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |2 drivers/gpu/drm/i915/i915_gem_dmabuf.c |2 drivers/gpu/drm/nouveau/nouveau_drm.c |1 drivers/gpu/drm/nouveau/nouveau_gem.h |1 drivers/gpu/drm/nouveau/nouveau_prime.c|7 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c |2 drivers/gpu/drm/radeon/radeon_drv.c|2 drivers/gpu/drm/radeon/radeon_prime.c |8 drivers/gpu/drm/ttm/ttm_object.c |2 drivers/media/v4l2-core/videobuf2-dma-contig.c |2 drivers/staging/android/Kconfig|1 drivers/staging/android/Makefile |2 drivers/staging/android/sw_sync.c |4 drivers/staging/android/sync.c | 892 drivers/staging/android/sync.h | 80 +- drivers/staging/android/sync_debug.c | 245 +++ drivers/staging/android/trace/sync.h | 12 include/drm/drmP.h |2 include/linux/dma-buf.h| 21 - include/linux/fence.h | 329 + include/linux/reservation.h| 18 include/linux/seqno-fence.h| 109 +++ include/trace/events/fence.h | 125 +++ 29 files changed, 1822 insertions(+), 657 deletions(-) create mode 100644 drivers/base/fence.c create mode 100644 drivers/staging/android/sync_debug.c create mode 100644 include/linux/fence.h create mode 100644 include/linux/seqno-fence.h create mode 100644 include/trace/events/fence.h -- Signature
[REGRESSION] ACPI / nouveau: replace open-coded _DSM code with helper functions
This commit breaks loading nouveau on my optimus laptop. I get the following spam in dmesg: [ 24.102587] MXM: GUID detected in BIOS [ 24.103167] ACPI Exception: AE_AML_PACKAGE_LIMIT, Index (0x3) is beyond end of object (length 0x0) (20131218/exoparg2-420) [ 24.103242] ACPI Error: Method parse/execution failed [\_SB_.PCI0.VGA_._DSM] (Node 88007c82e1e0), AE_AML_PACKAGE_LIMIT (20131218/psparse-536) [ 24.103354] ACPI: \_SB_.PCI0.VGA_: failed to evaluate _DSM (0x300b) [ 24.103964] ACPI Exception: AE_AML_PACKAGE_LIMIT, Index (0x3) is beyond end of object (length 0x0) (20131218/exoparg2-420) [ 24.104056] ACPI Error: Method parse/execution failed [\_SB_.PCI0.VGA_._DSM] (Node 88007c82e1e0), AE_AML_PACKAGE_LIMIT (20131218/psparse-536) [ 24.104133] ACPI Error: Method parse/execution failed [\_SB_.PCI0.P0P4.GFX0._DSM] (Node 88007c82e050), AE_AML_PACKAGE_LIMIT (20131218/psparse-536) [ 24.104247] ACPI: \_SB_.PCI0.P0P4.GFX0: failed to evaluate _DSM (0x300b) [ 24.108761] nouveau :04:00.0: enabling device (0004 -> 0007) [ 24.135000] [drm] hdmi device not found 4 0 1 [ 24.135950] nouveau D[ DEVICE][:04:00.0] initialised [ 24.136581] nouveau [ DEVICE][:04:00.0] BOOT0 : 0x0a8b00b1 [ 24.136594] nouveau [ DEVICE][:04:00.0] Chipset: GT218 (NVA8) [ 24.136649] nouveau [ DEVICE][:04:00.0] Family : NV50 [ 24.136661] nouveau D[ DEVICE][:04:00.0] crystal freq: 27000KHz [ 24.145003] nouveau [ VBIOS][:04:00.0] checking PRAMIN for image... [ 24.145085] nouveau [ VBIOS][:04:00.0] ... signature not found [ 24.145143] nouveau [ VBIOS][:04:00.0] checking PROM for image... [ 24.145196] nouveau [ VBIOS][:04:00.0] ... signature not found [ 24.145241] nouveau [ VBIOS][:04:00.0] checking ACPI for image... [ 24.145252] nouveau [ VBIOS][:04:00.0] ... signature not found [ 24.145262] nouveau [ VBIOS][:04:00.0] checking PCIROM for image... [ 24.145638] nouveau :04:00.0: Invalid ROM contents [ 24.146181] nouveau [ VBIOS][:04:00.0] ... signature not found [ 24.146195] nouveau [ VBIOS][:04:00.0] checking PLATFORM for image... [ 24.146253] nouveau [ VBIOS][:04:00.0] ... signature not found [ 24.146264] nouveau E[ VBIOS][:04:00.0] unable to locate usable image [ 24.146469] nouveau E[ DEVICE][:04:00.0] failed to create 0x1001, -22 [ 24.146676] nouveau E[ DRM] failed to create 0x8080, -22 Reverting b072e53b0a27a makes this problem go away. dmesg after reverting: [ 23.470101] MXM: GUID detected in BIOS [ 23.470239] ACPI Warning: \_SB_.PCI0.VGA_._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20131218/nsarguments-95) [ 23.470473] ACPI Warning: \_SB_.PCI0.VGA_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20131218/nsarguments-95) [ 23.472101] ACPI Warning: \_SB_.PCI0.VGA_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20131218/nsarguments-95) [ 23.473582] i915 :00:02.0: optimus capabilities: enabled, status dynamic power, hda bios codec supported [ 23.473699] ACPI Warning: \_SB_.PCI0.P0P4.GFX0._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20131218/nsarguments-95) [ 23.474185] ACPI Warning: \_SB_.PCI0.P0P4.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20131218/nsarguments-95) [ 23.475552] ACPI Warning: \_SB_.PCI0.P0P4.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20131218/nsarguments-95) [ 23.479677] pci :04:00.0: optimus capabilities: enabled, status dynamic power, hda bios codec supported [ 23.479756] VGA switcheroo: detected Optimus DSM method \_SB_.PCI0.P0P4.GFX0 handle [ 23.483963] nouveau :04:00.0: enabling device (0004 -> 0007) [ 23.529744] [drm] hdmi device not found 4 0 1 [ 23.531950] nouveau D[ DEVICE][:04:00.0] initialised [ 23.532587] nouveau [ DEVICE][:04:00.0] BOOT0 : 0x0a8b00b1 [ 23.532600] nouveau [ DEVICE][:04:00.0] Chipset: GT218 (NVA8) [ 23.532666] nouveau [ DEVICE][:04:00.0] Family : NV50 [ 23.532677] nouveau D[ DEVICE][:04:00.0] crystal freq: 27000KHz [ 23.546686] nouveau [ VBIOS][:04:00.0] checking PRAMIN for image... [ 23.547243] nouveau [ VBIOS][:04:00.0] ... signature not found [ 23.547257] nouveau [ VBIOS][:04:00.0] checking PROM for image... [ 23.547338] nouveau [ VBIOS][:04:00.0] ... signature not found [ 23.547348] nouveau [ VBIOS][:04:00.0] checking ACPI for image... [ 23.568444] asus_wmi: ASUS WMI generic driver loaded [ 23.868084] ppdev: user-space parallel port driver [ 23.891268] asus_wmi: Initialization: 0x0 [ 23.891700] asus_wmi: BIOS WMI version: 0.6 [ 23.892578] asus_wmi: SFUN value: 0x0 [ 24.203132] nouveau [ VBIOS][:04:00.0] ... appears to be valid [ 24.203148] nouveau
[Bug 75102] New: Radeon 4890 getting a blank screen and fans go up to 100% (kernel 3.13.3)
https://bugs.freedesktop.org/show_bug.cgi?id=75102 Priority: medium Bug ID: 75102 Assignee: dri-devel at lists.freedesktop.org Summary: Radeon 4890 getting a blank screen and fans go up to 100% (kernel 3.13.3) Severity: critical Classification: Unclassified OS: Linux (All) Reporter: peterasplund at gentoo.se Hardware: Other Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI I've been fiddling around with the cooling on my Radeon 4890 and replaced it with an Arctic Cooling I had mounted on my old 4850 card. It worked for a while, but then the screens went black and the fan maxed out completely. BUT I noticed that the computer was still running, so it hadn't crashed. I could SSH in and reboot it manually. I figured the card had gotten to hot, so I switched the coolers again. But the problem was still there! I started monitoring the temperatures, and they really weren't any hotter than normal. Around 45 degrees C. The weird behavior still repeated itself, even when just browsing the web for a couple of minutes. One time it happened after only 2-3 minutes! I then booted into Windows to see if the problem was there, and nothing happened. I ran benchmarks (3D Mark) and played Left 4 Dead on highest settings for an hour, and no issues. I then booted into Linux, and it still happened. So I then realized I had updated the kernel to 3.13.3 from 3.12.3, and I booted into the old kernel instead. And now I've been running some "emerges" for an hour, and browsed the web, without any issues. Is it possible some weird bug has gotten into the 3.13 kernel? I googled the issue, and saw that there were several posts about the same behavior on the Catalyst drivers a year or so back. Even on Windows that is. -- 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/20140217/ae22a40a/attachment.html>
[Bug 70711] Audio hdmi
https://bugzilla.kernel.org/show_bug.cgi?id=70711 --- Comment #1 from Vincenzo --- vincenzo at AthlonII-X4-640:~$ dmesg |grep HDMI [3.844720] [drm] HDMI-A-1 [ 15.831575] HDMI ATI/AMD: no speaker allocation for ELD [ 15.831619] HDMI ATI/AMD: no speaker allocation for ELD [ 15.831661] HDMI ATI/AMD: no speaker allocation for ELD [ 15.831705] HDMI ATI/AMD: no speaker allocation for ELD [ 15.831750] HDMI ATI/AMD: no speaker allocation for ELD [ 15.831798] HDMI ATI/AMD: no speaker allocation for ELD [ 15.831891] input: HDA ATI HDMI HDMI/DP,pcm=11 as /devices/pci:00/:00:02.0/:01:00.1/sound/card1/input11 [ 15.832011] input: HDA ATI HDMI HDMI/DP,pcm=10 as /devices/pci:00/:00:02.0/:01:00.1/sound/card1/input10 [ 15.832497] input: HDA ATI HDMI HDMI/DP,pcm=9 as /devices/pci:00/:00:02.0/:01:00.1/sound/card1/input9 [ 15.833505] input: HDA ATI HDMI HDMI/DP,pcm=8 as /devices/pci:00/:00:02.0/:01:00.1/sound/card1/input8 [ 15.834673] input: HDA ATI HDMI HDMI/DP,pcm=7 as /devices/pci:00/:00:02.0/:01:00.1/sound/card1/input7 [ 15.834804] input: HDA ATI HDMI HDMI/DP,pcm=3 as /devices/pci:00/:00:02.0/:01:00.1/sound/card1/input6 vincenzo at AthlonII-X4-640:~$ dmesg |grep radeon [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.14.0-rc3 root=UUID=fb4bee82-f698-44f0-b919-af1ebc821958 ro crashkernel=384M-2G:64M,2G-:128M quiet splash radeon.dpm=1 radeon.audio=1 vt.handoff=7 [0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.14.0-rc3 root=UUID=fb4bee82-f698-44f0-b919-af1ebc821958 ro crashkernel=384M-2G:64M,2G-:128M quiet splash radeon.dpm=1 radeon.audio=1 vt.handoff=7 [2.967985] [drm] radeon kernel modesetting enabled. [2.969165] radeon :01:00.0: VRAM: 1024M 0x - 0x3FFF (1024M used) [2.969167] radeon :01:00.0: GTT: 1024M 0x4000 - 0x7FFF [2.969371] [drm] radeon: 1024M of VRAM memory ready [2.969373] [drm] radeon: 1024M of GTT memory ready. [2.976653] [drm] radeon: dpm initialized [2.988849] radeon :01:00.0: WB enabled [2.988852] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x4c00 and cpu addr 0x880414622c00 [2.988854] radeon :01:00.0: fence driver on ring 1 use gpu addr 0x4c04 and cpu addr 0x880414622c04 [2.988856] radeon :01:00.0: fence driver on ring 2 use gpu addr 0x4c08 and cpu addr 0x880414622c08 [2.988858] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x4c0c and cpu addr 0x880414622c0c [2.988859] radeon :01:00.0: fence driver on ring 4 use gpu addr 0x4c10 and cpu addr 0x880414622c10 [2.989362] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00075a18 and cpu addr 0xc90011db5a18 [2.989389] radeon :01:00.0: irq 49 for MSI/MSI-X [2.989402] radeon :01:00.0: radeon: using MSI. [2.989430] [drm] radeon: irq initialized. [3.926329] fbcon: radeondrmfb (fb0) is primary device [3.955401] radeon :01:00.0: fb0: radeondrmfb frame buffer device [3.955403] radeon :01:00.0: registered panic notifier [3.964998] [drm] Initialized radeon 2.37.0 20080528 for :01:00.0 on minor 0 vincenzo at AthlonII-X4-640:~$ dmesg |grep audio [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.14.0-rc3 root=UUID=fb4bee82-f698-44f0-b919-af1ebc821958 ro crashkernel=384M-2G:64M,2G-:128M quiet splash radeon.dpm=1 radeon.audio=1 vt.handoff=7 [0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.14.0-rc3 root=UUID=fb4bee82-f698-44f0-b919-af1ebc821958 ro crashkernel=384M-2G:64M,2G-:128M quiet splash radeon.dpm=1 radeon.audio=1 vt.handoff=7 [3.692995] [drm] Enabling audio 0 support [3.692997] [drm] Enabling audio 1 support [3.692998] [drm] Enabling audio 2 support [3.692999] [drm] Enabling audio 3 support [3.693000] [drm] Enabling audio 4 support [3.693001] [drm] Enabling audio 5 support [ 15.737702] hda-intel :01:00.1: Handle VGA-switcheroo audio client -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 73781] [r600g] SIGFPE at ../../../../../src/gallium/drivers/r600/r600_state.c:3109
https://bugs.freedesktop.org/show_bug.cgi?id=73781 --- Comment #6 from jospezial --- I read something about this bug there: http://lists.freedesktop.org/archives/mesa-dev/2014-February/053164.html How is it going on? -- 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/20140217/1d58b6d0/attachment.html>
[Bug 70711] New: Audio hdmi
https://bugzilla.kernel.org/show_bug.cgi?id=70711 Bug ID: 70711 Summary: Audio hdmi Product: Drivers Version: 2.5 Kernel Version: 3.14.0-rc3 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: vincenzov72 at hotmail.com Regression: No Audio hdmi not work with radeon 7750, works good with radeon 6450 -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v3] drm/nouveau: support for platform devices
Upcoming mobile Kepler GPUs (such as GK20A) use the platform bus instead
of PCI to which Nouveau is tightly dependent. This patch allows Nouveau
to handle platform devices by:
- abstracting PCI-dependent functions that were typically used for
resource querying and page mapping,
- introducing a nv_device_is_pci() function that allows to make
PCI-dependent code conditional,
- providing a nouveau_drm_platform_probe() function that takes a GPU
platform device to be probed.
Core code as well as engine/subdev drivers are updated wherever possible
to make use of these functions. Some older drivers are too dependent on
PCI to be properly updated, but all newer code on which future chips may
depend should at least be runnable with platform devices.
Signed-off-by: Alexandre Courbot
---
Changes since v2:
- Moved MSI code under PCI-conditioned blocks in mc/base.c, as suggested by
Emil Velikov. This makes more sense with respect to how MSI is used and
allows us to get rid of a couple extra conditional statements.
drivers/gpu/drm/nouveau/core/engine/device/base.c | 83 --
drivers/gpu/drm/nouveau/core/engine/falcon.c | 6 +-
drivers/gpu/drm/nouveau/core/engine/fifo/base.c| 2 +-
drivers/gpu/drm/nouveau/core/engine/graph/nv20.c | 2 +-
drivers/gpu/drm/nouveau/core/engine/graph/nv40.c | 2 +-
drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c | 4 +-
drivers/gpu/drm/nouveau/core/engine/xtensa.c | 2 +-
drivers/gpu/drm/nouveau/core/include/core/device.h | 30
.../gpu/drm/nouveau/core/include/engine/device.h | 17 +++--
drivers/gpu/drm/nouveau/core/include/subdev/mc.h | 1 +
drivers/gpu/drm/nouveau/core/os.h | 1 +
drivers/gpu/drm/nouveau/core/subdev/bar/base.c | 4 +-
drivers/gpu/drm/nouveau/core/subdev/bar/nv50.c | 4 +-
drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c | 15 ++--
.../gpu/drm/nouveau/core/subdev/devinit/fbmem.h| 8 ++-
drivers/gpu/drm/nouveau/core/subdev/devinit/nv04.c | 2 +-
drivers/gpu/drm/nouveau/core/subdev/devinit/nv05.c | 2 +-
drivers/gpu/drm/nouveau/core/subdev/devinit/nv10.c | 2 +-
drivers/gpu/drm/nouveau/core/subdev/devinit/nv20.c | 2 +-
drivers/gpu/drm/nouveau/core/subdev/fb/nv50.c | 9 +--
drivers/gpu/drm/nouveau/core/subdev/fb/nvc0.c | 9 +--
drivers/gpu/drm/nouveau/core/subdev/i2c/base.c | 2 +-
drivers/gpu/drm/nouveau/core/subdev/instmem/nv40.c | 7 +-
drivers/gpu/drm/nouveau/core/subdev/mc/base.c | 55 --
drivers/gpu/drm/nouveau/core/subdev/mxm/base.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_abi16.c| 13 +++-
drivers/gpu/drm/nouveau/nouveau_agp.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bios.c | 4 ++
drivers/gpu/drm/nouveau/nouveau_bo.c | 22 +++---
drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_display.c | 3 +-
drivers/gpu/drm/nouveau/nouveau_drm.c | 59 ---
drivers/gpu/drm/nouveau/nouveau_sysfs.c| 8 ++-
drivers/gpu/drm/nouveau/nouveau_ttm.c | 31
drivers/gpu/drm/nouveau/nouveau_vga.c | 5 ++
35 files changed, 306 insertions(+), 116 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/engine/device/base.c
b/drivers/gpu/drm/nouveau/core/engine/device/base.c
index dd01c6c435d6..8a8f5f2d0eb5 100644
--- a/drivers/gpu/drm/nouveau/core/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/core/engine/device/base.c
@@ -131,8 +131,8 @@ nouveau_devobj_ctor(struct nouveau_object *parent,
if (ret)
return ret;
- mmio_base = pci_resource_start(device->pdev, 0);
- mmio_size = pci_resource_len(device->pdev, 0);
+ mmio_base = nv_device_resource_start(device, 0);
+ mmio_size = nv_device_resource_len(device, 0);
/* translate api disable mask into internal mapping */
disable = args->debug0;
@@ -446,6 +446,72 @@ nouveau_device_dtor(struct nouveau_object *object)
nouveau_engine_destroy(&device->base);
}
+resource_size_t
+nv_device_resource_start(struct nouveau_device *device, unsigned int bar)
+{
+ if (nv_device_is_pci(device)) {
+ return pci_resource_start(device->pdev, bar);
+ } else {
+ struct resource *res;
+ res = platform_get_resource(device->platformdev,
+ IORESOURCE_MEM, bar);
+ if (!res)
+ return 0;
+ return res->start;
+ }
+}
+
+resource_size_t
+nv_device_resource_len(struct nouveau_device *device, unsigned int bar)
+{
+ if (nv_device_is_pci(device)) {
+ return pci_resource_len(device->pdev, bar);
+ } else {
+ struct resource *res;
+ res = platform_get_resource(device->platformdev,
+ IORESOURCE_MEM, bar);
+ if (!res)
+
[PATCH] drm/radeon: fix display tiling setup on SI
Apply the same logic as CI to SI for setting up the
display tiling parameters. The num banks may vary
per tiling index just like CI.
Bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=71488
https://bugs.freedesktop.org/show_bug.cgi?id=73946
https://bugs.freedesktop.org/show_bug.cgi?id=74927
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/atombios_crtc.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index f0d409d..0d19f4f9 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1176,7 +1176,7 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
evergreen_tiling_fields(tiling_flags, &bankw, &bankh,
&mtaspect, &tile_split);
/* Set NUM_BANKS. */
- if (rdev->family >= CHIP_BONAIRE) {
+ if (rdev->family >= CHIP_TAHITI) {
unsigned tileb, index, num_banks, tile_split_bytes;
/* Calculate the macrotile mode index. */
@@ -1194,13 +1194,14 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
return -EINVAL;
}
- num_banks =
(rdev->config.cik.macrotile_mode_array[index] >> 6) & 0x3;
+ if (rdev->family >= CHIP_BONAIRE)
+ num_banks =
(rdev->config.cik.macrotile_mode_array[index] >> 6) & 0x3;
+ else
+ num_banks =
(rdev->config.si.tile_mode_array[index] >> 20) & 0x3;
fb_format |= EVERGREEN_GRPH_NUM_BANKS(num_banks);
} else {
- /* SI and older. */
- if (rdev->family >= CHIP_TAHITI)
- tmp = rdev->config.si.tile_config;
- else if (rdev->family >= CHIP_CAYMAN)
+ /* NI and older. */
+ if (rdev->family >= CHIP_CAYMAN)
tmp = rdev->config.cayman.tile_config;
else
tmp = rdev->config.evergreen.tile_config;
--
1.8.3.1
[Bug 73781] [r600g] SIGFPE at ../../../../../src/gallium/drivers/r600/r600_state.c:3109
https://bugs.freedesktop.org/show_bug.cgi?id=73781 --- Comment #5 from jospezial at gmx.de --- https://bugs.gentoo.org/show_bug.cgi?id=501286 media-libs/mesa crashes x11-drivers/xf86-video-ati[glamor] with SIGFPE with large textures (when firefox loads a specific website) x11-libs/glamor-0.6.0 media-libs/mesa-9.2.5 x11-base/xorg-server-1.15.0 Radeon HD 4850 RV770 patch from #c4 https://bugs.freedesktop.org/attachment.cgi?id=92645 works for me please add it to the source -- 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/20140217/9c457964/attachment.html>
[PATCH 2/6] seqno-fence: Hardware dma-buf implementation of fencing (v4)
On Mon, Feb 17, 2014 at 12:36 PM, Christian K?nig
wrote:
> Am 17.02.2014 18:27, schrieb Rob Clark:
>
>> On Mon, Feb 17, 2014 at 11:56 AM, Christian K?nig
>> wrote:
>>>
>>> Am 17.02.2014 16:56, schrieb Maarten Lankhorst:
>>>
This type of fence can be used with hardware synchronization for simple
hardware that can block execution until the condition
(dma_buf[offset] - value) >= 0 has been met.
>>>
>>>
>>> Can't we make that just "dma_buf[offset] != 0" instead? As far as I know
>>> this way it would match the definition M$ uses in their WDDM
>>> specification
>>> and so make it much more likely that hardware supports it.
>>
>> well 'buf[offset] >= value' at least means the same slot can be used
>> for multiple operations (with increasing values of 'value').. not sure
>> if that is something people care about.
>>
>>> =value seems to be possible with adreno and radeon. I'm not really sure
>>> about others (although I presume it as least supported for nv desktop
>>> stuff). For hw that cannot do >=value, we can either have a different fence
>>> implementation which uses the !=0 approach. Or change seqno-fence
>>> implementation later if needed. But if someone has hw that can do !=0 but
>>> not >=value, speak up now ;-)
>
>
> Here! Radeon can only do >=value on the DMA and 3D engine, but not with UVD
> or VCE. And for the 3D engine it means draining the pipe, which isn't really
> a good idea.
hmm, ok.. forgot you have a few extra rings compared to me. Is UVD
re-ordering from decode-order to display-order for you in hw? If not,
I guess you need sw intervention anyways when a frame is done for
frame re-ordering, so maybe hw->hw sync doesn't really matter as much
as compared to gpu/3d->display. For dma<->3d interactions, seems like
you would care more about hw<->hw sync, but I guess you aren't likely
to use GPU A to do a resolve blit for GPU B..
For 3D ring, I assume you probably want a CP_WAIT_FOR_IDLE before a
CP_MEM_WRITE to update fence value in memory (for the one signalling
the fence). But why would you need that before a CP_WAIT_REG_MEM (for
the one waiting for the fence)? I don't exactly have documentation
for adreno version of CP_WAIT_REG_{MEM,EQ,GTE}.. but PFP and ME
appear to be same instruction set as r600, so I'm pretty sure they
should have similar capabilities.. CP_WAIT_REG_MEM appears to be same
but with 32bit gpu addresses vs 64b.
BR,
-R
> Christian.
>
>
>>
>>> Apart from that I still don't like the idea of leaking a drivers IRQ
>>> context
>>> outside of the driver, but without a proper GPU scheduler there probably
>>> isn't much alternative.
>>
>> I guess it will be not uncommon scenario for gpu device to just need
>> to kick display device to write a few registers for a page flip..
>> probably best not to schedule a worker just for this (unless the
>> signalled device otherwise needs to). I think it is better in this
>> case to give the signalee some rope to hang themselves, and make it
>> the responsibility of the callback to kick things off to a worker if
>> needed.
>>
>> BR,
>> -R
>>
>>> Christian.
>>>
A software fallback still has to be provided in case the fence is used
with a device that doesn't support this mechanism. It is useful to
expose
this for graphics cards that have an op to support this.
Some cards like i915 can export those, but don't have an option to wait,
so they need the software fallback.
I extended the original patch by Rob Clark.
v1: Original
v2: Renamed from bikeshed to seqno, moved into dma-fence.c since
not much was left of the file. Lots of documentation added.
v3: Use fence_ops instead of custom callbacks. Moved to own file
to avoid circular dependency between dma-buf.h and fence.h
v4: Add spinlock pointer to seqno_fence_init
Signed-off-by: Maarten Lankhorst
---
Documentation/DocBook/device-drivers.tmpl |1
drivers/base/fence.c | 50 +
include/linux/seqno-fence.h | 109
+
3 files changed, 160 insertions(+)
create mode 100644 include/linux/seqno-fence.h
diff --git a/Documentation/DocBook/device-drivers.tmpl
b/Documentation/DocBook/device-drivers.tmpl
index 7a0c9ddb4818..8c85c20942c2 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -131,6 +131,7 @@ X!Edrivers/base/interface.c
!Edrivers/base/dma-buf.c
!Edrivers/base/fence.c
!Iinclude/linux/fence.h
+!Iinclude/linux/seqno-fence.h
!Edrivers/base/reservation.c
!Iinclude/linux/reservation.h
!Edrivers/base/dma-coherent.c
diff --git a/drivers/base/fence.c b/drivers/base/fence.c
index 12df2bf62034..cd0937127a89 100644
--- a/drivers/base/fence.c
+++ b/drivers/base/fence.c
@@ -25,6 +25,7 @@
#inclu
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #197 from Shawn Starr --- With 3.14-rcX are people seeing lockup on reboots anymore on HD2000-HD4000 series? I'm going to switch my W500 to it, right now it's hung while im away *sigh*, so I can't remotely reset 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/20140217/2814e629/attachment.html>
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux
https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #62 from Paul Menzel --- I forgot to thank you for all your help and it makes me sad that I had to come to the conclusion. -- 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/20140217/6bd1ca20/attachment.html>
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux
https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #61 from Paul Menzel --- I tried to finally get a usable laptop by using FGLRX, but neither 13.12 nor 14.1~beta1.3-1 worked with my Debian installation. That means, GNU/Linux is unusable with this AMD based laptop and, jugdging from the time wasted to get GNU/Linux to work, I regret ever buying it. The disk with MS Windows 8.1 was put back in and somebody else is using it now. Judging from the current state I won?t be able to recommend to anyone to buy an AMD based laptop. Sorry. Also I won?t be able to do any further tests. -- 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/20140217/ed183b72/attachment.html>
[PATCH 2/6] seqno-fence: Hardware dma-buf implementation of fencing (v4)
On Mon, Feb 17, 2014 at 11:56 AM, Christian K?nig
wrote:
> Am 17.02.2014 16:56, schrieb Maarten Lankhorst:
>
>> This type of fence can be used with hardware synchronization for simple
>> hardware that can block execution until the condition
>> (dma_buf[offset] - value) >= 0 has been met.
>
>
> Can't we make that just "dma_buf[offset] != 0" instead? As far as I know
> this way it would match the definition M$ uses in their WDDM specification
> and so make it much more likely that hardware supports it.
well 'buf[offset] >= value' at least means the same slot can be used
for multiple operations (with increasing values of 'value').. not sure
if that is something people care about.
>=value seems to be possible with adreno and radeon. I'm not really sure about
>others (although I presume it as least supported for nv desktop stuff). For
>hw that cannot do >=value, we can either have a different fence implementation
>which uses the !=0 approach. Or change seqno-fence implementation later if
>needed. But if someone has hw that can do !=0 but not >=value, speak up now
>;-)
> Apart from that I still don't like the idea of leaking a drivers IRQ context
> outside of the driver, but without a proper GPU scheduler there probably
> isn't much alternative.
I guess it will be not uncommon scenario for gpu device to just need
to kick display device to write a few registers for a page flip..
probably best not to schedule a worker just for this (unless the
signalled device otherwise needs to). I think it is better in this
case to give the signalee some rope to hang themselves, and make it
the responsibility of the callback to kick things off to a worker if
needed.
BR,
-R
> Christian.
>
>>
>> A software fallback still has to be provided in case the fence is used
>> with a device that doesn't support this mechanism. It is useful to expose
>> this for graphics cards that have an op to support this.
>>
>> Some cards like i915 can export those, but don't have an option to wait,
>> so they need the software fallback.
>>
>> I extended the original patch by Rob Clark.
>>
>> v1: Original
>> v2: Renamed from bikeshed to seqno, moved into dma-fence.c since
>> not much was left of the file. Lots of documentation added.
>> v3: Use fence_ops instead of custom callbacks. Moved to own file
>> to avoid circular dependency between dma-buf.h and fence.h
>> v4: Add spinlock pointer to seqno_fence_init
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> Documentation/DocBook/device-drivers.tmpl |1
>> drivers/base/fence.c | 50 +
>> include/linux/seqno-fence.h | 109
>> +
>> 3 files changed, 160 insertions(+)
>> create mode 100644 include/linux/seqno-fence.h
>>
>> diff --git a/Documentation/DocBook/device-drivers.tmpl
>> b/Documentation/DocBook/device-drivers.tmpl
>> index 7a0c9ddb4818..8c85c20942c2 100644
>> --- a/Documentation/DocBook/device-drivers.tmpl
>> +++ b/Documentation/DocBook/device-drivers.tmpl
>> @@ -131,6 +131,7 @@ X!Edrivers/base/interface.c
>> !Edrivers/base/dma-buf.c
>> !Edrivers/base/fence.c
>> !Iinclude/linux/fence.h
>> +!Iinclude/linux/seqno-fence.h
>> !Edrivers/base/reservation.c
>> !Iinclude/linux/reservation.h
>> !Edrivers/base/dma-coherent.c
>> diff --git a/drivers/base/fence.c b/drivers/base/fence.c
>> index 12df2bf62034..cd0937127a89 100644
>> --- a/drivers/base/fence.c
>> +++ b/drivers/base/fence.c
>> @@ -25,6 +25,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #define CREATE_TRACE_POINTS
>> #include
>> @@ -413,3 +414,52 @@ __fence_init(struct fence *fence, const struct
>> fence_ops *ops,
>> trace_fence_init(fence);
>> }
>> EXPORT_SYMBOL(__fence_init);
>> +
>> +static const char *seqno_fence_get_driver_name(struct fence *fence) {
>> + struct seqno_fence *seqno_fence = to_seqno_fence(fence);
>> + return seqno_fence->ops->get_driver_name(fence);
>> +}
>> +
>> +static const char *seqno_fence_get_timeline_name(struct fence *fence) {
>> + struct seqno_fence *seqno_fence = to_seqno_fence(fence);
>> + return seqno_fence->ops->get_timeline_name(fence);
>> +}
>> +
>> +static bool seqno_enable_signaling(struct fence *fence)
>> +{
>> + struct seqno_fence *seqno_fence = to_seqno_fence(fence);
>> + return seqno_fence->ops->enable_signaling(fence);
>> +}
>> +
>> +static bool seqno_signaled(struct fence *fence)
>> +{
>> + struct seqno_fence *seqno_fence = to_seqno_fence(fence);
>> + return seqno_fence->ops->signaled &&
>> seqno_fence->ops->signaled(fence);
>> +}
>> +
>> +static void seqno_release(struct fence *fence)
>> +{
>> + struct seqno_fence *f = to_seqno_fence(fence);
>> +
>> + dma_buf_put(f->sync_buf);
>> + if (f->ops->release)
>> + f->ops->release(fence);
>> + else
>> + kfree(f);
>> +}
>> +
>> +static long seqno_wait(struct fence *fence, bool intr, signed long
>> time
[PATCH 1/6] fence: dma-buf cross-device synchronization (v17)
On Mon, Feb 17, 2014 at 10:55 AM, Maarten Lankhorst
wrote:
> A fence can be attached to a buffer which is being filled or consumed
> by hw, to allow userspace to pass the buffer without waiting to another
> device. For example, userspace can call page_flip ioctl to display the
> next frame of graphics after kicking the GPU but while the GPU is still
> rendering. The display device sharing the buffer with the GPU would
> attach a callback to get notified when the GPU's rendering-complete IRQ
> fires, to update the scan-out address of the display, without having to
> wake up userspace.
>
> A driver must allocate a fence context for each execution ring that can
> run in parallel. The function for this takes an argument with how many
> contexts to allocate:
> + fence_context_alloc()
>
> A fence is transient, one-shot deal. It is allocated and attached
> to one or more dma-buf's. When the one that attached it is done, with
> the pending operation, it can signal the fence:
> + fence_signal()
>
> To have a rough approximation whether a fence is fired, call:
> + fence_is_signaled()
>
> The dma-buf-mgr handles tracking, and waiting on, the fences associated
> with a dma-buf.
>
> The one pending on the fence can add an async callback:
> + fence_add_callback()
>
> The callback can optionally be cancelled with:
> + fence_remove_callback()
>
> To wait synchronously, optionally with a timeout:
> + fence_wait()
> + fence_wait_timeout()
>
> When emitting a fence, call:
> + trace_fence_emit()
>
> To annotate that a fence is blocking on another fence, call:
> + trace_fence_annotate_wait_on(fence, on_fence)
>
> A default software-only implementation is provided, which can be used
> by drivers attaching a fence to a buffer when they have no other means
> for hw sync. But a memory backed fence is also envisioned, because it
> is common that GPU's can write to, or poll on some memory location for
> synchronization. For example:
>
> fence = custom_get_fence(...);
> if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
> dma_buf *fence_buf = seqno_fence->sync_buf;
> get_dma_buf(fence_buf);
>
> ... tell the hw the memory location to wait ...
> custom_wait_on(fence_buf, seqno_fence->seqno_ofs, fence->seqno);
> } else {
> /* fall-back to sw sync * /
> fence_add_callback(fence, my_cb);
> }
>
> On SoC platforms, if some other hw mechanism is provided for synchronizing
> between IP blocks, it could be supported as an alternate implementation
> with it's own fence ops in a similar way.
>
> enable_signaling callback is used to provide sw signaling in case a cpu
> waiter is requested or no compatible hardware signaling could be used.
>
> The intention is to provide a userspace interface (presumably via eventfd)
> later, to be used in conjunction with dma-buf's mmap support for sw access
> to buffers (or for userspace apps that would prefer to do their own
> synchronization).
>
> v1: Original
> v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
> that dma-fence didn't need to care about the sw->hw signaling path
> (it can be handled same as sw->sw case), and therefore the fence->ops
> can be simplified and more handled in the core. So remove the signal,
> add_callback, cancel_callback, and wait ops, and replace with a simple
> enable_signaling() op which can be used to inform a fence supporting
> hw->hw signaling that one or more devices which do not support hw
> signaling are waiting (and therefore it should enable an irq or do
> whatever is necessary in order that the CPU is notified when the
> fence is passed).
> v3: Fix locking fail in attach_fence() and get_fence()
> v4: Remove tie-in w/ dma-buf.. after discussion w/ danvet and mlankorst
> we decided that we need to be able to attach one fence to N dma-buf's,
> so using the list_head in dma-fence struct would be problematic.
> v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
> v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some
> comments
> about checking if fence fired or not. This is broken by design.
> waitqueue_active during destruction is now fatal, since the signaller
> should be holding a reference in enable_signalling until it signalled
> the fence. Pass the original dma_fence_cb along, and call __remove_wait
> in the dma_fence_callback handler, so that no cleanup needs to be
> performed.
> v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
> fence wasn't signaled yet, for example for hardware fences that may
> choose to signal blindly.
> v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
> header and fixed include mess. dma-fence.h now includes dma-buf.h
> All members are now initialized, so kmalloc can be used for
> allocating a dma-fence. More documentation added.
> v9: Change compiler bitfields to flags, change return ty
[PATCH 2/6] seqno-fence: Hardware dma-buf implementation of fencing (v4)
On Mon, Feb 17, 2014 at 10:56 AM, Maarten Lankhorst
wrote:
> This type of fence can be used with hardware synchronization for simple
> hardware that can block execution until the condition
> (dma_buf[offset] - value) >= 0 has been met.
>
> A software fallback still has to be provided in case the fence is used
> with a device that doesn't support this mechanism. It is useful to expose
> this for graphics cards that have an op to support this.
>
> Some cards like i915 can export those, but don't have an option to wait,
> so they need the software fallback.
>
> I extended the original patch by Rob Clark.
>
> v1: Original
> v2: Renamed from bikeshed to seqno, moved into dma-fence.c since
> not much was left of the file. Lots of documentation added.
> v3: Use fence_ops instead of custom callbacks. Moved to own file
> to avoid circular dependency between dma-buf.h and fence.h
> v4: Add spinlock pointer to seqno_fence_init
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Rob Clark
> ---
> Documentation/DocBook/device-drivers.tmpl |1
> drivers/base/fence.c | 50 +
> include/linux/seqno-fence.h | 109
> +
> 3 files changed, 160 insertions(+)
> create mode 100644 include/linux/seqno-fence.h
>
> diff --git a/Documentation/DocBook/device-drivers.tmpl
> b/Documentation/DocBook/device-drivers.tmpl
> index 7a0c9ddb4818..8c85c20942c2 100644
> --- a/Documentation/DocBook/device-drivers.tmpl
> +++ b/Documentation/DocBook/device-drivers.tmpl
> @@ -131,6 +131,7 @@ X!Edrivers/base/interface.c
> !Edrivers/base/dma-buf.c
> !Edrivers/base/fence.c
> !Iinclude/linux/fence.h
> +!Iinclude/linux/seqno-fence.h
> !Edrivers/base/reservation.c
> !Iinclude/linux/reservation.h
> !Edrivers/base/dma-coherent.c
> diff --git a/drivers/base/fence.c b/drivers/base/fence.c
> index 12df2bf62034..cd0937127a89 100644
> --- a/drivers/base/fence.c
> +++ b/drivers/base/fence.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
>
> #define CREATE_TRACE_POINTS
> #include
> @@ -413,3 +414,52 @@ __fence_init(struct fence *fence, const struct fence_ops
> *ops,
> trace_fence_init(fence);
> }
> EXPORT_SYMBOL(__fence_init);
> +
> +static const char *seqno_fence_get_driver_name(struct fence *fence) {
> + struct seqno_fence *seqno_fence = to_seqno_fence(fence);
> + return seqno_fence->ops->get_driver_name(fence);
> +}
> +
> +static const char *seqno_fence_get_timeline_name(struct fence *fence) {
> + struct seqno_fence *seqno_fence = to_seqno_fence(fence);
> + return seqno_fence->ops->get_timeline_name(fence);
> +}
> +
> +static bool seqno_enable_signaling(struct fence *fence)
> +{
> + struct seqno_fence *seqno_fence = to_seqno_fence(fence);
> + return seqno_fence->ops->enable_signaling(fence);
> +}
> +
> +static bool seqno_signaled(struct fence *fence)
> +{
> + struct seqno_fence *seqno_fence = to_seqno_fence(fence);
> + return seqno_fence->ops->signaled &&
> seqno_fence->ops->signaled(fence);
> +}
> +
> +static void seqno_release(struct fence *fence)
> +{
> + struct seqno_fence *f = to_seqno_fence(fence);
> +
> + dma_buf_put(f->sync_buf);
> + if (f->ops->release)
> + f->ops->release(fence);
> + else
> + kfree(f);
> +}
> +
> +static long seqno_wait(struct fence *fence, bool intr, signed long timeout)
> +{
> + struct seqno_fence *f = to_seqno_fence(fence);
> + return f->ops->wait(fence, intr, timeout);
> +}
> +
> +const struct fence_ops seqno_fence_ops = {
> + .get_driver_name = seqno_fence_get_driver_name,
> + .get_timeline_name = seqno_fence_get_timeline_name,
> + .enable_signaling = seqno_enable_signaling,
> + .signaled = seqno_signaled,
> + .wait = seqno_wait,
> + .release = seqno_release,
> +};
> +EXPORT_SYMBOL(seqno_fence_ops);
> diff --git a/include/linux/seqno-fence.h b/include/linux/seqno-fence.h
> new file mode 100644
> index ..952f7909128c
> --- /dev/null
> +++ b/include/linux/seqno-fence.h
> @@ -0,0 +1,109 @@
> +/*
> + * seqno-fence, using a dma-buf to synchronize fencing
> + *
> + * Copyright (C) 2012 Texas Instruments
> + * Copyright (C) 2012 Canonical Ltd
> + * Authors:
> + * Rob Clark
> + * Maarten Lankhorst
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful, but
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> with
> + * this program. If not, see
[PATCH 5/6] reservation: add support for fences to enable cross-device synchronisation
On Mon, Feb 17, 2014 at 10:58 AM, Maarten Lankhorst
wrote:
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Rob Clark
> ---
> include/linux/reservation.h | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/reservation.h b/include/linux/reservation.h
> index 813dae960ebd..92c4851b5a39 100644
> --- a/include/linux/reservation.h
> +++ b/include/linux/reservation.h
> @@ -6,7 +6,7 @@
> * Copyright (C) 2012 Texas Instruments
> *
> * Authors:
> - * Rob Clark
> + * Rob Clark
> * Maarten Lankhorst
> * Thomas Hellstrom
> *
> @@ -40,22 +40,38 @@
> #define _LINUX_RESERVATION_H
>
> #include
> +#include
>
> extern struct ww_class reservation_ww_class;
>
> struct reservation_object {
> struct ww_mutex lock;
> +
> + struct fence *fence_excl;
> + struct fence **fence_shared;
> + u32 fence_shared_count, fence_shared_max;
> };
>
> static inline void
> reservation_object_init(struct reservation_object *obj)
> {
> ww_mutex_init(&obj->lock, &reservation_ww_class);
> +
> + obj->fence_shared_count = obj->fence_shared_max = 0;
> + obj->fence_shared = NULL;
> + obj->fence_excl = NULL;
> }
>
> static inline void
> reservation_object_fini(struct reservation_object *obj)
> {
> + int i;
> +
> + if (obj->fence_excl)
> + fence_put(obj->fence_excl);
> + for (i = 0; i < obj->fence_shared_count; ++i)
> + fence_put(obj->fence_shared[i]);
> +
> ww_mutex_destroy(&obj->lock);
> }
>
>
GBM Buffer handling
Hi... I missed to mention one point in previous mail, we should not use X11/ wayland! Regards, Binoy. -Original Message- From: Binoy V. V. Sent: Monday, February 17, 2014 11:06 AM To: 'dri-devel at lists.freedesktop.org' Subject: GBM Buffer handling Hi... We are developing a client/ server mode application. Whether it's possible to create gbm surface in client and render using drm in server? We had tried to do so, server is getting crash when accessing the gbm surface created by client. Regards, Binoy. * Confidentiality Statement/Disclaimer * This message and any attachments is intended for the sole use of the intended recipient. It may contain confidential information. Any unauthorized use, dissemination or modification is strictly prohibited. If you are not the intended recipient, please notify the sender immediately then delete it from all your systems, and do not copy, use or print. Internet communications are not secure and it is the responsibility of the recipient to make sure that it is virus/malicious code exempt. The company/sender cannot be responsible for any unauthorized alterations or modifications made to the contents. If you require any form of confirmation of the contents, please contact the company/sender. The company/sender is not liable for any errors or omissions in the content of this message.
[PATCH 3/6] dma-buf: use reservation objects
On Mon, Feb 17, 2014 at 10:56 AM, Maarten Lankhorst
wrote:
> This allows reservation objects to be used in dma-buf. it's required
> for implementing polling support on the fences that belong to a dma-buf.
>
> Signed-off-by: Maarten Lankhorst
> Acked-by: Mauro Carvalho Chehab
> #drivers/media/v4l2-core/
> ---
> drivers/base/dma-buf.c | 22 --
> drivers/gpu/drm/drm_prime.c|8 +++-
> drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |2 +-
> drivers/gpu/drm/i915/i915_gem_dmabuf.c |2 +-
> drivers/gpu/drm/nouveau/nouveau_drm.c |1 +
> drivers/gpu/drm/nouveau/nouveau_gem.h |1 +
> drivers/gpu/drm/nouveau/nouveau_prime.c|7 +++
> drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c |2 +-
> drivers/gpu/drm/radeon/radeon_drv.c|2 ++
> drivers/gpu/drm/radeon/radeon_prime.c |8
> drivers/gpu/drm/ttm/ttm_object.c |2 +-
> drivers/media/v4l2-core/videobuf2-dma-contig.c |2 +-
> include/drm/drmP.h |2 ++
> include/linux/dma-buf.h|9 ++---
> 14 files changed, 59 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
> index 1e16cbd61da2..85e792c2c909 100644
> --- a/drivers/base/dma-buf.c
> +++ b/drivers/base/dma-buf.c
> @@ -25,10 +25,12 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> +#include
>
> static inline int is_dma_buf_file(struct file *);
>
> @@ -56,6 +58,9 @@ static int dma_buf_release(struct inode *inode, struct file
> *file)
> list_del(&dmabuf->list_node);
> mutex_unlock(&db_list.lock);
>
> + if (dmabuf->resv == (struct reservation_object*)&dmabuf[1])
> + reservation_object_fini(dmabuf->resv);
> +
> kfree(dmabuf);
> return 0;
> }
> @@ -128,6 +133,7 @@ static inline int is_dma_buf_file(struct file *file)
> * @size: [in]Size of the buffer
> * @flags: [in]mode flags for the file.
> * @exp_name: [in]name of the exporting module - useful for debugging.
> + * @resv: [in]reservation-object, NULL to allocate default one.
> *
> * Returns, on success, a newly created dma_buf object, which wraps the
> * supplied private data and operations for dma_buf_ops. On either missing
> @@ -135,10 +141,17 @@ static inline int is_dma_buf_file(struct file *file)
> *
> */
> struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops
> *ops,
> - size_t size, int flags, const char *exp_name)
> + size_t size, int flags, const char *exp_name,
> + struct reservation_object *resv)
> {
> struct dma_buf *dmabuf;
> struct file *file;
> + size_t alloc_size = sizeof(struct dma_buf);
> + if (!resv)
> + alloc_size += sizeof(struct reservation_object);
> + else
> + /* prevent &dma_buf[1] == dma_buf->resv */
> + alloc_size += 1;
>
> if (WARN_ON(!priv || !ops
> || !ops->map_dma_buf
> @@ -150,7 +163,7 @@ struct dma_buf *dma_buf_export_named(void *priv, const
> struct dma_buf_ops *ops,
> return ERR_PTR(-EINVAL);
> }
>
> - dmabuf = kzalloc(sizeof(struct dma_buf), GFP_KERNEL);
> + dmabuf = kzalloc(alloc_size, GFP_KERNEL);
> if (dmabuf == NULL)
> return ERR_PTR(-ENOMEM);
>
> @@ -158,6 +171,11 @@ struct dma_buf *dma_buf_export_named(void *priv, const
> struct dma_buf_ops *ops,
> dmabuf->ops = ops;
> dmabuf->size = size;
> dmabuf->exp_name = exp_name;
> + if (!resv) {
> + resv = (struct reservation_object*)&dmabuf[1];
> + reservation_object_init(resv);
> + }
> + dmabuf->resv = resv;
>
> file = anon_inode_getfile("dmabuf", &dma_buf_fops, dmabuf, flags);
> if (IS_ERR(file)) {
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 56805c39c906..a13e90245adf 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -318,7 +318,13 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops
> = {
> struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
> struct drm_gem_object *obj, int flags)
> {
> - return dma_buf_export(obj, &drm_gem_prime_dmabuf_ops, obj->size,
> flags);
> + struct reservation_object *robj = NULL;
> +
> + if (dev->driver->gem_prime_res_obj)
> + robj = dev->driver->gem_prime_res_obj(obj);
well, you could hook up msm_gem_prime_res_obj too (since I already
have a resv obj in 'struct msm_gem_object' ;-)
That said, I wonder if maybe we just want to promote the 'struct
reservation_object' ptr into 'struct
[PATCH 6/6] dma-buf: add poll support, v2
On Mon, Feb 17, 2014 at 10:58 AM, Maarten Lankhorst
wrote:
> Thanks to Fengguang Wu for spotting a missing static cast.
>
> v2:
> - Kill unused variable need_shared.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/base/dma-buf.c | 101
> +++
> include/linux/dma-buf.h | 12 ++
> 2 files changed, 113 insertions(+)
>
> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
> index 85e792c2c909..77ea621ab59d 100644
> --- a/drivers/base/dma-buf.c
> +++ b/drivers/base/dma-buf.c
> @@ -30,6 +30,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> static inline int is_dma_buf_file(struct file *);
> @@ -52,6 +53,13 @@ static int dma_buf_release(struct inode *inode, struct
> file *file)
>
> BUG_ON(dmabuf->vmapping_counter);
>
> + /*
> +* Any fences that a dma-buf poll can wait on should be signaled
> +* before releasing dma-buf. This is the responsibility of each
> +* driver that uses the reservation objects.
minor nit.. but wouldn't hurt to mention in the comment that if you
hit this BUG_ON it is because someone isn't holding a ref to the
dmabuf while there is a pending fence
> +*/
> + BUG_ON(dmabuf->cb_shared.active || dmabuf->cb_excl.active);
> +
> dmabuf->ops->release(dmabuf);
>
> mutex_lock(&db_list.lock);
> @@ -108,10 +116,99 @@ static loff_t dma_buf_llseek(struct file *file, loff_t
> offset, int whence)
> return base + offset;
> }
>
> +static void dma_buf_poll_cb(struct fence *fence, struct fence_cb *cb)
> +{
> + struct dma_buf_poll_cb_t *dcb = (struct dma_buf_poll_cb_t*) cb;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&dcb->poll->lock, flags);
> + wake_up_locked_poll(dcb->poll, dcb->active);
> + dcb->active = 0;
> + spin_unlock_irqrestore(&dcb->poll->lock, flags);
> +}
> +
> +static unsigned int dma_buf_poll(struct file *file, poll_table *poll)
> +{
> + struct dma_buf *dmabuf;
> + struct reservation_object *resv;
> + unsigned long events;
> +
> + dmabuf = file->private_data;
> + if (!dmabuf || !dmabuf->resv)
> + return POLLERR;
> +
> + resv = dmabuf->resv;
> +
> + poll_wait(file, &dmabuf->poll, poll);
> +
> + events = poll_requested_events(poll) & (POLLIN | POLLOUT);
> + if (!events)
> + return 0;
> +
> + ww_mutex_lock(&resv->lock, NULL);
> +
> + if (resv->fence_excl && (!(events & POLLOUT) ||
> resv->fence_shared_count == 0)) {
> + struct dma_buf_poll_cb_t *dcb = &dmabuf->cb_excl;
> + unsigned long pevents = POLLIN;
> +
> + if (resv->fence_shared_count == 0)
> + pevents |= POLLOUT;
> +
> + spin_lock_irq(&dmabuf->poll.lock);
> + if (dcb->active) {
> + dcb->active |= pevents;
> + events &= ~pevents;
> + } else
> + dcb->active = pevents;
> + spin_unlock_irq(&dmabuf->poll.lock);
> +
> + if (events & pevents) {
> + if (!fence_add_callback(resv->fence_excl,
> + &dcb->cb, dma_buf_poll_cb))
> + events &= ~pevents;
> + else
> + // No callback queued, wake up any additional waiters.
couple spots w/ c++ comments, which I assume you didn't mean to leave?
Anyways, other than those minor things,
Reviewed-by: Rob Clark
> + dma_buf_poll_cb(NULL, &dcb->cb);
> + }
> + }
> +
> + if ((events & POLLOUT) && resv->fence_shared_count > 0) {
> + struct dma_buf_poll_cb_t *dcb = &dmabuf->cb_shared;
> + int i;
> +
> + /* Only queue a new callback if no event has fired yet */
> + spin_lock_irq(&dmabuf->poll.lock);
> + if (dcb->active)
> + events &= ~POLLOUT;
> + else
> + dcb->active = POLLOUT;
> + spin_unlock_irq(&dmabuf->poll.lock);
> +
> + if (!(events & POLLOUT))
> + goto out;
> +
> + for (i = 0; i < resv->fence_shared_count; ++i)
> + if (!fence_add_callback(resv->fence_shared[i],
> + &dcb->cb, dma_buf_poll_cb)) {
> + events &= ~POLLOUT;
> + break;
> + }
> +
> + // No callback queued, wake up any additional waiters.
> + if (i == resv->fence_shared_count)
> + dma_buf_poll_cb(NULL, &dcb->cb);
> + }
> +
> +out:
> + ww_mutex_unlock(&resv->lock);
> + return events;
> +}
> +
> static const struct file_operations dma_buf_fops = {
>
Public version control tree for linux/drivers/gpu/drm/radeon?
Hi. linux-3.14.0-rc3/MAINTAINERS contains two references to the apparently nonexistent git tree git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git .? Here is the entry for DRM: DRM DRIVERS M:? David Airlie L:? dri-devel at lists.freedesktop.org T:? git git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git S:? Maintained F:? drivers/gpu/drm/ F:? include/drm/ F:? include/uapi/drm/ These references to .../drm-2.6.git should be deleted or changed, right? I sent an email to arlied at linux.ie about a week ago, but it included an incorrect suggested replacement link for the git tree, so I quickly sent another email asking him to disregard that message.? I did not get a response, and I'm not sure whether to recommend that he delete the references to .../drm-2.6.git or to recommend some other link as a replacement. By the way, I noticed this because I believe I am experiencing at least one "mode setting" bug in linux/drivers/gpu/drm/radeon, and I would like to try the latest version of the driver to reduce the chance of expending people's time on something that may have already been fixed.? My attempts at searching the web have so far ony turned up http://cgit.freedesktop.org/~airlied/linux/ , which appears to have a number of active branches, but I'm not sure which branch, if any, I should test against, and the list of commits at the bottom of the page suggests that the most recent commit to the main branch of that repository was over a year ago.? So, i'm really not sure what git tree I should try. Thanks in advance for any responses. Adam Richter -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140217/f5ee5c99/attachment-0001.html>
GBM Buffer handling
Hi... We are developing a client/ server mode application. Whether it's possible to create gbm surface in client and render using drm in server? We had tried to do so, server is getting crash when accessing the gbm surface created by client. Regards, Binoy. * Confidentiality Statement/Disclaimer * This message and any attachments is intended for the sole use of the intended recipient. It may contain confidential information. Any unauthorized use, dissemination or modification is strictly prohibited. If you are not the intended recipient, please notify the sender immediately then delete it from all your systems, and do not copy, use or print. Internet communications are not secure and it is the responsibility of the recipient to make sure that it is virus/malicious code exempt. The company/sender cannot be responsible for any unauthorized alterations or modifications made to the contents. If you require any form of confirmation of the contents, please contact the company/sender. The company/sender is not liable for any errors or omissions in the content of this message.
[PATCH RFC 3/3] video: Kconfig: move drm and fb into separate menus
On Friday, February 14, 2014 8:19 PM, Tomi Valkeinen wrote: > > At the moment the "Device Drivers / Graphics support" kernel config page > looks rather messy, with DRM and fbdev driver selections on the same > page, some on the top level Graphics support page, some under their > respective subsystems. > > If I'm not mistaken, this is caused by the drivers depending on other > things than DRM or FB, which causes Kconfig to arrange the options in > not-so-neat manner. > > Both DRM and FB have a main menuconfig option for the whole DRM or FB > subsystem. Optimally, this would be enough to arrange all DRM and FB > options under the respective subsystem, but for whatever reason this > doesn't work reliably. > > This patch adds an explicit submenu for DRM and FB, making it much > clearer which options are related to FB, and which to DRM. > > Signed-off-by: Tomi Valkeinen Reviewed-by: Jingoo Han I tested this patch. Menu becomes clearer! Thanks. Best regards, Jingoo Han > --- > drivers/video/Kconfig | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig > index f0f26a0b746e..70d174090a54 100644 > --- a/drivers/video/Kconfig > +++ b/drivers/video/Kconfig > @@ -21,9 +21,13 @@ source "drivers/gpu/vga/Kconfig" > > source "drivers/gpu/host1x/Kconfig" > > +menu "Direct Rendering Manager" > source "drivers/gpu/drm/Kconfig" > +endmenu > > +menu "Framebuffer Devices" > source "drivers/video/fbdev/Kconfig" > +endmenu > > source "drivers/video/backlight/Kconfig" > > -- > 1.8.3.2
[PATCH RFC 2/3] fbdev: move fbdev core files to separate directory
On Friday, February 14, 2014 8:19 PM, Tomi Valkeinen wrote:
>
> Instead of having fbdev framework core files at the root fbdev
> directory, mixed with random fbdev device drivers, move the fbdev core
> files to a separate core directory. This makes it much clearer which of
> the files are actually part of the fbdev framework, and which are part
> of device drivers.
>
> Signed-off-by: Tomi Valkeinen
Hi Tomi,
This is what I wanted for a long time!
Thank you for your effort!
Last year, I noticed that the current FB directory and files
are not clear. It looks good!
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> drivers/video/fbdev/Makefile | 16 +---
> drivers/video/fbdev/core/Makefile| 16
> drivers/video/fbdev/{ => core}/cfbcopyarea.c | 0
> drivers/video/fbdev/{ => core}/cfbfillrect.c | 0
> drivers/video/fbdev/{ => core}/cfbimgblt.c | 0
> drivers/video/fbdev/{ => core}/fb_ddc.c | 2 +-
> drivers/video/fbdev/{ => core}/fb_defio.c| 0
> drivers/video/fbdev/{ => core}/fb_draw.h | 0
> drivers/video/fbdev/{ => core}/fb_notify.c | 0
> drivers/video/fbdev/{ => core}/fb_sys_fops.c | 0
> drivers/video/fbdev/{ => core}/fbcmap.c | 0
> drivers/video/fbdev/{ => core}/fbcvt.c | 0
> drivers/video/fbdev/{ => core}/fbmem.c | 0
> drivers/video/fbdev/{ => core}/fbmon.c | 2 +-
> drivers/video/fbdev/{ => core}/fbsysfs.c | 0
> drivers/video/fbdev/{ => core}/modedb.c | 0
> drivers/video/fbdev/{ => core}/svgalib.c | 0
> drivers/video/fbdev/{ => core}/syscopyarea.c | 0
> drivers/video/fbdev/{ => core}/sysfillrect.c | 0
> drivers/video/fbdev/{ => core}/sysimgblt.c | 0
> drivers/video/fbdev/wmt_ge_rops.c| 2 +-
> 21 files changed, 20 insertions(+), 18 deletions(-)
> create mode 100644 drivers/video/fbdev/core/Makefile
> rename drivers/video/fbdev/{ => core}/cfbcopyarea.c (100%)
> rename drivers/video/fbdev/{ => core}/cfbfillrect.c (100%)
> rename drivers/video/fbdev/{ => core}/cfbimgblt.c (100%)
> rename drivers/video/fbdev/{ => core}/fb_ddc.c (99%)
> rename drivers/video/fbdev/{ => core}/fb_defio.c (100%)
> rename drivers/video/fbdev/{ => core}/fb_draw.h (100%)
> rename drivers/video/fbdev/{ => core}/fb_notify.c (100%)
> rename drivers/video/fbdev/{ => core}/fb_sys_fops.c (100%)
> rename drivers/video/fbdev/{ => core}/fbcmap.c (100%)
> rename drivers/video/fbdev/{ => core}/fbcvt.c (100%)
> rename drivers/video/fbdev/{ => core}/fbmem.c (100%)
> rename drivers/video/fbdev/{ => core}/fbmon.c (99%)
> rename drivers/video/fbdev/{ => core}/fbsysfs.c (100%)
> rename drivers/video/fbdev/{ => core}/modedb.c (100%)
> rename drivers/video/fbdev/{ => core}/svgalib.c (100%)
> rename drivers/video/fbdev/{ => core}/syscopyarea.c (100%)
> rename drivers/video/fbdev/{ => core}/sysfillrect.c (100%)
> rename drivers/video/fbdev/{ => core}/sysimgblt.c (100%)
[PATCH] Enable libkms by default on DragonFly
Signed-off-by: Fran?ois Tigeot --- configure.ac | 1 + 1 file changed, 1 insertion(+) diff --git a/configure.ac b/configure.ac index d2d19d6..b7eef96 100644 --- a/configure.ac +++ b/configure.ac @@ -187,6 +187,7 @@ if test "x$LIBKMS" = xauto ; then linux*) LIBKMS="yes" ;; freebsd* | kfreebsd*-gnu) LIBKMS="yes" ;; + dragonfly*) LIBKMS="yes" ;; *) LIBKMS="no" ;; esac fi -- 1.8.5.2
[Bug 70701] New: With DPM enabled, Radeon 4570 (R710) doesn't remain in Single_Disp state
https://bugzilla.kernel.org/show_bug.cgi?id=70701 Bug ID: 70701 Summary: With DPM enabled, Radeon 4570 (R710) doesn't remain in Single_Disp state Product: Drivers Version: 2.5 Kernel Version: 3.13 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: abhinav.kumar.in at gmail.com Regression: No When using DPM with the open-source radeon driver, the Card first gets into Power-State-1 which is the desirable one. But after few seconds, it changes its state to a seemingly multi-display one. Tested on a Dell Studio 1555 with Radeon 4570 running Trusty alpha and openSUSE 13.1. 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] RV710/M92 [Mobility Radeon HD 4530/4570/545v] [1002:9553] (prog-if 00 [VGA controller]) Subsystem: Dell Mobility Radeon HD 4570 [1028:02be] Flags: bus master, fast devsel, latency 0, IRQ 46 Memory at d000 (32-bit, prefetchable) [size=256M] I/O ports at 2000 [size=256] Memory at fc00 (32-bit, non-prefetchable) [size=64K] [virtual] Expansion ROM at fc02 [disabled] [size=128K] Capabilities: Kernel driver in use: radeon Dmesg log. (It successfully gets into single_disp video mode.) [2.047282] [drm] ib test on ring 5 succeeded [2.073894] [drm] radeon atom DIG backlight initialized [2.073898] [drm] Radeon Display Connectors [2.073900] [drm] Connector 0: [2.073902] [drm] VGA-1 [2.073904] [drm] DDC: 0x7fa0 0x7fa0 0x7fa4 0x7fa4 0x7fa8 0x7fa8 0x7fac 0x7fac [2.073906] [drm] Encoders: [2.073907] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [2.073923] [drm] Connector 1: [2.073925] [drm] HDMI-A-1 [2.073926] [drm] HPD1 [2.073928] [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [2.073930] [drm] Encoders: [2.073931] [drm] DFP1: INTERNAL_UNIPHY [2.073932] [drm] Connector 2: [2.073934] [drm] LVDS-1 [2.073937] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [2.073940] [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [2.073955] [drm] Encoders: [2.073956] [drm] LCD1: INTERNAL_UNIPHY2 [2.073997] [drm] Internal thermal controller with fan control [2.074090] == power state 0 == [2.074092] ui class: none [2.074094] internal class: boot [2.074096] caps: video [2.074099] uvdvclk: 0 dclk: 0 [2.074115] power level 0sclk: 5 mclk: 8 vddc: 1200 [2.074117] power level 1sclk: 5 mclk: 8 vddc: 1200 [2.074119] power level 2sclk: 5 mclk: 8 vddc: 1200 [2.074120] status: c r b [2.074123] == power state 1 == [2.074124] ui class: performance [2.074126] internal class: none [2.074128] caps: single_disp video [2.074131] uvdvclk: 0 dclk: 0 [2.074133] power level 0sclk: 22000 mclk: 3 vddc: 900 [2.074149] power level 1sclk: 3 mclk: 5 vddc: 900 [2.074150] power level 2sclk: 68000 mclk: 8 vddc: 1200 [2.074152] status: [2.074153] == power state 2 == [2.074155] ui class: battery [2.074156] internal class: none [2.074158] caps: single_disp video [2.074161] uvdvclk: 0 dclk: 0 [2.074163] power level 0sclk: 22000 mclk: 3 vddc: 900 [2.074164] power level 1sclk: 3 mclk: 3 vddc: 900 [2.074180] power level 2sclk: 3 mclk: 3 vddc: 900 [2.074181] status: [2.074183] == power state 3 == [2.074184] ui class: none [2.074185] internal class: uvd [2.074188] caps: video [2.074190] uvdvclk: 54000 dclk: 4 [2.074192] power level 0sclk: 6 mclk: 8 vddc: 1100 [2.074193] power level 1sclk: 6 mclk: 8 vddc: 1100 [2.074195] power level 2sclk: 6 mclk: 8 vddc: 1100 [2.074196] status: [2.074212] == power state 4 == [2.074213] ui class: performance [2.074214] internal class: none [2.074216] caps: video [2.074219] uvdvclk: 0 dclk: 0 [2.074220] power level 0sclk: 3 mclk: 8 vddc: 1200 [2.074222] power level 1sclk: 3 mclk: 8 vddc: 1200 [2.074224] power level 2sclk: 68000 mclk: 8 vddc: 1200 [2.074225] status: [2.074226] == power state 5 == [2.074227] ui class: battery [2.074243] internal class: none [2.074245] caps: video [2.074247] uvdvclk: 0 dclk: 0 [2.074249] power level 0sclk: 3 mclk: 4 vddc: 1000 [2.074251] power level 1
[Bug 70910] [radeonsi&r600g] wrong colors on radeonsi screen in some places when radeonsi and r600g gpus are installed
https://bugs.freedesktop.org/show_bug.cgi?id=70910 --- Comment #6 from Michel D?nzer --- (In reply to comment #2) > Unfortunately I can't make both drivers work with glamor now, X fails to > start. The log file looks like it starts up fine; it looks like there's a VT switch before the end of the log. Why do you say it fails to start? Is there more information in the X server's stderr output? (In reply to comment #4) > If I remove xorg.conf (both cards still plugged in), I have one screen > working (radeonsi) with correct colors. Looks like the Evergreen card should be available via DRI_PRIME in this case. -- 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/20140217/e08d16b2/attachment.html>
[Bug 73067] RV770 - screen flicker with radeon.dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=73067 --- Comment #14 from Benjamin Bellec --- (In reply to comment #13) > Anyway, do you plan to add your patch to kernel 3.10 too? It's a long-term > release and will be used by RHEL7. Shame on me. DPM landed in kernel 3.11. -- 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/20140217/ff5ef6b8/attachment.html>
[Bug 69694] Xorg doesn't start on KABINi with radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=69694 Michel D?nzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #24 from Michel D?nzer --- (In reply to comment #22) > Now without xorg.conf and with xorg.conf.d with: > Section "Module" > Load "dri2" > Load "glamoregl" > EndSection > > Xorg start without any problem. FWIW, the xorg.conf.d snippet shouldn't be necessary anymore either with xserver 1.15 or newer. > And what about render nodes? Will I be able to use second GPU as a render > node? You should be, but that doesn't help you for X. Not sure why X is ignoring your second GPU, but I notice that you are using slightly outdated Git snapshots of xserver and xf86-video-ati. Can you try the latest releases or a current Git snapshot for those? > Or this hybrid AMD GPU is considered as one and not two GPU? No. > For what concern this bug, You can now close it. Doing so, BTW you can do this yourself. :) -- 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/20140217/8891445c/attachment.html>
[Bug 74973] [radeonsi] Gimp OpenCL does not work
https://bugs.freedesktop.org/show_bug.cgi?id=74973 --- Comment #1 from Michel D?nzer --- Please provide more information about the crash; at least the stderr output from gimp, preferably with R600_DEBUG=cs. -- 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/20140217/7657bc49/attachment.html>
[Bug 74868] r600g: Diablo III Crashes After a few minutes
https://bugs.freedesktop.org/show_bug.cgi?id=74868 --- Comment #10 from Michel D?nzer --- Make sure your /usr/lib/xorg/modules/dri/r600_dri.so has debugging symbols. -- 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/20140217/19168660/attachment-0001.html>
Bug#622993: every 10s I get "[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid ..."
(Sorry if I'm spawning a very old thread here). After all this time I have been patching my kernels to workaround [0][1] [0] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624549> [1] <https://bugs.freedesktop.org/show_bug.cgi?id=37040> Some time ago I found [2] and today I finally solved the problem. [2] <http://www.blaicher.com/2012/06/howto-fixing-a-broken-edid-eeprom-with-a-bus-pirate-v4/> Some stuff I learned: the kernel does ignores checksums mismatches by 8... in the positive side! My mismatch was exactly -1, ie, 255. I have been modifying the original patch to workaround this since 2011. I'm attaching my last patch in case someone else needs it. It does adds a kernel parameter to ignore edid mismatches. Kinds regards, Lisandro. -- Theory and practice sometimes clash. And when that happens, theory loses. Every single time. Linus Benedict Torvalds. Lisandro Dami?n Nicanor P?rez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -- next part -- A non-text attachment was scrubbed... Name: drm-kms-add-a-module-param-to-disable-strict-EDID-3.12.patch Type: text/x-patch Size: 2682 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140217/359e3da5/attachment.bin> -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140217/359e3da5/attachment.pgp>
