Hi all,
This patch series is my 2nd real stab at fixing up the locking issues around our
two buffer sharing mechanisms in gem: flink and prime.
I think the approach taken here is much better than my first stab, and it also
seems to no longer leak buffers ;-) There some assorted cleanup and prep w
Note that this is slightly tricky since both drivers store their
native objects in dma_buf->priv. But both also embed the base
drm_gem_object at the first position, so the implicit cast is ok.
To use the release helper we need to export it, too.
Cc: Inki Dae
Cc: Intel Graphics Development
Signe
This fixes a WARN in i915_gem_free_object when the
obj->pages_pin_count isn't 0.
Reported-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
inde
Makes it more obviously correct what tricks we play by reusing the drm
prime release helper.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
Lifetime rules seem to be solid around ->import_attach. So this patch
just properly documents them.
Note that pointing directly at the attachment might have issues for
devices that have multiple struct device *dev parts constituting the
logical gpu and so might need multiple attachment points. Sim
It's unused, everyone is using the _unlocked variant only.
Signed-off-by: Daniel Vetter
---
include/drm/drmP.h | 18 --
1 file changed, 18 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index baf030c..f949cb2 100644
--- a/include/drm/drmP.h
+++ b/include/drm/d
Only one callsite and since ->handle_count is not a simple reference
count (it can resurrect) it's imo better to be explicit about things
than hide the refcount dance.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c | 3 ++-
include/drm/drmP.h| 7 ---
2 files changed, 2 in
We have three callers of this function now and it's neither
performance critical nor really small. So an inline function feels
like overkill and unecessarily separates the different parts of the
code.
Since all callers of drm_gem_object_handle_free are now in drm_gem.c
we can make that static (and
Calling this function with a NULL object is simply a bug, so papering
over a NULL object not a good idea.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index e53d1c9..5d41af1
Trying to drop a reference we don't have is a pretty serious bug.
Trying to paper over it is an even worse offense.
So scream into dmesg with a big WARN in case that ever happens.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
This is the 2nd attempt, I've always been a bit dissatisified with the
tricky nature of the first one:
http://lists.freedesktop.org/archives/dri-devel/2012-July/025451.html
The issue is that the flink ioctl can race with calling gem_close on
the last gem handle. In that case we'll end up with a z
handle_unreference only clears up the obj->name and the reference,
but would leave a dangling handle in the idr. The right thing
to do is to call handle_delete.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_prime.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driver
No one outside of drm should use this, the official interfaces are
drm_gem_handle_create and drm_gem_handle_delete. The handle refcounting
is purely an implementation detail of gem.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c | 2 +-
include/drm/drmP.h| 1 -
2 files change
Part of the function uses the properly-typed dmabuf variable, the
other an untyped void *buf. Kill the later.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_prime.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gp
if (!ret) implies that ret == 0, so no need to clear it again. And
explicitly check for ret == 0 to indicate that we're checking an errno
integer.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_prime.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/d
When exporting a gem object as a dma-buf the critical section for the
per-fd prime lock is just the adding (and in case of errors, removing)
of the handle to the per-fd lookup cache.
So restrict the critical section to just that part of the function.
This simplifies later reordering.
Signed-off-
I want to wrap the creation of a dma-buf from a gem object in it,
so that the obj->export_dma_buf cache can be atomically filled in.
Instead of creating a new mutex just for that variable I've figured
I can reuse the existing dev->object_name_lock, especially since
the new semantics will exactly m
The gem flink name holds a reference onto the object itself, and this
self-reference would prevent an flink'ed object from every being
freed. To break that loop we remove the flink name when the last
userspace handle disappears, i.e. when obj->handle_count reaches 0.
Now in gem_open we drop the de
The export dma-buf cache is semantically similar to an flink name. So
semantically it makes sense to treat it the same and remove the name
(i.e. the dma_buf pointer) and its references when the last gem handle
disappears.
Again we need to be careful, but double so: Not just could someone
race and
with the reworking semantics and locking of the obj->dma_buf pointer
this pointer is always set as long as there's still a gem handle
around and a dma_buf associated with this gem object.
Also, the per file-priv lookup-cache for dma-buf importing is also
unified between foreign and native objects.
All the gem based kms drivers really want the same function to
destroy a dumb framebuffer backing storage object.
So give it to them and roll it out in all drivers.
This still leaves the option open for kms drivers which don't use GEM
for backing storage, but it does decently simplify matters for
On Tue, Jul 16, 2013 at 10:31 AM, Daniel Vetter wrote:
> On Sun, Jul 14, 2013 at 09:56:45PM +0400, Konstantin Khlebnikov wrote:
> > Daniel Vetter wrote:
> > >On Sun, Jul 14, 2013 at 6:30 PM, Konstantin Khlebnikov
> > > wrote:
> > >>This patch fixes regression in power consumtion of sandy bridge
On Tue, Jul 16, 2013 at 11:34:25AM +0400, Konstantin Khlebnikov wrote:
> On Tue, Jul 16, 2013 at 10:31 AM, Daniel Vetter wrote:
>
> > On Sun, Jul 14, 2013 at 09:56:45PM +0400, Konstantin Khlebnikov wrote:
> > > Daniel Vetter wrote:
> > > >On Sun, Jul 14, 2013 at 6:30 PM, Konstantin Khlebnikov
> >
https://bugzilla.kernel.org/show_bug.cgi?id=60560
Bug ID: 60560
Summary: Kernel BUG/Oops during radeon gpu stall
Product: Drivers
Version: 2.5
Kernel Version: 3.10
Hardware: x86-64
OS: Linux
Tree: Mainline
On Tue, Jul 16, 2013 at 09:44:59AM +0200, Daniel Vetter wrote:
> The issue I have with the current patch is that it looks a bit like
> duct-tape since the point where we drop the forcewake references seems to
> lack justification. The write to MBCTL itself will temporarily wake up the
> chip, so ju
https://bugs.freedesktop.org/show_bug.cgi?id=60929
--- Comment #6 from Michel Dänzer ---
(In reply to comment #5)
> Any news on this one? Its really bad on radeonsi, since theres no workaround.
Doesn't --enable-shared-llvm work for you?
Any pointers to freely downloadable games for testing?
--
https://bugs.freedesktop.org/show_bug.cgi?id=66955
Priority: medium
Bug ID: 66955
Assignee: dri-devel@lists.freedesktop.org
Summary: Running the game "FTL" causes the Xserver to crash
inside the r600 dri code
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=60929
--- Comment #7 from Laurent carlier ---
(In reply to comment #6)
> (In reply to comment #5)
> > Any news on this one? Its really bad on radeonsi, since theres no
> > workaround.
>
> Doesn't --enable-shared-llvm work for you?
>
> Any pointers t
https://bugzilla.kernel.org/show_bug.cgi?id=60381
--- Comment #11 from Michel Dänzer ---
FWIW, I'm basically seeing the same problems with my 7770 card.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel ma
https://bugs.freedesktop.org/show_bug.cgi?id=66955
--- Comment #1 from Phil Armstrong ---
Turns out the real problem is that FTL bundles a version of libstdc++ that the
DRI drivers won't link against.
It looks like the net result is that *no* DRI drivers (not even swrast) can be
loaded, and the
https://bugs.freedesktop.org/show_bug.cgi?id=66955
--- Comment #2 from Phil Armstrong ---
Created attachment 82474
--> https://bugs.freedesktop.org/attachment.cgi?id=82474&action=edit
gdb backtrace of all threads
Backtrace
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=66888
--- Comment #1 from Michel Dänzer ---
Current st/mesa only advertises this extension if the driver actually supports
multisampling.
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=66955
--- Comment #3 from Phil Armstrong ---
Created attachment 82475
--> https://bugs.freedesktop.org/attachment.cgi?id=82475&action=edit
Backtrace with dri symbols
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=66955
Phil Armstrong changed:
What|Removed |Added
Summary|Running the game "FTL" |Substituting an older
https://bugs.freedesktop.org/show_bug.cgi?id=66955
--- Comment #4 from Phil Armstrong ---
Changed title to reflect underlying bug: I don't believe that the user should
be able to make the XServer process segfault by substituting the wrong
libstdc++ library when running an ordinary user process.
On Tue, Jul 16, 2013 at 10:31 AM, Chris Wilson wrote:
> On Tue, Jul 16, 2013 at 09:44:59AM +0200, Daniel Vetter wrote:
>> The issue I have with the current patch is that it looks a bit like
>> duct-tape since the point where we drop the forcewake references seems to
>> lack justification. The writ
On Tuesday, July 16, 2013 11:24:05 AM Aaron Lu wrote:
> On 07/15/2013 07:42 PM, Rafael J. Wysocki wrote:
> > On Monday, July 15, 2013 10:36:15 AM Aaron Lu wrote:
> >> On 07/13/2013 08:46 AM, Rafael J. Wysocki wrote:
> >>> From: Rafael J. Wysocki
> >>>
> >>> According to Matthew Garrett, "Windows 8
On Tue, Jul 16, 2013 at 08:32:40AM +0200, Daniel Vetter wrote:
> On Sun, Jul 14, 2013 at 08:30:09PM +0400, Konstantin Khlebnikov wrote:
> > This patch fixes regression in power consumtion of sandy bridge gpu, which
> > exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking
> > t
On Wed, Jul 10, 2013 at 02:12:10PM +0200, Daniel Vetter wrote:
> We not only have debugfs files to do pretty much the equivalent of
> lsof, we also have an ioctl. Not that compared to lsof this dumps a
> wee bit more information, but we can still get at that from debugfs
> easily.
>
> I've dug aro
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #30 from Christoph Bumiller ---
How does it depend on the depth test, and why does it seem "off" to make
something that is originally a shader property in D3D a shader property in
OpenGL as well ?
Not using shaders isn't allowed (at l
Hi Dave,
[resend, somehow this was lost somewhere. At least I couldn't find it in
the list archives.]
One feature latecomer, I've forgotten to merge the patch to reeanble the
Haswell power well feature now that the audio interaction is fixed up.
Since that was the only unfixed issue with it I've
https://bugs.freedesktop.org/show_bug.cgi?id=66955
Alex Deucher changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
https://bugzilla.kernel.org/show_bug.cgi?id=60560
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #1 from
https://bugzilla.kernel.org/show_bug.cgi?id=60560
Knut Tidemann changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=66961
Priority: medium
Bug ID: 66961
Assignee: dri-devel@lists.freedesktop.org
Summary: Kernel BUG/Oops during radeon gpu stall
Severity: normal
Classification: Unclassified
OS: Li
We not only have debugfs files to do pretty much the equivalent of
lsof, we also have an ioctl. Not that compared to lsof this dumps a
wee bit more information, but we can still get at that from debugfs
easily.
I've dug around in mesa, libdrm and ddx histories and the only users
seem to be drm/tes
https://bugs.freedesktop.org/show_bug.cgi?id=66961
Alex Deucher changed:
What|Removed |Added
Summary|Kernel BUG/Oops during |radeon gpu stall with
|
https://bugs.freedesktop.org/show_bug.cgi?id=66961
--- Comment #2 from Alex Deucher ---
Also, if this is a 32-bit game running on a 64-bit distro, make sure you have a
recent version of the 32-bit 3D driver.
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=66961
--- Comment #3 from Knut Andre Tidemann ---
Yes it is, both the 32 bit and the 64 bit are compiled from the same commit.
--
You are receiving this mail because:
You are the assignee for the bug.
___
d
https://bugs.freedesktop.org/show_bug.cgi?id=66932
--- Comment #4 from Alex Deucher ---
(In reply to comment #3)
>
> Well I think I'm already building radeon as a module since I have:
> CONFIG_DRM=m
> CONFIG_DRM_RADEON=m
>
> or am I missing something?
That should be fine. I assumed you were b
On Tue, Jul 16, 2013 at 03:14:15PM +0200, Daniel Vetter wrote:
> We not only have debugfs files to do pretty much the equivalent of
> lsof, we also have an ioctl. Not that compared to lsof this dumps a
> wee bit more information, but we can still get at that from debugfs
> easily.
Hmm, why are ret
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #31 from Henri Verbeet ---
You're mixing things up a bit, the functionality this bug is about is mostly
controlled by D3DRS_ZENABLE in d3d9. Considering only pre-transformed
(D3DFVF_XYZRHW) vertices, the behaviour is like this:
- Wh
https://bugs.freedesktop.org/show_bug.cgi?id=66964
Priority: medium
Bug ID: 66964
Assignee: dri-devel@lists.freedesktop.org
Summary: GPU fault detected
Severity: normal
Classification: Unclassified
OS: All
Reporter:
https://bugs.freedesktop.org/show_bug.cgi?id=66963
Priority: medium
Bug ID: 66963
Assignee: dri-devel@lists.freedesktop.org
Summary: r600: linux 3.11RC1 isn't booting with radeon.dpm=1
option in grub
Severity: blocker
Cla
https://bugzilla.kernel.org/show_bug.cgi?id=60381
--- Comment #12 from rafael castillo ---
well i tried drm-fixes-3.11 branch late night very fast but i got to KDE using
dpm=1 and UVD seemed to work but when i opened xonotic the GPU hard reset and
killed the monitors but is getting closer ;)
tod
https://bugs.freedesktop.org/show_bug.cgi?id=66964
--- Comment #1 from Alex Deucher ---
Are things improved any with Dave's drm-fixes tree:
http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-fixes
It contains some alignment fixes for VM that may help and it should provide
better debugging outp
https://bugs.freedesktop.org/show_bug.cgi?id=66964
Alex Deucher changed:
What|Removed |Added
Summary|GPU fault detected |GPU VM faults on ARUBA
--
You are receiv
https://bugs.freedesktop.org/show_bug.cgi?id=66967
Priority: medium
Bug ID: 66967
Assignee: dri-devel@lists.freedesktop.org
Summary: Dota 2 crashes with r600g when starting the tutorial
Severity: normal
Classification: Unclassified
https://bugzilla.kernel.org/show_bug.cgi?id=60381
--- Comment #13 from Arek Ruśniak ---
i can confirm this for 3d apps(lightsmark or unvanquished), but uvd still
doesn't work for me.
--
You are receiving this mail because:
You are watching the assignee of the bug.
__
On Tue, 16 Jul 2013 11:34:25 +0400
Konstantin Khlebnikov wrote:
> I've tested that patch and it really works for me. If you want change
> something for other hardware or
> extend range where forcewake is held prease do it in a separate patch.
> This will be good for bisecting new bugs in the futur
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #32 from Marek Olšák ---
There would be no advantage for r300g.
The problem with r300g is that it cannot do depth clamping without disabling
the clipping entirely. There is only one big switch called CLIP_DISABLE, which
"Disables cli
https://bugs.freedesktop.org/show_bug.cgi?id=66932
--- Comment #5 from Martin Andersson ---
(In reply to comment #4)
> (In reply to comment #3)
> >
> > Well I think I'm already building radeon as a module since I have:
> > CONFIG_DRM=m
> > CONFIG_DRM_RADEON=m
> >
> > or am I missing something?
https://bugs.freedesktop.org/show_bug.cgi?id=66972
Priority: medium
Bug ID: 66972
Assignee: dri-devel@lists.freedesktop.org
Summary: GPU lockup CP stall with radeon.dpm=1 on BARTS/6850
Severity: normal
Classification: Unclassified
https://bugs.freedesktop.org/show_bug.cgi?id=66974
Priority: medium
Bug ID: 66974
Assignee: dri-devel@lists.freedesktop.org
Summary: [radeonsi] rendering is broken in L4D2
Severity: normal
Classification: Unclassified
OS: Lin
https://bugs.freedesktop.org/show_bug.cgi?id=66974
Laurent carlier changed:
What|Removed |Added
Attachment #82494|text/plain |image/png
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=66974
--- Comment #1 from Laurent carlier ---
Created attachment 82495
--> https://bugs.freedesktop.org/attachment.cgi?id=82495&action=edit
Broken in-game rendering
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=66972
--- Comment #1 from Mike Lothian ---
Created attachment 82496
--> https://bugs.freedesktop.org/attachment.cgi?id=82496&action=edit
Dmesg
>From drm-fixes-3.11
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=66972
--- Comment #2 from Mike Lothian ---
I'm seeing similar things on my 6600 - it works very slowly (20fps on Lost
Coast) on linus tree and doesn't launch properly on drm-fixes-3.11
It was working fine on the wip5 branch
--
You are receiving this
This is the first set of patches to bring some sanity into gma500. The driver is
a mashup of different out-of-tree drivers and it's been easier to keep them
separated to find out what quirks are needed for each chip. As things have
matured it is now time to start removing duplicated code. The numbe
This patch aims to unify the bits and pieces that are common (or similar
enough) for pll clock calculations. Nothing makes use of this code yet
That will come in later patches.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/Makefile| 1 +
drivers/gpu/drm/gma500/gma_disp
Add chip specific callbacks for the generic and non-generic clock
calculation code. Also remove as much dupilicated code as possible.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/cdv_device.c| 1 +
drivers/gpu/drm/gma500/cdv_device.h| 1 +
drivers/gpu/drm/gma500
Replace any use of xxx_intel_pipe_has_type() with the generic
gma_pipe_has_type() function. Poulsbo still use it but that will be
removed when we rip out psb_intel_pipe_has_type().
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 8
drivers/gpu/drm/gma5
Add chip specific callbacks for the generic and non-generic clock
calculation code. Also remove as much dupilicated code as possible.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_device.c| 3 +-
drivers/gpu/drm/gma500/psb_device.h| 24
drivers/gpu/drm/gm
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_intel_display.h | 23 ---
1 file changed, 23 deletions(-)
delete mode 100644 drivers/gpu/drm/gma500/psb_intel_display.h
diff --git a/drivers/gpu/drm/gma500/psb_intel_display.h
b/drivers/gpu/drm/gma500/psb_intel_
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/gma_display.c | 326 +++
drivers/gpu/drm/gma500/gma_display.h | 14 ++
2 files changed, 340 insertions(+)
diff --git a/drivers/gpu/drm/gma500/gma_display.c
b/drivers/gpu/drm/gma500/gma_display.c
index 8f
This patch makes cdv use the gma_xxx counterparts that are identical. I
took them in one sweep as they should not cause any regressions.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/cdv_device.h| 9
drivers/gpu/drm/gma500/cdv_intel_display.c | 74 +++--
Also remove the duplicated oaktrail function.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/cdv_intel_dp.c| 3 ++-
drivers/gpu/drm/gma500/mdfld_intel_display.c | 6 +++---
drivers/gpu/drm/gma500/oaktrail_crtc.c | 6 +++---
drivers/gpu/drm/gma500/oaktrail_hdmi.c
This patch makes psb use the gma_xxx counterparts that are identical. I
took them in one sweep as they should not cause any regressions.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_intel_display.c | 41 +++---
1 file changed, 4 insertions(+), 37 deletio
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 77 +-
1 file changed, 1 insertion(+), 76 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index ae57b93..9eee57b 100644
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 137 +
drivers/gpu/drm/gma500/gma_display.c | 4 -
drivers/gpu/drm/gma500/gma_display.h | 5 ++
3 files changed, 8 insertions(+), 138 deletions(-)
diff --git a/drivers/gpu
This macro is needed for Cedarview specific stuff in the generic gma
functions.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_drv.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index eeed88c..ed1e567 1006
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_intel_display.c | 73 +-
1 file changed, 1 insertion(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c
b/drivers/gpu/drm/gma500/psb_intel_display.c
index 0642e7d..ca041c6 100644
There is a slight difference in how we pick the palette register in the
generic function but we should be ok as long as psb_intel_crtc->pipe and
the register map is sane.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 70 +-
1 file ch
This takes care of the remaining chips using the old generic code.
We don't check if the pipe number is valid but the old code peeked in
the register map before checking anyways so just ignore it.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/mdfld_intel_display.c | 2 +-
drivers/g
Use the generic gma functions instead of the medfield functions where
they are identical.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/mdfld_intel_display.c | 25 +++--
1 file changed, 3 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/gma500/mdfld_i
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_intel_display.c | 104 +
1 file changed, 1 insertion(+), 103 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c
b/drivers/gpu/drm/gma500/psb_intel_display.c
index 940c6f2..b52bde2 100644
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_intel_display.c | 23 +--
1 file changed, 1 insertion(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c
b/drivers/gpu/drm/gma500/psb_intel_display.c
index b52bde2..f4d308f 100644
--- a/d
Use the generic gma functions instead of the oaktrail functions where
they are identical.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/oaktrail_crtc.c | 25 +++--
1 file changed, 3 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/gma500/oaktrail_crtc
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/gma_display.c | 151 +++
drivers/gpu/drm/gma500/gma_display.h | 5 ++
2 files changed, 156 insertions(+)
diff --git a/drivers/gpu/drm/gma500/gma_display.c
b/drivers/gpu/drm/gma500/gma_display.c
index 7a
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 130 +
1 file changed, 2 insertions(+), 128 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index e30761a..2351f42 10064
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_intel_display.c | 157 +
1 file changed, 2 insertions(+), 155 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c
b/drivers/gpu/drm/gma500/psb_intel_display.c
index f4d308f..1e6a357 10064
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/gma_display.c | 41 ++
drivers/gpu/drm/gma500/gma_display.h | 4
drivers/gpu/drm/gma500/psb_intel_drv.h | 10 +
3 files changed, 55 insertions(+)
diff --git a/drivers/gpu/drm/gma500/gma_d
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/cdv_intel_crt.c | 13
drivers/gpu/drm/gma500/cdv_intel_display.c | 4 +--
drivers/gpu/drm/gma500/cdv_intel_dp.c| 17 +-
drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 19 ++-
drivers/gpu/drm/gma50
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/gma_display.c | 105 +++
drivers/gpu/drm/gma500/gma_display.h | 3 +
2 files changed, 108 insertions(+)
diff --git a/drivers/gpu/drm/gma500/gma_display.c
b/drivers/gpu/drm/gma500/gma_display.c
index 67d
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_intel_display.c | 109 +
1 file changed, 2 insertions(+), 107 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c
b/drivers/gpu/drm/gma500/psb_intel_display.c
index a419e79..317c585 10064
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 172 +
1 file changed, 2 insertions(+), 170 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 257e0e8..b84912f 10064
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_intel_display.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c
b/drivers/gpu/drm/gma500/psb_intel_display.c
index 317c585..05faf1c 100644
--- a/driver
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/gma_display.c | 16
drivers/gpu/drm/gma500/gma_display.h | 3 +++
2 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/gma500/gma_display.c
b/drivers/gpu/drm/gma500/gma_display.c
index cca40c0..2a3e925 100644
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 21 +
1 file changed, 1 insertion(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index b84912f..6bca1fe 100644
--- a/dri
https://bugs.freedesktop.org/show_bug.cgi?id=58033
--- Comment #18 from Chris Rankin ---
This bug is still happening on my 32 bit T60p after #66921 has been fixed.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel
1 - 100 of 283 matches
Mail list logo
