ri-devel/attachments/20140604/ce5e55c0/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #15 from Teofilis Martisius ---
Created attachment 138161
--> https://bugzilla.kernel.org/attachment.cgi?id=138161&action=edit
Dmesg from 3.15rc7 from Debian/Experimental
Asus K73TA laptop with AMD A6-3400M APU and Radeon 6550 GPU
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #14 from Teofilis Martisius ---
Hi,
Thank you for very quick response.
I have just tried v3.15rc7 from Debian Experimental, it still has this same
problem. I have attached an excerpt from dmesg at the end of this message. I'll
attach
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Chris Wilson
commit bc5bd37ce48c66e9192ad2e7231e9678880f6f8e upstream.
Pavel Roskin reported that DRM_IOCTL_MODE_GETCONNECTOR was overwritting
the 4 bytes beyond the end of its structure with a
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #13 from Alex Deucher ---
There have been a lot of PX fixes in 3.15. Can you try 3.15? Additionally,
you can disable the PX runtime pm support by appending radeon.runpm=0 on the
kernel command line in grub.
--
You are receiving thi
https://bugzilla.kernel.org/show_bug.cgi?id=51381
Teofilis Martisius changed:
What|Removed |Added
CC||Teofilis.Martisius at gmail.co
On Wed, Jun 4, 2014 at 6:54 AM, Matwey V. Kornilov wrote:
> From e7147352639fd8f92b1cc85cff9bc5046c7a2130 Mon Sep 17 00:00:00 2001
> From: "Matwey V. Kornilov"
> Date: Mon, 2 Jun 2014 20:17:29 +0400
> Subject: [PATCH] Replace type of paddr to uint32_t.
>
> This patch helps to avoid the following
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140604/c6edb1f7/attachment.html>
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/20140604/a134c240/attachment.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140604/1dfc48e7/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140604/62c0a701/attachment.html>
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140604/1625630e/attachment.html>
ug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140604/fe59fcbd/attachment.html>
On Mon, Jun 2, 2014 at 10:52 AM, YoungJun Cho wrote:
> This patch adds sysreg device node, and sysreg property
> to fimd device node which is required to use I80 interface.
Same here. The system register nodes have been added to exynos5250 and
exynos5420 by the patch:
dfbbdbf ARM: dts: Add sysreg
Hi,
On Mon, Jun 2, 2014 at 10:52 AM, YoungJun Cho wrote:
> This patch adds relevant to exynos5 compatible for exynos5 SoCs.
This change is not required. Please check the latest 'for-next' branch
of linux-samsung tree.
Recently a patch "dfbbdbf ARM: dts: Add sysreg sytem controller node
to exyno
On Wed, Jun 04, 2014 at 10:27:25AM -0400, Rob Clark wrote:
> For atomic, it will be quite necessary to not need to care so much
> about locking order. And 'state' gives us a convenient place to stash a
> ww_ctx for any sort of update that needs to grab multiple crtc locks.
>
> Because we will wan
From: Dave Airlie
This should avoid races between connector probing and HPD
irqs in the future, currently mode_config.mutex blocks this
possibility.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_dp_helper.c | 15 +++
drivers/gpu/drm/i915/intel_dp.c | 1 +
drivers/gp
Am 04.06.2014 15:46, schrieb Alex Deucher:
> On Wed, Jun 4, 2014 at 9:29 AM, Christian K?nig
> wrote:
>> From: Christian K?nig
>>
>> When we set the valid bit on invalid GART entries they are
>> loaded into the TLB when an adjacent entry is loaded. This
>> poisons the TLB with invalid entries wh
ves/dri-devel/attachments/20140604/6eeda9c1/attachment.html>
From: Dave Airlie
The digital ports from Ironlake and up have the ability to distinguish
between long and short HPD pulses. Displayport 1.1 only uses the short
form to request link retraining usually, so we haven't really needed
support for it until now.
However with DP 1.2 MST we need to handle
From: Christian K?nig
The underlying reason for the crashes seems to be fixed now.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_asic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/rade
From: Christian K?nig
We never check the return value anyway and if the
index isn't valid would crash way before calling
the functions.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/r100.c| 8 ++--
drivers/gpu/drm/radeon/r300.c| 7 ++-
drivers/gpu/drm/rade
From: Christian K?nig
When we set the valid bit on invalid GART entries they are
loaded into the TLB when an adjacent entry is loaded. This
poisons the TLB with invalid entries which are sometimes
not correctly removed on TLB flush.
For stable inclusion the patch probably needs to be modified a
On Wed, 04 Jun 2014, David Herrmann wrote:
> Hi
>
> On Wed, Jun 4, 2014 at 12:57 AM, Daniel Vetter
> wrote:
>> From: Chris Wilson
>>
>> Touching the VGA resources on an IVB EFI machine causes hard hangs when
>> we then kick out the efifb. Ouch.
>>
>> Apparently this also prevents unclaimed regi
Hi
On Wed, Jun 4, 2014 at 2:20 PM, Jani Nikula
wrote:
> On Wed, 04 Jun 2014, David Herrmann wrote:
>> You rely on compiler-optimizations here. "dummy_con" is not available
>> if !CONFIG_DUMMY_CONSOLE, but you use it. This causes linker-failure
>> if dead-code elimination is not done (-O0).
>
>
>From e7147352639fd8f92b1cc85cff9bc5046c7a2130 Mon Sep 17 00:00:00 2001
From: "Matwey V. Kornilov"
Date: Mon, 2 Jun 2014 20:17:29 +0400
Subject: [PATCH] Replace type of paddr to uint32_t.
This patch helps to avoid the following build issue:
drivers/gpu/drm/msm/msm_fbdev.c:108:2: error: passing a
On 3 June 2014 23:29, Daniel Vetter wrote:
> On Fri, May 30, 2014 at 01:12:09PM -0400, Rob Clark wrote:
>> For atomic, it will be quite necessary to not need to care so much
>> about locking order. And 'state' gives us a convenient place to stash a
>> ww_ctx for any sort of update that needs to g
On 4 June 2014 03:30, Daniel Vetter wrote:
> The drm core shouldn't depend upon any helpers, and we make sure this
> doesn't accidentally happen by moving them into the helper-only
> drm_kms_helper.ko module.
>
> v2: Don't break the build for vmwgfx, spotted by Matt.
>
> v3: Unbreak the depency lo
On 05/29/2014 11:28 AM, Inki Dae wrote:
> This patch makes sure that exynos drm framework handles deferred
> probe case correctly.
>
> Sub drivers could be probed before resources, clock, regulator,
> phy or panel, are ready for them so we should make sure that exynos
> drm core waits until all re
On 3 June 2014 21:56, Jani Nikula wrote:
> Hi all, this is v2 of [1] to remove drm_get_connector_name() and
> drm_get_encoder_name(), adding patch 1 for imx in staging and making
> some dereferences less of an eye sore. This is based on Dave's drm-next
> branch.
>
I pushed these, after regeneratin
On 3 June 2014 03:06, Greg Kroah-Hartman wrote:
> On Mon, Jun 02, 2014 at 06:36:22PM +0200, Philipp Zabel wrote:
>> Am Mittwoch, den 28.05.2014, 14:13 -0700 schrieb Greg Kroah-Hartman:
>> > On Mon, May 26, 2014 at 04:19:39PM +0200, Philipp Zabel wrote:
>> > > The i.MX Image Processing Unit (IPU) c
Am 02.06.2014 17:52, schrieb Alex Deucher:
> On Mon, Jun 2, 2014 at 11:33 AM, Christian K?nig
> wrote:
>> From: Christian K?nig
>>
>> And also domain to prefered_domains. That matches better
>> what those values represent.
>>
>> Signed-off-by: Christian K?nig
>> Cc: Marek Ol??k
> A couple of co
ot it. I need to leave this particular laptop right now, so I
can't do that atm. I'll have it done tomorrow. Thanks for all the help and the
patience.
--
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/20140604/7163ce67/attachment.html>
TML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140604/931fa1a4/attachment.html>
ng the vo=opengl option in mpv.
--
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/20140604/d5f32c74/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140604/949d33c3/attachment.html>
Hawaii has the same version of VCE as other CIK parts.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_vce.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/radeon/radeon_vce.c
b/drivers/gpu/drm/radeon/radeon_vce.c
index ced53dd..1
I've hand fixed this up and applied it, but please in future submit
patches using the guidelines in Documentation/SubmittingPatches.
Dave.
On 4 June 2014 00:56, David Mansfield wrote:
> spice-server and downstream code expect that the primary surface
> will always have surface_id = 0, while in r
On 3 June 2014 23:03, Christian K?nig wrote:
> Am 03.06.2014 14:58, schrieb Alex Deucher:
>
>> On Mon, Jun 2, 2014 at 11:21 PM, Michel D?nzer wrote:
>>>
>>> On 03.06.2014 07:55, Alex Deucher wrote:
This is the first pull request for radeon for 3.16. Christian has
a few other patch
Hi Dave,
The following changes since commit d1db0eea852497762cab43b905b879dfcd3b8987:
Linux 3.15-rc3 (2014-04-27 19:29:27 -0700)
are available in the git repository at:
git://git.pengutronix.de/git/pza/linux.git topic/ipu-destaging
for you to fetch changes up to d6ca8ca7ec555bdd3372687d0d7
Hi
On Wed, Jun 4, 2014 at 12:57 AM, Daniel Vetter
wrote:
> From: Chris Wilson
>
> Touching the VGA resources on an IVB EFI machine causes hard hangs when
> we then kick out the efifb. Ouch.
>
> Apparently this also prevents unclaimed register errors on hsw and
> hard machine hangs on my i855gm
On Wed, Jun 04, 2014 at 04:04:25PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This should avoid races between connector probing and HPD
> irqs in the future, currently mode_config.mutex blocks this
> possibility.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/drm_dp_helper.c
On Wed, Jun 04, 2014 at 01:38:38PM +1000, Dave Airlie wrote:
> On 3 June 2014 23:29, Daniel Vetter wrote:
> > On Fri, May 30, 2014 at 01:12:09PM -0400, Rob Clark wrote:
> >> For atomic, it will be quite necessary to not need to care so much
> >> about locking order. And 'state' gives us a conveni
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140604/02c10bfe/attachment.html>
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Matt Roper
Sent: Friday, May 23, 2014 2:30 AM
To: dri-devel at lists.freedesktop.org
Cc: intel-gfx at lists.freedesktop.org
Subject: [Intel-gfx] [PATCH 6/6] drm/i915: Switch to unified plane c
All drm_fb_helper_restore_fbdev_mode() call sites, save one, do the same
locking. Simplify this into drm_fb_helper_restore_fbdev_mode_unlocked().
Signed-off-by: Rob Clark
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/armada/armada_fbdev.c | 4 +--
drivers/gpu/drm/drm_fb_cma_helper.c
For atomic, it will be quite necessary to not need to care so much
about locking order. And 'state' gives us a convenient place to stash a
ww_ctx for any sort of update that needs to grab multiple crtc locks.
Because we will want to eventually make locking even more fine grained
(giving locks to
The remaining bits.. mostly addition of docs for drm_modeset_lock
Rob Clark (2):
drm: convert crtc and connection_mutex to ww_mutex (v4)
drm: add drm_fb_helper_restore_fbdev_mode_unlocked()
Documentation/DocBook/drm.tmpl| 6 +
drivers/gpu/drm/Makefile | 3 +-
On Wed, Jun 4, 2014 at 9:29 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> When we set the valid bit on invalid GART entries they are
> loaded into the TLB when an adjacent entry is loaded. This
> poisons the TLB with invalid entries which are sometimes
> not correctly removed on TLB flu
On Wed, Jun 4, 2014 at 7:00 AM, Christian K?nig
wrote:
> Am 02.06.2014 17:52, schrieb Alex Deucher:
>
>> On Mon, Jun 2, 2014 at 11:33 AM, Christian K?nig
>> wrote:
>>>
>>> From: Christian K?nig
>>>
>>> And also domain to prefered_domains. That matches better
>>> what those values represent.
>>>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140604/a28896b9/attachment.html>
e any other way to do it? (Sorry, I'm not a programmer
myself.)
--
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/20140604/e9b46ff5/attachment.html>
VERS_PATH="./lib/gallium/" mpv
>
> The error number was 139.
Can you get the backtrace of the segmentation fault?
--
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/20140604/5b04dab9/attachment.html>
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/20140604/e2bc9c56/attachment.html>
Thanks,
Christian.
--
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/20140604/759a6bcb/attachment.html>
Hi Linus,
all fairly small, radeon stability and a panic path fix.
Mostly radeon fixes, suspend/resume fix,
stability on the CIK chipsets,
along with a locking check avoidance patch for panic times regression.
Dave.
The following changes since commit 18ee37a485653aa635cfab9a3710e9bcf5fbca01:
From: Chris Wilson
Touching the VGA resources on an IVB EFI machine causes hard hangs when
we then kick out the efifb. Ouch.
Apparently this also prevents unclaimed register errors on hsw and
hard machine hangs on my i855gm when trying to unbind fbcon.
Also, we want this to make I915_FBDEV=n sa
Component|Drivers/DRI/R100|Drivers/Gallium/r600
--
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/20140604/22294
58 matches
Mail list logo