[PATCH 3/4] arm64: Juno: Add HDLCD support to the Juno boards.

On Wed, Aug 05, 2015 at 08:03:12PM +0100, Liviu Dudau wrote: > I have to confess that I am not entirely up to speed with the TDA19988 > situation at the moment. Andrew Jackson was dealing with that and > working with Jean to get that in the upstream, but his contract has > ended and he has moved

[Bug 91302] radeon.audio=1 causes issues with 7950

r the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150805/4e3fca23/attachment.html>

[Bug 91302] radeon.audio=1 causes issues with 7950

r the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150805/558af61d/attachment.html>

[Bug 91302] radeon.audio=1 causes issues with 7950

--- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150805/46b01c12/attachment.html>

[Bug 102351] Radeon R9 270: Flickering Screen (Dual Monitor setup)

https://bugzilla.kernel.org/show_bug.cgi?id=102351 beta992 at gmail.com changed: What|Removed |Added Kernel Version|Linux 4.2RC5|Linux desktop1

[Bug 102351] Radeon R9 270: Flickering Screen (Dual Monitor setup)

https://bugzilla.kernel.org/show_bug.cgi?id=102351 --- Comment #3 from beta992 at gmail.com --- Created attachment 184491 --> https://bugzilla.kernel.org/attachment.cgi?id=184491=edit xorg log -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 102351] Radeon R9 270: Flickering Screen (Dual Monitor setup)

https://bugzilla.kernel.org/show_bug.cgi?id=102351 --- Comment #2 from beta992 at gmail.com --- Created attachment 184481 --> https://bugzilla.kernel.org/attachment.cgi?id=184481=edit dmesg dmesg output -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 102351] Radeon R9 270: Flickering Screen (Dual Monitor setup)

https://bugzilla.kernel.org/show_bug.cgi?id=102351 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1

[Bug 102351] New: Radeon R9 270: Flickering Screen (Dual Monitor setup)

https://bugzilla.kernel.org/show_bug.cgi?id=102351 Bug ID: 102351 Summary: Radeon R9 270: Flickering Screen (Dual Monitor setup) Product: Drivers Version: 2.5 Kernel Version: Linux 4.2RC5 Hardware: All OS: Linux

[PATCH v2 09/11] drm/exynos: remove exynos_drm_create_enc_conn()

From: Gustavo Padovan This functions was just hiding the encoder and connector creation in a way that was less clean than if we get rid of it. For example, exynos_encoder ops had .create_connector() defined only because we were handing off the encoder and

[PATCH v2 08/11] drm/exynos: remove exynos_encoder's .commit() op

From: Gustavo Padovan .commit() is not used anymore, Exynos encoders now follow the .enable()/.disable() semantics from drm atomic core, so remove this callback. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 --

[PATCH v2 07/11] drm/exynos: remove extra call to exynos_dp_commit()

From: Gustavo Padovan exynos_dp_commit() was getting called twice by exynos encoder core, once inside the .enable() call and another time by .commit() itself. The remove of the second call caused the wake of a bug, the operations orders inside exynos_dp_commit

[PATCH v2 06/11] drm/exynos: remove extra call to hdmi_commit()

From: Gustavo Padovan hdmi_commit() was getting called twice by exynos encoder core, once inside the .enable() call and another time by .commit() itself. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_hdmi.c | 13 + 1 file

[PATCH v2 05/11] drm/exynos: remove struct exynos_drm_display

From: Gustavo Padovan This struct was just representing encoder information, it was a member of struct exynos_drm_encoder, so any code trying to access encoder data would have to go through the encoder struct, get the display struct and then get the data it want.

[PATCH v2 04/11] drm/exynos: simplify calculation of possible CRTCs

From: Gustavo Padovan All CRTCs can only be LCD, HDMI or VIDI, so basically all CRTCs will be a possible CRTCs. This patch removes an extra function with switch that was only checking if the CRTC type was one of those three above. Signed-off-by: Gustavo Padovan

[PATCH v2 03/11] drm/exynos: remove unused .remove() and .check_mode() ops from display

From: Gustavo Padovan These two display_ops are not used anywhere, remove them. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_drm_drv.h | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h

[PATCH v2 02/11] drm/exynos: remove wrappers for phy_power_{on,off}

From: Gustavo Padovan phy_power_on() and phy_power_off() already checks for NULL pointer. This patch removes the wrappers exynos_dp_phy_init() and exynos_dp_phy_exit() since the only think they were doing was a check for NULL phy. Signed-off-by: Gustavo Padovan

[PATCH v2 01/11] drm/exynos: split display's .dpms() into .enable() and .disable()

From: Gustavo Padovan The DRM Core doesn't have a dpms() operation anymore, everything now is enable() or disable(). Signed-off-by: Gustavo Padovan --- v2: set dp->dpms_mode after enable/disable --- drivers/gpu/drm/exynos/exynos_dp_core.c | 34

[PATCH v2 00/11] drm/exynos: remove exynos_drm_display and exynos_drm_encoder

From: Gustavo Padovan Hi, This patchset is another important step in the exynos clean up, it removes two exynos internal structs in favor of wider use of struct drm_encoder. Structs exynos_drm_display and exynos_drm_encoder were doing exactly what struct

[PATCH] drm/atomic: Call ww_acquire_done after check phase is complete

Op 05-08-15 om 17:03 schreef Daniel Vetter: > On Wed, Aug 5, 2015 at 4:57 PM, Maarten Lankhorst > wrote: >> Op 05-08-15 om 15:08 schreef Daniel Vetter: >>> We want to make sure that no one tries to acquire more locks and >>> states, and ww mutexes provide debug facilities for that. So use them.

[PATCH 3/4] arm64: Juno: Add HDLCD support to the Juno boards.

On Wed, Aug 05, 2015 at 06:53:03PM +0100, Russell King - ARM Linux wrote: > On Wed, Aug 05, 2015 at 03:28:11PM +0100, Liviu Dudau wrote: > > + hdmi-transmitter at 71 { > > compatible = "nxp,tda998x"; > > reg = <0x71>; > > + port {

[PATCH 3/3] drm/i915: Use CPU mapping for userspace dma-buf mmap()

Userspace is the one in charge of flush CPU by wrapping mmap with begin{,end}_cpu_access. v2: Remove LLC check cause we have dma-buf sync providers now. Also, fix return before transferring ownership when mmap fails. Signed-off-by: Tiago Vignatti --- drivers/gpu/drm/i915/i915_gem_dmabuf.c | 18

[PATCH 2/3] dma-buf: Add ioctls to allow userspace to flush

From: Daniel Vetter FIXME: Update kerneldoc for begin/end to make it clear that those are for mmap too. Open: Do we need a special indication that the begin/end is from userspace mmap and not from kernel mmap? There's also the question already about kernel internal

[PATCH 1/3] drm: prime: Honour O_RDWR during prime-handle-to-fd

From: Daniel Thompson Currently DRM_IOCTL_PRIME_HANDLE_TO_FD rejects all flags except (DRM|O)_CLOEXEC making it difficult (maybe impossible) for userspace to mmap() the resulting dma-buf even when this is supported by the DRM driver. It is trivial to relax the

[PATCH v2 0/3] mmap on the dma-buf directly

Hi, I've tested these patches (in drm-intel-nightly, but also in CrOS kernel v3.14) and they seem just enough for what we want to do: the idea is to create a GEM bo in one process and pass the prime handle of the it to another process, which in turn uses the handle only to map and write. This

[PATCH 3/4] arm64: Juno: Add HDLCD support to the Juno boards.

On Wed, Aug 05, 2015 at 03:28:11PM +0100, Liviu Dudau wrote: > + hdmi-transmitter at 71 { > compatible = "nxp,tda998x"; > reg = <0x71>; > + port { > + tda998x_1_input: endpoint at 0 { > +

[PATCH v2] drm/i2c: tda998x: Fix bad checksum of the HDMI AVI infoframe

On Wed, Aug 05, 2015 at 12:01:53AM +0100, Russell King - ARM Linux wrote: > On Tue, Aug 04, 2015 at 08:05:57AM +0200, Jean-Francois Moine wrote: > > On Tue, 28 Jul 2015 15:59:17 +0200 > > Jean-Francois Moine wrote: > > > > > Using hdmi_avi_infoframe_pack() to create the AVI infoframe calculates

[Bug 101391] Lockup after resume (kernel BUG at include/drm/drm_mm.h:145!)

https://bugzilla.kernel.org/show_bug.cgi?id=101391 --- Comment #3 from Michael Long --- Sorry for the delay, I tried a bisect: git bisect start 'v4.0..v4.1' 'drivers/gpu/drm' # good: [39a8804455fb23f09157341d3ba7db6d7ae6ee76] Linux 4.0 git bisect good 39a8804455fb23f09157341d3ba7db6d7ae6ee76 #

[Intel-gfx] [PATCH 1/2] drm/i915: Use CPU mapping for userspace dma-buf mmap()

On 08/05/2015 04:08 AM, Daniel Vetter wrote: > On Tue, Aug 04, 2015 at 06:30:25PM -0300, Tiago Vignatti wrote: > Nah they don't have to be equal since the problem isn't that nothing goes > out to memory where the display can see it, but usually only parts of it. > I.e. you need to change your test

[PATCH] drm/atomic: Call ww_acquire_done after check phase is complete

On Wed, Aug 5, 2015 at 4:57 PM, Maarten Lankhorst wrote: > > Op 05-08-15 om 15:08 schreef Daniel Vetter: >> We want to make sure that no one tries to acquire more locks and >> states, and ww mutexes provide debug facilities for that. So use them. >> >> Cc: Rob Clark >> Cc: Maarten Lankhorst >>

[PATCH] drm/atomic: Call ww_acquire_done after check phase is complete

Hey, Op 05-08-15 om 15:08 schreef Daniel Vetter: > We want to make sure that no one tries to acquire more locks and > states, and ww mutexes provide debug facilities for that. So use them. > > Cc: Rob Clark > Cc: Maarten Lankhorst > Signed-off-by: Daniel Vetter > --- >

[PATCH] drm/i915: Read WM before sanitize_encoder/crtc calls

If we shut down the crtc we might run into WM consistency checks which fail because we haven't yet read out the WM state. So do that before we sanitized the state. This fixes a WARNING in the ilk wm code which assumes that level 0 WM are always enabled in it's internal tracking. But since we

[pull] amdgpu drm-fixes-4.2

Hi Linus, Dave is on vacation at the moment, so please pull these fixes directly. Just a few amdgpu fixes to make sure we report the proper firmware information and number of render buffers to userspace and a typo in a debugging function. The following changes since commit

[PATCH] drm/msm/mdp: Clear pending interrupt status before enable interrupt

Pending interrupt status needs to be cleared before enable the interrupt. Otherwise it's possible to get a pending interrupt instead of an incoming interrupt. Signed-off-by: Jilai Wang --- drivers/gpu/drm/msm/mdp/mdp4/mdp4_irq.c | 10 +++--- drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h | 3 ++-

[PATCH 4/4] MAINTAINERS: Add Liviu Dudau as maintainer for ARM HDLCD driver.

Update MAINTAINERS file for HDLCD driver. Cc: Andrew Morton Cc: Arnd Bergmann Cc: Mauro Carvalho Chehab Cc: Greg KH Cc: Joe Perches Cc: Jiri Slaby Signed-off-by: Liviu Dudau --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index

[PATCH 3/4] arm64: Juno: Add HDLCD support to the Juno boards.

ARM's Juno board has two HDLCD controllers, each linked to an NXP TDA19988 HDMI transmitter that provides output encoding. Add them to the device tree. Signed-off-by: Liviu Dudau --- arch/arm64/boot/dts/arm/juno-base.dtsi | 70 +- 1 file changed, 68

[PATCH 2/4] drm: Add support for ARM's HDLCD controller.

The HDLCD controller is a display controller that supports resolutions up to 4096x4096 pixels. It is present on various development boards produced by ARM Ltd and emulated by the latest Fast Models from the company. Cc: David Airlie Cc: Robin Murphy Signed-off-by: Liviu Dudau ---

[PATCH 1/4] drm: arm: Add DT bindings documentation for HDLCD driver.

Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Signed-off-by: Liviu Dudau --- .../devicetree/bindings/drm/arm/arm,hdlcd.txt | 74 ++ 1 file changed, 74 insertions(+) create

[PATCH 0/4] drm: Add support for the ARM HDLCD display controller

This series adds support for ARM's HDLCD display controller found in Juno and ARM TC2 Coretile. The HDLCD outputs an RGB stream that feeds into a single digital encoder (DVI or HDMI). This series depends on Sudeep Holla's series that introduces support for SCPI[1] on Juno. Only the Juno

[PATCH 7/7] drm/cirrus: add DRIVER_ATOMIC to .driver_features

From: Zhao Junwang Since driver is now fully atomic, we should add DRIVER_ATOMIC to .driver_features Cc: Daniel Vetter Cc: Gerd Hoffmann Cc: Matthew Garrett Cc: Dave Airlie Signed-off-by: Zhao Junwang --- drivers/gpu/drm/cirrus/cirrus_drv.c |2 +- 1 file changed, 1

[PATCH 6/7] drm/cirrus: atomic dpms support

From: Zhao Junwang Run dpms operations through the atomic interfaces. This basically removes the .dpms() callback from encoders and crtcs and use .disable and .enable to turn the crtc on and off. use drm_atomic_helper_connector_dpms for connector Cc: Daniel Vetter Cc: Gerd

[PATCH 5/7] drm/cirrus: phase 3: use atomic .set_config helper

From: Zhao Junwang Now that phase 1 and phase 2 are completed, switch .set_config helper to use the atomic one. -stop looking legacy crtc->primary->fb, instead we should use crtc->primary->state->fb .prepare() calls are no more needed, remove them .mode_set() and

[PATCH 4/7] drm/cirrus: add return 0 to make sure if (bo->pin_count) early_exit

From: Zhao Junwang when the first modeset calls prepare_fb, bo->pin_count change from 0 to 1, then the second modeset with the same fb, that should set bo->pin_count to 2, and then when cleanup_fb was called, bo->pin_count should be 2 to 1. But in the cirrus_bo_pin, it will

[PATCH 3/7] drm/cirrus: phase 3: atomic updates of planes

From: Zhao Junwang Now that phase 1 and 2 are complete we can switch the update/disable_plane callbacks to their atomic version Cc: Daniel Vetter Cc: Gerd Hoffmann Cc: Matthew Garrett Cc: Dave Airlie Signed-off-by: Zhao Junwang --- drivers/gpu/drm/cirrus/cirrus_main.c |

[PATCH 2/7] drm/cirrus: phase 2: wire up state reset, duplicate and destroy

From: Zhao Junwang Set CRTC, planes and connectors to use the default implementations from the atomic helper library. Cc: Daniel Vetter Cc: Gerd Hoffmann Cc: Matthew Garrett Cc: Dave Airlie Signed-off-by: Zhao Junwang --- drivers/gpu/drm/cirrus/cirrus_mode.c | 12

[PATCH 1/7] drm/cirrus: phase 1 - use the transitional helpers

From: Zhao Junwang -register driver's own primary plane -use drm_crtc_init_with_planes instead drm_crtc_init -the new atomic_infrastructure needs ->mode_set_nofb callback Cc: Daniel Vetter Cc: Gerd Hoffmann Cc: Matthew Garrett Cc: Dave Airlie Signed-off-by: Zhao Junwang

[PATCH 0/7] drm/cirrus: convert cirrus to atomic mode-setting

From: Zhao Junwang This patch series aim to convert DRM_CIRRUS to atomic mode-setting. This mostly reference my previous patch series on DRM_BOCHS and Gustavo Padovan;s patch series on drm/exynos. Zhao Junwang (7): drm/cirrus: phase 1 - use the transitional helpers

[PATCH 7/7] drm/cirrus: add DRIVER_ATOMIC to .driver_features

MODESET | DRIVER_GEM, + .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC, .load = cirrus_driver_load, .unload = cirrus_driver_unload, .set_busid = drm_pci_set_busid, -- 1.7.10.4 -- next part -- An HTML attachment was scru

[PATCH 7/7] drm/cirrus: add DRIVER_ATOMIC to .driver_features

From: Zhao Junwang Since driver is now fully atomic, we should add DRIVER_ATOMIC to .driver_features Cc: Daniel Vetter Cc: Gerd Hoffmann Cc: Matthew Garrett Cc: Dave Airlie Cc: Zhao Junwang Signed-off-by: Zhao Junwang --- drivers/gpu/drm/cirrus/cirrus_drv.c |2 +-

[PATCH] drm/atomic: Call ww_acquire_done after check phase is complete

We want to make sure that no one tries to acquire more locks and states, and ww mutexes provide debug facilities for that. So use them. Cc: Rob Clark Cc: Maarten Lankhorst Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_atomic.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

[Bug 91522] Tonga display lock on agd5f drm-next-4.3-wip since drm/amdgpu: fix syncing to VM updates

org/archives/dri-devel/attachments/20150805/4312d6bc/attachment.html>

[RFC 05/21] drm/omap: Remove FB_KMS_HELPER and FB related config options

On 08/01/2015 03:32 PM, Laurent Pinchart wrote: > Hi Archit, > > Thank you for the patch. > > On Monday 13 July 2015 12:13:52 Archit Taneja wrote: >> Remove FB_* config options since the driver doesn't call any fbdev >> functions directly. >> >> Remove FB_KMS_HELPER as this would now be selected

[PATCH v3] drm: Add top level Kconfig option for DRM fbdev emulation

Legacy fbdev emulation support via DRM is achieved through KMS FB helpers. Most modesetting drivers enable provide fbdev emulation by default by selecting KMS FB helpers. A few provide a separate Kconfig option for the user to enable or disbale fbdev emulation. Enabling fbdev emulation is finally

[PULL] drm-amdkfd-next-fixes

On Wed, Aug 05, 2015 at 10:49:57AM +0300, Oded Gabbay wrote: > On Wed, Aug 5, 2015 at 10:48 AM, Daniel Vetter wrote: > > Forwarding -fixes pull to Linus since Dave is on vacation for 2 weeks. > > -Daniel > > > > Daniel, > This is for 4.3 merge window... > This is not for 4.2-rcX > I don't think

[PULL] drm-amdkfd-next-fixes

On Wed, Aug 5, 2015 at 10:48 AM, Daniel Vetter wrote: > Forwarding -fixes pull to Linus since Dave is on vacation for 2 weeks. > -Daniel > Daniel, This is for 4.3 merge window... This is not for 4.2-rcX I don't think we need to forward this to Linus. Oded

[PATCH 11/11] drm/exynos: remove struct exynos_drm_encoder layer

2015-08-05 Inki Dae : Hi Inki, > On 2015년 08월 04일 23:47, Gustavo Padovan wrote: > > Hi Inki, > > > > 2015-08-04 Inki Dae : > > > >> On 2015년 08월 04일 04:09, Gustavo Padovan wrote: > >>> From: Gustavo Padovan > >>> > >>> struct exynos_drm_encoder was justing wrapping struct

[PATCH v3 0/2] Add display timing for Okaya RS800480T-7X0

Hi all, On Wed, Jun 10, 2015 at 6:44 PM, Gary Bisson wrote: > Hi all, > > This patch is the follow-up of a request from Philipp to add the Okaya display > to the simple panel driver. > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/346657.html > > v2: > - split into 2 patches,

[PATCH 11/11] drm/exynos: remove struct exynos_drm_encoder layer

On 2015년 08월 04일 23:47, Gustavo Padovan wrote: > Hi Inki, > > 2015-08-04 Inki Dae : > >> On 2015년 08월 04일 04:09, Gustavo Padovan wrote: >>> From: Gustavo Padovan >>> >>> struct exynos_drm_encoder was justing wrapping struct drm_encoder, it had >>> only a drm_encoder member and the

[PULL] drm-amdkfd-next-fixes

Hi Dave, Two small bug fixes for the code you pulled for 4.3: - Used a SHIFT define instead of a MASK define to check if a bit is turned on when destroying hqd. Luckily, this is in gfx7 interface file with amdgpu, which was used only for bring-up purposes of amdgpu, so no real effect on

[PULL] drm-amdkfd-next-fixes

Forwarding -fixes pull to Linus since Dave is on vacation for 2 weeks. -Daniel On Wed, Aug 05, 2015 at 10:05:00AM +0300, Oded Gabbay wrote: > Hi Dave, > > Two small bug fixes for the code you pulled for 4.3: > > - Used a SHIFT define instead of a MASK define to check if a bit is turned on >

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

ialization for ‘omap_crtc_helper_funcs.atomic_flush’) [-Werror] Tomi -- next part -- A non-text attachment 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/20150805/60ee84d1/attachment.sig>

[Intel-gfx] [PATCH 1/2] drm/i915: Use CPU mapping for userspace dma-buf mmap()

On Tue, Aug 04, 2015 at 06:30:25PM -0300, Tiago Vignatti wrote: > On 07/31/2015 06:02 PM, Chris Wilson wrote: > > > >The first problem is that llc does not guarrantee that the buffer is > >cache coherent with all aspects of the GPU. For scanout and similar > >writes need to be WC. > > > >if

[Bug 65963] screen goes blank, Linux hangs - Radeon 7870, Gallium, Glamor

for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150805/6e349d9b/attachment.html>

[Bug 89699] Regression in 10.5.1 causes flickering/artifacting in a particular video game

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150805/08a621e2/attachment.html>

[Bug 89699] Regression in 10.5.1 causes flickering/artifacting in a particular video game

) -- 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/20150805/066270dc/attachment.html>

[PATCH v2] drm/i2c: tda998x: Fix bad checksum of the HDMI AVI infoframe

On Tue, Aug 04, 2015 at 08:05:57AM +0200, Jean-Francois Moine wrote: > On Tue, 28 Jul 2015 15:59:17 +0200 > Jean-Francois Moine wrote: > > > Using hdmi_avi_infoframe_pack() to create the AVI infoframe calculates > > the checksum of the frame and breaks the second calculation which is > > done in