[PATCH 2/2] drm/doc: Document the KMS property API

Hi Hans, Thanks for the review. On Saturday 22 June 2013 15:32:43 Hans Verkuil wrote: > Hi Laurent, > > Is this a hint to me that V4L2 should have a property API as well? :-) Honestly, not at all, but I'm of course willing to discuss the subject ;-) > Anyway, I found some typos below: Thank

[PATCH v2 2/2] drm/doc: Document the KMS property API

Signed-off-by: Laurent Pinchart Reviewed-by: Alex Deucher --- Documentation/DocBook/drm.tmpl | 143 + 1 file changed, 143 insertions(+) diff --git a/Documentation/DocBook/drm.tmpl

[PATCH v2 1/2] drm/doc: Remove outdated note about i915 driver not behaving properly

From: Laurent Pinchart The i915 driver has been fixed not to modify the mode argument of the encoder mode_fixup operation. Remove the related comment from the documentation. Signed-off-by: Laurent Pinchart Reviewed-by: Alex Deucher ---

[PATCH v2 0/2] Documentation improvements

Hello, Here are two patches that improve the DRM documentation by documenting the KMS property API, and removing an outdated note about the i915 driver. Changes since v1: - Fixed typos in patch 2/2 Laurent Pinchart (2): drm/doc: Remove outdated note about i915 driver not behaving properly

[PATCH 2/2] drm/doc: Document the KMS property API

Hi Laurent, Is this a hint to me that V4L2 should have a property API as well? :-) Anyway, I found some typos below: On Sat June 22 2013 15:00:27 Laurent Pinchart wrote: > Signed-off-by: Laurent Pinchart > --- > Documentation/DocBook/drm.tmpl |

Regression introduced by 90797e6d1ec0dfde6ba62a48b9ee3803887d6ed4 ("drm/i915: create compact dma scatter lists for gem objects") Was:Re: i915 mapping large (3MB) scatter list, hitting limits on certai

On Fri, Jun 21, 2013 at 10:03:43PM -0400, Konrad Rzeszutek Wilk wrote: > On Fri, Jun 21, 2013 at 03:28:28PM -0400, Konrad Rzeszutek Wilk wrote: > > Hey, > > CC-ing Imre, > > Imre, your patch 90797e6d1ec0dfde6ba62a48b9ee3803887d6ed4 > ("drm/i915: create compact dma scatter lists for gem objects")

[PATCH 2/2] drm/doc: Document the KMS property API

Signed-off-by: Laurent Pinchart --- Documentation/DocBook/drm.tmpl | 143 + 1 file changed, 143 insertions(+) diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index cea420d..9d4bb06

[PATCH 1/2] drm/doc: Remove outdated note about i915 driver not behaving properly

From: Laurent Pinchart The i915 driver has been fixed not to modify the mode argument of the encoder mode_fixup operation. Remove the related comment from the documentation. Signed-off-by: Laurent Pinchart --- Documentation/DocBook/drm.tmpl | 4 1 file

[PATCH 0/2] Documentation improvements

Hello, Here are two patches that improve the DRM documentation by documenting the KMS property API, and removing an outdated note about the i915 driver. Laurent Pinchart (2): drm/doc: Remove outdated note about i915 driver not behaving properly drm/doc: Document the KMS property API

[PATCH 2/2] drm: Convert drm class driver from legacy pm ops to dev_pm_ops

Convert drivers/gpu/drm class to use dev_pm_ops for power management and remove Legacy PM ops hooks. With this change, drm class registers suspend/resume callbacks via class->pm (dev_pm_ops) instead of Legacy class->suspend/resume. When __device_suspend() runs call-backs, it will find class->pm

[PATCH 1/2] power: add new interface to return pm_transition state

Add a new interface get_pm_transition() to return pm_transition state. This interface is intended to be used from dev_pm_ops class and type suspend interfaces that call legacy pm ops driver suspend interfaces. Legacy suspend pm_ops take pm_message_t as a parameter. e.g: drm_class_suspend() calls

[PATCH v2] drm: Improve manual IRQ installation documentation

Signed-off-by: Laurent Pinchart --- Documentation/DocBook/drm.tmpl | 118 - 1 file changed, 70 insertions(+), 48 deletions(-) Changes since v1: - Document manual IRQ registration diff --git

[PULL] drm-tegra-fixes

--- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130622/2640a62a/attachment.pgp>

'Timed out waiting for forcewake old ack to clear' and hangup on IvyBridge system

On Sat, Jun 22, 2013 at 12:16:46PM -0700, Jesse Barnes wrote: > On Fri, 21 Jun 2013 23:58:08 -0700 > Guenter Roeck wrote: > > > Hi all, > > > > after upgrading one of my servers to 3.8, then 3.9.7 and 3.10-rc6, I > > started to > > see lots of "Timed out waiting for forcewake old ack to clear"

[PATCH] drm: Improve manual IRQ installation documentation

; > drm_wait_vblank() function skips the irq_enabled check. > > > > > > > > Not quite. There's another check for dev->irq_enabled in the > > > > DRM_WAIT_ON() so it'll never actually block. > > > > > > Indeed. > > > > > > > Arguably this could be solved by making the DRM_WAIT_ON() condition > > > > drop the > > > > !dev->irq_enabled in case DRIVER_HAVE_IRQ isn't set. > > > > > > Or we could force drivers to set drm->irq_enabled, I'm fine with that as > > > well. > > > I can fix the documentation if that would be the preferred solution. > > > > Thinking about it some more, the latter seems more appropriate. Consider > > some driver that doesn't set DRIVER_HAVE_IRQ but also doesn't initialize > > interrupts manually. If so it'll cause DRM_IOCTL_WAIT_VBLANK to block > > indefinitely. > > > > On the other hand perhaps the check at the beginning of drm_wait_vblank > > should be improved. Maybe make it something like this: > > > > if (drm_core_check_feature(dev, DRIVER_HAVE_IRQ)) > > if (!drm_dev_to_irq(dev)) > > return -EINVAL; > > > > if (!dev->irq_enabled) > > return -EINVAL; > > I think the vblank subsystem is ripe for rework, and I have a few plans > for that. Would you mind sharing those plans so that maybe others can help out? > But till that happens I guess we could just roll forward with > whatever hacks we currently have ... So that means the above sounds like a reasonable interim solution? Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130622/0a0dc7ba/attachment.pgp>

[PATCH] drm: always provide debugfs function prototypes

e does here, but apart from that this patch looks good to me: Reviewed-by: Thierry Reding -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130622/d59c469a/attachment.pgp>

[Bug 65968] Massive memory corruption in Planetary Annihilation Alpha

are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130622/437a9e17/attachment.html>

'Timed out waiting for forcewake old ack to clear' and hangup on IvyBridge system

On Fri, 21 Jun 2013 23:58:08 -0700 Guenter Roeck wrote: > Hi all, > > after upgrading one of my servers to 3.8, then 3.9.7 and 3.10-rc6, I started > to > see lots of "Timed out waiting for forcewake old ack to clear" error messages, > including hang-ups especially if the system was highly

[Bug 65968] Massive memory corruption in Planetary Annihilation Alpha

are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130622/b2e216e2/attachment-0001.html>

[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

;>> access the buffer(buf1) as write, and data of the buffer(buf1) isn't >>>> needed to be shared*. They just need to use the buffer as *storage*. >>>> So All they want is to avoid stomping on the buffer in this case. >>>> >>> Sorry, but I don't see the point. If no one is interested in the data of >>> the buffer, why are you sharing it in the first place? >>> >> >> Just used as a storage. i.e., Task A fills the buffer with "AA" >> using CPU, And Task B fills the buffer with "BB" using DMA. They >> don't share data of the buffer, but they share *memory region* of the >> buffer. That would be very useful for the embedded systems with very >> small size system memory. > > Just so i understand. You want to share backing memory, you don't want > to share content ie you want to do memory management in userspace. > This sounds wrong on so many level (not even considering the security > implication). > > If Task A need memory and then can release it for Task B usage that > should be the role of kernel memory management which of course needs > synchronization btw A and B. But in no case this should be done using > dma-buf. dma-buf is for sharing content btw different devices not > sharing resources. > Just simply let's think of the case that a user process doesn't want for anyone, other CPU or DMA, to access a shared buffer while he is accessing the shared buffer. In this case, useful. Thanks, Inki Dae > > Also don't over complicate the vram case, just consider desktop gpu as > using system memory directly. They can do it and they do it. Migration > to vram is orthogonal to all this, it's an optimization so to speak. > > Cheers, > Jerome. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130622/8fe34092/attachment-0001.html>

[PATCH 0/2] Documentation improvements

On Sat, Jun 22, 2013 at 9:00 AM, Laurent Pinchart wrote: > Hello, > > Here are two patches that improve the DRM documentation by documenting the KMS > property API, and removing an outdated note about the i915 driver. > > Laurent Pinchart (2): >

[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

2013/6/21 Lucas Stach : > Hi Inki, > > please refrain from sending HTML Mails, it makes proper quoting without > messing up the layout everywhere pretty hard. > Sorry about that. I should have used text mode. > Am Freitag, den 21.06.2013, 20:01 +0900 schrieb Inki Dae: > [...] > >> Yeah,

[PATCH] drm: always provide debugfs function prototypes

It is generally considered bad style to enclose function prototypes in header files in #ifdef. This case illustrates why that is: The tegra host1x driver calls into the debugfs functions if CONFIG_DEBUG_FS is enabled, but that code is otherwise already discarded by the compiler, so leaving the

'Timed out waiting for forcewake old ack to clear' and hangup on IvyBridge system

Hi all, after upgrading one of my servers to 3.8, then 3.9.7 and 3.10-rc6, I started to see lots of "Timed out waiting for forcewake old ack to clear" error messages, including hang-ups especially if the system was highly loaded. With 3.5.24 everything was fine. After backing out commit

Re: [PATCH] drm: always provide debugfs function prototypes

On Sat, Jun 22, 2013 at 12:38:16AM +0200, Arnd Bergmann wrote: It is generally considered bad style to enclose function prototypes in header files in #ifdef. This case illustrates why that is: The tegra host1x driver calls into the debugfs functions if CONFIG_DEBUG_FS is enabled, but that code

Re: [PATCH] drm: Improve manual IRQ installation documentation

On Thu, Jun 20, 2013 at 04:55:03PM +0200, Daniel Vetter wrote: On Thu, Jun 20, 2013 at 01:00:36PM +0200, Thierry Reding wrote: On Thu, Jun 20, 2013 at 12:46:21PM +0200, Laurent Pinchart wrote: Hi Thierry, On Thursday 20 June 2013 12:40:26 Thierry Reding wrote: On Thu, Jun 20, 2013

Re: [PULL] drm-tegra-fixes

On Thu, Jun 20, 2013 at 11:07:11PM +0200, Thierry Reding wrote: On Fri, Jun 21, 2013 at 06:37:30AM +1000, Dave Airlie wrote: git://anongit.freedesktop.org/tegra/linux.git drm/fixes for you to fetch changes up to 2b15aa0fd466a4b2defdfd84c0b5168804b3eb33: gpu: host1x: Rework CPU

[PATCH v2] drm: Improve manual IRQ installation documentation

Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com --- Documentation/DocBook/drm.tmpl | 118 - 1 file changed, 70 insertions(+), 48 deletions(-) Changes since v1: - Document manual IRQ registration diff --git

[Bug 65968] Massive memory corruption in Planetary Annihilation Alpha

https://bugs.freedesktop.org/show_bug.cgi?id=65968 --- Comment #6 from Andreas Ringlstetter andreas.ringlstet...@gmail.com --- RADEON_DEBUG=noopt is not possible, the pixel shader programs are to big to be loaded without size optimizations. Hard limit of 512 instruction slots per pixel shader:

[PATCH 0/2] Documentation improvements

Hello, Here are two patches that improve the DRM documentation by documenting the KMS property API, and removing an outdated note about the i915 driver. Laurent Pinchart (2): drm/doc: Remove outdated note about i915 driver not behaving properly drm/doc: Document the KMS property API

[PATCH 1/2] drm/doc: Remove outdated note about i915 driver not behaving properly

From: Laurent Pinchart laurent.pinch...@ideasonboard.com The i915 driver has been fixed not to modify the mode argument of the encoder mode_fixup operation. Remove the related comment from the documentation. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com ---

[PATCH 2/2] drm/doc: Document the KMS property API

Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com --- Documentation/DocBook/drm.tmpl | 143 + 1 file changed, 143 insertions(+) diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index cea420d..9d4bb06

Re: [PATCH 2/2] drm/doc: Document the KMS property API

Hi Laurent, Is this a hint to me that V4L2 should have a property API as well? :-) Anyway, I found some typos below: On Sat June 22 2013 15:00:27 Laurent Pinchart wrote: Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com --- Documentation/DocBook/drm.tmpl | 143

[PATCH v2 0/2] Documentation improvements

Hello, Here are two patches that improve the DRM documentation by documenting the KMS property API, and removing an outdated note about the i915 driver. Changes since v1: - Fixed typos in patch 2/2 Laurent Pinchart (2): drm/doc: Remove outdated note about i915 driver not behaving properly

[PATCH v2 1/2] drm/doc: Remove outdated note about i915 driver not behaving properly

From: Laurent Pinchart laurent.pinch...@ideasonboard.com The i915 driver has been fixed not to modify the mode argument of the encoder mode_fixup operation. Remove the related comment from the documentation. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Reviewed-by: Alex

[PATCH v2 2/2] drm/doc: Document the KMS property API

Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com Reviewed-by: Alex Deucher alexander.deuc...@amd.com --- Documentation/DocBook/drm.tmpl | 143 + 1 file changed, 143 insertions(+) diff --git a/Documentation/DocBook/drm.tmpl

Re: [PATCH 2/2] drm/doc: Document the KMS property API

Hi Hans, Thanks for the review. On Saturday 22 June 2013 15:32:43 Hans Verkuil wrote: Hi Laurent, Is this a hint to me that V4L2 should have a property API as well? :-) Honestly, not at all, but I'm of course willing to discuss the subject ;-) Anyway, I found some typos below: Thank you.

Re: Regression introduced by 90797e6d1ec0dfde6ba62a48b9ee3803887d6ed4 (drm/i915: create compact dma scatter lists for gem objects) Was:Re: i915 mapping large (3MB) scatter list, hitting limits on ce

On Fri, Jun 21, 2013 at 10:03:43PM -0400, Konrad Rzeszutek Wilk wrote: On Fri, Jun 21, 2013 at 03:28:28PM -0400, Konrad Rzeszutek Wilk wrote: Hey, CC-ing Imre, Imre, your patch 90797e6d1ec0dfde6ba62a48b9ee3803887d6ed4 (drm/i915: create compact dma scatter lists for gem objects) is the

'Timed out waiting for forcewake old ack to clear' and hangup on IvyBridge system

Hi all, after upgrading one of my servers to 3.8, then 3.9.7 and 3.10-rc6, I started to see lots of Timed out waiting for forcewake old ack to clear error messages, including hang-ups especially if the system was highly loaded. With 3.5.24 everything was fine. After backing out commit 36ec8f877

Re: 'Timed out waiting for forcewake old ack to clear' and hangup on IvyBridge system

On Fri, 21 Jun 2013 23:58:08 -0700 Guenter Roeck li...@roeck-us.net wrote: Hi all, after upgrading one of my servers to 3.8, then 3.9.7 and 3.10-rc6, I started to see lots of Timed out waiting for forcewake old ack to clear error messages, including hang-ups especially if the system was

Re: [PATCH 1/2] power: add new interface to return pm_transition state

On Saturday, June 22, 2013 02:11:14 PM Shuah Khan wrote: Add a new interface get_pm_transition() to return pm_transition state. This interface is intended to be used from dev_pm_ops class and type suspend interfaces that call legacy pm ops driver suspend interfaces. Legacy suspend pm_ops take

[Bug 66064] New: ATI Mobility FireGL V5250 hardware incorrectly matched with RV530 dri settings in r_300.dri

https://bugs.freedesktop.org/show_bug.cgi?id=66064 Priority: medium Bug ID: 66064 Assignee: dri-devel@lists.freedesktop.org Summary: ATI Mobility FireGL V5250 hardware incorrectly matched with RV530 dri settings in r_300.dri

stereoscopic: 3D over standard 1080p using remote to switch into 3D mode.

Hello, I've successfully done a few tests using Chrome and WebGL to render two images side by side and having the TV compose the images into stereoscopic 3D. I don't know why there was a notion that one needed to send special HDMI commands. Well perhaps to reach full 1080p these commands might

[Bug 66067] New: Trine 2 color problems on Radeon HD 6770 (Juniper)

https://bugs.freedesktop.org/show_bug.cgi?id=66067 Priority: medium Bug ID: 66067 Assignee: dri-devel@lists.freedesktop.org Summary: Trine 2 color problems on Radeon HD 6770 (Juniper) Severity: normal Classification: Unclassified

[Bug 66067] Trine 2 color problems on Radeon HD 6770 (Juniper)

https://bugs.freedesktop.org/show_bug.cgi?id=66067 --- Comment #1 from Nicholas Miell nmi...@gmail.com --- Created attachment 81245 -- https://bugs.freedesktop.org/attachment.cgi?id=81245action=edit rendering with Catalyst -- You are receiving this mail because: You are the assignee for the

[Bug 66067] Trine 2 color problems on Radeon HD 6770 (Juniper)

https://bugs.freedesktop.org/show_bug.cgi?id=66067 Nicholas Miell nmi...@gmail.com changed: What|Removed |Added Attachment #81244|text/plain |image/png