On Sun, Jun 09, 2013 at 07:01:36PM -0400, Matthew Garrett wrote:
> Windows 8 introduced new policy for backlight control by pushing it out to
> graphics drivers. This appears to have coincided with a range of vendors
> adding Windows 8 checks to their backlight control code which trigger either
> a
On Wed, Aug 07, 2013 at 10:27:35AM +1000, Dave Airlie wrote:
> On Mon, Aug 5, 2013 at 5:35 AM, Daniel Vetter wrote:
> > Hi Dave,
>
> Okay since I missed this, then I merged patches from the list from
> David Herrmann
> fixing up drm_mm usage, then I merged this and it all fell to pieces.
>
> C
On Tue, Jul 30, 2013 at 03:51:49AM -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
> ---
>
> v1 -> v2: correct loop condition... no
On Tue, Aug 06, 2013 at 10:06:16PM -0400, Alex Deucher wrote:
> Patches 1-5, 10, 11 are:
>
> Reviewed-by: Alex Deucher
Entire series merged to drm-intel-next-queue with Dave's irc ack. Thanks
for the patches and review.
-Daniel
>
> On Tue, Aug 6, 2013 at 3:32 PM, Damien Lespiau
> wrote:
> >
On Wed, Aug 7, 2013 at 4:00 AM, Ville Syrjälä
wrote:
> On Tue, Jul 30, 2013 at 03:51:49AM -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: Il
On Wed, Aug 7, 2013 at 10:28 AM, Ilia Mirkin wrote:
>> Also there's no retry loop w/ ida_pre_get() and since that's outside the
>> big kms lock, there could be a (small) chance that someone else already
>> consumed the allocation done in ida_pre_get(). And then we'll return
>> -EAGAIN which is a r
https://bugzilla.kernel.org/show_bug.cgi?id=60710
--- Comment #4 from Chris Rankin ---
(In reply to Alex Deucher from comment #3)
> The hw i2c engine somehow got into a bad state.
Not only that, but GNOME3 put the HW I2C engine back into that same "bad state"
when I rebooted and logged back in.
vimOn Mit, 2013-07-17 at 12:58 +0100, Chris Wilson wrote:
> On Wed, Jun 12, 2013 at 11:58:44AM +0200, Michel Dänzer wrote:
> > From: Michel Dänzer
> >
> > It takes an unsigned value. This happens not to blow up on 64-bit
> > architectures, but it does on 32-bit, causing
> > drm_cal
Hi all,
I need to get my prime fixes in since they're blocking QA from running -nightly
prime tests. Which is a prerequisite of mine before I start touching dma-buf for
real to look at fencing and ww-mutex integration for i915.
These three patches are just a bit of prep cleanup and one bugfix tha
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
Cc: Maarten Lankhorst
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_dm
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
On Wed, Aug 07, 2013 at 11:15:07AM +0200, Daniel Vetter wrote:
> This fixes a WARN in i915_gem_free_object when the
> obj->pages_pin_count isn't 0.
>
> Reported-by: Maarten Lankhorst
> Cc: Maarten Lankhorst
> Signed-off-by: Daniel Vetter
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=6
On Wed, Aug 07, 2013 at 11:15:07AM +0200, Daniel Vetter wrote:
> This fixes a WARN in i915_gem_free_object when the
> obj->pages_pin_count isn't 0.
>
> Reported-by: Maarten Lankhorst
> Cc: Maarten Lankhorst
> Signed-off-by: Daniel Vetter
Papers over the WARN with iffy locking. Not all callers
On Wed, Aug 07, 2013 at 11:15:06AM +0200, Daniel Vetter wrote:
> 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 nee
On 08/07/2013 03:44 PM, Borislav Petkov wrote:
> On Sun, Jun 09, 2013 at 07:01:36PM -0400, Matthew Garrett wrote:
>> Windows 8 introduced new policy for backlight control by pushing it out to
>> graphics drivers. This appears to have coincided with a range of vendors
>> adding Windows 8 checks to t
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
> Sent: Wednesday, August 07, 2013 6:15 PM
> To: DRI Development
> Cc: Intel Graphics Development; Daniel Vetter; Inki Dae
> Subject: [PATCH 1/3] drm: use common drm_gem_dmabuf_release in i915/exynos
> drivers
>
>
On Wed, Aug 07, 2013 at 11:15:08AM +0200, Daniel Vetter wrote:
> Makes it more obviously correct what tricks we play by reusing the drm
> prime release helper.
>
> Signed-off-by: Daniel Vetter
I do like these little typesafe cast helpers.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Inte
On Wed, Aug 7, 2013 at 11:29 AM, Chris Wilson wrote:
> On Wed, Aug 07, 2013 at 11:15:07AM +0200, Daniel Vetter wrote:
>> This fixes a WARN in i915_gem_free_object when the
>> obj->pages_pin_count isn't 0.
>>
>> Reported-by: Maarten Lankhorst
>> Cc: Maarten Lankhorst
>> Signed-off-by: Daniel Vett
On Wed, Aug 7, 2013 at 11:40 AM, Inki Dae wrote:
>> -Original Message-
>> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
>> Sent: Wednesday, August 07, 2013 6:15 PM
>> To: DRI Development
>> Cc: Intel Graphics Development; Daniel Vetter; Inki Dae
>> Subject: [PATCH 1/3] drm: use commo
Hi
On Wed, Aug 7, 2013 at 10:19 AM, kbuild test robot
wrote:
> tree: git://people.freedesktop.org/~danvet/drm-intel.git drm-intel-nightly
> head: 3224cf6c3ee5ab9c280052c9fbed4f660310c411
> commit: 28ec711cd427f8b61f73712a43b8100ba8ca933b [243/249] drm/agp: move AGP
> cleanup paths to drm_agp
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
It's unclear whether ->map is allowed to fail with -EINTR, but
looking at current callers it's pretty clear that they don't
expect this to happen. So use a blocking mutex_lock call. Since
we don't wait for the gpu in our ->map callback the lack of the
gpu hang checks doesn't matter.
Furthermore th
https://bugs.freedesktop.org/show_bug.cgi?id=67187
--- Comment #12 from Harald Judt ---
I've run the tests again with the latest commits pulled from ~agd5f/linux, and
hibernate&suspend/resume seems to work fine now with uvd enabled! That's 12 out
of 12 successful attempts so far, so please let's
On 08/07/2013 06:55 PM, Daniel Vetter wrote:
On Wed, Aug 7, 2013 at 11:40 AM, Inki Dae wrote:
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
Sent: Wednesday, August 07, 2013 6:15 PM
To: DRI Development
Cc: Intel Graphics Development; Daniel Vetter; Inki Dae
Subje
On Wed, Aug 07, 2013 at 07:18:45PM +0900, Joonyoung Shim wrote:
> On 08/07/2013 06:55 PM, Daniel Vetter wrote:
> >On Wed, Aug 7, 2013 at 11:40 AM, Inki Dae wrote:
> >>>-Original Message-
> >>>From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
> >>>Sent: Wednesday, August 07, 2013 6:15 PM
On 08/07/2013 07:21 PM, Daniel Vetter wrote:
On Wed, Aug 07, 2013 at 07:18:45PM +0900, Joonyoung Shim wrote:
On 08/07/2013 06:55 PM, Daniel Vetter wrote:
On Wed, Aug 7, 2013 at 11:40 AM, Inki Dae wrote:
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
Sent: Wedne
On Wed, Aug 07, 2013 at 12:09:33PM +0200, Daniel Vetter wrote:
> It's unclear whether ->map is allowed to fail with -EINTR, but
> looking at current callers it's pretty clear that they don't
> expect this to happen. So use a blocking mutex_lock call. Since
> we don't wait for the gpu in our ->map c
On Wed, Aug 07, 2013 at 05:03:15PM +0800, Aaron Lu wrote:
> I think this would require the kernel has the knowledge of which
> backlight interface this system is using or should be using, or it
> wouldn't know which interface should receive and process the event...
Well, we can have a default one,
Op 07-08-13 12:09, Daniel Vetter schreef:
> 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 deadloc
On Wed, Aug 07, 2013 at 04:28:35AM -0400, Ilia Mirkin wrote:
> On Wed, Aug 7, 2013 at 4:00 AM, Ville Syrjälä
> wrote:
> > On Tue, Jul 30, 2013 at 03:51:49AM -0400, Ilia Mirkin wrote:
> >> @@ -722,8 +741,9 @@ int drm_connector_init(struct drm_device *dev,
> >> connector->dev = dev;
> >>
https://bugs.freedesktop.org/show_bug.cgi?id=67530
--- Comment #5 from Christian König ---
(In reply to comment #4)
> Created attachment 83741 [details] [review]
> use more common defaults for the level
>
> This patch adds more common defaults as level. Imho they are likely not
> correct for all
On Wed, Aug 7, 2013 at 12:30 PM, Chris Wilson wrote:
> On Wed, Aug 07, 2013 at 12:09:33PM +0200, Daniel Vetter wrote:
>> It's unclear whether ->map is allowed to fail with -EINTR, but
>> looking at current callers it's pretty clear that they don't
>> expect this to happen. So use a blocking mutex_
https://bugs.freedesktop.org/show_bug.cgi?id=66967
--- Comment #3 from Daniel ---
I'm not sure if I and others experience the same problem as you, but when I try
to start the first tutorial mission in DotA 2 (or change the resolution in the
options menu), the game crashes.
I reported my issues fi
On Tue, Aug 06, 2013 at 08:32:16PM +0100, Damien Lespiau wrote:
> 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 in
On Tue, Aug 06, 2013 at 08:32:18PM +0100, Damien Lespiau wrote:
> 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_i
On Tue, Aug 06, 2013 at 08:32:19PM +0100, Damien Lespiau wrote:
> 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
On Wed, Aug 07, 2013 at 01:56:58PM +0300, Ville Syrjälä wrote:
> On Tue, Aug 06, 2013 at 08:32:16PM +0100, Damien Lespiau wrote:
> > 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 bu
On Wed, Aug 07, 2013 at 10:36:08AM +, Matthew Garrett wrote:
> Not really. The ACPI driver is able to do this because the events and
> the backlight are associated with the same device.
Well, it doesn't work at least in my case.
I need to echo stuff into /sys/class/backlight/intel_backlight :
Hi David,
On Wednesday 07 August 2013 11:57:54 David Herrmann wrote:
> On Wed, Aug 7, 2013 at 10:19 AM, kbuild test robot wrote:
> > tree: git://people.freedesktop.org/~danvet/drm-intel.git
> > drm-intel-nightly head: 3224cf6c3ee5ab9c280052c9fbed4f660310c411
> > commit: 28ec711cd427f8b61f73712
Hi Dave,
The following changes since commit 32c913e4369ce7bd1d16a9b6983f7b8975c13f5a:
Merge tag 'drm-intel-next-2013-07-26-fixed' of
git://people.freedesktop.org/~danvet/drm-intel into drm-next (2013-08-07
18:11:35 +1000)
are available in the git repository at:
git://linuxtv.org/pinchartl
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 Vetter wrote:
> > >On Wed, Aug 7, 2013 at 11:40 AM, Inki Dae wrote:
> > >>>-Original Message-
> > >>>From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
> > >>>Sent
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 Vetter wrote:
>> > >On Wed, Aug 7, 2013 at 11:40 AM, Inki Dae wrote:
>> > >>>-Original Message-
>> > >>>F
The drm_agp_clear() function is only defined on platforms with AGP
support. Move the drm_core_has_AGP() check from drm_agp_clear() to the
caller to let the compiler optimize the drm_agp_clear() call away.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_agpsupport.c | 2 +-
drivers/gpu/dr
On Wed, Aug 7, 2013 at 2:17 PM, Laurent Pinchart
wrote:
> The drm_agp_clear() function is only defined on platforms with AGP
> support. Move the drm_core_has_AGP() check from drm_agp_clear() to the
> caller to let the compiler optimize the drm_agp_clear() call away.
>
> Signed-off-by: Laurent Pinc
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 Vetter wrote:
> >> > >On Wed, Aug 7, 2013 at 11:40 AM, Inki Dae
> wrote:
>
Hi Daniel,
On Wednesday 07 August 2013 14:19:34 Daniel Vetter wrote:
> On Wed, Aug 7, 2013 at 2:17 PM, Laurent Pinchart wrote:
> > The drm_agp_clear() function is only defined on platforms with AGP
> > support. Move the drm_core_has_AGP() check from drm_agp_clear() to the
> > caller to let the com
Hi
On Wed, Aug 7, 2013 at 2:39 PM, Laurent Pinchart
wrote:
> Hi Daniel,
>
> On Wednesday 07 August 2013 14:19:34 Daniel Vetter wrote:
>> On Wed, Aug 7, 2013 at 2:17 PM, Laurent Pinchart wrote:
>> > The drm_agp_clear() function is only defined on platforms with AGP
>> > support. Move the drm_core_
On Tue, Aug 6, 2013 at 4:03 PM, * SAMÍ * wrote:
> 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?
Please at
https://bugzilla.kernel.org/show_bug.cgi?id=60710
--- Comment #5 from Alex Deucher ---
(In reply to Chris Rankin from comment #4)
> (In reply to Alex Deucher from comment #3)
> > The hw i2c engine somehow got into a bad state.
>
> Not only that, but GNOME3 put the HW I2C engine back into that sa
On Wed, Aug 7, 2013 at 12:23 AM, John Stultz wrote:
> On Tue, Aug 6, 2013 at 5:15 AM, Rob Clark wrote:
>> well, let's divide things up into two categories:
>>
>> 1) the arrangement and format of pixels.. ie. what userspace would
>> need to know if it mmap's a buffer. This includes pixel format,
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
A bit more context than the previous patch that was a bit alone. This series
parses yet a bit more of the EDID:
- The HDMI VICs in the HDMI vendor specific block (HDMI 1.4, 4k modes)
- The CEA Video Capability Data Block
It also includes 2 EDIDs of TVs that have those bits.
--
Damien
__
Signed-off-by: Damien Lespiau
---
edid-decode.c | 84 +--
1 file changed, 82 insertions(+), 2 deletions(-)
diff --git a/edid-decode.c b/edid-decode.c
index 9840db6..7515181 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -32,6 +32,8 @@
#
Signed-off-by: Damien Lespiau
---
data/skyworth-50e780u-hdmi | Bin 0 -> 256 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 data/skyworth-50e780u-hdmi
diff --git a/data/skyworth-50e780u-hdmi b/data/skyworth-50e780u-hdmi
new file mode 100644
index
0
Signed-off-by: Damien Lespiau
---
edid-decode.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/edid-decode.c b/edid-decode.c
index 7515181..55e48a7 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -705,7 +705,7 @@ cea_hdmi_block(unsigned char *x)
Signed-off-by: Damien Lespiau
---
edid-decode.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/edid-decode.c b/edid-decode.c
index 55e48a7..5061228 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -659,6 +659,13 @@ cea_video_block(unsigned char *x)
---
data/samsung-UE40D8000YU-hmdi | Bin 0 -> 256 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 data/samsung-UE40D8000YU-hmdi
diff --git a/data/samsung-UE40D8000YU-hmdi b/data/samsung-UE40D8000YU-hmdi
new file mode 100644
index
Signed-off-by: Damien Lespiau
---
edid-decode.c | 69 +--
1 file changed, 67 insertions(+), 2 deletions(-)
diff --git a/edid-decode.c b/edid-decode.c
index 5061228..7aed3c6 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -32,8 +32,6 @@
#
Signed-off-by: Damien Lespiau
---
edid-decode.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/edid-decode.c b/edid-decode.c
index 7aed3c6..58297c9 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -861,6 +861,44 @@ cea_hdmi_block(unsigned char *x)
v2: Fix rebase fail that removed a necessary hunk
Signed-off-by: Damien Lespiau
---
edid-decode.c | 67 +++
1 file changed, 67 insertions(+)
diff --git a/edid-decode.c b/edid-decode.c
index 5061228..083ddd9 100644
--- a/edid-decode.c
+++ b
This was already required before, but no check in the kernel was done to
enforce it.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 73cf240..ddb065c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_displa
Allocating type=0 marks the memory as free. This allows the ltcg memory to be
allocated twice. Add a BUG_ON in core/mm.c to prevent this ever happening again.
Additionally some registers were not initialized in init, this causes them to be
uninitialized after suspend.
Signed-off-by: Maarten Lankho
It's my megabyte, I want to use it! At this point in init
vbios is copied over already, so there's no reason it cannot
used to hold other data now.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/nouveau/core/subdev/fb/ramnvc0.c
b/drivers/gpu/drm/nouveau/core/subdev/fb/ramnvc0.
https://bugzilla.kernel.org/show_bug.cgi?id=60710
--- Comment #6 from Chris Rankin ---
(In reply to Alex Deucher from comment #5)
> Well a warm reboot may not have fuly reset the hardware; the bad state may
> have persisted.
What "warm reboot"? IIRC, I powered the laptop down and came back to it
On Wed, 2013-08-07 at 09:44 +0200, Borislav Petkov wrote:
> Background is that on my x230, I needed to connect the
> Fn-Fx backlight hotkey presses to a script to write to
> /sys/class/backlight/intel_backlight/brightness because Fluxbox doesn't
> do that (and maybe doesn't have to).
>
> So, with
My Latitude E6510 has the following graphics HW:
01:00.0 VGA compatible controller: nVidia Corporation GT218 [NVS 3100M] (rev
a2) (prog-if 00 [VGA controller])
Subsystem: Dell Latitude E6510
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at e200 (32-bit, non-
Hi David,
On Wednesday 07 August 2013 15:53:15 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.
Please note t
Hi
On Wed, Aug 7, 2013 at 5:53 PM, Laurent Pinchart
wrote:
> Hi David,
>
> On Wednesday 07 August 2013 15:53:15 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 "sta
Just comment a bit on Rob's review with my own opinion.
On Wed, Aug 07, 2013 at 12:17:21PM -0400, Rob Clark wrote:
> On Thu, Jul 25, 2013 at 1:17 PM, wrote:
> > From: Tom Cooksey
> >
> > This is a mode-setting driver for the pl111 CLCD display controller
> > found on various ARM reference platf
Hi David,
On Wednesday 07 August 2013 18:12:23 David Herrmann wrote:
> On Wed, Aug 7, 2013 at 5:53 PM, Laurent Pinchart wrote:
> > On Wednesday 07 August 2013 15:53:15 David Herrmann wrote:
> >> We currently rely on gcc dead-code elimination so the drm_agp_* helpers
> >> are not called if drm_core
https://bugzilla.kernel.org/show_bug.cgi?id=60709
Torsten Krah changed:
What|Removed |Added
Summary|With 3.10.2 / 3.10.5 screen |With 3.10.3 / 3.10.5 screen
https://bugzilla.kernel.org/show_bug.cgi?id=60709
--- Comment #2 from Torsten Krah ---
Yes i am using radeon.audio=1. Disabling this makes 3.10.5 work without green
screen.
Attaching dmesg from 3.10.3 - thought it was .2, sorry.
I'll try to bisect - may take some time, i'll try asap.
--
You ar
https://bugzilla.kernel.org/show_bug.cgi?id=60709
--- Comment #3 from Torsten Krah ---
Created attachment 107140
--> https://bugzilla.kernel.org/attachment.cgi?id=107140&action=edit
dmesg 3.10.3 with radeon.audio=1
--
You are receiving this mail because:
You are watching the assignee of the b
https://bugzilla.kernel.org/show_bug.cgi?id=60709
Rafał Miłecki changed:
What|Removed |Added
CC||zaj...@gmail.com
--- Comment #4 from Rafa
> >> > Didn't you say that programmatically describing device placement
> >> > constraints was an unbounded problem? I guess we would have to
> >> > accept that it's not possible to describe all possible constraints
> >> > and instead find a way to describe the common ones?
> >>
> >> well, the poi
I'd sent these previously, but consolidating them into one patchset
for easier tracking. The individual driver patches are not needed
for msm drm/kms but the drm core bits are.
Rob Clark (9):
drm: add flip-work helper
drm/tilcdc: use flip-work helper
drm/omap: use flip-work helper
drm: co
A small helper to queue up work to do, from workqueue context, after a
flip. Typically useful to defer unreffing buffers that may be read by
the display controller until vblank.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/Makefile| 2 +-
drivers/gpu/drm/drm_flip_work.c | 124
Signed-off-by: Rob Clark
Tested-by: Darren Etheridge
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 33 -
1 file changed, 12 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 7418dcd..e09a76
Because, there is no reason for it not to be const.
v1: original
v2: fix compile break in vmwgfx, and couple related cleanups suggested
by Ville Syrjälä
Signed-off-by: Rob Clark
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 4 ++--
drivers/gpu/drm/gma500/psb_drv.c| 2 +-
drivers/gpu
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 slightly modified version of
drm_gem_create_mmap_offset() in omapdrm
Basically just extracting some code duplicated in gma500, omapdrm, udl,
and upcoming msm driver.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_gem.c | 103 ++
include/drm/drmP.h| 4 ++
2 files changed, 107 insertions(+)
diff --git a/drive
Signed-off-by: Rob Clark
---
drivers/gpu/drm/gma500/gtt.c | 38 ++
1 file changed, 6 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/gma500/gtt.c b/drivers/gpu/drm/gma500/gtt.c
index 1f82183..92babac 100644
--- a/drivers/gpu/drm/gma500/gtt.c
+++ b/
Signed-off-by: Rob Clark
---
drivers/gpu/drm/udl/udl_gem.c | 44 ++-
1 file changed, 6 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
index 2a4cb2f..8ea3f8f 100644
--- a/drivers/gpu/drm/udl/udl_gem
Signed-off-by: Rob Clark
---
drivers/gpu/drm/omapdrm/Makefile | 3 -
drivers/gpu/drm/omapdrm/omap_gem.c | 8 +-
drivers/gpu/drm/omapdrm/omap_gem_helpers.c | 124 -
3 files changed, 4 insertions(+), 131 deletions(-)
delete mode 100644 drivers/gpu/
And simplify how we hold a ref+pin to what is being scanned out by using
fb refcnt'ing. The previous logic pre-dated fb refcnt, and as a result
was less straightforward than it could have been. By holding a ref to
the fb, we don't have to care about how many plane's there are and
holding a ref to
This patchset can also be found here, for easier browsing:
http://cgit.freedesktop.org/~robclark/linux/log/?h=drm-next
git://people.freedesktop.org/~robclark/linux drm-next
Compared to the previous patchset, there are a number of
fixes (leaks, etc), fixed handling of some clocks (ie. don't di
oh, whoops, this one is already on drm-next
On Wed, Aug 7, 2013 at 1:41 PM, Rob Clark wrote:
> Because, there is no reason for it not to be const.
>
> v1: original
> v2: fix compile break in vmwgfx, and couple related cleanups suggested
> by Ville Syrjälä
>
> Signed-off-by: Rob Clark
> ---
>
On Wed, Aug 07, 2013 at 01:41:19PM -0400, Rob Clark wrote:
> A small helper to queue up work to do, from workqueue context, after a
> flip. Typically useful to defer unreffing buffers that may be read by
> the display controller until vblank.
>
> Signed-off-by: Rob Clark
Since you have this nic
https://bugzilla.kernel.org/show_bug.cgi?id=60709
--- Comment #5 from Torsten Krah ---
Created attachment 107141
--> https://bugzilla.kernel.org/attachment.cgi?id=107141&action=edit
hdmi regs 3.9.11 with radeon.audio=1
--
You are receiving this mail because:
You are watching the assignee of t
https://bugzilla.kernel.org/show_bug.cgi?id=60709
--- Comment #6 from Torsten Krah ---
Created attachment 107142
--> https://bugzilla.kernel.org/attachment.cgi?id=107142&action=edit
hdmi regs 3.10.5 with radeon.audio=0
--
You are receiving this mail because:
You are watching the assignee of t
On Wed, Aug 7, 2013 at 1:33 PM, Tom Cooksey wrote:
>
>> >> > Didn't you say that programmatically describing device placement
>> >> > constraints was an unbounded problem? I guess we would have to
>> >> > accept that it's not possible to describe all possible constraints
>> >> > and instead find a
On Wed, Aug 7, 2013 at 1:33 PM, Tom Cooksey wrote:
>
>> >> > Didn't you say that programmatically describing device placement
>> >> > constraints was an unbounded problem? I guess we would have to
>> >> > accept that it's not possible to describe all possible constraints
>> >> > and instead find a
On Wed, Aug 7, 2013 at 1:49 PM, Daniel Vetter wrote:
> On Wed, Aug 07, 2013 at 01:41:19PM -0400, Rob Clark wrote:
>> A small helper to queue up work to do, from workqueue context, after a
>> flip. Typically useful to defer unreffing buffers that may be read by
>> the display controller until vbla
This series parses one of the dark corners of the EDID to expose "4k x 2k"
modes to userspace. Those modes are part of HDMI 1.4.
To complete the 4k HDMI support, one needs:
* Hardware able to output a 300 MHz TMDS clock (Haswell can do that) and
Daniel's patch to bump that limit in the kern
A few styles issues have creept in here, fix them before touching this
code again.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 95d6f4b..51
HDMI 1.4 adds 4 "4k x 2k" modes in the the CEA vendor specific block.
With this commit, we now parse this block and expose the 4k modes that
we find there.
Signed-off-by: Damien Lespiau
Tested-by: Cancan Feng
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67030
---
drivers/gpu/drm/drm_
A small helper to queue up work to do, from workqueue context, after a
flip. Typically useful to defer unreffing buffers that may be read by
the display controller until vblank.
v1: original
v2: wire up docbook + couple docbook fixes
Signed-off-by: Rob Clark
Acked-by: Daniel Vetter
---
Docume
https://bugzilla.kernel.org/show_bug.cgi?id=60709
--- Comment #7 from Rafał Miłecki ---
Whoops, your avivotool is too old to support "hdmi" (or you mispelled it).
Could you update avivotool, please?
After updating I'll need output of "avivotool regs hdmi" from 3.9 and 3.10,
both using radeon.aud
https://bugzilla.kernel.org/show_bug.cgi?id=60709
Torsten Krah changed:
What|Removed |Added
Attachment #107141|0 |1
is obsolete|
1 - 100 of 276 matches
Mail list logo
