[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: There is only one fault register from Gen8 onwards (rev2)

== Series Details == Series: drm/i915: There is only one fault register from Gen8 onwards (rev2) URL : https://patchwork.freedesktop.org/series/26317/ State : success == Summary == Series 26317v2 drm/i915: There is only one fault register from Gen8 onwards

[Intel-gfx] [PATCH v2] drm/i915: There is only one fault register from Gen8 onwards

Until Haswell/Baytrail, the hardware used to have a per engine fault register (e.g. 0x4094 - render fault register, 0x4194 - media fault register, etc). But since Broadwell, all these registers were combined into a singe one, which specifies the engine id in bits 14:12. Luckily, the additional

Re: [Intel-gfx] [PATCH] drm/i915: There is only one fault register from Gen8 onwards

On 23/06/17 16:35, Chris Wilson wrote: Quoting Michel Thierry (2017-06-24 00:17:29) Until Haswell/Baytrail, the hardware used to have a per engine fault register (e.g. 0x4094 - render fault register, 0x4194 - media fault register, etc). But since Broadwell, all these registers were combined

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: There is only one fault register from Gen8 onwards

== Series Details == Series: drm/i915: There is only one fault register from Gen8 onwards URL : https://patchwork.freedesktop.org/series/26317/ State : success == Summary == Series 26317v1 drm/i915: There is only one fault register from Gen8 onwards

Re: [Intel-gfx] [PATCH] drm/i915: There is only one fault register from Gen8 onwards

Quoting Michel Thierry (2017-06-24 00:17:29) > Until Haswell/Baytrail, the hardware used to have a per engine fault > register (e.g. 0x4094 - render fault register, 0x4194 - media fault > register, etc). But since Broadwell, all these registers were combined > into a singe one, which specifies the

[Intel-gfx] [PATCH] drm/i915: There is only one fault register from Gen8 onwards

Until Haswell/Baytrail, the hardware used to have a per engine fault register (e.g. 0x4094 - render fault register, 0x4194 - media fault register, etc). But since Broadwell, all these registers were combined into a singe one, which specifies the engine id in bits 14:12. Luckily, the additional

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

> -Original Message- > From: Gerd Hoffmann [mailto:kra...@redhat.com] > Sent: Tuesday, June 20, 2017 6:58 PM > To: Zhang, Tina ; Alex Williamson > > Cc: intel-gfx@lists.freedesktop.org; linux-ker...@vger.kernel.org; Kirti > Wankhede

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

On Fri, 23 Jun 2017 09:26:59 +0200 Gerd Hoffmann wrote: > Hi, > > > Is this only going to support accelerated driver output, not basic > > VGA > > modes for BIOS interaction? > > Right now there is no vgabios or uefi support for the vgpu. > > But even with that in place

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Fix mutex imbalance for igt_render_engine_reset_fallback

On 23/06/17 06:19, Chris Wilson wrote: Smatch spots: drivers/gpu/drm/i915/selftests/intel_hangcheck.c:669 igt_render_engine_reset_fallback() error: double unlock 'mutex:>drm.struct_mutex' Signed-off-by: Chris Wilson Reviewed-by: Michel Thierry

[Intel-gfx] ✗ Fi.CI.BAT: failure for Blobifiers (FKA GET_PLANE2)

== Series Details == Series: Blobifiers (FKA GET_PLANE2) URL : https://patchwork.freedesktop.org/series/26304/ State : failure == Summary == CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK

[Intel-gfx] [PATCH 3/4] drm/i915: Add format modifiers for Intel

This was based on a patch originally by Kristian. It has been modified pretty heavily to use the new callbacks from the previous patch. v2: - Add LINEAR and Yf modifiers to list (Ville) - Combine i8xx and i965 into one list of formats (Ville) - Allow 1010102 formats for Y/Yf tiled (Ville)

[Intel-gfx] [PATCH 4/4] drm/i915: Add support for CCS modifiers

v2: Support sprite plane. Support pipe C/D limitation on GEN9. This requires rebase on the correct Ville patches Cc: Daniel Stone Cc: Kristian Høgsberg Signed-off-by: Ben Widawsky --- drivers/gpu/drm/i915/intel_display.c | 34

[Intel-gfx] [PATCH 2/4] drm: Create a format/modifier blob

Updated blob layout (Rob, Daniel, Kristian, xerpi) v2: * Removed __packed, and alignment (.+) * Fix indent in drm_format_modifier fields (Liviu) * Remove duplicated modifier > 64 check (Liviu) * Change comment about modifier (Liviu) * Remove arguments to blob creation, use plane instead (Liviu) *

[Intel-gfx] [PATCH v4 0/4] Blobifiers (FKA GET_PLANE2)

These patches create the blob property for modifiers, and the implementation for i915 modifiers. This [generally] has been tested in Weston by Daniel Stone as well as an earlier version of kmscube. This patch series was formerly known as "GET_PLANE2" because the interface for obtaining the

[Intel-gfx] [PATCH 1/4] drm: Plumb modifiers through plane init

This is the plumbing for supporting fb modifiers on planes. Modifiers have already been introduced to some extent, but this series will extend this to allow querying modifiers per plane. Based on this, the client to enable optimal modifications for framebuffers. This patch simply allows the DRM

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

On Fri, 23 Jun 2017 10:31:28 +0200 Gerd Hoffmann wrote: > On Fri, 2017-06-23 at 15:49 +0800, Zhi Wang wrote: > > Hi: > >  Thanks for the discussions! If the userspace application has  > > already maintained a LRU list, it looks like we don't need > > generation  > >

Re: [Intel-gfx] [PATCH 00/13] RESEND: remove drm_vblank_cleanup from drivers

On Wed, Jun 21, 2017 at 10:28:37AM +0200, Daniel Vetter wrote: > Hi all, > > This is the resend of the driver patches which haven't seen and ack/r-b yet > and > so aren't merged yet. I'd really like to get them all merged. Review/acks very > much appreciated. > > Thanks, Daniel > > Daniel

Re: [Intel-gfx] [RFC i-g-t 1/4] igt: Remove default from the engine list

On 23/06/2017 15:17, Szwichtenberg, Radoslaw wrote: On Fri, 2017-06-23 at 12:31 +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Default is not an engine but an ABI alias for RCS. Remove it from the engine list to eliminate redundant subtests and test passes. Does

Re: [Intel-gfx] [RFC i-g-t 1/4] igt: Remove default from the engine list

On Fri, 2017-06-23 at 12:31 +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Default is not an engine but an ABI alias for RCS. Remove it > from the engine list to eliminate redundant subtests and test > passes. Does it mean that we will have an ABI part that we

Re: [Intel-gfx] [PATCH 11/13] drm/vmwgfx: Drop drm_vblank_cleanup

On Wed, Jun 21, 2017 at 10:28:48AM +0200, Daniel Vetter wrote: > Again stopping the vblank before uninstalling the irq handler is kinda > the wrong way round, but the fb_off stuff should take care of > disabling the dsiplay at least in most cases. So drop the > drm_vblank_cleanup code since it's

[Intel-gfx] ✓ Fi.CI.BAT: success for fbdev helper locking rework and deferred setup (rev2)

== Series Details == Series: fbdev helper locking rework and deferred setup (rev2) URL : https://patchwork.freedesktop.org/series/26171/ State : success == Summary == Series 26171v2 fbdev helper locking rework and deferred setup

Re: [Intel-gfx] [PATCH 08/13] drm/rockchip: Drop drm_vblank_cleanup

On Wed, Jun 21, 2017 at 10:28:45AM +0200, Daniel Vetter wrote: > Either not relevant (in the load error paths) or done better already > (in the unload code, by calling drm_atomic_helper_shutdown). Drop it. > > Cc: Mark Yao > Signed-off-by: Daniel Vetter

[Intel-gfx] [PATCH i-g-t v2] lib/ioctl_wrappers: Fix function descriptions

Function description incorrectly stated that gem_context_get_param and gem_context_set_param were freeing hw context. v2: removed additional incorrect information Signed-off-by: Radoslaw Szwichtenberg --- lib/ioctl_wrappers.c | 12 1 file changed,

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Track user GTT faulting per-vma

== Series Details == Series: series starting with [1/3] drm/i915: Track user GTT faulting per-vma URL : https://patchwork.freedesktop.org/series/26290/ State : success == Summary == Series 26290v1 Series without cover letter

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Fix mutex imbalance for igt_render_engine_reset_fallback

== Series Details == Series: drm/i915/selftests: Fix mutex imbalance for igt_render_engine_reset_fallback URL : https://patchwork.freedesktop.org/series/26288/ State : success == Summary == Series 26288v1 drm/i915/selftests: Fix mutex imbalance for igt_render_engine_reset_fallback

[Intel-gfx] [PATCH] drm/fb-helper: Support deferred setup

From: Thierry Reding FB helper code falls back to a 1024x768 mode if no outputs are connected or don't report back any modes upon initialization. This can be annoying because outputs that are added to FB helper later on can't be used with FB helper if they don't support a

[Intel-gfx] [PATCH 3/3] drm/i915: Try a minimal attempt to insert the whole object for relocations

As we have a lightweight fallback to insert a single page into the aperture, try to avoid any heavier evictions when attempting to insert the entire object. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +++- 1 file changed, 3

[Intel-gfx] [PATCH 2/3] drm/i915: Only revoke the partial vma when releasing a fence register

As we may be using a partial vma for fence allocation, rather then revoke the mmap of all vma on the object only revoke the overlapping mmap for this fence. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_fence_reg.c | 4 ++--

[Intel-gfx] [PATCH 1/3] drm/i915: Track user GTT faulting per-vma

We don't wish to refault the entire object (other vma) when unbinding one partial vma. To do this track which vma have been faulted into the user's address space. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 31

[Intel-gfx] [PATCH i-g-t] lib/ioctl_wrappers: Fix function descriptions

Function description incorrectly stated that gem_context_get_param and gem_context_set_param were freeing hw context. Signed-off-by: Radoslaw Szwichtenberg --- lib/ioctl_wrappers.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

[Intel-gfx] [PATCH] drm/i915/selftests: Fix mutex imbalance for igt_render_engine_reset_fallback

Smatch spots: drivers/gpu/drm/i915/selftests/intel_hangcheck.c:669 igt_render_engine_reset_fallback() error: double unlock 'mutex:>drm.struct_mutex' Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 21 ++--- 1 file

Re: [Intel-gfx] [PATCH v3] drm/i915: Break modeset deadlocks on reset

Quoting Tvrtko Ursulin (2017-06-23 13:35:24) > > On 22/06/2017 11:56, Chris Wilson wrote: > > Trying to do a modeset from within a reset is fraught with danger. We > > can fall into a cyclic deadlock where the modeset is waiting on a > > previous modeset that is waiting on a request, and since

Re: [Intel-gfx] [PATCH v3] drm/i915: Break modeset deadlocks on reset

On 22/06/2017 11:56, Chris Wilson wrote: Trying to do a modeset from within a reset is fraught with danger. We can fall into a cyclic deadlock where the modeset is waiting on a previous modeset that is waiting on a request, and since the GPU hung that request completion is waiting on the reset.

Re: [Intel-gfx] [PATCH 00/12] fbdev helper locking rework and deferred setup

On Fri, Jun 23, 2017 at 09:38:49AM +0200, Daniel Vetter wrote: > On Thu, Jun 22, 2017 at 4:54 PM, Liviu Dudau wrote: > > On Wed, Jun 21, 2017 at 08:28:03PM +0200, Daniel Vetter wrote: > >> Hi all, > >> > >> This is Thierry's deferred fbdev setup series, with the locking rework

Re: [Intel-gfx] [kbuild-all] [RFC PATCH drm-intel] drm: arcpgu: arc_pgu_crtc_mode_valid() can be static

On Fri, Jun 23, 2017 at 01:08:17PM +0200, Daniel Vetter wrote: On Fri, Jun 23, 2017 at 06:51:05PM +0800, Fengguang Wu wrote: Hi Daniel, On Fri, Jun 23, 2017 at 12:30:17PM +0200, Daniel Vetter wrote: > On Fri, Jun 23, 2017 at 05:54:18PM +0800, kbuild test robot wrote: > > > > Signed-off-by:

Re: [Intel-gfx] [RFC 2/2] drm/i915: Engine capabilities uAPI

Quoting Tvrtko Ursulin (2017-06-23 12:58:19) > > On 21/06/2017 10:45, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2017-06-21 10:13:57) > >> From: Tvrtko Ursulin > >> > >> This is a lighter-weight alternative to the previously posted > >> RFC titled "drm/i915: Engine

Re: [Intel-gfx] [RFC 2/2] drm/i915: Engine capabilities uAPI

On 21/06/2017 10:45, Chris Wilson wrote: Quoting Tvrtko Ursulin (2017-06-21 10:13:57) From: Tvrtko Ursulin This is a lighter-weight alternative to the previously posted RFC titled "drm/i915: Engine discovery uAPI" which still allows some engine configuration probing

[Intel-gfx] [RFC i-g-t 3/4] gem_sync: Add all and store_all subtests

From: Tvrtko Ursulin Extended versions of the already existing short tests. Signed-off-by: Tvrtko Ursulin --- tests/gem_sync.c | 5 + 1 file changed, 5 insertions(+) diff --git a/tests/gem_sync.c b/tests/gem_sync.c index

[Intel-gfx] [RFC i-g-t 2/4] gem_exec_basic: Exercise the default engine selection

From: Tvrtko Ursulin Exercise the ABI with a basic test now that we have removed the defaul engine alias from the engine list. Signed-off-by: Tvrtko Ursulin --- tests/gem_exec_basic.c| 9 +

[Intel-gfx] [RFC i-g-t 4/4] extended.testlist: Remove some test-subtest combinations

From: Tvrtko Ursulin For tests with attempt to hit races and such by running for relatively long time, it seems that it might be possible to get by only testing some subtest-engine combinations as long as in total we still exercise all engines per test. More precisely,

[Intel-gfx] [RFC i-g-t 0/4] Redundant test pruning

From: Tvrtko Ursulin Small series which saves test execution time by removing the redundant tests. Tvrtko Ursulin (4): igt: Remove default from the engine list gem_exec_basic: Exercise the default engine selection gem_sync: Add all and store_all subtests

[Intel-gfx] [RFC i-g-t 1/4] igt: Remove default from the engine list

From: Tvrtko Ursulin Default is not an engine but an ABI alias for RCS. Remove it from the engine list to eliminate redundant subtests and test passes. Signed-off-by: Tvrtko Ursulin --- lib/igt_gt.c | 1 -

Re: [Intel-gfx] [RFC i-g-t 1/2] extended.testlist: Remove default and render engine test duplicates

Quoting Daniel Vetter (2017-06-23 12:14:49) > On Thu, Jun 22, 2017 at 12:45 PM, Tvrtko Ursulin > wrote: > > > > On 22/06/2017 10:54, Daniel Vetter wrote: > >> > >> On Fri, Jun 16, 2017 at 12:55 PM, Tvrtko Ursulin > >> wrote: > >>> > >>> From:

Re: [Intel-gfx] [PATCH v2] drm/vgem: Pin our pages for dmabuf exports

Quoting Daniel Vetter (2017-06-23 12:02:53) > On Thu, Jun 22, 2017 at 02:46:17PM +0100, Chris Wilson wrote: > > + /* Flush the object from the CPU cache so that importers can rely > > + * on coherent indirect access via the exported dma-address. > > + */ > >

Re: [Intel-gfx] [RFC i-g-t 1/2] extended.testlist: Remove default and render engine test duplicates

On Thu, Jun 22, 2017 at 12:45 PM, Tvrtko Ursulin wrote: > > On 22/06/2017 10:54, Daniel Vetter wrote: >> >> On Fri, Jun 16, 2017 at 12:55 PM, Tvrtko Ursulin >> wrote: >>> >>> From: Tvrtko Ursulin >>> >>> Where there

Re: [Intel-gfx] [kbuild-all] [RFC PATCH drm-intel] drm: arcpgu: arc_pgu_crtc_mode_valid() can be static

On Fri, Jun 23, 2017 at 06:51:05PM +0800, Fengguang Wu wrote: > Hi Daniel, > > On Fri, Jun 23, 2017 at 12:30:17PM +0200, Daniel Vetter wrote: > > On Fri, Jun 23, 2017 at 05:54:18PM +0800, kbuild test robot wrote: > > > > > > Signed-off-by: Fengguang Wu > > > > Oops,

[Intel-gfx] ✗ Fi.CI.BAT: failure for improve the fb_setcmap helper (rev4)

== Series Details == Series: improve the fb_setcmap helper (rev4) URL : https://patchwork.freedesktop.org/series/26281/ State : failure == Summary == Series 26281v4 improve the fb_setcmap helper https://patchwork.freedesktop.org/api/1.0/series/26281/revisions/4/mbox/ Test kms_sink_crc_basic:

Re: [Intel-gfx] [PATCH v2] drm/vgem: Pin our pages for dmabuf exports

On Fri, Jun 23, 2017 at 01:02:53PM +0200, Daniel Vetter wrote: > Anyway looks all good, will push to drm-misc-fixes. Correction, pushed to -misc-next because it conflicts with the dma-buf import stuff from Laura and other bits. If you want it in -fixes I need a backport. I left the cc: stable in

Re: [Intel-gfx] [PATCH v2] drm/vgem: Pin our pages for dmabuf exports

On Thu, Jun 22, 2017 at 02:46:17PM +0100, Chris Wilson wrote: > When the caller maps their dmabuf and we return an sg_table, the caller > doesn't expect the pages beneath that sg_table to vanish on a whim (i.e. > under mempressure). The contract is that the pages are pinned for the > duration of

Re: [Intel-gfx] [kbuild-all] [RFC PATCH drm-intel] drm: arcpgu: arc_pgu_crtc_mode_valid() can be static

Hi Daniel, On Fri, Jun 23, 2017 at 12:30:17PM +0200, Daniel Vetter wrote: On Fri, Jun 23, 2017 at 05:54:18PM +0800, kbuild test robot wrote: Signed-off-by: Fengguang Wu Oops, missed that, applied. Btw, for regression fixes like that, could you perhaps auto-generate

Re: [Intel-gfx] [PATCH] drm/i915: Avoid keeping waitboost active for signaling threads

Quoting Michał Winiarski (2017-06-23 11:35:06) > On Thu, Jun 22, 2017 at 11:55:51AM +0100, Chris Wilson wrote: > > Once a client has requested a waitboost, we keep that waitboost active > > until all clients are no longer waiting. This is because we don't > > distinguish which waiter deserves the

Re: [Intel-gfx] [PATCH] drm/i915: Avoid keeping waitboost active for signaling threads

On Thu, Jun 22, 2017 at 11:55:51AM +0100, Chris Wilson wrote: > Once a client has requested a waitboost, we keep that waitboost active > until all clients are no longer waiting. This is because we don't > distinguish which waiter deserves the boost. However, with the advent of > fence signaling,

Re: [Intel-gfx] [RFC PATCH drm-intel] drm: arcpgu: arc_pgu_crtc_mode_valid() can be static

On Fri, Jun 23, 2017 at 05:54:18PM +0800, kbuild test robot wrote: > > Signed-off-by: Fengguang Wu Oops, missed that, applied. Btw, for regression fixes like that, could you perhaps auto-generate the Fixes: line per the kernel process? Makes it easier for me to know

Re: [Intel-gfx] [PATCH v5 7/7] drm: create hdmi output property

On Fri, Jun 23, 2017 at 03:35:30PM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 6/23/2017 2:50 PM, Daniel Vetter wrote: > > On Thu, Jun 22, 2017 at 10:33 AM, Sharma, Shashank > > wrote: > > > > - The property values should be limited to what the

[Intel-gfx] [PATCH 01/11] drm/fb-helper: do a generic fb_setcmap helper in terms of crtc .gamma_set

This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get totally obsolete. I think the gamma_store can end up invalid on error. But the way I read it, that can happen in drm_mode_gamma_set_ioctl as well, so why should this pesky legacy fbdev stuff be any better?

[Intel-gfx] [PATCH v2 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. Signed-off-by: Peter Rosin ---

[Intel-gfx] [PATCH] drm/i915: select CRC32

kbuild test robot found a build failure when building with thin archives: http://marc.info/?l=linux-kbuild=149802285009737=2 Signed-off-by: Nicholas Piggin --- drivers/gpu/drm/i915/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/Kconfig

Re: [Intel-gfx] [PATCH 01/11] drm/fb-helper: do a generic fb_setcmap helper in terms of crtc .gamma_set

On 2017-06-21 09:38, Daniel Vetter wrote: > On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote: >> This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get >> totally obsolete. >> >> I think the gamma_store can end up invalid on error. But the way I read >> it, that can

[Intel-gfx] [PATCH v2 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. Signed-off-by: Peter Rosin ---

[Intel-gfx] [PATCH v2 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. Signed-off-by: Peter Rosin ---

[Intel-gfx] [PATCH 10/11] 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. Signed-off-by: Peter Rosin --- drivers/gpu/drm/stm/ltdc.c | 12

[Intel-gfx] [PATCH 05/11] dmr: 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. It is a bit strange that the fb helper .load_lut was not hooked up, so this change may well

[Intel-gfx] [PATCH v2 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. Signed-off-by: Peter Rosin ---

[Intel-gfx] [PATCH v2 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. Signed-off-by: Peter Rosin --- drivers/gpu/drm/armada/armada_crtc.c | 10 -- drivers/gpu/drm/armada/armada_crtc.h | 2 -- drivers/gpu/drm/armada/armada_fbdev.c | 2 -- 3

[Intel-gfx] [PATCH v2 03/14] drm/fb-helper: do a generic fb_setcmap helper in terms of crtc .gamma_set

This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get totally obsolete. Signed-off-by: Peter Rosin --- drivers/gpu/drm/drm_fb_helper.c | 151 +--- 1 file changed, 63 insertions(+), 88 deletions(-) This is an alternative

Re: [Intel-gfx] [PATCH v2 13/14] drm: stm: remove dead code and pointless local lut storage

On 2017-06-22 13:49, Philippe CORNU wrote: > On 06/22/2017 08:06 AM, Peter Rosin wrote: >> 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. >> > > Hi

[Intel-gfx] [PATCH 09/11] 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. Signed-off-by: Peter Rosin ---

[Intel-gfx] [PATCH v2 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. Signed-off-by: Peter Rosin --- drivers/gpu/drm/gma500/framebuffer.c |

[Intel-gfx] [PATCH 04/11] 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. Signed-off-by: Peter Rosin ---

[Intel-gfx] [PATCH 07/11] 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. Signed-off-by: Peter Rosin ---

[Intel-gfx] [PATCH v2 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. Signed-off-by: Peter Rosin --- include/drm/drm_fb_helper.h | 32 include/drm/drm_modeset_helper_vtables.h | 16

Re: [Intel-gfx] [PATCH 08/11] drm: nouveau: remove dead code and pointless local lut storage

On 2017-06-20 21:25, Peter Rosin wrote: > 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. [...] > - for (i = 0; i < 256;

[Intel-gfx] [PATCH 00/11] 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. Boris and Daniel, was this approximately what you had

[Intel-gfx] [PATCH 02/11] 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. Signed-off-by: Peter Rosin ---

[Intel-gfx] [PATCH v2 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

[Intel-gfx] [PATCH v2 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. Signed-off-by: Peter Rosin --- drivers/gpu/drm/ast/ast_drv.h |

[Intel-gfx] [PATCH v2 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. Signed-off-by: Peter Rosin ---

Re: [Intel-gfx] [PATCH 01/11] drm/fb-helper: do a generic fb_setcmap helper in terms of crtc .gamma_set

On 2017-06-22 08:36, Daniel Vetter wrote: > On Wed, Jun 21, 2017 at 11:40:52AM +0200, Peter Rosin wrote: >> On 2017-06-21 09:38, Daniel Vetter wrote: >>> On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote: This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get

[Intel-gfx] [PATCH v2 02/14] drm/fb-helper: remove drm_fb_helper_save_lut_atomic

drm_fb_helper_save_lut_atomic is redundant since the .gamma_store is now always kept up to date by drm_fb_helper_setcmap. Signed-off-by: Peter Rosin --- drivers/gpu/drm/drm_fb_helper.c | 17 - 1 file changed, 17 deletions(-) diff --git

[Intel-gfx] [PATCH 08/11] 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. Signed-off-by: Peter Rosin ---

[Intel-gfx] [PATCH 03/11] 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. Signed-off-by: Peter Rosin --- drivers/gpu/drm/ast/ast_drv.h |

[Intel-gfx] [PATCH v2 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. Signed-off-by: Peter Rosin --- drivers/gpu/drm/stm/ltdc.c | 12

Re: [Intel-gfx] [PATCH] drm/i915: select CRC32

On Wed, 21 Jun 2017 10:15:56 +0100 Chris Wilson wrote: > Quoting Daniel Vetter (2017-06-21 10:13:41) > > On Wed, Jun 21, 2017 at 04:34:20PM +1000, Nicholas Piggin wrote: > > > kbuild test robot found a build failure when building with thin > > > archives: > > > > > >

[Intel-gfx] [PATCH v2 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.

[Intel-gfx] [PATCH v2 03/14] drm/fb-helper: do a generic fb_setcmap helper in terms of crtc .gamma_set

This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get totally obsolete. Signed-off-by: Peter Rosin --- drivers/gpu/drm/drm_fb_helper.c | 154 1 file changed, 63 insertions(+), 91 deletions(-) diff --git

[Intel-gfx] [PATCH 11/11] 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. Signed-off-by: Peter Rosin --- include/drm/drm_fb_helper.h | 32 include/drm/drm_modeset_helper_vtables.h | 16

[Intel-gfx] [PATCH v2 01/14] drm/fb-helper: keep the .gamma_store updated in drm_fb_helper_setcmap

I think the gamma_store can end up invalid on error. But the way I read it, that can happen in drm_mode_gamma_set_ioctl as well, so why should this pesky legacy fbdev stuff be any better? Signed-off-by: Peter Rosin --- drivers/gpu/drm/drm_fb_helper.c | 27

[Intel-gfx] [PATCH 06/11] 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.

Re: [Intel-gfx] [PATCH 09/12] drm/fb-helper: Split dpms handling into legacy and atomic paths

On 2017-06-21 20:28, Daniel Vetter wrote: > Like with panning and modesetting, and like with those, stick with > simple drm_modeset_locking_all for the legacy path, and the full > atomic dance for atomic drivers. > > This means a bit more boilerplate since setting up the atomic state > machinery

[Intel-gfx] [PATCH v2 01/14] drm/fb-helper: keep the .gamma_store updated in drm_fb_helper_setcmap

I think the gamma_store can end up invalid on error. But the way I read it, that can happen in drm_mode_gamma_set_ioctl as well, so why should this pesky legacy fbdev stuff be any better? Signed-off-by: Peter Rosin --- drivers/gpu/drm/drm_fb_helper.c | 27

Re: [Intel-gfx] [PATCH v12 0/3] Enhancement to intel_dp_aux_backlight driver

On Thu, Jun 22, 2017 at 12:03:36PM -0700, Puthikorn Voravootivat wrote: > This patch set contain 3 patches which are already reviewed by DK. > Another 6 patches in previous version was already merged in v7 and v9. > - First patch sets the PWM freqency to match data in panel vbt. > - Next patch

Re: [Intel-gfx] [PATCH v5 7/7] drm: create hdmi output property

Regards Shashank On 6/23/2017 2:50 PM, Daniel Vetter wrote: On Thu, Jun 22, 2017 at 10:33 AM, Sharma, Shashank wrote: - The property values should be limited to what the driver can support, I guess that would mean limiting the available ycbcr modes? Or does

Re: [Intel-gfx] [RESEND-CI v4 09/15] drm: add helper functions for YCBCR output handling

Regards Shashank On 6/23/2017 2:42 PM, Daniel Vetter wrote: On Thu, Jun 22, 2017 at 11:42 AM, Sharma, Shashank wrote: You should explain in 1-2 sentences what exactly this function does, and when a driver should use it. Just documenting the input/output stuff

[Intel-gfx] [RFC PATCH drm-intel] drm: arcpgu: arc_pgu_crtc_mode_valid() can be static

Signed-off-by: Fengguang Wu --- arcpgu_crtc.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c b/drivers/gpu/drm/arc/arcpgu_crtc.c index 99fbdae..611af74 100644 --- a/drivers/gpu/drm/arc/arcpgu_crtc.c +++

[Intel-gfx] [drm-intel:drm-intel-nightly 1499/1516] drivers/gpu/drm/arc/arcpgu_crtc.c:67:22: sparse: symbol 'arc_pgu_crtc_mode_valid' was not declared. Should it be static?

tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly head: cd6f0ef4478545aa014d92cabe4d794bfe54fe33 commit: 2b3d860efa3461af109469e6de2eea48f6ef5cdd [1499/1516] drm: arcpgu: Use crtc->mode_valid() callback reproduce: # apt-get install sparse git checkout

Re: [Intel-gfx] [kra...@redhat.com: Re: [PATCH v9 5/7] vfio: Define vfio based dma-buf operations]

Hi Gred and Alex: Thanks for the reply! It would be better that kernel only provides functions instead of maintaining states from my point of view. If there is any existing async notification channel in vfio device fd? like reporting device events from vfio to QEMU? If so, It would be nice

Re: [Intel-gfx] [PATCH v2 13/14] drm: stm: remove dead code and pointless local lut storage

On Thu, Jun 22, 2017 at 11:49:34AM +, Philippe CORNU wrote: > > > On 06/22/2017 08:06 AM, Peter Rosin wrote: > > 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

Re: [Intel-gfx] [PATCH v5 7/7] drm: create hdmi output property

On Thu, Jun 22, 2017 at 10:33 AM, Sharma, Shashank wrote: >> - The property values should be limited to what the driver can support, I >>guess that would mean limiting the available ycbcr modes? Or does all >>our hw support all the modes, including 420 (on the

Re: [Intel-gfx] [RESEND-CI v4 09/15] drm: add helper functions for YCBCR output handling

On Thu, Jun 22, 2017 at 11:42 AM, Sharma, Shashank wrote: >> You should explain in 1-2 sentences what exactly this function does, and >> when a driver should use it. Just documenting the input/output stuff >> doesn't make the kerneldoc all that useful. > > Did you miss

Re: [Intel-gfx] [PATCH 01/13] drm/amd|radeon: Drop drm_vblank_cleanup

On Thu, Jun 22, 2017 at 08:54:51AM -0400, Alex Deucher wrote: > On Wed, Jun 21, 2017 at 4:28 AM, Daniel Vetter wrote: > > Both drivers shut down all crtc beforehand already, which will shut up > > any pending vblank (the only thing vblank_cleanup really does is > > disable

  1   2   >