Re: [Intel-gfx] [RFC 0/3] Engine utilization tracking

On 5/9/2017 8:51 AM, Tvrtko Ursulin wrote: On 09/05/2017 16:29, Chris Wilson wrote: On Tue, May 09, 2017 at 04:16:41PM +0100, Tvrtko Ursulin wrote: On 09/05/2017 15:26, Chris Wilson wrote: On Tue, May 09, 2017 at 03:09:33PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin

Re: [Intel-gfx] [RFC 0/3] Engine utilization tracking

On 09/05/2017 16:29, Chris Wilson wrote: On Tue, May 09, 2017 at 04:16:41PM +0100, Tvrtko Ursulin wrote: On 09/05/2017 15:26, Chris Wilson wrote: On Tue, May 09, 2017 at 03:09:33PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin By popular customer demand here

Re: [Intel-gfx] [RFC 3/3] drm/i915: Export engine busy stats in debugfs

On 5/9/2017 7:09 AM, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Export the stats added in the previous patch in debugfs. Number of active clients reading this data is tracked and the static key is only enabled whilst there are some. Userspace is intended to keep

[Intel-gfx] ✗ Fi.CI.BAT: failure for Cannonpoint Enabling Patches

== Series Details == Series: Cannonpoint Enabling Patches URL : https://patchwork.freedesktop.org/series/24151/ State : failure == Summary == CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK

[Intel-gfx] [PATCH v2 5/5] ACPI: button: Obselete acpi_lid_open() invocations

Since notification side has been changed to always notify kernel listeners using _LID returning value. Now listeners needn't invoke acpi_lid_open(), it should use a spec suggested control method lid device usage model: register lid notification and use the notified value instead, which is the only

[Intel-gfx] [PATCH 2/6] drm/i915/cnp: Add PCI ID for Cannonpoint LP PCH

From: Dhinakaran Pandiyan The first two bytes of PCI ID for CNP_LP PCH are the same as that of SPT_LP. We should really be looking at the first 9 bits instead of the first 8 to identify platforms, although this seems to have not caused any problems on earlier

[Intel-gfx] [PATCH 0/6] Cannonpoint Enabling Patches

Rebased Rodrigo's patche series that enabled Cannonpoint support. https://patchwork.freedesktop.org/project/intel-gfx/patches/?submitter=13413==cnl= v2: rebased. fix compilation issues. Dhinakaran Pandiyan (1): drm/i915/cnp: Add PCI ID for Cannonpoint LP PCH Rodrigo Vivi (5): drm/i915/cnp:

[Intel-gfx] [PATCH 5/6] drm/i915/cnp: add CNP gmbus support

From: Rodrigo Vivi On CNP PCH based platforms the gmbus is on the south display that is on PCH. The existing implementation for previous platforms already covers the need for CNP expect for the pin pair configuration that follows similar definitions that we had on BXT.

[Intel-gfx] [PATCH 1/6] drm/i915/cnp: Introduce Cannonpoint PCH.

From: Rodrigo Vivi Most of south engine display that is in PCH is still the same as SPT and KBP, except for this key differences: - Backlight: Backlight programming changed in CNP PCH. - Panel Power: Sligh programming changed in CNP PCH. - GMBUS and GPIO: The pin mapping

[Intel-gfx] [PATCH 4/6] drm/i915/cnp: Backlight support for CNP.

From: Rodrigo Vivi Split out BXT and CNP's setup_backlight(),enable_backlight(), disable_backlight() and hz_to_pwm() into two separate functions instead of reusing BXT function. Reuse set_backlight() and get_backlight() since they have no reference to the utility pin.

[Intel-gfx] [PATCH 3/6] drm/i915/cnp: Get/set proper Raw clock frequency on CNP.

From: Rodrigo Vivi RAWCLK_FREQ register has changed for platforms with CNP+. [29:26] This field provides the denominator for the fractional part of the microsecond counter divider. The numerator is fixed at 1. Program this field to the denominator of

[Intel-gfx] [PATCH 6/6] drm/i915/cnp: Panel Power sequence changes for CNP PCH.

From: Rodrigo Vivi As for BXT, PP_DIVISOR was removed from CNP PCH and power cycle delay has been moved to PP_CONTROL. v2: rebased. Cc: Jani Nikula Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_dp.c | 10

[Intel-gfx] ✓ Fi.CI.BAT: success for Cannonpoint Enabling Patches (rev2)

== Series Details == Series: Cannonpoint Enabling Patches (rev2) URL : https://patchwork.freedesktop.org/series/24151/ State : success == Summary == Series 24151v2 Cannonpoint Enabling Patches https://patchwork.freedesktop.org/api/1.0/series/24151/revisions/2/mbox/ Test gem_exec_fence:

Re: [Intel-gfx] [PATCH] drm/vgem: Convert to a struct drm_device subclass

On 05/08/2017 06:22 AM, Chris Wilson wrote: With Laura's introduction of the fake platform device for importing dmabuf, we add a second static that is logically tied to the vgem_device. Convert vgem over to using the struct drm_device subclassing, so that the platform device is stored inside its

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

Chris, In set_cache_level, we change obj->cache_level then update obj->cache_coherent but I think this order has to be reversed because coherency needs to be determined based on the previous cache_level, not the new one. After chaning code as shown below: obj->cache_coherent =

[Intel-gfx] [PATCH 1/2] drm/i915: Move uncore definitions into a separate header

In order to allow use of e.g. forcewake_domains in a other feature headers included from the top of i915_drv.h, move all uncore related definitions into their own header. Signed-off-by: Michal Wajdeczko Suggested-by: Joonas Lahtinen

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Move uncore definitions into a separate header

On Tue, May 09, 2017 at 12:00:58PM +0300, Mika Kuoppala wrote: > Michal Wajdeczko writes: > > > In order to allow use of e.g. forcewake_domains in a other feature headers > > included from the top of i915_drv.h, move all uncore related definitions > > into their own

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Rename assert_forcewakes_inactive

Michal Wajdeczko writes: > All other functions related to uncore start with intel_uncore prefix. > Follow that pattern. > > Signed-off-by: Michal Wajdeczko > Cc: Joonas Lahtinen Reviewed-by: Mika Kuoppala

[Intel-gfx] [PATCH v2 1/2] drm/i915: Move uncore definitions into a separate header

In order to allow use of e.g. forcewake_domains in a other feature headers included from the top of i915_drv.h, move all uncore related definitions into their own header. v2: move __mask_next_bit macro to utils header (Mika) Signed-off-by: Michal Wajdeczko

[Intel-gfx] [PATCH 07/11] drm/i915/skl+: Fail the flip if ddb min requirement exceeds pipe allocation

DDB minimum requirement of crtc configuration (cumulative of all the enabled planes in crtc) may exceed the allocated DDB for crtc/pipe. This patch make changes to fail the flip/ioctl if minimum requirement for pipe exceeds the total ddb allocated to the pipe. Previously it succeeded but making

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Move uncore definitions into a separate header

== Series Details == Series: series starting with [1/2] drm/i915: Move uncore definitions into a separate header URL : https://patchwork.freedesktop.org/series/24161/ State : success == Summary == Series 24161v1 Series without cover letter

Re: [Intel-gfx] [PATCH 03/11] drm: parse ycbcr 420 vdb block

Regards Shashank On 5/8/2017 10:39 PM, Ville Syrjälä wrote: On Mon, May 08, 2017 at 10:11:53PM +0530, Sharma, Shashank wrote: Regards Shashank On 5/8/2017 9:54 PM, Ville Syrjälä wrote: On Fri, Apr 07, 2017 at 07:39:20PM +0300, Shashank Sharma wrote: From: Jose Abreu

[Intel-gfx] [PATCH 07/11] drm/i915/skl+: Fail the flip if ddb min requirement exceeds pipe allocation

DDB minimum requirement of crtc configuration (cumulative of all the enabled planes in crtc) may exceed the allocated DDB for crtc/pipe. This patch make changes to fail the flip/ioctl if minimum requirement for pipe exceeds the total ddb allocated to the pipe. Previously it succeeded but making

Re: [Intel-gfx] [PATCH v1] ACPI: Switch to use generic UUID API

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index 7b86508ac8cf..93b4f0de9418 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -210,13 +210,12 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci) #ifdef CONFIG_ACPI

[Intel-gfx] [PATCH 2/2] drm/i915: Rename assert_forcewakes_inactive

All other functions related to uncore start with intel_uncore prefix. Follow that pattern. Signed-off-by: Michal Wajdeczko Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_drv.c | 2 +- drivers/gpu/drm/i915/intel_uncore.c | 4

[Intel-gfx] ✓ Fi.CI.BAT: success for Implement DDB algorithm and WM cleanup (rev4)

== Series Details == Series: Implement DDB algorithm and WM cleanup (rev4) URL : https://patchwork.freedesktop.org/series/20376/ State : success == Summary == Series 20376v4 Implement DDB algorithm and WM cleanup https://patchwork.freedesktop.org/api/1.0/series/20376/revisions/4/mbox/ Test

Re: [Intel-gfx] [PATCH 04/11] drm: parse ycbcr420 vcb block

Regards Shashank On 5/8/2017 10:28 PM, Ville Syrjälä wrote: On Fri, Apr 07, 2017 at 07:39:21PM +0300, Shashank Sharma wrote: HDMI 2.0 spec adds support for ycbcr420 subsampled output. CEA-861-F adds two new blocks in EDID, to provide information about sink's support for ycbcr420 output. One

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Move uncore definitions into a separate header

Michal Wajdeczko writes: > In order to allow use of e.g. forcewake_domains in a other feature headers > included from the top of i915_drv.h, move all uncore related definitions > into their own header. > > Signed-off-by: Michal Wajdeczko >

Re: [Intel-gfx] [PATCH v4] drm/i915/gvt: return the correct usable aperture size under gvt environment

Really sorry, please ignore this mail with wrong patch. Will send the correct one then. Thanks. Best Regards. Weinan, LI > -Original Message- > From: Li, Weinan Z > Sent: Wednesday, May 10, 2017 10:48 AM > To: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org > Cc:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: return the correct usable aperture size under gvt environment (rev2)

== Series Details == Series: drm/i915/gvt: return the correct usable aperture size under gvt environment (rev2) URL : https://patchwork.freedesktop.org/series/24206/ State : success == Summary == Series 24206v2 drm/i915/gvt: return the correct usable aperture size under gvt environment

Re: [Intel-gfx] [PATCH v3] drm/i915/gvt: return the actual aperture size under gvt environment

> -Original Message- > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] > Sent: Tuesday, May 9, 2017 8:36 PM > To: Li, Weinan Z ; intel-gfx@lists.freedesktop.org; > intel- > gvt-...@lists.freedesktop.org > Cc: Chris Wilson >

[Intel-gfx] [PATCH v4] drm/i915/gvt: return the correct usable aperture size under gvt environment

I915_GEM_GET_APERTURE ioctl is used to probe aperture size from userspace. In gvt environment, each vm only use the ballooned part of aperture, so we should return the correct available aperture size exclude the reserved part by balloon. v2: add 'reserved' in struct i915_address_space to record

[Intel-gfx] [PATCH v4] drm/i915/gvt: return the correct usable aperture size under gvt environment

I915_GEM_GET_APERTURE ioctl is used to probe aperture size from userspace. In gvt environment, each vm only use the ballooned part of aperture, so we should return the correct available aperture size exclude the reserved part by balloon. v2: add 'reserved' in struct i915_address_space to record

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Move uncore definitions into a separate header

Michal Wajdeczko writes: > In order to allow use of e.g. forcewake_domains in a other feature headers > included from the top of i915_drv.h, move all uncore related definitions > into their own header. > > v2: move __mask_next_bit macro to utils header (Mika) > >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Show dmc debug registers on Kabylake

== Series Details == Series: drm/i915: Show dmc debug registers on Kabylake URL : https://patchwork.freedesktop.org/series/24171/ State : success == Summary == Series 24171v1 drm/i915: Show dmc debug registers on Kabylake

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915: Move uncore definitions into a separate header (rev2)

== Series Details == Series: series starting with [v2,1/2] drm/i915: Move uncore definitions into a separate header (rev2) URL : https://patchwork.freedesktop.org/series/24161/ State : success == Summary == Series 24161v2 Series without cover letter

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Rename assert_forcewakes_inactive

On Tue, May 09, 2017 at 07:36:09AM +, Michal Wajdeczko wrote: > All other functions related to uncore start with intel_uncore prefix. > Follow that pattern. Debatable. Fwiw, we use the assert_*() pattern frequently because that "it's a debug only function" is important to make it the first

Re: [Intel-gfx] [i-g-t PATCH 3/4] lib/igt_debugfs: Add helper to return path to device.

On Thu, Apr 20, 2017 at 11:13:47AM +0300, Abdiel Janulgue wrote: > Signed-off-by: Abdiel Janulgue > --- > lib/igt_debugfs.c | 26 ++ > lib/igt_debugfs.h | 1 + > 2 files changed, 27 insertions(+) > > diff --git a/lib/igt_debugfs.c

Re: [Intel-gfx] [PATCH i-g-t v3] lib/igt_kms: Force outputs to use full range RGB

On Tue, 2017-04-18 at 16:04 +0300, Ander Conselvan de Oliveira wrote: > In at least SKL and GLK (possibly other devices too), using a cursor > plane to scan out an fb might result in a different pipe crc than > when > using a regular plane at the same position with the same fb while > using > the

Re: [Intel-gfx] [i-g-t PATCH 4/4] Convert shell script tests to C version

On Thu, Apr 20, 2017 at 11:13:48AM +0300, Abdiel Janulgue wrote: > Converted: > - check_drm_clients (ensures no other clients are running. >functionality provided by drm_open_driver_master). > - debugfs_emon_crash > - debugfs_wedged > - drv_debugfs_reader > - sysfs_l3_parity > -

[Intel-gfx] [PATCH v2] drm/i915/gvt: disable GVT-g if host GuC submission is enabled

Currently GVT-g cannot work properly when host GuC submission is enabled, so disable GVT in this case. v2: update the user message (Joonas) Cc: Zhenyu Wang Signed-off-by: Chuanxiao Dong --- drivers/gpu/drm/i915/intel_gvt.c | 5 + 1 file

Re: [Intel-gfx] [PATCH] drm/i915: Show dmc debug registers on Kabylake

On Tue, May 09, 2017 at 01:05:22PM +0300, Mika Kuoppala wrote: > The assumption is that the registers offsets are > identical as with skl. Also all the published > kbl firmwares support the debug registers. So > let kbl show the debug counts. > > Bugzilla:

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Rename assert_forcewakes_inactive

On Tue, May 09, 2017 at 11:09:58AM +0100, Chris Wilson wrote: > On Tue, May 09, 2017 at 07:36:09AM +, Michal Wajdeczko wrote: > > All other functions related to uncore start with intel_uncore prefix. > > Follow that pattern. > > Debatable. Fwiw, we use the assert_*() pattern frequently

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: disable GVT-g if host GuC submission is enabled (rev2)

== Series Details == Series: drm/i915/gvt: disable GVT-g if host GuC submission is enabled (rev2) URL : https://patchwork.freedesktop.org/series/23796/ State : success == Summary == Series 23796v2 drm/i915/gvt: disable GVT-g if host GuC submission is enabled

Re: [Intel-gfx] [RFC 4/4] drm/i915: Expose RPCS (SSEU) configuration to userspace

On 02/05/17 12:49, Chris Wilson wrote: diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h index 34ee011f08ac..106d9140d65e 100644 --- a/include/uapi/drm/i915_drm.h +++ b/include/uapi/drm/i915_drm.h @@ -1327,6 +1327,17 @@ struct drm_i915_gem_context_param { #define

[Intel-gfx] [PATCH] drm/i915: Show dmc debug registers on Kabylake

The assumption is that the registers offsets are identical as with skl. Also all the published kbl firmwares support the debug registers. So let kbl show the debug counts. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100975 Cc: Imre Deak Signed-off-by: Mika

Re: [Intel-gfx] [PATCH 8/8] drm: Remove redundant NULL check during atomic plane commit

On Wed, Apr 26, 2017 at 06:44:53PM +0300, Ville Syrjälä wrote: > On Wed, Apr 26, 2017 at 04:40:13PM +0300, Imre Deak wrote: > > plane_state can't be NULL anywhere in this function, so the NULL check > > at the end is redundant, remove it. > > > > Cc: dri-de...@lists.freedesktop.org > >

Re: [Intel-gfx] [i-g-t PATCH 1/4] lib/igt_core: Add igt_exec helpers

On Thu, Apr 20, 2017 at 11:13:45AM +0300, Abdiel Janulgue wrote: > Support executing external processes with the goal of capturing its > standard streams to the igt logging infrastructure in addition to its > exit status. > > Cc: Daniel Vetter > Cc: Petri Latvala

Re: [Intel-gfx] [PATCH 03/11] drm: parse ycbcr 420 vdb block

Regards Shashank On 5/9/2017 8:58 PM, Ville Syrjälä wrote: On Tue, May 09, 2017 at 02:04:55PM +0530, Sharma, Shashank wrote: Regards Shashank On 5/8/2017 10:39 PM, Ville Syrjälä wrote: On Mon, May 08, 2017 at 10:11:53PM +0530, Sharma, Shashank wrote: Regards Shashank On 5/8/2017 9:54

Re: [Intel-gfx] [PATCH v5 3/9] drm/i915: Drop AUX backlight enable check for backlight control

On Tue, 2017-05-09 at 16:39 -0700, Puthikorn Voravootivat wrote: > > How is backlight enabled in this case? > Using eDP BL_ENABLE pin Sure, but I am not seeing how this falls back to one of the [bxt,lpt]_enable_backlight() functions in intel_panel.c. Apologies if I am missing something very

[Intel-gfx] [PATCH v4 2/3] drm/i915/guc: Make scratch register base and count flexible

We are using some scratch registers in MMIO based send function. Make their base and count flexible in preparation of upcoming GuC firmware/hardware changes. While around, change cmd len parameter verification from WARN_ON to GEM_BUG_ON as we don't need this all the time. v2: call out

Re: [Intel-gfx] vlv_disable_backlight causing warnings with i915 @ Xorg start

On Mon, May 08, 2017 at 09:27:36AM -0400, Andrew Siplas wrote: > At Xorg startup after a fresh compile of the mainline kernel, WARN_ON is > truthy and throws a warning into the kernel's dmesg buffer. > > I'm still trying to understand the driver, but it originates here: > > -- > > static void

[Intel-gfx] [PATCH 2/2] drm/i915/glk: Enable cold boot for GLK DSI

As per BSEPC, if device ready bit is '0' in enable IO sequence then its a cold boot/reset scenario eg: S3/S4 resume. In these conditions we need to program certain registers and prepare port from the middle of DSI enable sequence otherwise feature like S3/S4 doesn't work. Signed-off-by: Madhav

[Intel-gfx] [PATCH 1/2] drm/i915/glk: Calculate high/low switch count for GLK

As per BSPEC, high/low switch count to be programmed in terms of byteclock using exit_zero_count and prep_count. For Geminilake exit/prep counts are already calculated in terms of byteclock. This patch calculates high/low switch count using counts value in byteclock, old calculation leads to

Re: [Intel-gfx] [PATCH 2/2] drm/i915/glk: Enable cold boot for GLK DSI

On Tue, May 09, 2017 at 06:59:25PM +0530, Madhav Chauhan wrote: > As per BSEPC, if device ready bit is '0' in enable IO sequence > then its a cold boot/reset scenario eg: S3/S4 resume. In these > conditions we need to program certain registers and prepare port > from the middle of DSI enable

[Intel-gfx] [PATCH 1/5] drm/vblank: Switch drm_driver->get_vblank_timestamp to return a bool

There's really no reason for anything more: - Calling this while the crtc vblank stuff isn't set up is a driver bug. Those places alrready DRM_ERROR. - Calling this when the crtc is off is either a driver bug (calling drm_crtc_handle_vblank at the wrong time) or a core bug (for anything

[Intel-gfx] [PATCH 4/5] drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos

If we restrict this helper to only kms drivers (which is the case) we can look up the correct mode easily ourselves. But it's a bit tricky: - All legacy drivers look at crtc->hwmode. But that is updated already at the beginning of the modeset helper, which means when we disable a pipe. Hence

[Intel-gfx] [PATCH 2/5] drm/vblank: Switch to bool in_vblank_irq in get_vblank_timestamp

It's overkill to have a flag parameter which is essentially used just as a boolean. This takes care of core + adjusting drivers. Adjusting the scanout position callback is a bit harder, since radeon also supplies it's own driver-private flags in there. v2: Fixup misplaced hunks (Neil). v3:

[Intel-gfx] [PATCH 3/5] drm/vblank: Add FIXME comments about moving the vblank ts hooks

This is going to be a bit too much, but good to have at least a small note about where this should all head towards. Acked-by: Ville Syrjälä Reviewed-by: Neil Armstrong Signed-off-by: Daniel Vetter ---

[Intel-gfx] [PATCH 5/5] drm/vblank: Lock down vblank->hwmode more

In the previous patch we've implemented hwmode tracking a la i915 for the vblank timestamp calculations. But that was just the basic semantics, i915 has some nice sanity checks to make sure we keep getting this right. Move them over too. v2: - WARN_ON_ONCE to avoid excessive spam (Ville) - Really

[Intel-gfx] [RFC 1/3] drm/i915: Wrap context schedule notification

From: Tvrtko Ursulin No functional change just something which will be handy in the following patch. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_lrc.c | 22 +++--- 1 file changed, 15 insertions(+), 7

[Intel-gfx] [RFC 0/3] Engine utilization tracking

From: Tvrtko Ursulin By popular customer demand here is the prototype for cheap engine utilization tracking. It uses static branches so in the default off case it really should be cheap. It exports the per engine total time something has been executing (in nano-

[Intel-gfx] [RFC 3/3] drm/i915: Export engine busy stats in debugfs

From: Tvrtko Ursulin Export the stats added in the previous patch in debugfs. Number of active clients reading this data is tracked and the static key is only enabled whilst there are some. Userspace is intended to keep the file descriptor open, seeking to the

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/glk: Calculate high/low switch count for GLK

== Series Details == Series: series starting with [1/2] drm/i915/glk: Calculate high/low switch count for GLK URL : https://patchwork.freedesktop.org/series/24173/ State : success == Summary == Series 24173v1 Series without cover letter

[Intel-gfx] [RFC 2/3] drm/i915: Engine busy time tracking

From: Tvrtko Ursulin Track total time requests have been executing on the hardware. To make this cheap it is hidden behind a static branch with the intention that it is only enabled when there is a consumer listening. This means that in the default off case the total

Re: [Intel-gfx] [PATCH v3] drm/i915/gvt: return the actual aperture size under gvt environment

On ti, 2017-05-09 at 03:10 +, Li, Weinan Z wrote: > > > > @@ -242,6 +242,9 @@ int intel_vgt_balloon(struct drm_i915_private > > > > *dev_priv) > > > >   goto err; > > > >   } > > > > > > > > + for (i = 0; i < ARRAY_SIZE(bl_info.space); i++) > > > > +

Re: [Intel-gfx] [PATCH v1] ACPI: Switch to use generic UUID API

Hi, Andy Shevchenko writes: > acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16 > bytes. Instead we convert them to use uuid_le type. At the same time we > convert current users. > > acpi_str_to_uuid() becomes useless after the conversion

Re: [Intel-gfx] [PATCH V6] drm/i915: Disable stolen memory when i915 runs in guest vm

On Mon, 08 May 2017 13:07:10 +0300 Joonas Lahtinen wrote: > On la, 2017-05-06 at 02:58 +, Zhang, Xiong Y wrote: > > > > > > On ke, 2017-05-03 at 09:22 +, Zhang, Xiong Y wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > +

[Intel-gfx] vlv_disable_backlight causing warnings with i915 @ Xorg start

At Xorg startup after a fresh compile of the mainline kernel, WARN_ON is truthy and throws a warning into the kernel's dmesg buffer. I'm still trying to understand the driver, but it originates here: -- static void vlv_disable_backlight(struct intel_connector *connector) { struct

[Intel-gfx] [PATCH v6 2/9] drm/i915: Correctly enable backlight brightness adjustment via DPCD

intel_dp_aux_enable_backlight() assumed that the register BACKLIGHT_BRIGHTNESS_CONTROL_MODE can only has value 01 (DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET) when initialize. This patch fixed that by handling all cases of that register. Signed-off-by: Puthikorn Voravootivat

[Intel-gfx] [PATCH v6 6/9] drm/i915: Support dynamic backlight via DPCD register

This patch enables dynamic backlight by default for eDP panel that supports this feature via DPCD register and set minimum / maximum brightness to 0% and 100% of the normal brightness. Signed-off-by: Puthikorn Voravootivat --- drivers/gpu/drm/i915/intel_dp_aux_backlight.c |

[Intel-gfx] [PATCH v6 0/9] Enhancement to intel_dp_aux_backlight driver

This patch set contain 9 patches. - First five patches fix bug in the driver and allow choosing which way to adjust brightness if both PWM pin and AUX are supported - Next patch adds enable DBC by default - Next patch makes the driver restore last brightness level after turning display off and

[Intel-gfx] [PATCH v6 9/9] drm/i915: Set PWM divider to match desired frequency in vbt

Read desired PWM frequency from panel vbt and calculate the value for divider in DPCD address 0x724 and 0x728 to have as many bits as possible for PWM duty cyle for granularity of brightness adjustment while the frequency is still within 25% of the desired frequency. Signed-off-by: Puthikorn

[Intel-gfx] [PATCH v6 7/9] drm/i915: Restore brightness level in aux backlight driver

Some panel will default to zero brightness when turning the panel off and on again. This patch restores last brightness level back when panel is turning back on. Signed-off-by: Puthikorn Voravootivat Reviewed-by: Dhinakaran Pandiyan ---

[Intel-gfx] [PATCH v6 4/9] drm/i915: Allow choosing how to adjust brightness if both supported

Add option to allow choosing how to adjust brightness if panel supports both PWM pin and AUX channel. Signed-off-by: Puthikorn Voravootivat --- drivers/gpu/drm/i915/i915_params.c| 8 +--- drivers/gpu/drm/i915/i915_params.h| 2 +-

[Intel-gfx] [PATCH v6 1/9] drm/i915: Fix cap check for intel_dp_aux_backlight driver

intel_dp_aux_backlight driver should check for the DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP before enable the driver. Signed-off-by: Puthikorn Voravootivat --- drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 1 + 1 file changed, 1 insertion(+) diff --git

[Intel-gfx] [PATCH v6 3/9] drm/i915: Drop AUX backlight enable check for backlight control

There are some panel that (1) does not support display backlight enable via AUX (2) support display backlight adjustment via AUX (3) support display backlight enable via eDP BL_ENABLE pin The current driver required that (1) must be support to enable (2). This patch drops that requirement.

[Intel-gfx] [PATCH v6 8/9] drm: Add definition for eDP backlight frequency

This patch adds the following definition - Bit mask for EDP_PWMGEN_BIT_COUNT and min/max cap register which only use bit 0:4 - Base frequency (27 MHz) for backlight PWM frequency generator. Signed-off-by: Puthikorn Voravootivat --- include/drm/drm_dp_helper.h | 2 ++ 1

[Intel-gfx] [PATCH v6 5/9] drm/i915: Set backlight mode before enable backlight

We should set backlight mode register before set register to enable the backlight. Signed-off-by: Puthikorn Voravootivat Reviewed-by: Dhinakaran Pandiyan --- drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 4 ++-- 1 file changed, 2

Re: [Intel-gfx] [PATCH v1] ACPI: Switch to use generic UUID API

On Thu, 2017-05-04 at 12:21 +0300, Andy Shevchenko wrote: > acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16 > bytes. Instead we convert them to use uuid_le type. At the same time > we > convert current users. > > acpi_str_to_uuid() becomes useless after the conversion and

Re: [Intel-gfx] [PATCH v5 3/9] drm/i915: Drop AUX backlight enable check for backlight control

> How is backlight enabled in this case? Using eDP BL_ENABLE pin On Sat, May 6, 2017 at 1:59 AM, Pandiyan, Dhinakaran < dhinakaran.pandi...@intel.com> wrote: > On Wed, 2017-05-03 at 17:28 -0700, Puthikorn Voravootivat wrote: > > There are some panel that > > (1) does not support display

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Move uncore definitions into a separate header

Michal Wajdeczko writes: > In order to allow use of e.g. forcewake_domains in a other feature headers > included from the top of i915_drv.h, move all uncore related definitions > into their own header. > > v2: move __mask_next_bit macro to utils header (Mika) > >

Re: [Intel-gfx] [PATCH] drm/i915: Show dmc debug registers on Kabylake

Imre Deak writes: > On Tue, May 09, 2017 at 01:05:22PM +0300, Mika Kuoppala wrote: >> The assumption is that the registers offsets are >> identical as with skl. Also all the published >> kbl firmwares support the debug registers. So >> let kbl show the debug counts. >> >>

Re: [Intel-gfx] [RFC 0/3] Engine utilization tracking

On Tue, May 09, 2017 at 03:09:33PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > By popular customer demand here is the prototype for cheap engine utilization > tracking. customer and debugfs? > It uses static branches so in the default off case it really

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/vblank: Switch drm_driver->get_vblank_timestamp to return a bool

== Series Details == Series: series starting with [1/5] drm/vblank: Switch drm_driver->get_vblank_timestamp to return a bool URL : https://patchwork.freedesktop.org/series/24175/ State : success == Summary == Series 24175v1 Series without cover letter

Re: [Intel-gfx] vlv_disable_backlight causing warnings with i915 @ Xorg start

FWIW the HDMI connector was in use at the time--plugged in and mirroring from boot, then (auto-)switching over to extending desktop at X start-- backlight possibly flicks off/on briefly while starting X/expanding to HDMI. On May 9 16:34:10, Ville Syrjälä wrote: > On Mon, May 08, 2017 at

[Intel-gfx] ✓ Fi.CI.BAT: success for Engine utilization tracking

== Series Details == Series: Engine utilization tracking URL : https://patchwork.freedesktop.org/series/24177/ State : success == Summary == Series 24177v1 Engine utilization tracking https://patchwork.freedesktop.org/api/1.0/series/24177/revisions/1/mbox/ Test gem_exec_fence:

Re: [Intel-gfx] [RFC 0/3] Engine utilization tracking

On 09/05/2017 15:26, Chris Wilson wrote: On Tue, May 09, 2017 at 03:09:33PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin By popular customer demand here is the prototype for cheap engine utilization tracking. customer and debugfs? Well I did write in one of

Re: [Intel-gfx] [PATCH 03/11] drm: parse ycbcr 420 vdb block

On Tue, May 09, 2017 at 02:04:55PM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 5/8/2017 10:39 PM, Ville Syrjälä wrote: > > On Mon, May 08, 2017 at 10:11:53PM +0530, Sharma, Shashank wrote: > >> Regards > >> > >> Shashank > >> > >> > >> On 5/8/2017 9:54 PM, Ville Syrjälä

Re: [Intel-gfx] [RFC 0/3] Engine utilization tracking

On Tue, May 09, 2017 at 04:16:41PM +0100, Tvrtko Ursulin wrote: > > On 09/05/2017 15:26, Chris Wilson wrote: > >On Tue, May 09, 2017 at 03:09:33PM +0100, Tvrtko Ursulin wrote: > >>From: Tvrtko Ursulin > >> > >>By popular customer demand here is the prototype for cheap