[RFC][PATCH 3/4] drm/bridge: adv7511: Enable the audio data and clock pads on adv7533

From: Srinivas Kandagatla This patch enables the Audio Data and Clock pads to the adv7533 bridge. Without this patch audio can not be played. Cc: David Airlie Cc: Archit Taneja Cc: Laurent Pinchart Cc: Wolfram Sang Cc:

[RFC][PATCH 2/4] drm/bridge: adv7511: Add Audio support.

This patch adds support to Audio for both adv7511 and adv7533 bridge chips. This patch was originally from [1] by Lars-Peter Clausen and was adapted by Archit Taneja and Srinivas Kandagatla . Then I heavily reworked it to use the hdmi-codec driver. So credit to them, but blame to me. [1]

[RFC][PATCH 1/4] drm/bridge: adv7511: Move the common data structures to header file

From: Archit Taneja This patch moves the adv7511 data structure to header file so that the audio driver file could use it. Cc: David Airlie Cc: Archit Taneja Cc: Laurent Pinchart Cc: Wolfram Sang Cc: Srinivas Kandagatla Cc:

[RFC][PATCH 0/4] Audio support for adv7511 hdmi bridge

This is an initial swing at getting the adv7511 hdmi bridge audio support reviewed. I've taken the core audio work done by Lars-Peter Clausen, and adapted by Srinivas Kandagatla and Archit Taneja, and tried to rework it to use the hdmi-codec sound driver. This patchset, along with the i2s driver

[PATCH v4 5/5] drm: simpledrm: honour remove_conflicting_framebuffers()

There is currently no non-fbdev mechanism in place to kick out simpledrm when the real hw-driver is probed. As a stop gap until that is in place, honour remove_conflicting_framebuffers() and delete the simple-framebuffer platform device when it's called. Signed-off-by: Noralf Trønnes ---

[PATCH v4 4/5] drm: simpledrm: add fbdev fallback support

Create a simple fbdev device during SimpleDRM setup so legacy user-space and fbcon can use it. Original work by David Herrmann. Cc: dh.herrmann at gmail.com Signed-off-by: Noralf Trønnes --- Changes from version 3: - Remove #ifdef CONFIG_DRM_FBDEV_EMULATION - Use

[PATCH v4 3/5] drm: add SimpleDRM driver

The SimpleDRM driver binds to simple-framebuffer devices and provides a DRM/KMS API. It provides only a single CRTC+encoder+connector combination plus one initial mode. Userspace can create dumb-buffers which can be blit into the real framebuffer similar to UDL. No access to the real framebuffer

[PATCH v4 2/5] drm/fb-helper: Add drm_fb_helper_set_suspend_lock()

This adds a function that also takes the console lock before calling fb_set_suspend() in contrast to drm_fb_helper_set_suspend() which is a plain wrapper around fb_set_suspend(). Resume is run asynchronously using a worker if the console lock is already taken. This is modelled after the i915

[PATCH v4 1/5] of: Add EXPORT_SYMBOL for of_chosen

Export of_chosen so drivers built as modules can get access to it. The simpledrm driver will use this and is compatible with simple-framebuffer which is a subnode of /chosen. Signed-off-by: Noralf Trønnes --- drivers/of/base.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH v4 0/5] drm: add SimpleDRM driver

This patchset adds the simpledrm driver by David Herrmann based on a patchset[1] from 2014. That patchset also included patches for kicking out simpledrm by real drivers. I have stayed away from that since it involves another subsystem and I would probably be unable to answer any questions about

[PATCH] Re: Mullins support in xf86-video-amdgpu

On 08/22/2016 08:27 PM, Michel Dänzer wrote: > On 23/08/16 10:18 AM, Reid Hekman wrote: >> >> I was encouraged by a commit I saw today to add Sea Islands PCI ids to >> xf86-video-amdgpu. However I did not see MULLINS included. Are there >> other showstoppers preventing inclusion? > > I assume

[PATCH] drm/gma500: dont expose bytes from kernel stack

Hi Heinrich, [auto build test ERROR on drm/drm-next] [also build test ERROR on v4.8-rc3 next-20160822] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for convenience) to rec

[urgent] drm/fb-helper: Fix the dummy remove_conflicting_framebuffers

We always need to remove conflicting framebuffers if any other fb driver is enabled, and not just if we are setting up an fbdev ourselves. Unfortunately remove_conflicting_framebuffers() was incorrectly stubbed out if !fbdev rather than !fb leading to major memory corruption (and corrupt

[PATCH v2 2/2] Documentation/sphinx: link dma-buf rsts

Include dma-buf sphinx documentation into top level index. Signed-off-by: Sumit Semwal --- Documentation/index.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/index.rst b/Documentation/index.rst index e0fc72963e87..8d05070122c2 100644 --- a/Documentation/index.rst +++

[PATCH v2 1/2] Documentation: move dma-buf documentation to rst

Branch out dma-buf related documentation into its own rst file to allow adding it to the sphinx documentation generated. While at it, move dma-buf-sharing.txt into rst as the dma-buf guide too; adjust MAINTAINERS accordingly. v2: - Removed authorship as suggested by Jani, - Address review

[PATCH v2 0/2] doc: dma-buf: sphinx conversion

Convert dma-buf documentation over to sphinx. While at that, convert dma-buf-sharing.txt as well, and make it the dma-buf API guide. There is no content change yet; only format conversion and creation of some hyperlinks. v2: Address review comments from Jonathan Corbet and Markus Heiser. Sumit

[PATCH 1/1] drm/gma500: dont expose stack, mrst_lvds_find_best_pll

Hi Heinrich, [auto build test ERROR on drm/drm-next] [also build test ERROR on v4.8-rc3 next-20160822] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for convenience) to rec

Mullins support in xf86-video-amdgpu

attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160822/21857c35/attachment.html>

[RFC] Using C99 stdint vs kernel __uX types in kernel drmUAPI (was Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from ")

chment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160822/81caa154/attachment.html>

[RFC] Using C99 stdint vs kernel __uX types in kernel drmUAPI (was Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from ")

On Mon, Aug 22, 2016 at 04:05:21PM +0100, Emil Velikov wrote: > On 22 August 2016 at 15:38, Daniel Vetter wrote: > > On Mon, Aug 22, 2016 at 12:38 PM, Rob Clark wrote: > >>> That said, _note_ that some applications are built with -C89 -pedantic > >>> [1] which means that using stdint.h may or

[RFC 0/2] New feature: Framebuffer processors

In STM SoC we have hardware block doing scaling/colorspace conversion, we have decide to use v4l2 mem2mem API for it: https://linuxtv.org/downloads/v4l-dvb-apis/selection-api.html the code is here:

[RFC 0/2] New feature: Framebuffer processors

On Mon, Aug 22, 2016 at 11:59:24AM +0200, Christian König wrote: > Am 22.08.2016 um 11:44 schrieb Marek Szyprowski: > > Dear all, > > > > This is the initial proposal for extending DRM API with generic support for > > hardware modules, which can be used for processing image data from the one > >

[PATCH v3 3/3] drm/imx: Add active plane reconfiguration support

On Mon, Aug 22, 2016 at 04:23:36PM +0800, Ying Liu wrote: > On Mon, Aug 22, 2016 at 3:53 PM, Daniel Vetter wrote: > > On Mon, Aug 22, 2016 at 9:43 AM, Ying Liu wrote: > + > + /* > + * The relevant plane's ->atomic_check callback may set > + *

[RFC] Using C99 stdint vs kernel __uX types in kernel drmUAPI (was Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from ")

On Mon, Aug 22, 2016 at 12:38 PM, Rob Clark wrote: >> That said, _note_ that some applications are built with -C89 -pedantic >> [1] which means that using stdint.h may or may not work as expected. >> So we'll want a __STDC_VESION__ check + #error in case of pre-C99 ? >> If the affected programs

[PATCH 0/4] Backported vlv fixes for 4.7.y

On Mon, Aug 22, 2016 at 11:31:31AM -0400, Lyude wrote: > Hope this didn't take too long! Here's the backported versions of the patches > you had trouble applying to stable. The patch for FBC won't be necessary as > that is already present in 4.7.y. > > Cheers, > Lyude Thanks, but what are

[PATCH v3 1/5] drm/rockchip: sort registers define by chip's number

On Thu, Aug 18, 2016 at 6:02 AM, Mark yao wrote: > On 2016年08月18日 17:11, Daniel Vetter wrote: >> >> On Thu, Aug 18, 2016 at 05:08:14PM +0800, Mark yao wrote: >>> >>> >Hi Sean >>> > >>> >Thanks for send v3 patch for rk3399 vop support. >>> > >>> >But sorry for that, I had changed my mind,

[PATCH v3 3/3] drm/imx: Add active plane reconfiguration support

On Mon, Aug 22, 2016 at 3:53 PM, Daniel Vetter wrote: > On Mon, Aug 22, 2016 at 9:43 AM, Ying Liu wrote: + + /* + * The relevant plane's ->atomic_check callback may set + * crtc_state->mode_changed to be true when the active + * plane needs to be

[RFC] Using C99 stdint vs kernel __uX types in kernel drmUAPI (was Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from ")

On 22 August 2016 at 15:38, Daniel Vetter wrote: > On Mon, Aug 22, 2016 at 12:38 PM, Rob Clark wrote: >>> That said, _note_ that some applications are built with -C89 -pedantic >>> [1] which means that using stdint.h may or may not work as expected. >>> So we'll want a __STDC_VESION__ check +

[PATCH -next] drm/i915: Fix non static symbol warning

On Sun, 21 Aug 2016, Wei Yongjun wrote: > From: Wei Yongjun > > Fixes the following sparse warning: > > drivers/gpu/drm/i915/intel_hotplug.c:480:6: warning: > symbol 'i915_hpd_poll_init_work' was not declared. Should it be static? > > Also move the '{' to new line. Thanks for the patch, but

[Bug 95306] Random Blank(black) screens on "Carrizo"

tps://lists.freedesktop.org/archives/dri-devel/attachments/20160822/dd95450f/attachment.html>

[Bug 95306] Random Blank(black) screens on "Carrizo"

ail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160822/2f5f165c/attachment.html>

[Bug 95306] Random Blank(black) screens on "Carrizo"

TTY and back. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160822/d6c63e21/attachment.html>

[Bug 95306] Random Blank(black) screens on "Carrizo"

ail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160822/08a6b961/attachment-0001.html>

[PATCH v3 3/3] drm/imx: Add active plane reconfiguration support

Hi Daniel, On Mon, Aug 22, 2016 at 3:20 PM, Daniel Vetter wrote: > On Fri, Aug 19, 2016 at 05:36:59PM +0800, Liu Ying wrote: >> We don't support configuring active plane on-the-fly for imx-drm. >> The relevant CRTC should be disabled before the plane configuration. >> Of course, the plane itself

[PATCH 2/2] drm/msm: protect against faults from copy_from_user() in submit ioctl

An evil userspace could try to cause deadlock by passing an unfaulted-in GEM bo as submit->bos (or submit->cmds) table. Which will trigger msm_gem_fault() while we already hold struct_mutex. See: https://github.com/freedreno/msmtest/blob/master/evilsubmittest.c Cc: stable at vger.kernel.org

[PATCH 1/2] drm/msm: fix use of copy_from_user() while holding spinlock

Use instead __copy_from_user_inatomic() and fallback to slow-path where we drop and re-aquire the lock in case of fault. Cc: stable at vger.kernel.org Reported-by: Vaishali Thakkar Signed-off-by: Rob Clark --- drivers/gpu/drm/msm/msm_gem_submit.c | 27 ++- 1 file

[PATCH v2 4/7] drm/bridge: Add RGB to VGA bridge support

tp://free-electrons.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160822/846b3b46/attachment.sig>

[PATCH v3 1/3] drm/atomic-helper: Add atomic_disable CRTC helper callback

On Mon, Aug 22, 2016 at 3:01 PM, Daniel Vetter wrote: > On Fri, Aug 19, 2016 at 05:36:57PM +0800, Liu Ying wrote: >> Some display controllers need plane(s) to be disabled together with >> the relevant CRTC, e.g., the IPUv3 display controller for imx-drm. >> This patch adds atomic_disable CRTC

[PATCH 01/18] drm/etnaviv: reset GPU when coming back from suspend

Am Montag, den 22.08.2016, 13:27 +0100 schrieb Russell King - ARM Linux: > On Mon, Aug 22, 2016 at 02:15:25PM +0200, Lucas Stach wrote: > > Am Montag, den 22.08.2016, 12:20 +0100 schrieb Russell King - ARM Linux: > > > On Mon, Aug 22, 2016 at 01:00:55PM +0200, Lucas Stach wrote: > > > > The GPU

[PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from "

On Mon, 22 Aug 2016, Daniel Vetter wrote: > On Sat, Aug 20, 2016 at 8:58 PM, Emil Velikov > wrote: >> >> All I can think of is that you (?) are porting some changes from the >> kernel to libdrm or vice-versa. In the latter case please _don't_ do >> that. Work with your changes in upstream

[PATCH 03/18] drm/etnaviv: only check if the cmdbuf is inside the linear window on MMUv1

Am Montag, den 22.08.2016, 12:22 +0100 schrieb Russell King - ARM Linux: > On Mon, Aug 22, 2016 at 01:00:57PM +0200, Lucas Stach wrote: > > There is no linear window on MMUv2 and the FE can access the full 4GB > > address space either directly (as long as the MMU isn't configured) or > > through

[PATCH 01/18] drm/etnaviv: reset GPU when coming back from suspend

Am Montag, den 22.08.2016, 12:20 +0100 schrieb Russell King - ARM Linux: > On Mon, Aug 22, 2016 at 01:00:55PM +0200, Lucas Stach wrote: > > The GPU may still keep its state when in suspend, which breaks the > > assumption that the hardware is in a clean state before the init > > routine runs. Make

[RFC] Using C99 stdint vs kernel __uX types in kernel drmUAPI (was Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from ")

On Mon, 22 Aug 2016, Emil Velikov wrote: > Although last time around people leaned towards the __uX types, if we > have a consensus amongst drm (kernel) developers about using stdint > ones everything should be fine. > We just need a handful of acks from the different maintainers. > My

[PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from "

On Sat, 20 Aug 2016, Emil Velikov wrote: > > If you or any !Linux folks are around on XDC we should really sit down > and untangle some/all of these issues. > > Thanks > Emil > If there was to be some sort of BoF (doesn't have to be formal, and could be an after-hours event), I would

[RFC 0/2] New feature: Framebuffer processors

Hello Marek, Marek Szyprowski wrote: > Dear Tobias > > > On 2016-08-22 12:07, Tobias Jakobi wrote: >> Hey Marek, >> >> I had a quick look at the series and I really like the new approach. >> >> I was wondering about the following though. If I understand this >> correctly I can only perform m2m

[RFC] Using C99 stdint vs kernel __uX types in kernel drmUAPI (was Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from ")

On Mon, Aug 22, 2016 at 09:48:10AM +0100, Emil Velikov wrote: > On 20 August 2016 at 23:31, Rob Clark wrote: > > On Sat, Aug 20, 2016 at 1:58 PM, Mikko Rapeli > > wrote: > >> Cc'ing lkml too. > >> > >> On Fri, Aug 19, 2016 at 11:54:21PM +0100, Emil Velikov wrote: > >>> Story time: > >>> I was

[PATCH 01/18] drm/etnaviv: reset GPU when coming back from suspend

On Mon, Aug 22, 2016 at 02:15:25PM +0200, Lucas Stach wrote: > Am Montag, den 22.08.2016, 12:20 +0100 schrieb Russell King - ARM Linux: > > On Mon, Aug 22, 2016 at 01:00:55PM +0200, Lucas Stach wrote: > > > The GPU may still keep its state when in suspend, which breaks the > > > assumption that

[PATCH v12 4/7] drm/i915/skl: Update plane watermarks atomically during plane updates

Op 17-08-16 om 21:55 schreef Lyude: > Thanks to Ville for suggesting this as a potential solution to pipe > underruns on Skylake. > > On Skylake all of the registers for configuring planes, including the > registers for configuring their watermarks, are double buffered. New > values written to

[PATCH 18/18] drm/etnaviv: fix up model and revision for GC2000+

GC2000+ on the i.MX6QP is just a re-branded GC3000, lets call it by its real name to avoid confusion in other parts of the driver. Signed-off-by: Lucas Stach --- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 12 1 file changed, 12 insertions(+) diff --git

[PATCH 17/18] drm/etnaviv: implement IOMMUv2 translation

All other parts are now in place, so implement the actual translation step and hook it up, so the driver claims support for cores with the new MMU. Signed-off-by: Lucas Stach --- drivers/gpu/drm/etnaviv/etnaviv_iommu.h| 3 +- drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c | 255

[PATCH 16/18] drm/etnaviv: handle MMU exception in IRQ handler

Bit 30 of the interrupt status signals an MMU exception. Handle this condition properly and dump some useful registers. Signed-off-by: Lucas Stach --- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 12 drivers/gpu/drm/etnaviv/state_hi.xml.h | 9 + 2 files changed, 17

[PATCH 15/18] drm/etnaviv: add flushing logic for MMUv2

Flushing works differently on MMUv2, in that it's only necessary to set a single bit in the control register to flush all translation units. A semaphore stall then makes sure that the flush has propagated properly. Signed-off-by: Lucas Stach --- drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 31

[PATCH 14/18] drm/etnaviv: add function to construct MMUv2 init buffer

Both the safe/scratch address and the master TLB address are per pipe with the CPU mapped registers not properly propagating to the different translation units. The only way to correctly configure all translation units is to have a command stream snipped executed by the FE, before any other

[PATCH 13/18] drm/etnaviv: map cmdbuf through MMU on version 2

With MMUv2 all buffers need to be mapped through the MMU once it is enabled. Align the buffer size to 4K, as the MMU is only able to map page aligned buffers. Signed-off-by: Lucas Stach --- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 4 drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 2 ++

[PATCH 12/18] drm/etnaviv: split out iova search and MMU reaping logic

With MMUv2 the command buffers need to be mapped through the MMU. Split out the iova search and MMU reaping logic so it can be reused for the cmdbuf mapping, where no GEM object is involved. Signed-off-by: Lucas Stach --- drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 62

[PATCH 11/18] drm/etnaviv: split out FE start

Split out into a new externally visible function, as the IOMMUv2 code needs this functionality, too. Signed-off-by: Lucas Stach --- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 15 ++- drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 1 + 2 files changed, 11 insertions(+), 5 deletions(-) diff

[PATCH 10/18] drm/etnaviv: split out wait for gpu idle

Split out into a new externally visible function, as the IOMMUv2 code needs this functionality, too. Signed-off-by: Lucas Stach --- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 40 +++ drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 1 + 2 files changed, 23 insertions(+), 18

[PATCH 09/18] drm/etnaviv: move gpu_va() to etnaviv mmu

The GPU virtual address for the command buffers differs depending on the IOMMU version. Move the calculation of the iova into etnaviv mmu, to enable proper dispatch. Signed-off-by: Lucas Stach --- drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 16 ++--

[PATCH 08/18] drm/etnaviv: remove unused iommu_v2 header

This has been there from the original merge, but has never been used. Get rid of it. Signed-off-by: Lucas Stach --- drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.h | 25 - 1 file changed, 25 deletions(-) delete mode 100644 drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.h diff

[PATCH 07/18] drm/etnaviv: move IOMMU domain allocation into etnaviv MMU

The GPU code doesn't need to deal with the IOMMU directly, instead it can all be hidden behind the etnaviv mmu interface. Move the last remaining part into etnaviv mmu. Signed-off-by: Lucas Stach --- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 33 +++---

[PATCH 06/18] drm/etnaviv: indirect IOMMU restore through etnaviv MMU

So we can call the v2 restore code once it is there. Signed-off-by: Lucas Stach --- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 +- drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 9 + drivers/gpu/drm/etnaviv/etnaviv_mmu.h | 1 + 3 files changed, 11 insertions(+), 1 deletion(-) diff --git

[PATCH 05/18] drm/etnaviv: move linear window setup into etnaviv_iommuv1_restore

It is only relevant for the V1 MMU, so we should not do this in the common code. Signed-off-by: Lucas Stach --- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 9 + drivers/gpu/drm/etnaviv/etnaviv_iommu.c | 7 +++ 2 files changed, 8 insertions(+), 8 deletions(-) diff --git

[PATCH 04/18] drm/etnaviv: rename etnaviv_iommu_domain_restore to etnaviv_iommuv1_restore

This function has external visibility and only handles the Vivant IOMMU version 1. Rename to make this more clear and allow a clear separation of the different IOMMU versions. Also drop the domain parameter, as we can infer it from the GPU we are dealing with. Signed-off-by: Lucas Stach ---

[PATCH 03/18] drm/etnaviv: only check if the cmdbuf is inside the linear window on MMUv1

There is no linear window on MMUv2 and the FE can access the full 4GB address space either directly (as long as the MMU isn't configured) or through the MMU, once it is up. Signed-off-by: Lucas Stach --- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 4 +++- 1 file changed, 3 insertions(+), 1

[PATCH 02/18] drm/etnaviv: only try to use the linear window on MMUv1

As the comment above the code states, the linear window is only available on MMUv1. Don't try to use it on MMUv2. Signed-off-by: Lucas Stach --- drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c

[PATCH 01/18] drm/etnaviv: reset GPU when coming back from suspend

The GPU may still keep its state when in suspend, which breaks the assumption that the hardware is in a clean state before the init routine runs. Make sure to reset the GPU when coming back from suspend, so this assumption is validated. Signed-off-by: Lucas Stach ---

[PATCH 00/18] drm/etnaviv: MMUv2 and new hardware support

Hi all, this series adds support for the new MMU version 2, found on newer Vivante cores. The new MMU provides full isolation, with no way for the GPU to bypass it. This may enable optimizations like skipping commandstream validation later on. For now we stick with a single address space for all

[PATCH] drm/i915/skl: Set dirty_pipes to active_crtcs, not ~0

Using intel_state->active_crtcs allows us to more easily check whether or not we've updated all of the CRTCs that needed ddb updates since we can just do: mask_of_crtcs_we_updated == intel_state->wm_results.dirty_pipes Signed-off-by: Lyude --- drivers/gpu/drm/i915/intel_pm.c | 2 +- 1

[RFC 0/2] New feature: Framebuffer processors

Dear Tobias On 2016-08-22 12:07, Tobias Jakobi wrote: > Hey Marek, > > I had a quick look at the series and I really like the new approach. > > I was wondering about the following though. If I understand this > correctly I can only perform m2m operations on buffers which are > registered as

[PATCH v13 4/7] drm/i915/skl: Update plane watermarks atomically during plane updates

Thanks to Ville for suggesting this as a potential solution to pipe underruns on Skylake. On Skylake all of the registers for configuring planes, including the registers for configuring their watermarks, are double buffered. New values written to them won't take effect until said registers are

[PATCH v2 2/2] Documentation/sphinx: link dma-buf rsts

Em Mon, 22 Aug 2016 20:41:45 +0530 Sumit Semwal escreveu: > Include dma-buf sphinx documentation into top level index. > > Signed-off-by: Sumit Semwal > --- > Documentation/index.rst | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/index.rst b/Documentation/index.rst

[PATCH 03/18] drm/etnaviv: only check if the cmdbuf is inside the linear window on MMUv1

On Mon, Aug 22, 2016 at 01:00:57PM +0200, Lucas Stach wrote: > There is no linear window on MMUv2 and the FE can access the full 4GB > address space either directly (as long as the MMU isn't configured) or > through the MMU, once it is up. > > Signed-off-by: Lucas Stach > --- >

[Bug 97371] AMDGPU/Iceland amdgpu: failed testing IB on ring 9/10

cause: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160822/2aee8c0a/attachment.html>

[PATCH 01/18] drm/etnaviv: reset GPU when coming back from suspend

On Mon, Aug 22, 2016 at 01:00:55PM +0200, Lucas Stach wrote: > The GPU may still keep its state when in suspend, which breaks the > assumption that the hardware is in a clean state before the init > routine runs. Make sure to reset the GPU when coming back from > suspend, so this assumption is

[PATCH] drm: Avoid calling dev_printk(.dev = NULL)

On Fri, Aug 19, 2016 at 7:33 AM, Sean Paul wrote: > On Aug 19, 2016 12:37 AM, "Chris Wilson" wrote: >> >> Since dev_printk likes to print "(NULL device *):" when passed in a NULL >> pointer, we have to manually call printk() ourselves. >> >> Fixes: c4e68a583202 ("drm: Introduce DRM_DEV_* log

[RFC 0/2] New feature: Framebuffer processors

Hey Marek, I had a quick look at the series and I really like the new approach. I was wondering about the following though. If I understand this correctly I can only perform m2m operations on buffers which are registered as framebuffers. Is this possible to weaken that requirements such that

[RFC 0/2] New feature: Framebuffer processors

Am 22.08.2016 um 11:44 schrieb Marek Szyprowski: > Dear all, > > This is the initial proposal for extending DRM API with generic support for > hardware modules, which can be used for processing image data from the one > memory buffer to another. Typical memory-to-memory operations are: > rotation,

[Bug 153121] UVD not responding, trying to reset the VCPU, ATI Mobility Radeon HD 5650

https://bugzilla.kernel.org/show_bug.cgi?id=153121 --- Comment #33 from Kontantin Ivanov --- Created attachment 229681 --> https://bugzilla.kernel.org/attachment.cgi?id=229681=edit 4.8.0-040800rc3 Xorg.0.log yet another Xorg.0.log (4.8.0-rc3) -- You are receiving this mail because: You are

[Bug 153121] UVD not responding, trying to reset the VCPU, ATI Mobility Radeon HD 5650

https://bugzilla.kernel.org/show_bug.cgi?id=153121 --- Comment #32 from Kontantin Ivanov --- Created attachment 229671 --> https://bugzilla.kernel.org/attachment.cgi?id=229671=edit 4.8.0-040800rc3 dmesg yet another dmesg for 4.8.0-rc3 -- You are receiving this mail because: You are watching

[RFC code example] example code for testing fbproc drivers

This is simple example how DRM FBProc API can be used from userspace. The code allocates 2 dumb framebuffers, fill first with test pattern and then performs 180 degree rotation of the image data. TODO: add code to release all allocated resources Signed-off-by: Marek Szyprowski --- rotate.c |

[RFC libdrm] add support for framebuffer processor (fbproc) objects

This patch extends DRM API with generic support for hardware modules, which can be used for processing image data from the one memory buffer to another. Typical memory-to-memory operations are: rotation, scaling, colour space conversion or mix of them. I named such hardware modules a framebuffer

[RFC 2/2] drm/exynos: register rotator as fbproc instead of custom ipp framework

This is a quick conversion of Exynos DRM rotator driver from Exynos IPP framework to generic DRM FBProc API to demonstrate how to use it from the driver side. Not-for-merge-yet: the code of the driver must be cleaned up first, because its internals still depends on Exynos IPP structures.

[RFC 1/2] drm: add support for framebuffer processors

This patch extends DRM API with generic support for hardware modules, which can be used for processing image data from the one memory buffer to another. Typical memory-to-memory operations are: rotation, scaling, colour space conversion or mix of them. I named such hardware modules a framebuffer

[RFC 0/2] New feature: Framebuffer processors

Dear all, This is the initial proposal for extending DRM API with generic support for hardware modules, which can be used for processing image data from the one memory buffer to another. Typical memory-to-memory operations are: rotation, scaling, colour space conversion or mix of them. In this

[PATCH 1/1] drm/gma500: dont expose stack, mrst_lvds_find_best_pll

On Sun, 21 Aug 2016, Heinrich Schuchardt wrote: > All components of variable clock should be initialized > to avoid bytes from the kernel stack to be exposed. > > Reported-by: Joe Perches > Signed-off-by: Heinrich Schuchardt > --- > drivers/gpu/drm/gma500/oaktrail_crtc.c | 1 + > 1 file

[PATCH v7 8/8] drm/rockchip: Add dmc notifier in vop driver

when in ddr frequency scaling process, vop can not do enable or disable operation, since in dcf we check vop clock to see whether vop work. If vop work, dcf do ddr frequency scaling when vop in vblank status, and we need to read vop register to check whether vop go into vblank status. If vop not

[PATCH v7 7/8] PM / devfreq: rockchip: add devfreq driver for rk3399 dmc

base on dfi result, we do ddr frequency scaling, register dmc driver to devfreq framework, and use simple-ondemand policy. Signed-off-by: Lin Huang Reviewed-by: Chanwoo Choi --- Changes in v7: - remove a blank line Changes in v6: - fix some nit suggest by Chanwoo Choi Changes in v5: - improve

[PATCH v7 6/8] Documentation: bindings: add dt documentation for rk3399 dmc

This patch adds the documentation for rockchip rk3399 dmc driver. Signed-off-by: Lin Huang --- Changes in v7: -None Changes in v6: -Add more detail in Documentation Changes in v5: -None Changes in v4: -None Changes in v3: -None Changes in v2: -None Changes in v1: -None

[PATCH v7 5/8] PM / devfreq: event: support rockchip dfi controller

on rk3399 platform, there is dfi conroller can monitor ddr load, base on this result, we can do ddr freqency scaling. Signed-off-by: Lin Huang Acked-by: Chanwoo Choi --- Changes in v7: -access need to *4 to get right DDR loading Changes in v6: -None Changes in v5: -None Changes in v4: -None

[PATCH v7 4/8] Documentation: bindings: add dt documentation for dfi controller

This patch adds the documentation for rockchip dfi devfreq-event driver. Signed-off-by: Lin Huang --- Changes in v7: -None Changes in v6: -None Changes in v5: -None Changes in v4: -None Changes in v3: -None Changes in v2: -None Changes in v1: -None

[PATCH v7 3/8] clk: rockchip: rk3399: add ddrc clock support

add ddrc clock setting, so we can do ddr frequency scaling on rk3399 platform in future. Signed-off-by: Lin Huang --- Changes in v7: - change SCLK_DDRC name from clk_ddrc to sclk_ddrc Changes in v6: - None Changes in v5: - fit for the ddr type Changes in v4: - None Changes in v3: - None

[PATCH v7 2/8] clk: rockchip: rk3399: add SCLK_DDRCLK ID for ddrc

Signed-off-by: Lin Huang --- Changes in v7: -None Changes in v6: -None Changes in v5: -None Changes in v4: -None Changes in v3: -None Changes in v2: -None Changes in v1: -None include/dt-bindings/clock/rk3399-cru.h | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH v7 1/8] clk: rockchip: add new clock-type for the ddrclk

On new rockchip platform(rk3399 etc), there have dcf controller to do ddr frequency scaling, and this controller will implement in arm-trust-firmware. We add a special clock-type to handle that. Signed-off-by: Lin Huang --- Changes in v7: - add rockchip_ddrclk_sip_ops so we can distinguish other

[PATCH v7 0/8] rk3399 support ddr frequency scaling

rk3399 platform have dfi controller can monitor ddr load, and dcf controller to handle ddr register so we can get the right ddr frequency and make ddr controller happy work(which will implement in bl31). So we do ddr frequency scaling with following flow: kernel

[8086:0416] i915 Inability to drive internal (eDP) panel since 4.7 final

tps://lists.freedesktop.org/archives/dri-devel/attachments/20160822/a0b6e532/attachment-0001.sig>

[PATCH] drm/gma500: dont expose bytes from kernel stack

On Sun, 21 Aug 2016, Heinrich Schuchardt wrote: > Components m1, m2, p2, dot, vco of variable clock should be > initialized to avoid bytes from the kernel stack to be > exposed. > > Signed-off-by: Heinrich Schuchardt > --- > drivers/gpu/drm/gma500/oaktrail_crtc.c | 1 + > 1 file changed, 1

[PATCH 4/4] drm/i915: Enable polling when we don't have hpd

Unfortunately, there's two situations where we lose hpd right now: - Runtime suspend - When we've shut off all of the power wells on Valleyview/Cherryview While it would be nice if this didn't cause issues, this has the ability to get us in some awkward states where a user won't be able to get

[PATCH 3/4] drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug()

One of the things preventing us from using polling is the fact that calling valleyview_crt_detect_hotplug() when there's a VGA cable connected results in sending another hotplug. With polling enabled when HPD is disabled, this results in a scenario like this: - We enable power wells and reset the

[PATCH 2/4] drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init()

While VGA hotplugging worked(ish) before, it looks like that was mainly because we'd unintentionally enable it in valleyview_crt_detect_hotplug() when we did a force trigger. This doesn't work reliably enough because whenever the display powerwell on vlv gets disabled, the values set in VLV_ADPA

[PATCH 1/4] drm/i915/vlv: Make intel_crt_reset() per-encoder

This lets call intel_crt_reset() in contexts where IRQs are disabled and as such, can't hold the locks required to work with the connectors. Cc: stable at vger.kernel.org Cc: Ville Syrjälä Acked-by: Daniel Vetter Signed-off-by: Lyude --- drivers/gpu/drm/i915/intel_crt.c | 10 +- 1

  1   2   >