[PATCH] drm/msm/dp: use flags argument of devm_gpiod_get to set direction

On Mon, Jun 15, 2015 at 5:00 PM, Uwe Kleine-König wrote: > On Tue, Jun 09, 2015 at 11:38:45AM +0200, Uwe Kleine-König wrote: >> Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions) >> which appeared in v3.17-rc1, the gpiod_get* functions take an additional >> parameter that

[Intel-gfx] [PATCH v2 00/10] Color Manager Implementation

+Susanta/Shashank How does this review from Daniel sound to you guys? I know you've ask for the Display team to review the latest design doc before you start the external communication and there's been some discussion below... Thanks. Annie Matheson Intel Corporation Phone: (503) 712-0586

[PATCH] drm/dp/mst: close deadlock in connector destruction.

On 15 June 2015 at 17:49, Daniel Vetter wrote: > On Mon, Jun 15, 2015 at 10:34:28AM +1000, Dave Airlie wrote: >> From: Dave Airlie >> >> I've only seen this once, and I failed to capture the >> lockdep backtrace, but I did some investigations. >> >> If we are calling into the MST layer from EDID

[Nouveau] [PATCH v2 2/2] drm/nouveau: add GEM_SET_TILING staging ioctl

On 06/15/2015 04:56 PM, Daniel Vetter wrote: > On Mon, Jun 15, 2015 at 04:09:29PM +0900, Alexandre Courbot wrote: >> From: Ari Hirvonen >> >> Add new NOUVEAU_GEM_SET_TILING ioctl to set correct tiling >> mode for imported dma-bufs. This ioctl is staging for now >> and enabled with the

[PATCH v2 3/3] drm/exynos: initialize VIDCON0 when fimd is disabled

Hi Joonyoung, 2015-06-12 Joonyoung Shim : > When the fimd is disabled by fimd_disable(), enabled overlay layers also > are disabled. If clocks for fimd are enabled by fimd_enable() on this > case, it can lead IOMMU page fault. The reason is that VIDCON0_ENVID and > VIDCON0_ENVID_F bits of

[PATCH v2 2/3] drm/exynos: remove chained calls to enable

Hi Joonyoung, 2015-06-12 Joonyoung Shim : > With atomic modesetting all the control for CRTC, Planes, Encoders and > Connectors should come from DRM core, so the driver is not allowed to > enable or disable planes from inside the crtc_enable()/disable() call. > > But it needs to disable planes

[PATCH v2 1/3] drm/exynos: remove to call mixer_wait_for_vblank

Hi Joonyoung, 2015-06-12 Joonyoung Shim : > The reason waiting vblank is to be power gated and disabled clocks after > dma operation is completed. The dma operation is stopped already before > be power gated and clocks are disabled when mixer is disabled by commit > 381be025ac1a6("drm/exynos:

[PATCH] drm/mgag200: Reject non-character-cell-aligned mode widths

Turns out 1366x768 does not in fact work on this hardware. Signed-off-by: Adam Jackson --- drivers/gpu/drm/mgag200/mgag200_mode.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c b/drivers/gpu/drm/mgag200/mgag200_mode.c index 6e84df9..ad4b901

[PATCH v2 2/2] drm/nouveau: add GEM_SET_TILING staging ioctl

On 06/15/2015 04:09 PM, Alexandre Courbot wrote: > From: Ari Hirvonen > > Add new NOUVEAU_GEM_SET_TILING ioctl to set correct tiling > mode for imported dma-bufs. This ioctl is staging for now > and enabled with the "staging_tiling" module option. Adding Thierry to the conversation since he

[PATCH v2 2/2] drm/nouveau: add GEM_SET_TILING staging ioctl

From: Ari Hirvonen Add new NOUVEAU_GEM_SET_TILING ioctl to set correct tiling mode for imported dma-bufs. This ioctl is staging for now and enabled with the "staging_tiling" module option. Signed-off-by: Ari Hirvonen [acourbot at nvidia.com: carry upstream, many fixes]

[PATCH v2 1/2] drm/nouveau: placeholders for staging ioctls

Reserve the 8 highest ioctls for "staging" features, i.e. ioctls that may change or be dropped altogether and that thus should not be given a definite number. This will allow us to experiment with experimental APIs for a while before setting them in stone. Staging ioctls are not expected to stay

[PATCH v2 0/2] drm/nouveau: option for staging ioctls and new GEM_SET_TILING ioctl

Second version of this patchset addressing Ben's comments and fixing a few extra things. This patchset proposes to introduce a "staging" module option to dynamically enable features (mostly ioctls) that are merged but may be refined before they are declared "stable". The second patch illustrates

[PATCH] drm/atomic: pass old crtc state to atomic_begin/flush.

On Mon, Jun 15, 2015 at 11:18:46AM +0200, Maarten Lankhorst wrote: > Op 15-06-15 om 11:13 schreef Daniel Vetter: > > On Mon, Jun 15, 2015 at 09:30:19AM +0200, Maarten Lankhorst wrote: > >> Op 15-06-15 om 09:10 schreef Daniel Vetter: > >>> On Fri, Jun 12, 2015 at 11:18:22AM +0200, Maarten Lankhorst

[PATCH v10 00/17] drm/exynos: atomic modesetting support

Hi Gustavo, On 2015년 06월 02일 00:04, Gustavo Padovan wrote: > From: Gustavo Padovan > > Hi, > > Here goes the full support for atomic modesetting on exynos. I've > split the patches in the various phases of atomic support. > > v2: fixes comments by Joonyoung > - remove unused var

[GIT PULL] omapdrm atomic modesetting for 4.2

ent was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150615/6fc39322/attachment.sig>

[Bug 90926] Unusable GPU

: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150615/dd852865/attachment.html>

[Bug 90926] Unusable GPU

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150615/c0fa3a6c/attachment.html>

[Bug 90926] Unusable GPU

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150615/0e456cd1/attachment.html>

[Intel-gfx] [BUG, bisect] Re: drm/i915: WARN_ON(dev_priv->mm.busy)

On Mon, 15 Jun 2015, Ville Syrjälä wrote: > On Mon, Jun 15, 2015 at 01:25:38AM -0700, Jeremiah Mahler wrote: >> Daniel, >> >> On Mon, Jun 15, 2015 at 08:57:47AM +0200, Daniel Vetter wrote: >> > Can you please retest with >> > >> > commit 0aedb1626566efd72b369c01992ee7413c82a0c5 >> > Author:

[PATCH v3] ARM: dts: fix the clock-frequency of rinato board's panel

On 15.06.2015 13:03, Hyungwon Hwang wrote: > From: Hyungwon Hwang > > After the commit abc0b1447d4974963548777a5ba4a4457c82c426 > ("drm: Perform basic sanity checks on probed modes"), proper > clock-frequency becomes mandatory for validating the mode of panel. > The display does not work if

[PATCH v3] ARM: dts: fix the clock-frequency of rinato board's panel

From: Hyungwon Hwang After the commit abc0b1447d4974963548777a5ba4a4457c82c426 ("drm: Perform basic sanity checks on probed modes"), proper clock-frequency becomes mandatory for validating the mode of panel. The display does not work if there is no mode validated. Also,

[Intel-gfx] [BUG, bisect] Re: drm/i915: WARN_ON(dev_priv->mm.busy)

On Mon, 15 Jun 2015, Ville Syrjälä wrote: > On Mon, Jun 15, 2015 at 01:25:38AM -0700, Jeremiah Mahler wrote: >> Daniel, >> >> On Mon, Jun 15, 2015 at 08:57:47AM +0200, Daniel Vetter wrote: >> > Can you please retest with >> > >> > commit 0aedb1626566efd72b369c01992ee7413c82a0c5 >> > Author:

[Intel-gfx] [BUG, bisect] Re: drm/i915: WARN_ON(dev_priv->mm.busy)

On Mon, Jun 15, 2015 at 01:25:38AM -0700, Jeremiah Mahler wrote: > Daniel, > > On Mon, Jun 15, 2015 at 08:57:47AM +0200, Daniel Vetter wrote: > > Can you please retest with > > > > commit 0aedb1626566efd72b369c01992ee7413c82a0c5 > > Author: Ville Syrjälä > > Date: Thu May 28 18:32:36 2015

[PATCH 00/21] On-demand device registration

Am 15.06.2015 um 10:58 schrieb Linus Walleij: > On Sat, Jun 13, 2015 at 8:27 PM, Alexander Holler > wrote: > >> And because you've said that "problem space is a bit convoluted" and I >> disagree, here's a summary from my point of view: >> >> 1. All the necessary information (dependencies between

[PATCH] drm/atomic: pass old crtc state to atomic_begin/flush.

Op 15-06-15 om 11:13 schreef Daniel Vetter: > On Mon, Jun 15, 2015 at 09:30:19AM +0200, Maarten Lankhorst wrote: >> Op 15-06-15 om 09:10 schreef Daniel Vetter: >>> On Fri, Jun 12, 2015 at 11:18:22AM +0200, Maarten Lankhorst wrote: In intel it's useful to keep track of some state changes with

[PATCH] drm/atomic: pass old crtc state to atomic_begin/flush.

On Mon, Jun 15, 2015 at 09:30:19AM +0200, Maarten Lankhorst wrote: > Op 15-06-15 om 09:10 schreef Daniel Vetter: > > On Fri, Jun 12, 2015 at 11:18:22AM +0200, Maarten Lankhorst wrote: > >> In intel it's useful to keep track of some state changes with old > >> crtc state vs new state, for example

[PATCH 00/21] On-demand device registration

On Sat, Jun 13, 2015 at 8:27 PM, Alexander Holler wrote: > And because you've said that "problem space is a bit convoluted" and I > disagree, here's a summary from my point of view: > > 1. All the necessary information (dependencies between drivers) already > exists at compile time. The set of

[Intel-gfx] [PATCH v2] drm/atomic: Handle vblank events in atomic ioctl correctly.

Op 15-06-15 om 08:22 schreef Daniel Vetter: > On Tue, Jun 02, 2015 at 09:00:46AM +0200, Maarten Lankhorst wrote: >> All users of async updates seem to clear clear crtc_state->event >> correctly, so move destroying vblank event to crtc_destroy_state. >> >> This is better than manually free'ing it

[PATCH] drm/dp/mst: close deadlock in connector destruction.

From: Dave Airlie I've only seen this once, and I failed to capture the lockdep backtrace, but I did some investigations. If we are calling into the MST layer from EDID probing, we have the mode_config mutex held, if during that EDID probing, the MST hub goes away, then we

[Nouveau] [PATCH v2 2/2] drm/nouveau: add GEM_SET_TILING staging ioctl

On Mon, Jun 15, 2015 at 04:09:29PM +0900, Alexandre Courbot wrote: > From: Ari Hirvonen > > Add new NOUVEAU_GEM_SET_TILING ioctl to set correct tiling > mode for imported dma-bufs. This ioctl is staging for now > and enabled with the "staging_tiling" module option. > > Signed-off-by: Ari

[PATCH] drm/dp/mst: close deadlock in connector destruction.

On Mon, Jun 15, 2015 at 10:34:28AM +1000, Dave Airlie wrote: > From: Dave Airlie > > I've only seen this once, and I failed to capture the > lockdep backtrace, but I did some investigations. > > If we are calling into the MST layer from EDID probing, > we have the mode_config mutex held, if

problem of drm to show fullscreen video

source size: 3200x1800, however, the frame was froze on screen, log is as attached. Anyone has clue? William -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150615/b5204007/attachment.html>

problem of drm to show fullscreen video

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150615/3a80b14a/attachment-0001.html> -- next part -- A non-text attachment was scrubbed... Name: messages.zip Type: application/x-zip-compressed Size: 481755 bytes Desc: messages.zip URL: <http://lists.freedesktop.org/archives/

[PATCH] drm/atomic: pass old crtc state to atomic_begin/flush.

Op 15-06-15 om 09:10 schreef Daniel Vetter: > On Fri, Jun 12, 2015 at 11:18:22AM +0200, Maarten Lankhorst wrote: >> In intel it's useful to keep track of some state changes with old >> crtc state vs new state, for example to disable initial planes or >> when a modeset's prevented during fastboot.

[Intel-gfx] [PATCH] drm: Turn off Legacy Context Functions

On Wed, Jun 10, 2015 at 09:05:14AM +0100, Peter Antoine wrote: > The context functions are not used by the i915 driver and should not > be used by modeset drivers. These driver functions contain several bugs > and security holes. This change makes these functions optional can be > turned on by a

linux-next: Tree for Jun 15 (amdgpu)

On 06/15/15 02:05, Michael Ellerman wrote: > Hi all, > > Changes since 20150612: > on x86_64: when CONFIG_DEBUG_FS is not enabled: drivers/built-in.o: In function `amdgpu_device_init': (.text+0x1dbd88): undefined reference to `amdgpu_debugfs_regs_init' drivers/built-in.o: In function

[PATCH] drm/atomic: pass old crtc state to atomic_begin/flush.

On Fri, Jun 12, 2015 at 11:18:22AM +0200, Maarten Lankhorst wrote: > In intel it's useful to keep track of some state changes with old > crtc state vs new state, for example to disable initial planes or > when a modeset's prevented during fastboot. > > Signed-off-by: Maarten Lankhorst Hm, thus

[Intel-gfx] [BUG, bisect] Re: drm/i915: WARN_ON(dev_priv->mm.busy)

Can you please retest with commit 0aedb1626566efd72b369c01992ee7413c82a0c5 Author: Ville Syrjälä Date: Thu May 28 18:32:36 2015 +0300 drm/i915: Don't skip request retirement if the active list is empty Thanks, Daniel On Sun, Jun 07, 2015 at 10:56:41PM -0700, Jeremiah Mahler wrote: >

[PATCH] drm/dp/mst: close deadlock in connector destruction.

On Mon, 15 Jun 2015, Dave Airlie wrote: > From: Dave Airlie > > I've only seen this once, and I failed to capture the > lockdep backtrace, but I did some investigations. > > If we are calling into the MST layer from EDID probing, > we have the mode_config mutex held, if during that EDID >

[Intel-gfx] [PATCH v2 00/10] Color Manager Implementation

On Tue, Jun 09, 2015 at 01:50:48PM +0100, Damien Lespiau wrote: > On Thu, Jun 04, 2015 at 07:12:31PM +0530, Kausal Malladi wrote: > > From: Kausal Malladi > > > > This patch set adds color manager implementation in drm/i915 layer. > > Color Manager is an extension in i915 driver to support color

[PATCH 01/25] drm: add generic lock-free queue implementation

On Thu, Jun 04, 2015 at 06:38:21PM +0800, Jammy Zhou wrote: > Signed-off-by: Jammy Zhou > Signed-off-by: Shaoyun Liu > Reviewed-by: Christian K?nig What exactly is this needed for? Is this really something that's useful in drm core (smells like yet another single purpose helper for just one

[Intel-gfx] [PATCH v2] drm/atomic: Handle vblank events in atomic ioctl correctly.

On Tue, Jun 02, 2015 at 09:00:46AM +0200, Maarten Lankhorst wrote: > All users of async updates seem to clear clear crtc_state->event > correctly, so move destroying vblank event to crtc_destroy_state. > > This is better than manually free'ing it in the atomic ioctl, since > this code seems to do

[PATCH] drm/nouveau: Use drm_vblank_on/off consistently

In commit 9cba5efab5a8145ae6c52ea273553f069c294482 Author: Mario Kleiner Date: Tue Jul 29 02:36:44 2014 +0200 drm/nouveau: Dis/Enable vblank irqs during suspend/resume drm_vblank_on/off calls where added around suspend/resume to make sure vblank stay doesn't go boom over that transition.

[PATCH] drm/cma: Fix 64-bit size_t build warnings

On Fri, Jun 05, 2015 at 01:24:30PM +0200, Thierry Reding wrote: > On Mon, May 04, 2015 at 04:16:19PM +0200, Geert Uytterhoeven wrote: > > From: Magnus Damm > > > > Fix warnings related to size_t when building for 64-bit architectures: > > > >

[Bug 90728] dvd playback with vlc and vdpau causes segmentation fault

? gnome-shell? Yes. Probably best if you can run gnome-shell from gdb from a remote shell. -- 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/20150615/9f1dc820/attachment.html>

[Bug 90728] dvd playback with vlc and vdpau causes segmentation fault

hen I am pretty clueless how to do it...Sorry...But if you give me some tips I'll do my best.. -- 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/20150615/452fe5bc/attachment.html>

[Bug 90728] dvd playback with vlc and vdpau causes segmentation fault

- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150615/64346e83/attachment.html>

[Intel-gfx] [BUG, bisect] Re: drm/i915: WARN_ON(dev_priv->mm.busy)

Daniel, On Mon, Jun 15, 2015 at 08:57:47AM +0200, Daniel Vetter wrote: > Can you please retest with > > commit 0aedb1626566efd72b369c01992ee7413c82a0c5 > Author: Ville Syrjälä > Date: Thu May 28 18:32:36 2015 +0300 > > drm/i915: Don't skip request retirement if the active list is empty

[Bug 90926] Unusable GPU

HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150615/2a4934d6/attachment.html>