Hi Daniel, Rob,
On 11 May 2012 21:00, Rob Clark wrote:
> On Tue, Apr 24, 2012 at 4:08 AM, Daniel Vetter wrote:
>> Compared to Rob Clark's RFC I've ditched the prepare/finish hooks
>>
>> Cc: Rob Clark
>> Cc: Rebecca Schultz Zavin
>> Signed-Off-by: Daniel Vetter
>
> Acked-by: Rob Clark
Thanks
Hi Dave,
On 17 May 2012 16:01, Dave Airlie wrote:
> From: Dave Airlie
>
> The main requirement I have for this interface is for scanning out
> using the USB gpu devices. Since these devices have to read the
> framebuffer on updates and linearly compress it, using kmaps
> is a major overhead for
On 05/17/2012 12:20 AM, Ben Skeggs wrote:
On Thu, May 17, 2012 at 10:30 AM, Ben Skeggs wrote:
Am Mittwoch, den 16.05.2012, 12:17 -0600 schrieb Tim Gardner:
commit b99da31ed8521eb78d5d6930f3128f8ecdb75fae causes the backlight in
my Dell XPS M1710 to stop working. Symptoms are dim display and wo
Hi, Laurent.
> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinchart at ideasonboard.com]
> Sent: Thursday, May 17, 2012 7:22 PM
> To: Inki Dae
> Cc: dri-devel at lists.freedesktop.org
> Subject: Re: [PATCH 2/4] drm: exynos: Remove dummy encoder get_crtc
> operation implemen
Hi Dave,
Fixed it. Please pull from
git://git.infradead.org/users/kmpark/linux-samsung exynos-drm-next again.
Please let me know if there is any problem and Sorry for inconvenience
caused.
Thanks,
Inki Dae
> -Original Message-
> From: Dave Airlie [mailto:airlied at gmail.com]
> Sent: Th
> -Original Message-
> From: Dave Airlie [mailto:airlied at gmail.com]
> Sent: Thursday, May 17, 2012 7:27 PM
> To: Joonyoung Shim
> Cc: dri-devel at lists.freedesktop.org; kyungmin.park at samsung.com;
> inki.dae at samsung.com
> Subject: Re: [PATCH v2] drm/exynos: add G2D driver
>
> On
On Thu, May 17, 2012 at 06:32:19AM -0600, Rob Clark wrote:
> On Thu, May 17, 2012 at 4:31 AM, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > The main requirement I have for this interface is for scanning out
> > using the USB gpu devices. Since these devices have to read the
> > framebuffer on
From: Jerome Glisse
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h | 528 +-
drivers/gpu/drm/radeon/radeon_ring.c |3 +-
2 files changed, 267 insertions(+), 264 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/d
From: Jerome Glisse
This try to identify the faulty user command stream that caused
lockup. If it finds one it create big blob that contains all
information, this include packet stream but also snapshot of all
bo used by the faulty packet stream.
This means that the blod is self contained and ca
From: Jerome Glisse
Allow caller of radeon_vm_bo_update_pte to get the virtual bo offset.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h |3 ++-
drivers/gpu/drm/radeon/radeon_cs.c |2 +-
drivers/gpu/drm/radeon/radeon_gart.c | 11 ---
3 files changed,
From: Jerome Glisse
Allow radeon debugfs file to provide a custom read function. This
is usefull in case you don't want to double buffer with seq_file,
or simply in case the buffer data is too big to be buffered by
seq_file.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/r100.c
From: Jerome Glisse
Allow driver to provide a custom read callback for debugfs file.
Usefull if driver try to dump big buffer, avoid double buffering.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/drm_debugfs.c | 19 ---
drivers/gpu/drm/i915/i915_debugfs.c
Ok this time is final version, i added a bunch of flags to cmd buffer
to make the userspace tools life easier.
Cheers,
Jerome
> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinchart at ideasonboard.com]
> Sent: Thursday, May 17, 2012 12:09 AM
> To: Inki Dae
> Cc: dri-devel at lists.freedesktop.org
> Subject: [PATCH 4/4] drm: exynos: Keep a reference to frame buffer GEM
> objects
>
> GEM objects u
> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinchart at ideasonboard.com]
> Sent: Thursday, May 17, 2012 12:09 AM
> To: Inki Dae
> Cc: dri-devel at lists.freedesktop.org
> Subject: [PATCH 3/4] drm: exynos: Don't cast GEM object to Exynos GEM
> object when not needed
>
>
> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinchart at ideasonboard.com]
> Sent: Thursday, May 17, 2012 12:09 AM
> To: Inki Dae
> Cc: dri-devel at lists.freedesktop.org
> Subject: [PATCH 2/4] drm: exynos: Remove dummy encoder get_crtc operation
> implementation
>
> The
> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinchart at ideasonboard.com]
> Sent: Thursday, May 17, 2012 12:09 AM
> To: Inki Dae
> Cc: dri-devel at lists.freedesktop.org
> Subject: [PATCH 1/4] drm: exynos: DRIVER_BUS_PLATFORM is not a driver
> feature
>
> DRIVER_BUS_PLA
On Tue, 08 May 2012 11:50:33 +0200
Tomasz Stanislawski wrote:
> This patch adds a new constructor for an sg table. The table is constructed
> from an array of struct pages. All contiguous chunks of the pages are merged
> into a single sg nodes. A user may provide an offset and a size of a buffer
On Tue, 08 May 2012 11:50:33 +0200
Tomasz Stanislawski wrote:
> This patch adds a new constructor for an sg table. The table is constructed
> from an array of struct pages. All contiguous chunks of the pages are merged
> into a single sg nodes. A user may provide an offset and a size of a buffer
On Thu, May 17, 2012 at 10:30 AM, Ben Skeggs wrote:
> Am Mittwoch, den 16.05.2012, 12:17 -0600 schrieb Tim Gardner:
>> commit b99da31ed8521eb78d5d6930f3128f8ecdb75fae causes the backlight in
>> my Dell XPS M1710 to stop working. Symptoms are dim display and won't
>> respond to key brightness event
From: Jerome Glisse
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h | 528 +-
drivers/gpu/drm/radeon/radeon_ring.c |3 +-
2 files changed, 267 insertions(+), 264 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/d
From: Jerome Glisse
This try to identify the faulty user command stream that caused
lockup. If it finds one it create big blob that contains all
information, this include packet stream but also snapshot of all
bo used by the faulty packet stream.
This means that the blod is self contained and ca
From: Jerome Glisse
Allow caller of radeon_vm_bo_update_pte to get the virtual bo offset.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h |3 ++-
drivers/gpu/drm/radeon/radeon_cs.c |2 +-
drivers/gpu/drm/radeon/radeon_gart.c | 11 ---
3 files changed,
From: Jerome Glisse
Allow radeon debugfs file to provide a custom read function. This
is usefull in case you don't want to double buffer with seq_file,
or simply in case the buffer data is too big to be buffered by
seq_file.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/r100.c
From: Jerome Glisse
Allow driver to provide a custom read callback for debugfs file.
Usefull if driver try to dump big buffer, avoid double buffering.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/drm_debugfs.c | 19 ---
drivers/gpu/drm/i915/i915_debugfs.c
Make the format more future proof reliable by adding a total chunk
size field that allow old userspace to skip over potentialy new
chunk. Not sure this is really needed but hey.
Jerome
On Wed, May 16, 2012 at 10:22 PM, wrote:
> From: Jerome Glisse
>
> This try to identify the faulty user command stream that caused
> lockup. If it finds one it create big blob that contains all
> information needed to replay the faulty command stream.
Can you state what exactly is going to end
From: Jerome Glisse
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h | 528 +-
drivers/gpu/drm/radeon/radeon_ring.c |3 +-
2 files changed, 267 insertions(+), 264 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/d
From: Jerome Glisse
This try to identify the faulty user command stream that caused
lockup. If it finds one it create big blob that contains all
information, this include packet stream but also snapshot of all
bo used by the faulty packet stream.
This means that the blod is self contained and ca
From: Jerome Glisse
Allow caller of radeon_vm_bo_update_pte to get the virtual bo offset.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h |3 ++-
drivers/gpu/drm/radeon/radeon_cs.c |2 +-
drivers/gpu/drm/radeon/radeon_gart.c | 11 ---
3 files changed,
From: Jerome Glisse
Allow radeon debugfs file to provide a custom read function. This
is usefull in case you don't want to double buffer with seq_file,
or simply in case the buffer data is too big to be buffered by
seq_file.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/r100.c
From: Jerome Glisse
Allow driver to provide a custom read callback for debugfs file.
Usefull if driver try to dump big buffer, avoid double buffering.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/drm_debugfs.c | 19 ---
drivers/gpu/drm/i915/i915_debugfs.c
Ok this time is final version, i added a bunch of flags to cmd buffer
to make the userspace tools life easier.
Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, 17 May 2012 01:36:29 +0200
Guillaume Cl?ment wrote:
>
> > Either way, if I add an empty "save" function, suspend works again (but at
> > the moment, resume still doesn't work, I'm still trying to work on that).
> >
> > If I just add a "if (connector->funcs->save)", this also fixes the c
From: Jerome Glisse
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h | 528 +-
drivers/gpu/drm/radeon/radeon_ring.c |3 +-
2 files changed, 267 insertions(+), 264 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/d
From: Jerome Glisse
This try to identify the faulty user command stream that caused
lockup. If it finds one it create big blob that contains all
information, this include packet stream but also snapshot of all
bo used by the faulty packet stream.
This means that the blod is self contained and ca
From: Jerome Glisse
Allow caller of radeon_vm_bo_update_pte to get the virtual bo offset.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h |3 ++-
drivers/gpu/drm/radeon/radeon_cs.c |2 +-
drivers/gpu/drm/radeon/radeon_gart.c | 11 ---
3 files changed,
From: Jerome Glisse
Allow radeon debugfs file to provide a custom read function. This
is usefull in case you don't want to double buffer with seq_file,
or simply in case the buffer data is too big to be buffered by
seq_file.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/r100.c
From: Jerome Glisse
Allow driver to provide a custom read callback for debugfs file.
Usefull if driver try to dump big buffer, avoid double buffering.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/drm_debugfs.c | 19 ---
drivers/gpu/drm/i915/i915_debugfs.c
So here is improved patchset, where i splited ground work necessary
for the dumping into their own patch. The debugfs improvement could
probably be usefull to intel instead of having i915 have it's own
debugfs file stuff.
The lockup dumping public api have been move into radeon_drm.h
Stressing th
On Thu, May 17, 2012 at 1:32 PM, Rob Clark wrote:
> On Thu, May 17, 2012 at 4:31 AM, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> The main requirement I have for this interface is for scanning out
>> using the USB gpu devices. Since these devices have to read the
>> framebuffer on updates and l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17/05/12 13:27, Steven Newbury wrote:
> On 15/05/12 18:42, Yinghai Lu wrote:
>> On Tue, May 15, 2012 at 2:54 AM, Steven Newbury
>> wrote:
>
>>> I'll get re-synced back up, and if they're still relevant give
>>> the patches a test. Is there an u
Drivers for hardware without gamma support should not be forced to
implement a no-op gamma set operation.
Signed-off-by: Laurent Pinchart
Cc: Rob Clark
---
drivers/gpu/drm/drm_crtc.c |5 +
drivers/gpu/drm/drm_fb_helper.c |3 +++
drivers/staging/omapdrm/omap_crtc.c |
The DRM mode config functions structure declared by drivers and pointed
to by the drm_mode_config funcs field is never modified. Make it a const
pointer.
Signed-off-by: Laurent Pinchart
Cc: Inki Dae
Cc: Alan Cox
Cc: Daniel Vetter
Cc: Ben Skeggs
Cc: Alex Deucher
Cc: Dave Airlie
Cc: Thomas He
The GEM vm operations structure is passed to the VM core that stores it
in a const field. There vm operations structures can thus be const in
DRM as well.
Signed-off-by: Laurent Pinchart
Cc: Inki Dae
Cc: Alan Cox
Cc: Daniel Vetter
Cc: Alex Deucher
Cc: Dave Airlie
Cc: Rob Clark
---
drivers/
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_crtc.c| 12 ++--
drivers/gpu/drm/drm_crtc_helper.c |2 +-
drivers/gpu/drm/drm_edid_load.c |8
drivers/gpu/drm/drm_fb_helper.c |5 +
drivers/gpu/drm/drm_gem.c |2 +-
drivers/gpu/drm/d
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_crtc.c|2 +-
drivers/gpu/drm/drm_sysfs.c |8
include/drm/drmP.h| 10 +-
include/drm/drm_crtc.h| 21 +++--
include/drm/drm_crtc_helper.h | 21 +
5 fi
A race condition exists in drm_vblank_cleanup() if the vblank disable
timer callback runs after freeing the memory that its callback function
tries to access. Fix this by deleting the timer synchronously.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_irq.c |2 +-
1 files changed, 1
Hello,
While studying the DRM core I came across a couple of issues or strange
constructs. Here are 6 patches that try to fix them.
Criticism is as usual welcome. Please bear with my lack of experience with the
DRM core :-)
Laurent Pinchart (6):
drm: Delete the vblank timer synchronously at cl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 15/05/12 18:42, Yinghai Lu wrote:
> On Tue, May 15, 2012 at 2:54 AM, Steven Newbury
> wrote:
>
>> I'll get re-synced back up, and if they're still relevant give
>> the patches a test. Is there an updated branch I should work
>> from?
>
> git://g
From: Jerome Glisse
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h | 528 +-
drivers/gpu/drm/radeon/radeon_ring.c |3 +-
2 files changed, 267 insertions(+), 264 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/d
From: Jerome Glisse
This try to identify the faulty user command stream that caused
lockup. If it finds one it create big blob that contains all
information, this include packet stream but also snapshot of all
bo used by the faulty packet stream.
This means that the blod is self contained and ca
From: Jerome Glisse
Allow caller of radeon_vm_bo_update_pte to get the virtual bo offset.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h |3 ++-
drivers/gpu/drm/radeon/radeon_cs.c |2 +-
drivers/gpu/drm/radeon/radeon_gart.c | 11 ---
3 files changed,
From: Jerome Glisse
Allow radeon debugfs file to provide a custom read function. This
is usefull in case you don't want to double buffer with seq_file,
or simply in case the buffer data is too big to be buffered by
seq_file.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/r100.c
From: Jerome Glisse
Allow driver to provide a custom read callback for debugfs file.
Usefull if driver try to dump big buffer, avoid double buffering.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/drm_debugfs.c | 19 ---
drivers/gpu/drm/i915/i915_debugfs.c
Make the format more future proof reliable by adding a total chunk
size field that allow old userspace to skip over potentialy new
chunk. Not sure this is really needed but hey.
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lis
Hi Inki,
On Thursday 17 May 2012 17:21:46 Inki Dae wrote:
> On Thursday, May 17, 2012 12:09 AM Laurent Pinchart wrote:
> >
> > The encoder get_crtc operation is called to retrieve a pointer to the
> > CRTC the encoder is currenctly connected to, right after setting the
> > encoder::crtc field to
Am 17.05.2012 09:09, schrieb Dan Carpenter:
> drm_core_ioremap() initializes ->handle. We already know
> "dev->agp_buffer_map" is a valid pointer.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/gpu/drm/savage/savage_bci.c
> b/drivers/gpu/drm/savage/savage_bci.c
> index cb1ee4e..6e
From: Jerome Glisse
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h | 528 +-
drivers/gpu/drm/radeon/radeon_ring.c |3 +-
2 files changed, 267 insertions(+), 264 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/d
From: Jerome Glisse
This try to identify the faulty user command stream that caused
lockup. If it finds one it create big blob that contains all
information, this include packet stream but also snapshot of all
bo used by the faulty packet stream.
This means that the blod is self contained and ca
From: Dave Airlie
The main requirement I have for this interface is for scanning out
using the USB gpu devices. Since these devices have to read the
framebuffer on updates and linearly compress it, using kmaps
is a major overhead for every update.
v2: fix warn issues pointed out by Sylwester Naw
From: Jerome Glisse
Allow caller of radeon_vm_bo_update_pte to get the virtual bo offset.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h |3 ++-
drivers/gpu/drm/radeon/radeon_cs.c |2 +-
drivers/gpu/drm/radeon/radeon_gart.c | 11 ---
3 files changed,
From: Jerome Glisse
Allow radeon debugfs file to provide a custom read function. This
is usefull in case you don't want to double buffer with seq_file,
or simply in case the buffer data is too big to be buffered by
seq_file.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/r100.c
From: Jerome Glisse
Allow driver to provide a custom read callback for debugfs file.
Usefull if driver try to dump big buffer, avoid double buffering.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/drm_debugfs.c | 19 ---
drivers/gpu/drm/i915/i915_debugfs.c
So here is improved patchset, where i splited ground work necessary
for the dumping into their own patch. The debugfs improvement could
probably be usefull to intel instead of having i915 have it's own
debugfs file stuff.
The lockup dumping public api have been move into radeon_drm.h
Stressing th
On Thu, Apr 26, 2012 at 9:48 AM, Joonyoung Shim
wrote:
> The G2D is a 2D graphic accelerator that supports Bit Block Transfer.
> This G2D driver is exynos drm specific and supports only G2D(version
> 4.1) of later Exynos series from Exynos4X12 because supporting DMA.
>
> The G2D is performed by t
https://bugzilla.kernel.org/show_bug.cgi?id=39832
--- Comment #22 from Carlos 2012-05-17
11:14:02 ---
Thanks for the reply. In fact, I already try the radeon.audio=1 settings, as
well to play sound with command sudo aplay -D plughw:1,3 (music).mp3 and
nothing. I tried as well kernel 3.3 no
On Thu, May 17, 2012 at 10:41 AM, Dave Airlie wrote:
> On Wed, May 16, 2012 at 10:22 PM, ? wrote:
>> From: Jerome Glisse
>>
>> This try to identify the faulty user command stream that caused
>> lockup. If it finds one it create big blob that contains all
>> information needed to replay the faulty
Is there any discussion on HDCP on the summit? It is tightly
coupled with HDMI and DVI and should be managed together with the
transmitter. But there is not code to handle HDCP in DRM/FB/V4L in
latest kernel. Any thoughts on HDCP? Or you guys think there is risk
to support it in kernel? Thanks
On Thu, May 17, 2012 at 06:32:19AM -0600, Rob Clark wrote:
> On Thu, May 17, 2012 at 4:31 AM, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > The main requirement I have for this interface is for scanning out
> > using the USB gpu devices. Since these devices have to read the
> > framebuffer on
Am Mittwoch, den 16.05.2012, 12:17 -0600 schrieb Tim Gardner:
> commit b99da31ed8521eb78d5d6930f3128f8ecdb75fae causes the backlight in
> my Dell XPS M1710 to stop working. Symptoms are dim display and won't
> respond to key brightness events. I bisected and confirmed that
> reverting this single p
drm_core_ioremap() initializes ->handle. We already know
"dev->agp_buffer_map" is a valid pointer.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/savage/savage_bci.c
b/drivers/gpu/drm/savage/savage_bci.c
index cb1ee4e..6eb507a 100644
--- a/drivers/gpu/drm/savage/savage_bci.c
+++ b/d
On 05/17/2012 12:09 AM, Dan Carpenter wrote:
drm_core_ioremap() initializes ->handle. We already know
"dev->agp_buffer_map" is a valid pointer.
Signed-off-by: Dan Carpenter
I'm surprised that has never been hit.
Reviewed-by: Ian Romanick
diff --git a/drivers/gpu/drm/savage/savage_bci.c
On 05/17/2012 12:09 AM, Dan Carpenter wrote:
> drm_core_ioremap() initializes ->handle. We already know
> "dev->agp_buffer_map" is a valid pointer.
>
> Signed-off-by: Dan Carpenter
I'm surprised that has never been hit.
Reviewed-by: Ian Romanick
>
> diff --git a/drivers/gpu/drm/savage/savage_b
On Thu May 17 2012 04:46:37 Jun Nie wrote:
> Is there any discussion on HDCP on the summit? It is tightly
> coupled with HDMI and DVI and should be managed together with the
> transmitter. But there is not code to handle HDCP in DRM/FB/V4L in
> latest kernel. Any thoughts on HDCP? Or you guys t
On Thu, May 17, 2012 at 5:34 AM, Steven Newbury wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Strange, the busn branch is merged with for-pci-res-alloc, but for
> some reason it isn't working. Only the bridge is detected, not the
> devices behind it.
Can you post the boot log ? maybe recently re
On Thu, May 17, 2012 at 5:34 AM, Steven Newbury
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Strange, the busn branch is merged with for-pci-res-alloc, but for
> some reason it isn't working. ?Only the bridge is detected, not the
> devices behind it.
Can you post the boot log ? maybe recently r
On 05/17/2012 12:20 AM, Ben Skeggs wrote:
> On Thu, May 17, 2012 at 10:30 AM, Ben Skeggs wrote:
>> Am Mittwoch, den 16.05.2012, 12:17 -0600 schrieb Tim Gardner:
>>> commit b99da31ed8521eb78d5d6930f3128f8ecdb75fae causes the backlight in
>>> my Dell XPS M1710 to stop working. Symptoms are dim displ
On Thu, May 17, 2012 at 10:41 AM, Dave Airlie wrote:
> On Wed, May 16, 2012 at 10:22 PM, wrote:
>> From: Jerome Glisse
>>
>> This try to identify the faulty user command stream that caused
>> lockup. If it finds one it create big blob that contains all
>> information needed to replay the faulty
On Wed, May 16, 2012 at 10:22 PM, wrote:
> From: Jerome Glisse
>
> This try to identify the faulty user command stream that caused
> lockup. If it finds one it create big blob that contains all
> information needed to replay the faulty command stream.
Can you state what exactly is going to end
https://bugzilla.kernel.org/show_bug.cgi?id=39832
--- Comment #21 from Rafa? Mi?ecki 2012-05-17 07:14:14
---
(In reply to comment #20)
> I can confirm that this bug still a problem Kernel Linux 3.2.0. I tried
> everything I found all forums. Simply doesnt work.
This bug(report) is only abo
On Thu, 17 May 2012 01:36:29 +0200
Guillaume Clément wrote:
>
> > Either way, if I add an empty "save" function, suspend works again (but at
> > the moment, resume still doesn't work, I'm still trying to work on that).
> >
> > If I just add a "if (connector->funcs->save)", this also fixes the c
On Thu, May 17, 2012 at 5:27 AM, Laurent Pinchart
wrote:
> Drivers for hardware without gamma support should not be forced to
> implement a no-op gamma set operation.
>
> Signed-off-by: Laurent Pinchart
> Cc: Rob Clark
Reviewed-by: Rob Clark
> ---
> ?drivers/gpu/drm/drm_crtc.c ? ? ? ? ?| ? ?5
On Thu, May 17, 2012 at 4:31 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> The main requirement I have for this interface is for scanning out
> using the USB gpu devices. Since these devices have to read the
> framebuffer on updates and linearly compress it, using kmaps
> is a major overhead for
Hi, Laurent.
> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
> Sent: Thursday, May 17, 2012 7:22 PM
> To: Inki Dae
> Cc: dri-devel@lists.freedesktop.org
> Subject: Re: [PATCH 2/4] drm: exynos: Remove dummy encoder get_crtc
> operation implementation
On Thu, May 17, 2012 at 1:32 PM, Rob Clark wrote:
> On Thu, May 17, 2012 at 4:31 AM, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> The main requirement I have for this interface is for scanning out
>> using the USB gpu devices. Since these devices have to read the
>> framebuffer on updates and l
On Thu, May 17, 2012 at 5:27 AM, Laurent Pinchart
wrote:
> Drivers for hardware without gamma support should not be forced to
> implement a no-op gamma set operation.
>
> Signed-off-by: Laurent Pinchart
> Cc: Rob Clark
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/drm_crtc.c | 5
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17/05/12 13:27, Steven Newbury wrote:
> On 15/05/12 18:42, Yinghai Lu wrote:
>> On Tue, May 15, 2012 at 2:54 AM, Steven Newbury
>> wrote:
>
>>> I'll get re-synced back up, and if they're still relevant give
>>> the patches a test. Is there an u
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 15/05/12 18:42, Yinghai Lu wrote:
> On Tue, May 15, 2012 at 2:54 AM, Steven Newbury
> wrote:
>
>> I'll get re-synced back up, and if they're still relevant give
>> the patches a test. Is there an updated branch I should work
>> from?
>
> git://g
On Thu, May 17, 2012 at 4:31 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> The main requirement I have for this interface is for scanning out
> using the USB gpu devices. Since these devices have to read the
> framebuffer on updates and linearly compress it, using kmaps
> is a major overhead for
https://bugs.freedesktop.org/show_bug.cgi?id=48747
--- Comment #10 from Jos van Wolput 2012-05-16
21:48:31 PDT ---
(In reply to comment #9)
> Commit: 11f056a3f0b87e86267efa8b5ac9d36a343c9dc1
> Author: Michel D?nzer
> Date: Wed May 16 17:45:17 2012 +0200
>
> r600g: Set tiling information for
Am 17.05.2012 09:09, schrieb Dan Carpenter:
> drm_core_ioremap() initializes ->handle. We already know
> "dev->agp_buffer_map" is a valid pointer.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/gpu/drm/savage/savage_bci.c
> b/drivers/gpu/drm/savage/savage_bci.c
> index cb1ee4e..6e
Hi Dave,
Fixed it. Please pull from
git://git.infradead.org/users/kmpark/linux-samsung exynos-drm-next again.
Please let me know if there is any problem and Sorry for inconvenience
caused.
Thanks,
Inki Dae
> -Original Message-
> From: Dave Airlie [mailto:airl...@gmail.com]
> Sent: Thurs
Drivers for hardware without gamma support should not be forced to
implement a no-op gamma set operation.
Signed-off-by: Laurent Pinchart
Cc: Rob Clark
---
drivers/gpu/drm/drm_crtc.c |5 +
drivers/gpu/drm/drm_fb_helper.c |3 +++
drivers/staging/omapdrm/omap_crtc.c |
The DRM mode config functions structure declared by drivers and pointed
to by the drm_mode_config funcs field is never modified. Make it a const
pointer.
Signed-off-by: Laurent Pinchart
Cc: Inki Dae
Cc: Alan Cox
Cc: Daniel Vetter
Cc: Ben Skeggs
Cc: Alex Deucher
Cc: Dave Airlie
Cc: Thomas He
The GEM vm operations structure is passed to the VM core that stores it
in a const field. There vm operations structures can thus be const in
DRM as well.
Signed-off-by: Laurent Pinchart
Cc: Inki Dae
Cc: Alan Cox
Cc: Daniel Vetter
Cc: Alex Deucher
Cc: Dave Airlie
Cc: Rob Clark
---
drivers/
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_crtc.c|2 +-
drivers/gpu/drm/drm_sysfs.c |8
include/drm/drmP.h| 10 +-
include/drm/drm_crtc.h| 21 +++--
include/drm/drm_crtc_helper.h | 21 +
5 fi
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_crtc.c| 12 ++--
drivers/gpu/drm/drm_crtc_helper.c |2 +-
drivers/gpu/drm/drm_edid_load.c |8
drivers/gpu/drm/drm_fb_helper.c |5 +
drivers/gpu/drm/drm_gem.c |2 +-
drivers/gpu/drm/d
A race condition exists in drm_vblank_cleanup() if the vblank disable
timer callback runs after freeing the memory that its callback function
tries to access. Fix this by deleting the timer synchronously.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_irq.c |2 +-
1 files changed, 1
Hello,
While studying the DRM core I came across a couple of issues or strange
constructs. Here are 6 patches that try to fix them.
Criticism is as usual welcome. Please bear with my lack of experience with the
DRM core :-)
Laurent Pinchart (6):
drm: Delete the vblank timer synchronously at cl
1 - 100 of 130 matches
Mail list logo
