Hi Inki,
On Thu, Aug 08, 2013 at 01:56:28PM +0900, Inki Dae wrote:
> Hi, Daniel. You can repost your patch set including the below my patch. And
> my patch numbering is wrong. Sorry about that.
Thanks for the patch, I'll submit it toghether with the other ones soon.
-Daniel
>
> [PATCH 1/4] -> [
https://bugzilla.kernel.org/show_bug.cgi?id=60606
--- Comment #3 from Jani Nikula ---
Sebastien, to confirm, you need "drm/i915: do not disable backlight on
vgaswitcheroo switch off" to be able to switch from IGD to DIS? So having that
is an improvement? And without that, the workarounds won't he
Hi Dave,
Inki supplied a patch to convert exynos, so I think these prep patches are ready
to go in. I want a common drm_gem_dmabuf_release function across all drivers
since th oops fix around the teardown of the obj->export_dma_buf pointer needs
to have changed code in there, and duplicating trick
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.
v2: Add locking to unmap, noticed by Chris Wilson. Note that even
though we call unmap with our own dev->struct_mutex held that won't
result in an immediate deadlock since we never go through the dma_buf
interfaces fo
Makes it more obviously correct what tricks we play by reusing the drm
prime release helper.
Reviewed-by: Chris Wilson
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/d
From: Inki Dae
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos
I've checked both implementations (radeon/nouveau) and they both grab
the page array from ttm simply by dereferencing it and then wrapping
it up with drm_prime_pages_to_sg in the callback and map it with
dma_map_sg (in the helper).
Only the grabbing of the underlying page array is anything we need
https://bugs.freedesktop.org/show_bug.cgi?id=67888
Priority: medium
Bug ID: 67888
Assignee: dri-devel@lists.freedesktop.org
Summary: R600g: GPU hang occurs when trying to do GPU profile
of Trine 2 apitrace trace
Severity: maj
https://bugs.freedesktop.org/show_bug.cgi?id=67800
--- Comment #5 from Kertesz Laszlo ---
(In reply to comment #4)
> This may be a duplicate of bug 65958. Does setting the env var RADEON_VA=0
> in your /etc/environment fix the issue?
(In reply to comment #4)
> This may be a duplicate of bug 659
Hi Dave,
A few bugfixes for serious stuff and regressions. Highlight is the
reinstated hack to keep the i915 backlight on when running on an optimus
machine, this prevents black screens especially with some radeon muxed
platforms. And the patch to quiet dmesg on Linus' old mac mini ;-)
Cheers, Da
On Wed, Aug 07, 2013 at 10:34:48PM -0400, Ilia Mirkin wrote:
> This makes it so that reloading a module does not cause all the
> connector ids to change, which are user-visible and sometimes used
> for configuration.
>
> Signed-off-by: Ilia Mirkin
> ---
>
> v2 -> v3:
> - rename ida struct name
https://bugzilla.kernel.org/show_bug.cgi?id=60606
--- Comment #4 from Sebastien Fievet ---
(In reply to Jani Nikula from comment #3)
I reverted the patch and double checked. The workaround is enough for me.
What I do is :
1. echo OFF > /sys/kernel/debug/vgaswitcheroo/switch at init time with a rc
https://bugzilla.kernel.org/show_bug.cgi?id=60532
Jani Nikula changed:
What|Removed |Added
Component|Video(DRI - Intel) |Video(DRI - non Intel)
Assignee|i
https://bugzilla.kernel.org/show_bug.cgi?id=60720
Bug ID: 60720
Summary: System freeze randomly with latest kernel 3.10 (also
3.11-rc4)
Product: Drivers
Version: 2.5
Kernel Version: 3.10 to 3.11-rc4
Hardware: All
> -Original Message-
> From: Rafał Miłecki [mailto:zaj...@gmail.com]
> Sent: Thursday, August 08, 2013 12:37 AM
> To: Alex Deucher
> Cc: dri-devel@lists.freedesktop.org; airl...@gmail.com; Deucher, Alexander
> Subject: Re: [pull] radeon drm-fixes-3.11
>
> 2013/8/8 Alex Deucher :
> > Some m
https://bugs.freedesktop.org/show_bug.cgi?id=67876
--- Comment #3 from Alex Deucher ---
I'm not sure why you aren't getting the smc error message, you should be. To
fix teh UVD error messages, you also need an updated rlc ucode.
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #84 from Alex Deucher ---
Does disabling clockgating avoid the hangs?
diff --git a/drivers/gpu/drm/radeon/rv6xx_dpm.c
b/drivers/gpu/drm/radeon/rv6xx_dpm.c
index bdd888b..85f2ab8 100644
--- a/drivers/gpu/drm/radeon/rv6xx_dpm.c
+++ b/d
https://bugzilla.kernel.org/show_bug.cgi?id=60720
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #1 from
https://bugs.freedesktop.org/show_bug.cgi?id=66738
Alex Deucher changed:
What|Removed |Added
Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=67901
Priority: medium
Bug ID: 67901
Assignee: dri-devel@lists.freedesktop.org
Summary: Black screen or freeze on radeon driver on AMD 6470M /
Intel HD 3000
Severity: normal
Cl
https://bugs.freedesktop.org/show_bug.cgi?id=67888
--- Comment #1 from Alex Deucher ---
Do you get the same hang with dpm disabled?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.fr
Hi all,
So a bunch of patches went in already, and a few of the ones here small fixups
(DocBook, compile fail for funny .configs and 1 unused variable). And slight
rebasing on top of David's drm_dev cleanup refactoring. The big change is that
the get_client ioclt isn't a complete noop now but fake
KMS drivers really shouldn't need to do anything on firstopen, so kill
empty callbacks.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/omapdrm/omap_drv.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 2f9
Again, it does nothing.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon_drv.c | 2 --
drivers/gpu/drm/radeon/radeon_kms.c | 13 -
2 files changed, 15 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index fa7a7e1..3
This thing seems to do some kind of delayed setup. Really, real kms
drivers shouldn't do that at all. Either stuff needs to be dynamically
hotplugged or the driver setup sequence needs to be fixed.
This patch here just moves the setup at the very end of the driver
load callback, with the locking a
So if we survey kms drivers there's a bunch of things they commonly do
in ->lastclose
- delayed processing of vga switcheroo requests (i915, nouveau,
radeon)
- force-restoring the fbcon (most)
- resetting a bunch properties to make fbcon work better (omap)
- disabling all outputs (vmwgfx)
In sho
It has way too much potential for driver writers to do stupid things
like delayed hw setup because the load sequence is somehow racy (e.g.
the imx driver in staging). So don't call it for modesetting drivers,
which reduces the complexity of the drm core -> driver interface a
notch.
v2: Don't forge
Totally unused, so just rip it out. Anyway, we want drivers to be
fully backwards compatible, allowing them to change behaviour is just
a recipe for them to break badly.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_ioctl.c | 3 ---
include/drm/drmP.h | 2 --
2 files changed, 5 d
I've decided that some clear markers for what's legacy dri1/non-gem
code is useful. I've opted to use the drm_legacy prefix and then hide
all the checks in that function for better readability in the common
code.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 6 +-
drivers
Only the radeon/r128/ati ums drivers use this. Furthermore the cleanup
was already only done for UMS drivers. Also a quick check of the ATI
ddx git history shows that only the UMS code ever used this facility.
So we can safely disallow these pair of ioctls for modesetting
drivers.
Signed-off-by:
Now only legacy ums drivers have the DRIVER_HAVE_DMA driver feature
flag set, so strictly speaking the modesetting check is redundant. But
adding it has the upside that it makes it very clear that the dma
support is legacy stuff.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_bufs.c | 15 +
And hide the checks a bit better. This was already disallowed for
modesetting drivers, so no functinal change here.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_dma.c | 17 +++--
drivers/gpu/drm/drm_drv.c | 4 +---
drivers/gpu/drm/drm_fops.c | 12 +++-
include/drm/
It's kzalloced ...
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index cebd847..9c27d42 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/driv
So after a lot of digging around in git histories it looks like this
has only ever be used by dri1 render clients. Hence we can fully
disable the entire thing for modesetting drivers and so greatly reduce
the attack surface for potential exploits (or at least tools like
trinity ...).
Also add the
So I've stumbled over drm_fasync and wondered what it does. Digging
that up is quite a story.
First I've had to read up on what this does and ended up being rather
bewildered why peopled loved signals so much back in the days that
they've created SIGIO just for that ...
Then I wondered how this e
No driver ever sets that flag, so good riddance!
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_bufs.c | 161 +
include/drm/drmP.h | 1 -
2 files changed, 2 insertions(+), 160 deletions(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/driv
Signed-off-by: Daniel Vetter
---
include/drm/drmP.h | 9 -
1 file changed, 9 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index f526a7a9..914055e 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -165,13 +165,7 @@ int drm_err(const char *func, const char *f
The gma500 driver somehow set the DRIVER_IRQ_VBL flag, but since
there's no code at all to check for this we can kill it. The other two
are completely unused.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/gma500/psb_drv.c | 2 +-
include/drm/drmP.h | 3 ---
2 files changed, 1 in
The new arch_phys_wc_add/del functions do the right thing both with
and without MTRR support in the kernel. So we can drop these
additional checks.
David Herrmann suggest to also kill the DRIVER_USE_MTRR flag since
it's now unused, which spurred me to do a bit a better audit of the
affected driver
I've forgotten this and shuffling all the little pieces into the
respective patches is rather cumbersome ...
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl | 29 -
1 file changed, 29 deletions(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Document
We might as well have a real ioctl function which checks for the
callbacks. This seems to be a remnant from back in the days when each
drm driver had their own complete ioctl table, with no shared core
drm table at all.
To make really sure no mis-guided user in a kms driver pops up again
explicitl
They're only used by the agpgart support code in drm_agpgart.c,
not by any drivers.
I think long-term we should create a drm_internal.h include file with
all the various functions only used by the drm core and not exported
to drivers, and remove them from drmP.h. Oh, and someone should kill
that u
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
Again only used by a tests in libdrm and by dristat. Nowadays we have
much better tracing tools to get detailed insights into what a drm
driver is doing. And for a simple "does it work" kind of question that
these stats could answer we have plenty of dmesg debug log spew.
So I don't see any use fo
The idr is protected with our spinlock, if we don't hold that nothing
prevents the gem objects from disappearing from under us.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_info.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_inf
So almost two years ago I've tried to nuke the procfs code already
once before:
http://lists.freedesktop.org/archives/dri-devel/2011-October/015707.html
The conclusion was that userspace drivers (specifically libdrm device
node detection) stopped relying on procfs in 2001. But after some
digging
We kzalloc this structure, and for real kms devices we should never
loose track of things really.
But ums/legacy drivers rely on the drm core to clean up a bit of cruft
between lastclose and firstopen (i.e. when X is being restarted), so
keep this around. But give it a clear drm_legacy_ prefix and
On Thu, Aug 8, 2013 at 9:41 AM, Daniel Vetter wrote:
> KMS drivers really shouldn't need to do anything on firstopen, so kill
> empty callbacks.
>
> Signed-off-by: Daniel Vetter
Acked-by: Rob Clark
> ---
> drivers/gpu/drm/omapdrm/omap_drv.c | 7 ---
> 1 file changed, 7 deletions(-)
>
> di
On Thu, Aug 8, 2013 at 9:41 AM, Daniel Vetter wrote:
> Totally unused, so just rip it out. Anyway, we want drivers to be
> fully backwards compatible, allowing them to change behaviour is just
> a recipe for them to break badly.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Rob Clark
> ---
>
On 08/06/2013 08:03 PM, Daniel Vetter wrote:
> On Tue, Aug 6, 2013 at 7:42 PM, Toralf Förster wrote:
>> On 07/26/2013 07:58 PM, Daniel Vetter wrote:
>>> On Wed, Jul 24, 2013 at 05:51:41PM +0200, Toralf Förster wrote:
Realized this today while booting a ThinkPad T420 with integrated intel
>>>
Hi
On Wed, Aug 7, 2013 at 7:41 PM, Rob Clark wrote:
> Variant of drm_gem_create_mmap_offset() which doesn't make the
> assumption that virtual size and physical size (obj->size) are the same.
> This is needed in omapdrm to deal with tiled buffers. And lets us get
> rid of a duplicated and slight
Daniel Vetter writes:
> Again only used by a tests in libdrm and by dristat. Nowadays we have
> much better tracing tools to get detailed insights into what a drm
> driver is doing. And for a simple "does it work" kind of question that
> these stats could answer we have plenty of dmesg debug log
On Thu, Aug 8, 2013 at 11:34 AM, miaou sami wrote:
> Hi,
>
> thanks for the explanation.
> Do you know if this is a hardware limitation, or if an updated version of
> the driver will come some day?
It's not a hardware limitation. The driver relies on what the OEM put
in the power tables as that
Currently, both ranges overlap. Fix the limits so both ranges are mutually
exclusive. Also use the occasion to convert whitespaces to tabs.
Signed-off-by: Kristian Høgsberg
(fixed up tabs and adjust commit-msg accordingly)
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_stub.c | 12 ++
Hi
On Thu, Aug 8, 2013 at 7:10 PM, David Herrmann wrote:
> Currently, both ranges overlap. Fix the limits so both ranges are mutually
> exclusive. Also use the occasion to convert whitespaces to tabs.
>
> Signed-off-by: Kristian Høgsberg
> (fixed up tabs and adjust commit-msg accordingly)
> Sign
In next-20130808, building tegra_defconfig for ARM yields:
> drivers/built-in.o: In function `drm_lastclose':
> /home/swarren/shared/git_wa/kernel/kernel.git/drivers/gpu/drm/drm_drv.c:198:
> undefined reference to `drm_agp_clear'
That's because drm_agp_clear() is called
Hi
On Thu, Aug 8, 2013 at 12:20 PM, Mark Brown wrote:
> From: Mark Brown
>
> Commit 28ec711 (drm/agp: move AGP cleanup paths to drm_agpsupport.c)
> broke the build for platforms which do not have AGP since it moved the
> AGP cleanup code inside an #ifdef __OS_HAS_AGP which are referenced
> uncon
Hi
On Thu, Aug 8, 2013 at 12:01 PM, Vincent Stehlé
wrote:
> Hi,
>
> Linux next-20130808 link breaks for me with ARM config multi_v7defconfig.
>
> It seems this is due to the following commit:
>
> 28ec711 drm/agp: move AGP cleanup paths to drm_agpsupport.c
>
> .
Hi
On Thu, Aug 8, 2013 at 8:00 PM, Stephen Warren wrote:
> In next-20130808, building tegra_defconfig for ARM yields:
>
>> drivers/built-in.o: In function `drm_lastclose':
>> /home/swarren/shared/git_wa/kernel/kernel.git/drivers/gpu/drm/drm_drv.c:198:
>> undefine
On 08/08/2013 12:13 PM, David Herrmann wrote:
> Hi
>
> On Thu, Aug 8, 2013 at 8:00 PM, Stephen Warren wrote:
>> In next-20130808, building tegra_defconfig for ARM yields:
>>
>>> drivers/built-in.o: In function `drm_lastclose':
>>> /home/swarren/sha
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #85 from Sergey ---
> Does disabling clockgating avoid the hangs?
Caught hang after hibernate.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel maili
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #86 from Alex Deucher ---
Ingoring suspend/hibernate, is anyone getting hangs or gpu resets with dpm
enabled under normal operation? If so, can you try disabling clockgating as
per comment 84? Lets address suspend/hibernate issues s
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #87 from Hrvoje Senjan ---
(In reply to comment #86)
> Ingoring suspend/hibernate, is anyone getting hangs or gpu resets with dpm
> enabled under normal operation? If so, can you try disabling clockgating as
> per comment 84? Lets a
Hi
On Thu, Aug 8, 2013 at 9:21 PM, Stephen Warren wrote:
> On 08/08/2013 12:13 PM, David Herrmann wrote:
>> Hi
>>
>> On Thu, Aug 8, 2013 at 8:00 PM, Stephen Warren wrote:
>>> In next-20130808, building tegra_defconfig for ARM yields:
>>>
>>>
We currently rely on gcc dead-code elimination so the drm_agp_* helpers
are not called if drm_core_has_AGP() is false. That's ugly as hell so
provide "static inline" dummies for the case that AGP is disabled.
Fixes a build-regression introduced by:
commit 28ec711cd427f8b61f73712a43b8100ba8ca933
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #88 from Francisco Pina Martins ---
I've been using DPM in my rv635 for a few days now (intensive use, as this is
my main machine) and had no issues yet.
I can however, still tempt fate and try some nasty things such as quick zoom
in/
Hi Bryan,
On Wed, 7 Aug 2013, Bryan Wu wrote:
> Hi Guennadi and LMML,
>
> I'm working on a camera controller driver for Tegra, which is using
> soc_camera. But we also need to use Tegra specific host1x interface
> like syncpt APIs.
>
> Since host1x is quite Tegra specific framework which is in
This patch adds the notion of a drm_bridge. A bridge is a chained
device which hangs off an encoder. The drm driver using the bridge
should provide the association between encoder and bridge. Once a
bridge is associated with an encoder, it will participate in mode
set, dpms, and optionally connecti
On 08/08/2013 02:19 PM, David Herrmann wrote:
> We currently rely on gcc dead-code elimination so the drm_agp_* helpers
> are not called if drm_core_has_AGP() is false. That's ugly as hell so
> provide "static inline" dummies for the case that AGP is disabled.
>
> Fixes a build-regression introduc
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #89 from Alex Deucher ---
(In reply to comment #88)
> I've been using DPM in my rv635 for a few days now (intensive use, as this
> is my main machine) and had no issues yet.
> I can however, still tempt fate and try some nasty things
From: Fabio Estevam
Commit 28ec711 (drm/agp: move AGP cleanup paths to drm_agpsupport.c) causes the
following link error on ARM (imx_v6_v7_defconfig):
drivers/built-in.o: In function `drm_lastclose':
:(.text+0x588a0): undefined reference to `drm_agp_clear'
make: *** [vmlinux] Error 1
drm_agp_c
Sebastian Hesselbarth wrote on Tue
[2013-Aug-06 00:20:10 +0200]:
> This patch set picks up several patches sent during the past months
> related with NXP TDA998x HDMI transmitter driver. The patches have
> been tested on Marvell Dove (Armada DRM) on several HDMI modes with
> audio playing on S/PD
https://bugs.freedesktop.org/show_bug.cgi?id=67187
--- Comment #13 from Bastian Triller ---
Resume from suspend only works when I have the power plug attached. It doesn't
matter, if I suspended on AC or not as long I have attached it on resume.
--
You are receiving this mail because:
You are th
https://bugs.freedesktop.org/show_bug.cgi?id=67187
--- Comment #14 from Bastian Triller ---
Created attachment 83867
--> https://bugs.freedesktop.org/attachment.cgi?id=83867&action=edit
dmesg
there was an error on the first suspend:
...
[drm:rv770_stop_dpm] *ERROR* Could not force DPM to low.
https://bugs.freedesktop.org/show_bug.cgi?id=67187
--- Comment #15 from Alex Deucher ---
(In reply to comment #13)
> Resume from suspend only works when I have the power plug attached. It
> doesn't matter, if I suspended on AC or not as long I have attached it on
> resume.
Does resume work with
https://bugs.freedesktop.org/show_bug.cgi?id=67927
Priority: medium
Bug ID: 67927
Assignee: dri-devel@lists.freedesktop.org
Summary: R600_DEBUG=sb: Celestia show 2 earths, one wrongly
rendered
Severity: major
Classificati
On Thu, Aug 8, 2013 at 11:03 PM, Sean Paul wrote:
> This patch adds the notion of a drm_bridge. A bridge is a chained
> device which hangs off an encoder. The drm driver using the bridge
> should provide the association between encoder and bridge. Once a
> bridge is associated with an encoder, it
On Thu, Aug 8, 2013 at 8:36 PM, Daniel Vetter wrote:
> On Thu, Aug 8, 2013 at 11:03 PM, Sean Paul wrote:
>> This patch adds the notion of a drm_bridge. A bridge is a chained
>> device which hangs off an encoder. The drm driver using the bridge
>> should provide the association between encoder and
On Thu, Aug 8, 2013 at 5:36 PM, Daniel Vetter wrote:
> On Thu, Aug 8, 2013 at 11:03 PM, Sean Paul wrote:
>> This patch adds the notion of a drm_bridge. A bridge is a chained
>> device which hangs off an encoder. The drm driver using the bridge
>> should provide the association between encoder and
https://bugzilla.kernel.org/show_bug.cgi?id=60709
--- Comment #17 from Torsten Krah ---
Done with bisect - did take some time but got it:
d3418eacad403033e95e49dc14afa37c2112c134 is the first bad commit
commit d3418eacad403033e95e49dc14afa37c2112c134
Author: Rafał Miłecki
Date: Thu Apr 18 09:
From: Mark Brown
Commit 28ec711 (drm/agp: move AGP cleanup paths to drm_agpsupport.c)
broke the build for platforms which do not have AGP since it moved the
AGP cleanup code inside an #ifdef __OS_HAS_AGP which are referenced
unconditionally in drm_drv.c. This causes build failures for embedded
S
Hi,
thanks for the explanation.
Do you know if this is a hardware limitation, or if an updated version of the
driver will come some day?
Regards,
Sam
> Date: Wed, 7 Aug 2013 18:06:05 -0400
> Subject: Re: [3.11-rc4] [HD2400] - radeon.dpm
> From: alexdeuc...@gmail.com
> To: miaous...@hotmail.com
On Thu, Aug 8, 2013 at 1:52 PM, Guennadi Liakhovetski
wrote:
> Hi Bryan,
>
> On Wed, 7 Aug 2013, Bryan Wu wrote:
>
>> Hi Guennadi and LMML,
>>
>> I'm working on a camera controller driver for Tegra, which is using
>> soc_camera. But we also need to use Tegra specific host1x interface
>> like syncp
https://bugs.freedesktop.org/show_bug.cgi?id=66738
--- Comment #12 from lh ---
(In reply to comment #11)
> Are you running the same userspace stack with both kernel 3.9 and kernel
> 3.10/3.11? If so, it sounds like this is UVD related.
Yes, I have two kernels: arch official kernel 3.9.9 and ker
On Wed, Aug 07, 2013 at 09:37:52PM +0900, Inki Dae wrote:
> 2013/8/7 Daniel Vetter
>
> > On Wed, Aug 7, 2013 at 2:01 PM, Inki Dae wrote:
> > >
> > >
> > > 2013/8/7 Daniel Vetter
> > >>
> > >> On Wed, Aug 07, 2013 at 07:18:45PM +0900, Joonyoung Shim wrote:
> > >> > On 08/07/2013 06:55 PM, Daniel
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130808/091381d5/attachment.html>
gs with dpm disabled?
--
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/20130808/7fe95399/attachment.html>
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130808/0c7dd62c/attachment.html>
Hi Dave,
I've got a couple of arch/arm/ patches that depend on this series and that I
would like to get merged in v3.12. They should go upstream through the arm-soc
tree. Would you be able to provide a stable branch with this patch set based
on one of the 3.11-rcX tags ? Ideally that branch sho
On Thu, Aug 8, 2013 at 10:43 AM, Laurent Pinchart
wrote:
> Hi Dave,
>
> I've got a couple of arch/arm/ patches that depend on this series and that I
> would like to get merged in v3.12. They should go upstream through the arm-soc
> tree. Would you be able to provide a stable branch with this patch
rg/archives/dri-devel/attachments/20130808/91d8796e/attachment.html>
On Wed, Aug 07, 2013 at 08:50:20PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Aug 07, 2013 at 12:09:32PM +0200, Daniel Vetter wrote:
> > This fixes a WARN in i915_gem_free_object when the
> > obj->pages_pin_count isn't 0.
> >
> > v2: Add locking to unmap, noticed by Chris Wilson. Note that even
Hi Dave,
(CC'ing Simon Horman, the shmobile tree maintainer)
On Thursday 08 August 2013 10:57:33 Dave Airlie wrote:
> On Thu, Aug 8, 2013 at 10:43 AM, Laurent Pinchart wrote:
> > Hi Dave,
> >
> > I've got a couple of arch/arm/ patches that depend on this series and that
> > I would like to get m
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Thursday, August 08, 2013 8:21 AM
> To: Inki Dae
> Cc: Daniel Vetter; Intel Graphics Development; DRI Development
> Subject: Re: [PATCH 1/3] drm: use common drm_gem_dmabuf_re
2013/8/8 Alex Deucher :
> Some more radeon fixes. Mostly dpm and uvd fixes. Fixes hangs
> with dpm on more rv6xx asics, and fixes suspend and resume with UVD.
That
fix audio dto calculation on DCE3+
looks promising, I had no idea you're working on that. Thanks for
releasing that!
Maybe you coul
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 3cd56e1..fd76449
Hi, Daniel. You can repost your patch set including the below my patch. And
my patch numbering is wrong. Sorry about that.
[PATCH 1/4] -> [PATCH 4/4]
Thanks,
Inki Dae
> -Original Message-
> From: Inki Dae [mailto:inki.dae at samsung.com]
> Sent: Thursday, August 08, 2013 1:40 PM
> To: d
On Thu, Aug 08, 2013 at 03:34:17AM +0200, Laurent Pinchart wrote:
> Hi Dave,
>
> (CC'ing Simon Horman, the shmobile tree maintainer)
>
> On Thursday 08 August 2013 10:57:33 Dave Airlie wrote:
> > On Thu, Aug 8, 2013 at 10:43 AM, Laurent Pinchart wrote:
> > > Hi Dave,
> > >
> > > I've got a coupl
On Thu, Aug 8, 2013 at 6:32 AM, Inki Dae wrote:
>
>
>> -Original Message-
>> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
>> Vetter
>> Sent: Thursday, August 08, 2013 8:21 AM
>> To: Inki Dae
>> Cc: Daniel Vetter; Intel Graphics Development; DRI Development
>>
1 - 100 of 182 matches
Mail list logo
