Re: [PATCH 1/4] drm/atomic: implement drm_atomic_helper_commit_tail for runtime_pm users

On Fri, Jul 14, 2017 at 1:43 AM, Laurent Pinchart wrote: >> Commit 52055bafa1ff ("drm: rcar-du: Move plane commit code from CRTC >> start to CRTC resume") changed the order of the plane commit and CRTC >> enable operations to accommodate the runtime PM

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3

https://bugs.freedesktop.org/show_bug.cgi?id=101731 --- Comment #16 from Philipp Überbacher --- I finally came around to uploading this trace (should be up for 30 days). Remember that it was with amdgpu-pro and replaying did not cause the freeze. I hope it helps anyway.

Re: [PATCH v2 06/14] drm/edid: parse YCBCR420 videomodes from EDID

Regards Shashank On 7/13/2017 9:51 PM, Ville Syrjälä wrote: On Thu, Jul 13, 2017 at 09:03:12PM +0530, Shashank Sharma wrote: HDMI 2.0 spec adds support for YCBCR420 sub-sampled output. CEA-861-F adds two new blocks in EDID's CEA extension blocks, to provide information about sink's YCBCR420

Re: [PATCH 2/2] drm/amdgpu: Implement ttm_bo_driver.access_vram callback

On 14/07/17 06:23 AM, Felix Kuehling wrote: > On 17-07-13 05:08 PM, Felix Kuehling wrote: >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h >> @@ -78,6 +78,8 @@ int amdgpu_fill_buffer(struct amdgpu_bo *bo, >> struct dma_fence

Re: [PATCH 1/2] drm: Implement vm_operations_struct.access

On 14/07/17 06:08 AM, Felix Kuehling wrote: > Allows gdb to access contents of user mode mapped BOs. VRAM access > requires the driver to implement a new callback in ttm_bo_driver. Thanks for doing this. Looks mostly good, but I still have some comments. The shortlog prefix should be "drm/ttm:".

[PATCH v5 14/14] drm: remove unused and redundant callbacks

Drivers no longer have any need for these callbacks, and there are no users. Zap. Zap-zap-zzzap-p-pp-p. Acked-by: Daniel Vetter Signed-off-by: Peter Rosin --- include/drm/drm_crtc.h | 8 include/drm/drm_fb_helper.h

Re: [PATCH] drm: rcar-du: Fix comments to comply with the kernel coding style

Hi Laurent, Thanks for this - I think that's a better way forward in this instance now that a few of the locations have been touched, rather than leaving the driver in a mixed state. On 12/07/17 18:00, Laurent Pinchart wrote: > To avoid mixing comment styles when new comments complying with the

[PATCH v5 04/14] drm: amd: remove dead code and pointless local lut storage

The redundant fb helpers .load_lut, .gamma_set and .gamma_get are no longer used. Remove the dead code and hook up the crtc .gamma_set to use the crtc gamma_store directly instead of duplicating that info locally. Acked-by: Daniel Vetter Signed-off-by: Peter Rosin

Re: [PATCH v2 09/14] v4l: vsp1: Add support for multiple LIF instances

Hi Laurent, On 26/06/17 19:12, Laurent Pinchart wrote: > The VSP2-DL instance (present in the H3 ES2.0 and M3-N SoCs) has two LIF > instances. Adapt the driver infrastructure to support multiple LIFs. > Support for multiple display pipelines will be added separately. > > The change to the entity

[PATCH v5 12/14] drm: radeon: remove dead code and pointless local lut storage

The redundant fb helpers .load_lut, .gamma_set and .gamma_get are no longer used. Remove the dead code and hook up the crtc .gamma_set to use the crtc gamma_store directly instead of duplicating that info locally. Acked-by: Daniel Vetter Signed-off-by: Peter Rosin

[PATCH v5 01/14] drm: rename, adjust and export drm_atomic_replace_property_blob

The function has little to do with atomic, it's just where it has so far been needed. So, rename it to drm_property_replace_blob, move it to drm_property.c and export it. Change the semantics to return whether the blob was replaced instead of using an extra argument for that. Signed-off-by:

[PATCH v5 00/14] improve the fb_setcmap helper

Hi! While trying to get CLUT support for the atmel_hlcdc driver, and specifically for the emulated fbdev interface, I received some push-back that my feeble in-driver attempts should be solved by the core. This is my attempt to do it right. I have obviously not tested all of this with more than

Re: [PATCH v2 05/14] v4l: vsp1: Don't create links for DRM pipeline

On 26/06/17 19:12, Laurent Pinchart wrote: > When the VSP1 is used in a DRM pipeline the driver doesn't register the > media device. Links between entities are not exposed to userspace, but > are still used internally for the sole purpose of setting up internal > source to sink pointers through

Re: [PATCH v2 06/14] v4l: vsp1: Add pipe index argument to the VSP-DU API

On 26/06/17 19:12, Laurent Pinchart wrote: > In the H3 ES2.0 SoC the VSP2-DL instance has two connections to DU > channels that need to be configured independently. Extend the VSP-DU API > with a pipeline index to identify which pipeline the caller wants to > operate on. > > Signed-off-by:

Linux: Smooth splashscreen with system having weston with drm-backend

Dear All, I am looking for an solution to have early smooth splashscreen on the Linux system with Weston and drm-backend. I tried showing splashscreen using Linux logo and fbcon Linux features but it is not smooth as when system boots logo gets displayed via kernel and as the Weston starts I see

[PATCH v5 06/14] drm: ast: remove dead code and pointless local lut storage

The redundant fb helpers .load_lut, .gamma_set and .gamma_get are no longer used. Remove the dead code and hook up the crtc .gamma_set to use the crtc gamma_store directly instead of duplicating that info locally. Acked-by: Daniel Vetter Signed-off-by: Peter Rosin

[PATCH v2 2/2] drm/panel: simple: Add support for ddc-only panel

From: Patrick Bruenn This is a fix for the CX9020 Embedded PC. On that device the 24-bit parallel-display signal of the imx53 is combined with an I2C channel and converted to DVI-D port. Devicetree magic always requires a panel connected to the parallel-display port. We

Re: [PATCH] drm: rcar-du: Setup planes before enabling CRTC to avoid flicker

On 13/07/17 16:51, Kieran Bingham wrote: > Hi Laurent, > > I've just seen Maxime's latest series "[PATCH 0/4] drm/sun4i: Fix a register > access bug" and it relates directly to a comment I had in this patch: > > On 12/07/17 17:35, Kieran Bingham wrote: >> Hi Laurent, >> >> On 28/06/17 19:50,

Re: [PATCH v2 01/14] v4l: vsp1: Fill display list headers without holding dlm spinlock

Hi Laurent, Starts easy ... (I haven't gone through these in numerical order of course :D) On 26/06/17 19:12, Laurent Pinchart wrote: > The display list headers are filled using information from the display > list only. Lower the display list manager spinlock contention by filling > the headers

Re: [PATCH v2 02/14] v4l: vsp1: Don't recycle active list at display start

Hi Laurent, On 26/06/17 19:12, Laurent Pinchart wrote: > When the display start interrupt occurs, we know that the hardware has > finished loading the active display list. The driver then proceeds to > recycle the list, assuming it won't be needed anymore. > > This assumption holds true for

[PATCH v5 07/14] drm: cirrus: remove dead code and pointless local lut storage

The redundant fb helpers .load_lut, .gamma_set and .gamma_get are no longer used. Remove the dead code and hook up the crtc .gamma_set to use the crtc gamma_store directly instead of duplicating that info locally. Acked-by: Daniel Vetter Signed-off-by: Peter Rosin

[PATCH v3 0/2] Add CX9020 device tree

From: Patrick Bruenn Add device tree for Beckhoff CX9020 Embedded PC. The CX9020 differs from i.MX53 Quick Start Board by: - use uart2 instead of uart1 - DVI-D connector instead of VGA - no audio - CCAT FPGA connected to emi - enable rtc v3: add missing changelog, sorry

Re: [PATCH] drm: rcar-du: Setup planes before enabling CRTC to avoid flicker

Hi Laurent, I've just seen Maxime's latest series "[PATCH 0/4] drm/sun4i: Fix a register access bug" and it relates directly to a comment I had in this patch: On 12/07/17 17:35, Kieran Bingham wrote: > Hi Laurent, > > On 28/06/17 19:50, Laurent Pinchart wrote: >> Commit 52055bafa1ff ("drm:

Re: [PATCH v2 07/14] v4l: vsp1: Add support for the BRS entity

On 26/06/17 19:12, Laurent Pinchart wrote: > The Blend/ROP Sub Unit (BRS) is a stripped-down version of the BRU found > in several VSP2 instances. Compared to a regular BRU, it supports two > inputs only, and thus has no ROP unit. > > Add support for the BRS by modeling it as a new entity type,

[PATCH v3 2/2] drm/panel: simple: Add support for ddc-only panel

From: Patrick Bruenn This is a fix for the CX9020 Embedded PC. On that device the 24-bit parallel-display signal of the imx53 is combined with an I2C channel and converted to DVI-D port. Devicetree magic always requires a panel connected to the parallel-display port. We

[PATCH v5 03/14] drm/fb-helper: separate the fb_setcmap helper into atomic and legacy paths

The legacy path implements setcmap in terms of crtc .gamma_set. The atomic path implements setcmap by directly updating the crtc gamma_lut property. This has a couple of benefits: - it makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get completely obsolete. They are now unused

[PATCH v5 11/14] drm: nouveau: remove dead code and pointless local lut storage

The redundant fb helpers .load_lut, .gamma_set and .gamma_get are no longer used. Remove the dead code and hook up the crtc .gamma_set to use the crtc gamma_store directly instead of duplicating that info locally. Acked-by: Daniel Vetter Signed-off-by: Peter Rosin

[PATCH v5 13/14] drm: stm: remove dead code and pointless local lut storage

The redundant fb helper .load_lut is no longer used, and can not work right without also providing the fb helpers .gamma_set and .gamma_get thus rendering the code in this driver suspect. Just remove the dead code. Acked-by: Daniel Vetter Signed-off-by: Peter Rosin

Re: [RESEND] [PATCH v2.1 1/2] dt-bindings: display: rcar-du: Add a VSP channel index to the vsps DT property

On Wed, Jul 12, 2017 at 11:43:36AM +0300, Laurent Pinchart wrote: > On some R-Car SoCs a single VSP can serve multiple DU channels through > multiple LIF instances in the VSP. The current DT bindings don't support > specifying that kind of SoC integration scheme. Extend them with a VSP > channel

Re: [PATCH v2 03/14] v4l: vsp1: Don't set WPF sink pointer

On 26/06/17 19:12, Laurent Pinchart wrote: > The sink pointer is used to configure routing inside the VSP, and as > such must point to the next VSP entity in the pipeline. The WPF being a > pipeline terminal sink, its output route can't be configured. The > routing configuration code already

Re: [PATCH v2 04/14] v4l: vsp1: Store source and sink pointers as vsp1_entity

Hi Laurent, This looks like a good simplification/removal of obfuscation to me! On 26/06/17 19:12, Laurent Pinchart wrote: > The internal VSP entity source and sink pointers are stored as > media_entity pointers, which are then cast to a vsp1_entity. As all > sources and sinks are vsp1_entity

Re: [PATCH v2 08/14] v4l: vsp1: Add support for new VSP2-BS, VSP2-DL and VSP2-D instances

Hi Laurent, On 26/06/17 19:12, Laurent Pinchart wrote: > New Gen3 SoCs come with two new VSP2 variants names VSP2-BS and VSP2-DL, > as well as a new VSP2-D variant on V3M and V3H SoCs. Add new entries for > them in the VSP device info table. > > Signed-off-by: Laurent Pinchart

[PATCH v5 08/14] drm: gma500: remove dead code and pointless local lut storage

The redundant fb helpers .gamma_set and .gamma_get are no longer used. Remove the dead code and hook up the crtc .gamma_set to use the crtc gamma_store directly instead of duplicating that info locally. Acked-by: Daniel Vetter Signed-off-by: Peter Rosin

[PATCH v2 0/2] Add CX9020 device tree

From: Patrick Bruenn Add device tree for Beckhoff CX9020 Embedded PC. The CX9020 differs from i.MX53 Quick Start Board by: - use uart2 instead of uart1 - DVI-D connector instead of VGA - no audio - CCAT FPGA connected to emi - enable rtc Patrick Bruenn (2): ARM: dts:

Re: [RESEND] [PATCH v2.1 1/2] dt-bindings: display: rcar-du: Add a VSP channel index to the vsps DT property

On Thu, Jul 13, 2017 at 09:46:19AM +0200, Simon Horman wrote: > On Wed, Jul 12, 2017 at 11:43:36AM +0300, Laurent Pinchart wrote: > > On some R-Car SoCs a single VSP can serve multiple DU channels through > > multiple LIF instances in the VSP. The current DT bindings don't support > > specifying

[PATCH v5 05/14] drm: armada: remove dead empty functions

The redundant fb helpers .gamma_set and .gamma_get are no longer used. Remove the dead code. Acked-by: Daniel Vetter Signed-off-by: Peter Rosin --- drivers/gpu/drm/armada/armada_crtc.c | 10 -- drivers/gpu/drm/armada/armada_crtc.h | 2 --

[PATCH v5 09/14] drm: i915: remove dead code and pointless local lut storage

The driver stores lut values from the fbdev interface, and is able to give them back, but does not appear to do anything with these lut values. The generic fb helpers have replaced this function, and may even have made the driver work for the C8 mode from the fbdev interface. But that is untested.

[PATCH v5 02/14] drm/atomic-helper: update lut props directly in ..._legacy_gamma_set

Do not waste cycles looking up the property id when we have the actual property already. Signed-off-by: Peter Rosin --- drivers/gpu/drm/drm_atomic_helper.c | 20 +--- 1 file changed, 5 insertions(+), 15 deletions(-) diff --git

Re: [PATCH v2 00/14] Renesas R-Car VSP: Add H3 ES2.0 support

Hi Laurent, Thankyou for these patches, bringing life to the outputs of my ES2.0 target board. I have tested them on my board, and including the VSP unit test suite, and kmscube utilities. Feel free to add a Tested-by: Kieran Bingham to all of the

[PATCH v5 10/14] drm: mgag200: remove dead code and pointless local lut storage

The redundant fb helpers .load_lut, .gamma_set and .gamma_get are no longer used. Remove the dead code and hook up the crtc .gamma_set to use the crtc gamma_store directly instead of duplicating that info locally. Acked-by: Daniel Vetter Signed-off-by: Peter Rosin

Re: [PATCH v2 00/14] Renesas R-Car VSP: Add H3 ES2.0 support

Hi Kieran, On Thursday 13 Jul 2017 13:25:55 Kieran Bingham wrote: > Hi Laurent, > > Thank you for these patches, bringing life to the outputs of my ES2.0 target > board. > > I have tested them on my board, and including the VSP unit test suite, and > kmscube utilities. > > Feel free to add a

[Bug 101746] radeonsi: Kernel syscall lockup caused probably by GPU crash

https://bugs.freedesktop.org/show_bug.cgi?id=101746 --- Comment #2 from Tobias Auerochs --- Sadly could not find any useful information out of various process logs, in particular Xorg.0.log contains nothing error related. The only thing that is somewhat interesting is that

[PATCH v2.1 08/14] v4l: vsp1: Add support for new VSP2-BS, VSP2-DL and VSP2-D instances

New Gen3 SoCs come with two new VSP2 variants names VSP2-BS and VSP2-DL, as well as a new VSP2-D variant on V3M and V3H SoCs. Add new entries for them in the VSP device info table. Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham

Re: [PATCH 3/3] drm/ttm: add transparent huge page support for DMA allocations

Hi Christian, [auto build test WARNING on drm/drm-next] [also build test WARNING on v4.12 next-20170713] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Christian-K-nig/drm-ttm-add-support

Re: [PATCH] drm: rcar-du: Setup planes before enabling CRTC to avoid flicker

Hi Kieran, On Wednesday 12 Jul 2017 17:35:53 Kieran Bingham wrote: > On 28/06/17 19:50, Laurent Pinchart wrote: > > Commit 52055bafa1ff ("drm: rcar-du: Move plane commit code from CRTC > > start to CRTC resume") changed the order of the plane commit and CRTC > > enable operations to accommodate

Re: [PATCH 1/4] drm/atomic: implement drm_atomic_helper_commit_tail for runtime_pm users

Hi Maxime, Thank you for the patch. On Thursday 13 Jul 2017 16:41:13 Maxime Ripard wrote: > The current drm_atomic_helper_commit_tail helper works only if the CRTC is > accessible, and documents an alternative implementation that is supposed to > be used if that happens. > > That implementation

Re: [PATCH] drm: rcar-du: Setup planes before enabling CRTC to avoid flicker

Hi Kieran, On Thursday 13 Jul 2017 16:51:18 Kieran Bingham wrote: > Hi Laurent, > > I've just seen Maxime's latest series "[PATCH 0/4] drm/sun4i: Fix a register > access bug" and it relates directly to a comment I had in this patch: > On 12/07/17 17:35, Kieran Bingham wrote: > > > On 28/06/17

Re: [PATCH v2 08/14] v4l: vsp1: Add support for new VSP2-BS, VSP2-DL and VSP2-D instances

Hi Kieran, On Thursday 13 Jul 2017 18:49:19 Kieran Bingham wrote: > On 26/06/17 19:12, Laurent Pinchart wrote: > > New Gen3 SoCs come with two new VSP2 variants names VSP2-BS and VSP2-DL, > > as well as a new VSP2-D variant on V3M and V3H SoCs. Add new entries for > > them in the VSP device info

Re: [PATCH] drm: rcar-du: Fix comments to comply with the kernel coding style

Hi Daniel, On Thursday 13 Jul 2017 14:38:15 Daniel Vetter wrote: > On Wed, Jul 12, 2017 at 08:00:42PM +0300, Laurent Pinchart wrote: > > To avoid mixing comment styles when new comments complying with the > > kernel coding style are introduced, fix all multiline comments in one > > go. > > > >

Re: [PATCH v2 06/14] v4l: vsp1: Add pipe index argument to the VSP-DU API

Hi Kieran, On Thursday 13 Jul 2017 14:16:03 Kieran Bingham wrote: > On 26/06/17 19:12, Laurent Pinchart wrote: > > In the H3 ES2.0 SoC the VSP2-DL instance has two connections to DU > > channels that need to be configured independently. Extend the VSP-DU API > > with a pipeline index to identify

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3

https://bugs.freedesktop.org/show_bug.cgi?id=101731 --- Comment #15 from Shmerl --- Interestingly, when I record a trace, and it reaches the point where it's supposed to freeze, it doesn't. I.e. the tracing somehow prevents it from happening. -- You are receiving this mail

[PATCH] drm: rcar-du: Wait for flip completion instead of vblank in commit tail

Page flips can take more than one vertical blanking to complete if arming the page flips races with the vertical blanking interrupt. Waiting for one vblank to complete the atomic commit in the commit tail handler is thus incorrect, and can lead to framebuffers being released while still being

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3

https://bugs.freedesktop.org/show_bug.cgi?id=101731 --- Comment #14 from Shmerl --- I didn't get to the freeze point in the replay, but I remember in the past, when I recorded a trace and replayed it, it actually showed images (i.e. video like). So I suppose something is

Re: [PATCH 2/2] drm/amdgpu: Implement ttm_bo_driver.access_vram callback

On 17-07-13 05:08 PM, Felix Kuehling wrote: > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h > @@ -78,6 +78,8 @@ int amdgpu_fill_buffer(struct amdgpu_bo *bo, > struct dma_fence **fence); > > int amdgpu_mmap(struct file *filp,

[Bug 196273] Loss of video output and system freezes *ERROR* Couldn't read SADs: 0

https://bugzilla.kernel.org/show_bug.cgi?id=196273 Olaf H B (o...@seldiame.net) changed: What|Removed |Added Status|NEW |RESOLVED

[PATCH 2/2] drm/amdgpu: Implement ttm_bo_driver.access_vram callback

Allows gdb to access contents of user mode mapped VRAM BOs. Signed-off-by: Felix Kuehling --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 59 + drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 2 ++ 2 files changed, 61 insertions(+) diff --git

[PATCH 1/2] drm: Implement vm_operations_struct.access

Allows gdb to access contents of user mode mapped BOs. VRAM access requires the driver to implement a new callback in ttm_bo_driver. Signed-off-by: Felix Kuehling --- drivers/gpu/drm/ttm/ttm_bo_vm.c | 66 -

Re: [PATCH v2 2/5] drm/rockchip: vop: support verify registers with vop version

On Thu, Jul 13, 2017 at 09:45:12AM +0800, Mark yao wrote: > On 2017年07月13日 01:53, Sean Paul wrote: > > On Wed, Jul 12, 2017 at 10:03:38AM +0800, Mark Yao wrote: > > > > Please add a commit message describing *what* and *why* you are making the > > change. > > Got it, I will fix it at next

Re: vmgfx gcc-7.1.1 warning..

On Thu, Jul 13, 2017 at 10:28 PM, Daniel Vetter wrote: > On Thu, Jul 13, 2017 at 10:11 PM, Linus Torvalds > wrote: >> This one actually seems to imply that vmw_cmd_invalid() is broken: >> >> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:522:34: warning:

Re: [PATCH v2 1/5] drm/rockchip: vop: get rid of register init table

On Thu, Jul 13, 2017 at 09:33:45AM +0800, Mark yao wrote: > On 2017年07月13日 00:47, Sean Paul wrote: > > On Wed, Jul 12, 2017 at 10:03:27AM +0800, Mark Yao wrote: > > > Register init table use un-document define, it is unreadable, > > > And sometimes we only want to update tiny bits, init table > >

Re: vmgfx gcc-7.1.1 warning..

On Thu, Jul 13, 2017 at 10:11 PM, Linus Torvalds wrote: > This one actually seems to imply that vmw_cmd_invalid() is broken: > > drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:522:34: warning: the omitted > middle operand in ?: will always be ‘true’, suggest explicit

Re: [PATCH v2 4/5] drm/rockchip: vop: add a series of vop support

On Wed, Jul 12, 2017 at 9:31 PM, Mark yao wrote: > On 2017年07月13日 02:33, Sean Paul wrote: > > On Wed, Jul 12, 2017 at 10:03:54AM +0800, Mark Yao wrote: > > Vop Full framework now has following vops: > IP versionchipname > 3.1 rk3288 > 3.2

Re: [PATCH 2/2] dim: Try to gc the rr-cache

On Wed, Jul 12, 2017 at 02:12:24PM +0200, Daniel Vetter wrote: > The problem is that we have a distributed cache - every committer has > a copy. Which means even just a slight clock skew will make sure that > a naive gc algorithm results in lots of thrashing around. > > To fix this add a huge

Re: [PATCH 1/2] dim: Move all rerere updating into helpers

On Wed, Jul 12, 2017 at 02:12:23PM +0200, Daniel Vetter wrote: > Just prep work. > > Signed-off-by: Daniel Vetter Reviewed-by: Sean Paul > --- > dim | 61 ++--- > 1 file changed, 34

vmgfx gcc-7.1.1 warning..

This one actually seems to imply that vmw_cmd_invalid() is broken: drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:522:34: warning: the omitted middle operand in ?: will always be ‘true’, suggest explicit middle operand [-Wparentheses] return capable(CAP_SYS_ADMIN) ? : -EINVAL;

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

On Thu, Jul 13, 2017 at 10:42 AM, Ville Syrjälä wrote: > On Thu, Jul 13, 2017 at 09:23:11AM -0700, Stéphane Marchesin wrote: >> On Thu, Jul 13, 2017 at 3:13 AM, Ville Syrjälä >> wrote: >> > On Wed, Jul 12, 2017 at 07:28:14PM -0700,

Re: [PATCH 1/4] drm/atomic: implement drm_atomic_helper_commit_tail for runtime_pm users

On Thu, Jul 13, 2017 at 04:41:13PM +0200, Maxime Ripard wrote: > The current drm_atomic_helper_commit_tail helper works only if the CRTC is > accessible, and documents an alternative implementation that is supposed to > be used if that happens. > > That implementation is then duplicated by some

Re: [Intel-gfx] [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

On Thu, Jul 13, 2017 at 06:29:33PM +0530, Ramalingam C wrote: > > > On Thursday 13 July 2017 04:06 PM, Daniel Vetter wrote: > > On Thu, Jul 13, 2017 at 12:15 PM, Ramalingam C > > wrote: > > > > > > On Thursday 13 July 2017 02:15 PM, Daniel Vetter wrote: > > > > > > On

Re: 4.9-rc1 lockdep warning suggesting a deadlock between nouveau and i915 with prime video outputs active

On Thu, Jul 13, 2017 at 03:04:58PM +0100, Chris Wilson wrote: > Quoting Jiri Slaby (2017-07-13 14:57:31) > > Stealing this thread as an opensuse user hit that too: > > https://bugzilla.suse.com/show_bug.cgi?id=1045105 > > It's a false positive. I did once upon a time send some patches to move >

Re: [PATCH 1/4] fbcon: Make fbcon a built-time depency for fbdev

On Thu, Jul 13, 2017 at 4:47 PM, Sean Paul wrote: > On Thu, Jul 06, 2017 at 02:57:32PM +0200, Daniel Vetter wrote: > > > >> Cc: dri-devel@lists.freedesktop.org >> Signed-off-by: Daniel Vetter > > Just 2 nits, code looks good. > > Reviewed-by: Sean

[Bug 101644] Applying for drm-misc commit rights

https://bugs.freedesktop.org/show_bug.cgi?id=101644 Daniel Vetter changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop

[Bug 101644] Applying for drm-misc commit rights

https://bugs.freedesktop.org/show_bug.cgi?id=101644 Daniel Vetter changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment

Re: [PATCH v2 4/4] drm/tinydrm: Add RePaper e-ink driver

Den 13.07.2017 19.52, skrev Eric Anholt: Noralf Trønnes writes: Den 28.06.2017 16.27, skrev Noralf Trønnes: Den 26.06.2017 11.49, skrev Daniel Vetter: On Thu, Jun 08, 2017 at 05:14:35PM +0200, Noralf Trønnes wrote: This adds support for the Pervasive Displays RePaper

[Bug 101644] Applying for drm-misc commit rights

https://bugs.freedesktop.org/show_bug.cgi?id=101644 --- Comment #2 from Noralf Trønnes --- Missing step: Name: Noralf Trønnes Email: nor...@tronnes.org Preferred account name: notro -- You are receiving this mail because: You are the assignee for the

Re: [PATCH v2 4/4] drm/tinydrm: Add RePaper e-ink driver

Noralf Trønnes writes: > Den 28.06.2017 16.27, skrev Noralf Trønnes: >> >> Den 26.06.2017 11.49, skrev Daniel Vetter: >>> On Thu, Jun 08, 2017 at 05:14:35PM +0200, Noralf Trønnes wrote: This adds support for the Pervasive Displays RePaper branded displays. The

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

On Thu, Jul 13, 2017 at 09:23:11AM -0700, Stéphane Marchesin wrote: > On Thu, Jul 13, 2017 at 3:13 AM, Ville Syrjälä > wrote: > > On Wed, Jul 12, 2017 at 07:28:14PM -0700, Stéphane Marchesin wrote: > >> On Fri, May 5, 2017 at 10:40 AM, Ville Syrjälä > >>

[Bug 196197] [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

https://bugzilla.kernel.org/show_bug.cgi?id=196197 --- Comment #8 from Andreas Brogle (an...@ok.de) --- Hello, is there a chance that this bug will be fixed ? Or would it be easier to install another graphics card ? Greetings, Andreas -- You are receiving this mail because: You are watching the

Re: [PATCH] drm/udl: Make page_flip asynchronous

On Thu, Jul 13, 2017 at 6:25 PM, Stéphane Marchesin wrote: >> Can't we roll this driver over to the atomic helpers instead? There >> you get nonblocking pretty much for free ... I'm not sure extending >> the old modeset code has all that much benefit really. > > This

Re: [PATCH] drm/udl: Make page_flip asynchronous

On Mon, Jul 10, 2017 at 11:58 PM, Daniel Vetter wrote: > On Fri, Jul 7, 2017 at 7:48 AM, Dawid Kurek > wrote: >> In page_flip vblank is sent with no delay. Driver does not know when the >> actual update is present on the display and has no means for

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

On Thu, Jul 13, 2017 at 3:13 AM, Ville Syrjälä wrote: > On Wed, Jul 12, 2017 at 07:28:14PM -0700, Stéphane Marchesin wrote: >> On Fri, May 5, 2017 at 10:40 AM, Ville Syrjälä >> wrote: >> > >> > On Fri, May 05, 2017 at 10:26:36AM

Re: [PATCH v2 06/14] drm/edid: parse YCBCR420 videomodes from EDID

On Thu, Jul 13, 2017 at 09:03:12PM +0530, Shashank Sharma wrote: > HDMI 2.0 spec adds support for YCBCR420 sub-sampled output. > CEA-861-F adds two new blocks in EDID's CEA extension blocks, > to provide information about sink's YCBCR420 output capabilities. > > These blocks are: > > -

Re: [PATCH 01/18] regmap: mmio: Add function to attach a clock

On Thu, Jul 13, 2017 at 04:12:56PM +0200, Maxime Ripard wrote: > This might be problematic if the clock to enable is stored in another node. > Let's add a function that allows to attach a clock that has already been > retrieved to a regmap in order to fix this. What is the use case for this?

Re: [PATCH 13/16] drm/mediatek: Convert to new iterator macros

Op 12-07-17 om 11:45 schreef Daniel Vetter: > On Wed, Jul 12, 2017 at 10:13:41AM +0200, Maarten Lankhorst wrote: >> for_each_obj_in_state is about to be removed, so use the new atomic >> iterator macros. >> >> Signed-off-by: Maarten Lankhorst >> Cc: CK Hu

Re: [PATCH v2 4/4] drm/tinydrm: Add RePaper e-ink driver

Den 28.06.2017 16.27, skrev Noralf Trønnes: Den 26.06.2017 11.49, skrev Daniel Vetter: On Thu, Jun 08, 2017 at 05:14:35PM +0200, Noralf Trønnes wrote: This adds support for the Pervasive Displays RePaper branded displays. The controller code is taken from the userspace driver available

[PATCH v2 12/14] drm/i915: prepare csc unit for YCBCR420 output

To support ycbcr output, we need a pipe CSC block to do RGB->YCBCR conversion. Current Intel platforms have only one pipe CSC unit, so we can either do color correction using it, or we can perform RGB->YCBCR conversion. This function adds a csc handler, which uses recommended bspec values to

[PATCH v2 14/14] drm/i915/glk: set HDMI 2.0 identifier

This patch sets the is_hdmi2_src identifier in drm connector for GLK platform. GLK contains a native HDMI 2.0 controller. This identifier will help the EDID handling functions to save lot of work which is specific to HDMI 2.0 sources. V3: Added this patch V4: Rebase V4: Rebase V5: Added r-b from

[PATCH v2 13/14] drm/i915: set colorspace for YCBCR420 outputs

When output colorspace is YCBCR420, we have to load the corresponding colorspace in AVI infoframe. This patch fills the colorspace of AVI infoframe as per the output mode. V2: Rebase V3: Rebase V4: Rebase V5: Added r-b from Ander V6: Checking RGB/YCBCR420 output only (Ville) V7: Add colorspace

[PATCH v2 09/14] drm/i915: add config function for YCBCR420 outputs

This patch checks encoder level support for YCBCR420 outputs. The logic goes as simple as this: If the input mode is YCBCR420-only mode: prepare HDMI for YCBCR420 output, else continue with RGB output mode. It checks if the mode is YCBCR420 and source can support this output then it marks the

[PATCH v2 10/14] drm/i915: prepare scaler for YCBCR420 modeset

To get a YCBCR420 output from intel platforms, we need one scaler to scale down YCBCR444 samples to YCBCR420 samples. This patch: - Does scaler allocation for HDMI ycbcr420 outputs. - Programs PIPE_MISC register for ycbcr420 output. - Adds a new scaler user "HDMI output" to plug-into existing

[PATCH v2 11/14] drm/i915: prepare pipe for YCBCR420 output

To get HDMI YCBCR420 output, the PIPEMISC register should be programmed to: - Generate YCBCR output (bit 11) - In case of YCBCR420 outputs, it should be programmed in full blend mode to use the scaler in 5x3 ratio (bits 26 and 27) This patch: - Adds definition of these bits. - Programs PIPEMISC

[PATCH v2 08/14] drm: add helper functions for YCBCR420 handling

This patch adds helper functions for YCBCR 420 handling. These functions do: - check if a given video mode is YCBCR 420 only mode. - check if a given video mode is YCBCR 420 also mode. V2: Added YCBCR functions as helpers in DRM layer, instead of keeping it in I915 layer. V3: Added handling

[PATCH v2 07/14] drm/edid: parse ycbcr 420 deep color information

CEA-861-F spec adds ycbcr420 deep color support information in hf-vsdb block. This patch extends the existing hf-vsdb parsing function by adding parsing of ycbcr420 deep color support from the EDID and adding it into display information stored. V2: Rebase V3: Rebase V4: Moved definition of

[PATCH v2 06/14] drm/edid: parse YCBCR420 videomodes from EDID

HDMI 2.0 spec adds support for YCBCR420 sub-sampled output. CEA-861-F adds two new blocks in EDID's CEA extension blocks, to provide information about sink's YCBCR420 output capabilities. These blocks are: - YCBCR420vdb(YCBCR 420 video data block): This block contains VICs of video modes, which

[PATCH v2 05/14] drm: add helper to validate YCBCR420 modes

YCBCR420 modes are supported only on HDMI 2.0 capable sources. This patch adds: - A drm helper to validate YCBCR420-only mode on a particular connector. This function will help pruning the YCBCR420-only modes from the connector's modelist. - A bool variable (ycbcr_420_allowed) in the drm

[PATCH v2 04/14] drm/edid: cleanup patch for CEA extended-tag macro

CEA-861-F introduces extended tag codes for EDID extension blocks, which indicates the actual type of the data block. The code for using exteded tag is 0x7, whereas in the existing code, the corresponding macro is named as "VIDEO_CAPABILITY_BLOCK" This patch renames the macro and usages from

[PATCH v2 02/14] drm/edid: complete CEA modedb(VIC 1-107)

CEA-861-F specs defines new video modes to be used with HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to 1-107. Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now to be able to parse new CEA modes using the existing methods, we have to complete the modedb (VIC=65

[PATCH v2 03/14] drm/edid: parse sink information before CEA blocks

CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks. This block contains a map of indexes of CEA modes, which can support YCBCR 420 output also. To avoid multiple parsing of same CEA block, let's parse the sink information and get this map, before parsing CEA modes. This patch moves the

[PATCH v2 01/14] drm: handle HDMI 2.0 VICs in AVI info-frames

HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). For any other mode, the VIC filed in AVI infoframes should be 0. HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is extended to (VIC 1-107). This patch adds a bool input variable, which indicates if

[PATCH v2 00/14] YCBCR 4:2:0 handling in DRM layer

Following YCBCR 4:4:4 and 4:2:2, YCBCR 4:2:0 is a new output format, which is currently supported on HDMI 2.0 sources/sinks. Due to lower chroma sub-sampling rate, YCBCR 4:2:0 can drive the video modes at half the pixel clock than YCBCR 4:4:4 or RGB 8:8:8 outputs. For example, a CEA 4K@60, RGB

Re: [PATCH 4/4] drm/: Drop fbdev info flags

On Thu, Jul 06, 2017 at 02:57:35PM +0200, Daniel Vetter wrote: > - FBINFO_CAN_FORCE_OUTPUT has been a lie ever since we nerfed > the entire panic handling code in our fbdev emulation. We might > restore kms panic output, but not through the bazillion of legacy > code layers called

  1   2   >