https://bugzilla.kernel.org/show_bug.cgi?id=60687
--- Comment #9 from Rafał Miłecki ---
@Gabor: can you boot 3.10.3 and call:
avivotool regset 0x12c44 0x0033
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri
https://bugzilla.kernel.org/show_bug.cgi?id=60687
--- Comment #10 from Rafał Miłecki ---
(Please make it *after* connecting HDMI display, after it breaks)
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel
At Mon, 5 Aug 2013 12:56:04 +1000,
Dave Airlie wrote:
>
> Add support for HDMI audio device on VGA cards that powerdown
> to D3cold using non-standard ACPI/PCI infrastructure (optimus).
>
> This does a couple of things to make it work:
>
> a) add a set of power ops for the hdmi domain, and enab
https://bugzilla.kernel.org/show_bug.cgi?id=60687
--- Comment #11 from Gabor Hasenfrasz ---
@Rafał: It's working. After switching to mirroring, or to HDMI only, and
entering this command, the display starts working with sound.
--
You are receiving this mail because:
You are watching the assigne
Vikas,
On 08/06/2013 07:23 AM, Vikas Sajjan wrote:
> While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
> connected with resolution 2560x1600, following error occured even with
> IOMMU enabled:
> [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate buffer.
> [0
https://bugzilla.kernel.org/show_bug.cgi?id=60659
Aaron Lu changed:
What|Removed |Added
CC||aaron...@intel.com
--- Comment #8 from Aaron L
We can apply the same optimisation tricks as kref_put_mutex() in our
local equivalent function. However, we have a different locking semantic
(we unlock ourselves, in kref_put_mutex() the callee unlocks) so that we
can use the same callbacks for both locked and unlocked kref_put()s and
so can not s
Hi
On Mon, Aug 5, 2013 at 9:46 AM, Daniel Vetter wrote:
> On Sat, Jul 27, 2013 at 01:36:27PM +0200, David Herrmann wrote:
>> Add a "best_match" flag similar to the drm_mm_search_*() helpers so we
>> can convert TTM to use them in follow up patches. We can also inline the
>> non-generic helpers an
On Tue, Aug 6, 2013 at 11:39 AM, David Herrmann wrote:
>
> On Mon, Aug 5, 2013 at 9:46 AM, Daniel Vetter wrote:
>> On Sat, Jul 27, 2013 at 01:36:27PM +0200, David Herrmann wrote:
>>> Add a "best_match" flag similar to the drm_mm_search_*() helpers so we
>>> can convert TTM to use them in follow u
Hi Vikas,
On 6 August 2013 10:53, Vikas Sajjan wrote:
> While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
> connected with resolution 2560x1600, following error occured even with
> IOMMU enabled:
> [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate buffer.
Hi Rob,
+lkml
> >> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey
> >> wrote:
> >> >> > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to
> >> >> >also allocate buffers for the GPU. Still not sure how to
> >> >> >resolve this as we don't use DRM for our GPU driver.
> >> >>
>
On Mon, Aug 5, 2013 at 8:10 PM, Dave Airlie wrote:
>> diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h
>> new file mode 100644
>> index 000..a586fbd
>> --- /dev/null
>> +++ b/include/uapi/drm/msm_drm.h
>> @@ -0,0 +1,198 @@
>> +/*
>> + * Copyright (C) 2013 Red Hat
>> + * Aut
On Tue, Aug 6, 2013 at 7:31 AM, Tom Cooksey wrote:
>
>> > So in some respects, there is a constraint on how buffers which will
>> > be drawn to using the GPU are allocated. I don't really like the idea
>> > of teaching the display controller DRM driver about the GPU buffer
>> > constraints, even i
Am Dienstag, den 06.08.2013, 12:31 +0100 schrieb Tom Cooksey:
> Hi Rob,
>
> +lkml
>
> > >> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey
> > >> wrote:
> > >> >> > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to
> > >> >> >also allocate buffers for the GPU. Still not sure how to
https://bugs.freedesktop.org/show_bug.cgi?id=67825
Priority: medium
Bug ID: 67825
Assignee: dri-devel@lists.freedesktop.org
Summary: Screen corruption/lockups on Northern Islands (BARTS)
with dpm active
Severity: normal
C
This is a cirrus version of Egbert Eich's patch for mgag200.
Without bo.bdev->dev_mapping set, the ttm_bo_unmap_virtual_locked
called from ttm_bo_handle_move_mem returns with no effect. If any
application accessed the memory before it was moved, it will
access wrong memory next time. This causes c
https://bugs.freedesktop.org/show_bug.cgi?id=67825
--- Comment #1 from Alex Deucher ---
Please attach your full dmesg output.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesk
https://bugs.freedesktop.org/show_bug.cgi?id=67722
--- Comment #1 from Alex Deucher ---
(In reply to comment #0)
>
> https://bugs.freedesktop.org/show_bug.cgi?id=66963 was fixed but here comes
> new problem. When booting into X(KDE splash screen), it seemed to
> freeze(even after a cold reset),
https://bugs.freedesktop.org/show_bug.cgi?id=67800
--- Comment #1 from Alex Deucher ---
Please attach your dmesg output.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.o
https://bugs.freedesktop.org/show_bug.cgi?id=67825
--- Comment #2 from Alex S ---
Created attachment 83721
--> https://bugs.freedesktop.org/attachment.cgi?id=83721&action=edit
Full dmesg log
Added the full dmesg log as per request of Alex Deucher.
--
You are receiving this mail because:
You
https://bugs.freedesktop.org/show_bug.cgi?id=67825
Alex S changed:
What|Removed |Added
Attachment #83713|0 |1
is obsolete|
Hi Rob,
> >> > We may also then have additional constraints when sharing buffers
> >> > between the display HW and video decode or even camera ISP HW.
> >> > Programmatically describing buffer allocation constraints is very
> >> > difficult and I'm not sure you can actually do it - there's some
>
https://bugs.freedesktop.org/show_bug.cgi?id=67800
--- Comment #2 from Kertesz Laszlo ---
Created attachment 83722
--> https://bugs.freedesktop.org/attachment.cgi?id=83722&action=edit
Attached dmesg rright after boot
--
You are receiving this mail because:
You are the assignee for the bug.
__
On Tue, Aug 6, 2013 at 8:18 AM, Lucas Stach wrote:
> Am Dienstag, den 06.08.2013, 12:31 +0100 schrieb Tom Cooksey:
>> Hi Rob,
>>
>> +lkml
>>
>> > >> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey
>> > >> wrote:
>> > >> >> > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to
>> > >> >> >
https://bugs.freedesktop.org/show_bug.cgi?id=67722
--- Comment #2 from Daniel ---
No, I mean without dpm enabled all boots are OK. This happens only when I
enable dpm, not always, occasionally. Sometimes even after a cold reset, if
shutdown by force counts.
--
You are receiving this mail becaus
Am Dienstag, den 06.08.2013, 10:14 -0400 schrieb Rob Clark:
> On Tue, Aug 6, 2013 at 8:18 AM, Lucas Stach wrote:
> > Am Dienstag, den 06.08.2013, 12:31 +0100 schrieb Tom Cooksey:
> >> Hi Rob,
> >>
> >> +lkml
> >>
> >> > >> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey
> >> > >> wrote:
> >> > >> >
On Tue, Aug 6, 2013 at 10:03 AM, Tom Cooksey wrote:
> Hi Rob,
>
>> >> > We may also then have additional constraints when sharing buffers
>> >> > between the display HW and video decode or even camera ISP HW.
>> >> > Programmatically describing buffer allocation constraints is very
>> >> > difficu
On Tue, Aug 6, 2013 at 10:36 AM, Lucas Stach wrote:
> Am Dienstag, den 06.08.2013, 10:14 -0400 schrieb Rob Clark:
>> On Tue, Aug 6, 2013 at 8:18 AM, Lucas Stach wrote:
>> > Am Dienstag, den 06.08.2013, 12:31 +0100 schrieb Tom Cooksey:
>> >> Hi Rob,
>> >>
>> >> +lkml
>> >>
>> >> > >> On Fri, Jul 2
On Tue, Aug 6, 2013 at 2:18 PM, Lucas Stach wrote:
> I strongly disagree with exposing low-level hardware details like tiling
> to userspace. If we have to do the negotiation of those things in
> userspace we will end up with having to pipe those information through
> things like the wayland proto
From: Sebastian Hesselbarth [mailto:sebastian.hesselba...@gmail.com]
> Subject: [PATCH 0/8] Several NXP TDA998x patches
>
> 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
> >> ... This is the purpose of the attach step,
> >> so you know all the devices involved in sharing up front before
> >> allocating the backing pages. (Or in the worst case, if you have a
> >> "late attacher" you at least know when no device is doing dma access
> >> to a buffer and can reallocat
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
>> graphic :
>
> Can you please retest with latest upstream git from Linus' tree?
erm, that patch won't apply
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
>>> graphic :
>>
>> Can you please retest with latest
https://bugzilla.kernel.org/show_bug.cgi?id=60674
--- Comment #5 from nuc...@hotmail.com ---
Indeed downgrading to kernel 3.9.9 doesn't solve the issue for me.. will play
with mesa now
--
You are receiving this mail because:
You are watching the assignee of the bug.
_
https://bugzilla.kernel.org/show_bug.cgi?id=60674
--- Comment #6 from nuc...@hotmail.com ---
Ah, sorry! Downgrading to kernel 3.9.9 does solve the issue! SDDM (my login
manager) still flickers but this seems to be Qt5 related. Really sorry, ignore
my previous comment!
--
You are receiving this m
On Tue, Aug 6, 2013 at 1:38 PM, Tom Cooksey wrote:
>
>> >> ... This is the purpose of the attach step,
>> >> so you know all the devices involved in sharing up front before
>> >> allocating the backing pages. (Or in the worst case, if you have a
>> >> "late attacher" you at least know when no devi
Re-posting the whole series because I forgot dri-devel in the first version and
also added a few patches from the review.
Version 2 of the series:
http://lists.freedesktop.org/archives/intel-gfx/2013-August/031183.html
With Ville's comments so far addressed.
I've also added the already posted
Cc: Thierry Reding
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/video/hdmi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 4017833..dbd882f 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video
And a way to pack hdmi_infoframe generically.
Cc: Thierry Reding
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/video/hdmi.c | 43 +++
include/linux/hdmi.h | 17 +
2 files changed, 60 insertions(+)
diff --git a/driv
Cc: Thierry Reding
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
include/linux/hdmi.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index 0f3f82e..bc6743e 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -23,6 +2
If the user if this API is providing a bigger buffer than the infoframe
size, it could be for a could reason. For instance it could be because
it gives the buffer that will be written to the hardware, up to the
maximum of an infoframe size.
Instead of just zeroing up to the infoframe size, let's z
From CEA-861:
Data Byte 1, bit A0 indicates whether Active Format Data is present in
Data Byte 2 bits R3 through R0. A source device shall set A0=1 when
any of the AFD bits are set.
ie. if we want to set active_aspect, we need to set the
active_info_valid bit to 1 as well.
Cc: Thierry Redi
First step in the move to the shared infoframe infrastructure, let's
move the different infoframe helpers and the write_infoframe() vfunc to
a type (enum hdmi_infoframe_type) and a buffer + len instead of using
our struct dip_infoframe.
v2: constify the infoframe pointer and don't mix signs (Ville
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
Signed-off-by: Paulo Zanoni
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/i915/intel_sdvo.c | 38 --
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.
I cannot find any evidence what we shouldn't try to set those fields
when setting a non-CEA mode on an HDMI sink. So just kill that return.
Suggested-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/d
Let's use the drivers/video/hmdi.c and drm infoframe helpers to build
our infoframes.
v2: Simplify the logic to compute the buffer size. We can just take the
maximum infoframe size rounded to 32, which happens to be what the
hardware let us write anyway.
v3: Remove unnecessary memset() (Ville Syr
set_frame() wraps the write_frame() vfunc. Be consistent and name the
wrapping function like the vfunc being called.
It's doubly confusing as we also have a set_infoframes() vfunc and
set_infoframe() doesn't wrap it.
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/
All the HDMI infoframe code has been ported to use video/hdmi.c, so it's
time to say bye bye to this code.
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_drv.h | 61 ---
drivers/gpu/drm/i915/intel_hdmi.c | 15
Suggested-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c| 3 +++
drivers/gpu/drm/i915/intel_hdmi.c | 3 ---
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 8d1139f..a9c8980 100644
https://bugs.freedesktop.org/show_bug.cgi?id=67530
--- Comment #4 from gurket...@googlemail.com ---
Created attachment 83741
--> https://bugs.freedesktop.org/attachment.cgi?id=83741&action=edit
use more common defaults for the level
This patch adds more common defaults as level. Imho they are l
On Tue, Aug 06, 2013 at 09:59:46AM +0100, Chris Wilson wrote:
> We can apply the same optimisation tricks as kref_put_mutex() in our
> local equivalent function. However, we have a different locking semantic
> (we unlock ourselves, in kref_put_mutex() the callee unlocks) so that we
> can use the sa
https://bugzilla.kernel.org/show_bug.cgi?id=60709
Bug ID: 60709
Summary: With 3.10.2 / 3.10.5 screen output is "green" - looks
like a green overlay
Product: Drivers
Version: 2.5
Kernel Version: 3.10.5
Hardware: i386
https://bugzilla.kernel.org/show_bug.cgi?id=60710
Bug ID: 60710
Summary: Radeon RV530 I2C failure with DVI monitor.
Product: Drivers
Version: 2.5
Kernel Version: 3.10.5
Hardware: i386
OS: Linux
Tree: Mainline
https://bugzilla.kernel.org/show_bug.cgi?id=60710
--- Comment #1 from Chris Rankin ---
Created attachment 107126
--> https://bugzilla.kernel.org/attachment.cgi?id=107126&action=edit
dmesg log for 3.10.5 (WORKING)
This doesn't demonstrate the problem. It's merely to describe the T60p hardware
b
On Tue, Aug 06, 2013 at 11:27:50PM +0200, Daniel Vetter wrote:
> On Tue, Aug 06, 2013 at 09:59:46AM +0100, Chris Wilson wrote:
> > We can apply the same optimisation tricks as kref_put_mutex() in our
> > local equivalent function. However, we have a different locking semantic
> > (we unlock ourselv
https://bugzilla.kernel.org/show_bug.cgi?id=60710
--- Comment #2 from Chris Rankin ---
Created attachment 107128
--> https://bugzilla.kernel.org/attachment.cgi?id=107128&action=edit
Relevant slice of /var/log/messages
I've trawled through my remaining logs, and after the initial error they rea
https://bugzilla.kernel.org/show_bug.cgi?id=60709
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #1 from
https://bugzilla.kernel.org/show_bug.cgi?id=60710
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #3 from
On Tue, Jul 30, 2013 at 6:41 PM, Peter Zijlstra wrote:
> On Tue, Jul 30, 2013 at 10:13:41AM +0200, Maarten Lankhorst wrote:
>> The check needs to be for > 1, because ctx->acquired is already incremented.
>> This will prevent ww_mutex_lock_slow from returning -EDEADLK and not locking
>> the mutex.
On Tue, Jul 30, 2013 at 5:51 PM, 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.
I like this, anyone else want to comment/review?
Dave.
>
> Signed-off-by: Ilia Mirkin
Hey Tom and Rob,
since you both have drivers pending, you might want to do some cross
review, I know Rob has looked at the pl111 one already,
but I think its a good thing for people writing drivers to review
other drivers as you can learn a lot of stuff you wouldn't otherwise.
same goes for SoC
On Tue, Aug 6, 2013 at 8:12 PM, Dave Airlie wrote:
> On Tue, Jul 30, 2013 at 5:51 PM, 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.
>
> I like this, anyone else want
https://bugs.freedesktop.org/show_bug.cgi?id=67849
Priority: medium
Bug ID: 67849
Assignee: dri-devel@lists.freedesktop.org
Summary: continuos reboots
Severity: critical
Classification: Unclassified
OS: Linux (All)
On Tue, Aug 6, 2013 at 8:40 PM, Rob Clark wrote:
> On Tue, Aug 6, 2013 at 8:12 PM, Dave Airlie wrote:
>> On Tue, Jul 30, 2013 at 5:51 PM, 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
Patches 1-5, 10, 11 are:
Reviewed-by: Alex Deucher
On Tue, Aug 6, 2013 at 3:32 PM, Damien Lespiau wrote:
> Cc: Thierry Reding
> Reviewed-by: Ville Syrjälä
> Signed-off-by: Damien Lespiau
> ---
> drivers/video/hdmi.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --gi
On Mon, Jul 29, 2013 at 7:58 AM, Rob Clark wrote:
> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey wrote:
>> Hi Rob,
>>
>>> > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
>>> >allocate buffers for the GPU. Still not sure how to resolve this
>>> >as we don't use DRM fo
Hi Inki,
On Tue, Aug 6, 2013 at 5:27 PM, Sachin Kamat wrote:
> On 6 August 2013 17:22, Vikas Sajjan wrote:
>> While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
>> connected with resolution 2560x1600, following error occured even with
>> IOMMU enabled:
>> [0.88] [drm:low
On Tue, Aug 6, 2013 at 5:15 AM, Rob Clark wrote:
> On Tue, Aug 6, 2013 at 7:31 AM, Tom Cooksey wrote:
>>
>>> > So in some respects, there is a constraint on how buffers which will
>>> > be drawn to using the GPU are allocated. I don't really like the idea
>>> > of teaching the display controller
> -Original Message-
> From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
> ow...@vger.kernel.org] On Behalf Of Vikas Sajjan
> Sent: Wednesday, August 07, 2013 1:11 PM
> To: Sachin Kamat
> Cc: Vikas Sajjan; linux-samsung-soc; dri-devel@lists.freedesktop.org;
> Kukjin
While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
connected with resolution 2560x1600, following error occured even with
IOMMU enabled:
[0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate buffer.
[0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
T
On 6 August 2013 17:22, Vikas Sajjan wrote:
> While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
> connected with resolution 2560x1600, following error occured even with
> IOMMU enabled:
> [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate buffer.
> [0.89
Hi,
I was testing 3.11-rc4 with and without radeon.dpm=1 and I expected some
results, either in performance or in power consumption, but I do not
notice any change...
Should I worry?
Or do you want me to do any specific test?
I have an ATI Mobility HD2400 (RV610).
|cat /sys/class/drm/card0/d
Hi Inki Dae,
On 7 August 2013 10:18, Inki Dae wrote:
>
>
>> -Original Message-
>> From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
>> ow...@vger.kernel.org] On Behalf Of Vikas Sajjan
>> Sent: Wednesday, August 07, 2013 1:11 PM
>> To: Sachin Kamat
>> Cc: Vikas Sajja
Op 07-08-13 02:05, Dave Airlie schreef:
> On Tue, Jul 30, 2013 at 6:41 PM, Peter Zijlstra wrote:
>> On Tue, Jul 30, 2013 at 10:13:41AM +0200, Maarten Lankhorst wrote:
>>> The check needs to be for > 1, because ctx->acquired is already incremented.
>>> This will prevent ww_mutex_lock_slow from retu
https://bugs.freedesktop.org/show_bug.cgi?id=67800
--- Comment #3 from Kertesz Laszlo ---
So. It seems that dpms isnt the (only) culprit after all. I left it disabled
for the night and in the morning the computer was frozen again (the monitor was
blanked, but still had signal).
--
You are recei
https://bugs.freedesktop.org/show_bug.cgi?id=67800
Kertesz Laszlo changed:
What|Removed |Added
Summary|Computer freezes after idle |Computer freezes after idle
> diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h
> new file mode 100644
> index 000..a586fbd
> --- /dev/null
> +++ b/include/uapi/drm/msm_drm.h
> @@ -0,0 +1,198 @@
> +/*
> + * Copyright (C) 2013 Red Hat
> + * Author: Rob Clark
> + *
> + * This program is free software; yo
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130806/5a7fa0f5/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130806/126dfa0c/attachment.html>
|Trinity 7500G |
--
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/20130806/b22e07e8/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130806/f166f58c/attachment-0001.html>
card (the
5650), but that's a separate bug I guess.
--
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/20130806/4b9b2bd0/attachment.html>
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130806/dbb3cf6d/attachment.html>
n/a).
>Aug 6 00:15:18 mars rtkit-daemon[1849]: Demoted 4 threads.
>Aug 6 00:15:18 mars acpid: client 1333[0:0] has disconnected
>Aug 6 00:15:18 mars kernel: [ 154.655659] Restarting tasks ... done.
>Aug 6 00:15:18 mars kernel: [ 154.677972] video LNXVIDEO:00: Restoring
>backlight state
>Aug 6 00:15:18 mars kernel: [ 154.679920] video LNXVIDEO:01: Restoring
>backlight state
>Aug 6 00:15:18 mars acpid: client connected from 1333[0:0]
>Aug 6 00:15:18 mars acpid: 1 client rule loaded
>Aug 6 00:15:18 mars anacron[3134]: Anacron 2.3 started on 2013-08-06
>Aug 6 00:15:18 mars anacron[3134]: Will run job `cron.daily' in 5 min.
>Aug 6 00:15:18 mars anacron[3134]: Jobs will be executed sequentially
>Aug 6 00:15:24 mars acpid: client 1333[0:0] has disconnected
>Aug 6 00:15:24 mars acpid: client connected from 1333[0:0]
>Aug 6 00:15:24 mars acpid: 1 client rule loaded
--
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/20130806/748b92aa/attachment-0001.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/20130806/aeae7b2d/attachment.html>
From: Russell King
TDA19988 devices need their RAM enabled in order to read EDID
information. Add support for this.
Signed-off-by: Russell King
Tested-by: Sebastian Hesselbarth
---
Cc: David Airlie
Cc: Darren Etheridge
Cc: Rob Clark
Cc: Russell King
Cc: Daniel Vetter
Cc: dri-devel at lis
From: Russell King
The npix/nline registers are supposed to be programmed with the total
number of pixels/lines, not the displayed pixels/lines, and not minus
one either.
Signed-off-by: Russell King
Tested-by: Sebastian Hesselbarth
---
Cc: David Airlie
Cc: Darren Etheridge
Cc: Rob Clark
Cc:
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/PDIF. I have also quickly tested on Beaglebone
Black (tilcdc) for one DVI mod
From: Russell King
When switching between various drivers for this device, it's possible
that some critical registers are left containing values which affect
the device operation. One such case encountered is the VIP output
mux register. This defaults to 0x24 on powerup, but other drivers may
s
From: Russell King
The video-input-port (VIP) is highly configurable. This prepares
current driver to allow to configure VIP configuration, as some
boards connect lcd controller and TDA998x "pin-swapped" and depend
on VIP to swap the pins by register configuration.
Signed-off-by: Russell King
T
From: Russell King
This patch adds tda998x specific parameters to allow it to be configured
for different boards using it. Also, this implements rudimentary audio
support for S/PDIF attached controllers.
Signed-off-by: Russell King
Signed-off-by: Sebastian Hesselbarth
---
Changelog:
for v1:
-
This fixes the wrong sync generation and sync calculation of TDA998x
for HS/VS-based sync detection.
Signed-off-by: Sebastian Hesselbarth
---
Cc: David Airlie
Cc: Darren Etheridge
Cc: Rob Clark
Cc: Russell King
Cc: Daniel Vetter
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger
From: Darren Etheridge
Some LCD controller cannot provide valid VESA style sync, i.e. coincident
HS/VS edges. First, this patch adds hskew passed from the adjusted_mode to
reference pixel calculation to allow those controllers to add an offset
relative to the expected reference pixel.
Signed-off
From: Darren Etheridge
Add a fixup function that will flip the hsync priority and
add a hskew value that is used to shift the tda998x to the
right by a variable number of pixels depending on the mode.
This works around an issue with the sync timings that tilcdc
is outputing.
Signed-off-by: Darre
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Monday, August 05, 2013 1:42 PM
> To: Chris Wilson; Liu, Chuansheng; daniel.vetter at ffwll.ch; airlied at
> linux.ie;
> intel-gfx at lists.freedesktop.org; Li, Fei; dri-de
While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
connected with resolution 2560x1600, following error occured even with
IOMMU enabled:
[0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate buffer.
[0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
T
ect *obj,
+ struct i915_address_space *vm)
+{
+ struct i915_vma *vma;
+ list_for_each_entry(vma, &obj->vma_list, vma_link)
+ if (vma->vm == vm)
+ return vma;
+
+ return NULL;
+}
-- next part ---
branch, thanks Alex.
--
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/20130806/ad52dac3/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=60687
--- Comment #9 from Rafa? Mi?ecki ---
@Gabor: can you boot 3.10.3 and call:
avivotool regset 0x12c44 0x0033
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=60687
--- Comment #10 from Rafa? Mi?ecki ---
(Please make it *after* connecting HDMI display, after it breaks)
--
You are receiving this mail because:
You are watching the assignee of the bug.
1 - 100 of 164 matches
Mail list logo
