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

Hi Rodrigo, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on v4.12-rc3 next-20170530] [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/Rodrigo-Vivi/drm-i915-cnp

Re: [Intel-gfx] [PULL] topic/e1000e-fix

On Wed, May 31, 2017 at 1:06 AM, Dave Airlie wrote: > On 31 May 2017 at 08:10, David Miller wrote: >> From: Daniel Vetter >> Date: Tue, 30 May 2017 22:15:42 +0200 >> >>> If the e1000e maintainer wants to coalesce or not return

Re: [Intel-gfx] [PATCH v6 3/6] drm/i915/gvt: Frame buffer decoder support for GVT-g

On 2017.05.27 16:38:49 +0800, Xiaoguang Chen wrote: > decode frambuffer attributes of primary, cursor and sprite plane > > Signed-off-by: Xiaoguang Chen > --- > drivers/gpu/drm/i915/gvt/Makefile | 3 +- > drivers/gpu/drm/i915/gvt/display.c| 2 +- >

Re: [Intel-gfx] [PATCH v6 2/6] drm/i915/gvt: OpRegion support for GVT-g

On 2017.05.27 16:38:48 +0800, Xiaoguang Chen wrote: > OpRegion is needed to support display related operation for > intel vgpu. > > A vfio device region is added to intel vgpu to deliver the > host OpRegion information to user space so user space can > construct the OpRegion for vgpu. > >

Re: [Intel-gfx] [PATCH v10 2/3] drm/i915: Add option to support dynamic backlight via DPCD

On Fri, 2017-05-26 at 18:42 -0700, Puthikorn Voravootivat wrote: > This patch adds option to enable dynamic backlight 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

Re: [Intel-gfx] [PATCH v10 3/3] drm/i915: Set PWM divider to match desired frequency in vbt

The patch looks good overall, it would have been easier to merge if you'd sent this as the first patch in this version. Some comments inline. On Fri, 2017-05-26 at 18:42 -0700, Puthikorn Voravootivat wrote: > Read desired PWM frequency from panel vbt and calculate the > value for divider in

Re: [Intel-gfx] [PATCH] Defined NM doesn't work on KBL and uses automatic N/M.

-Original Message- From: Jani Nikula [mailto:jani.nik...@linux.intel.com] Sent: Monday, May 29, 2017 4:29 PM To: Wang, Quanxian ; intel-gfx@lists.freedesktop.org Cc: Yang, Libin Subject: RE: [PATCH] Defined NM doesn't work on KBL and uses

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

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

Re: [Intel-gfx] [PATCH v3] drm/i915: Enable guest i915 full ppgtt functionality

On 2017.05.30 11:37:50 +0300, Joonas Lahtinen wrote: > On ma, 2017-05-22 at 16:19 +0800, Tina Zhang wrote: > > Enable the guest i915 full ppgtt functionality when host can provide this > > capability. vgt_caps is introduced to guest i915 driver to get the vgpu > > capabilities from the device

[Intel-gfx] [PATCH v7] drm/i915: 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 v6 0/6] drm/i915/gvt: Dma-buf support for GVT-g

Hi Gerd, It is based on 4.12.0-rc1 >-Original Message- >From: Gerd Hoffmann [mailto:kra...@redhat.com] >Sent: Tuesday, May 30, 2017 6:24 PM >To: Chen, Xiaoguang ; >alex.william...@redhat.com; ch...@chris-wilson.co.uk; intel- >g...@lists.freedesktop.org;

Re: [Intel-gfx] [PATCH v3] drm/i915: Enable guest i915 full ppgtt functionality

> -Original Message- > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] > Sent: Tuesday, May 30, 2017 4:38 PM > To: Zhang, Tina ; intel-gfx@lists.freedesktop.org > Cc: zhen...@linux.intel.com; intel-gvt-...@lists.freedesktop.org > Subject: Re: [PATCH

Re: [Intel-gfx] [PATCH v2 07/11] drm: add ycbcr helper functions

Hi Shashank, [auto build test WARNING on drm/drm-next] [also build test WARNING on next-20170530] [cannot apply to v4.12-rc3] [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/Shashank-Sharma/HDMI

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Fix doorbell id selection

== Series Details == Series: drm/i915/guc: Fix doorbell id selection URL : https://patchwork.freedesktop.org/series/25076/ State : success == Summary == Series 25076v1 drm/i915/guc: Fix doorbell id selection https://patchwork.freedesktop.org/api/1.0/series/25076/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix doorbell id selection

On 30/05/17 17:05, Michel Thierry wrote: We are passing parameters in the wrong order to find next zero bit, and when it doesn't find anything it returns size (offset in the code), which is always zero. For reference the function is defined as: find_next_bit( *addr, size, offset ) The

[Intel-gfx] [PATCH] drm/i915/guc: Fix doorbell id selection

We are passing parameters in the wrong order to find next zero bit, and when it doesn't find anything it returns size (offset in the code), which is always zero. For reference the function is defined as: find_next_bit( *addr, size, offset ) The incorrect parameter order was added by commit

Re: [Intel-gfx] [RFC PATCH 6/7] drm: add support for DisplayPort CEC-Tunneling-over-AUX

On 05/26/2017 12:18 AM, Daniel Vetter wrote: On Thu, May 25, 2017 at 05:06:25PM +0200, Hans Verkuil wrote: From: Hans Verkuil This adds support for the DisplayPort CEC-Tunneling-over-AUX feature that is part of the DisplayPort 1.3 standard. Unfortunately, not all

Re: [Intel-gfx] [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

On 05/30/2017 02:29 PM, Hans Verkuil wrote: On 05/30/2017 10:32 PM, Clint Taylor wrote: On 05/30/2017 09:54 AM, Hans Verkuil wrote: On 05/30/2017 06:49 PM, Hans Verkuil wrote: On 05/30/2017 04:19 PM, Clint Taylor wrote: On 05/30/2017 12:11 AM, Jani Nikula wrote: On Tue, 30 May 2017,

Re: [Intel-gfx] [PULL] topic/e1000e-fix

On 31 May 2017 at 08:10, David Miller wrote: > From: Daniel Vetter > Date: Tue, 30 May 2017 22:15:42 +0200 > >> If the e1000e maintainer wants to coalesce or not return statements >> this simple way, that's imo on him to change the color as needed. >

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/13] drm/i915/cnp: Introduce Cannonpoint PCH.

== Series Details == Series: series starting with [01/13] drm/i915/cnp: Introduce Cannonpoint PCH. URL : https://patchwork.freedesktop.org/series/25070/ State : success == Summary == Series 25070v1 Series without cover letter

[Intel-gfx] [PATCH 01/13] drm/i915/cnp: Introduce Cannonpoint PCH.

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 has changed in CNP PCH. All of these

[Intel-gfx] [PATCH 08/13] drm/i915/cfl: Coffee Lake uses CNP PCH.

So let's force it on the virtual detection. Also it is still the only silicon for now on this PCH, so WARN otherwise. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_drv.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.c

[Intel-gfx] [PATCH 07/13] drm/i915/cfl: Introduce Coffee Lake platform definition.

Coffee Lake is a Intel® Processor containing Intel® HD Graphics following Kabylake. It is Gen9 graphics based platform on top of CNP PCH. Let's start by adding the platform definition based on previous platforms but yet as preliminary_hw_support. On following patches we will start adding PCI

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

As for BXT, PP_DIVISOR was removed from CNP PCH and power cycle delay has been moved to PP_CONTROL. Cc: Jani Nikula Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_dp.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-)

[Intel-gfx] [PATCH 11/13] drm/i915/cfl: Add CFL PCI IDs for U SKU

From: Anusha Srivatsa Follow the spec and add the PCI Ids. Cc: Rodrigo Vivi Signed-off-by: Anusha Srivatsa Signed-off-by: Rodrigo Vivi --- include/drm/i915_pciids.h | 3 ++- 1 file changed,

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

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 the fractional portion of reference

[Intel-gfx] [PATCH 13/13] drm/i915/cfl: Coffe Lake reuses Kabylake DMC.

From the DMC perspective the same firmware is used on both platforms. We haven't recieved any separated release specifically for Coffee Lake so let's just re-use what is already there for Kabylake. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_pci.c | 1 +

[Intel-gfx] [PATCH 12/13] drm/i915/cfl: Introduce Coffee Lake workardounds.

Coffee Lake inherit most of Kabylake production workardounds. Only difference identified so far is: - WaDisableLSQCROPERFforOCL is marked as SIWA_NEVER Cc: Dhinakaran Pandiyan Signed-off-by: Rodrigo Vivi ---

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

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. v2: Reuse BXT functions with controller 0

[Intel-gfx] [PATCH 09/13] drm/i915/cfl: Basic PM plumbing for Coffee Lake.

All here is pretty much like Kabylake, expect the PCH. This patch exclude the addition of DMC, GuC and most workardounds since they might have changes/updates. v2: Take advantage of IS_GEN9_BC minimizing the needed plumbing. Signed-off-by: Rodrigo Vivi ---

[Intel-gfx] [PATCH 10/13] drm/i915/cfl: Add Coffee Lake PCI IDs for H and S Skus.

Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_pci.c | 1 + include/drm/i915_pciids.h | 4 2 files changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c index 31ea988..0b1c96d 100644 ---

[Intel-gfx] [PATCH 02/13] 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 05/13] drm/i915/cnp: add CNP gmbus support

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. v2: Don't drop "_BXT" as the indicator of the

Re: [Intel-gfx] [PATCH v2 08/11] drm/i915: handle ycbcr outputs

Hi Shashank, [auto build test ERROR on drm/drm-next] [also build test ERROR on next-20170530] [cannot apply to v4.12-rc3] [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/Shashank-Sharma/HDMI

[Intel-gfx] [PATCH i-g-t] tests/kms_setmode: increase MAX_CRTCS to 6

AMD GPUs can have 6 CRTCs. This requires us to allocate the combinations on the heap. Signed-off-by: Harry Wentland --- tests/kms_setmode.c | 25 +++-- 1 file changed, 15 insertions(+), 10 deletions(-) diff --git a/tests/kms_setmode.c

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915/cnp: Introduce Cannonpoint PCH.

== Series Details == Series: series starting with [1/6] drm/i915/cnp: Introduce Cannonpoint PCH. URL : https://patchwork.freedesktop.org/series/25068/ State : success == Summary == Series 25068v1 Series without cover letter

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

As for BXT, PP_DIVISOR was removed from CNP PCH and power cycle delay has been moved to PP_CONTROL. Cc: Jani Nikula Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_dp.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-)

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

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 has changed in CNP PCH. All of these

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

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 the fractional portion of reference

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

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. v2: Don't drop "_BXT" as the indicator of the

[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 4/6] drm/i915/cnp: Backlight support for CNP.

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. v2: Reuse BXT functions with controller 0

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/6] drm/i915/cnp: Introduce Cannonpoint PCH.

== Series Details == Series: series starting with [1/6] drm/i915/cnp: Introduce Cannonpoint PCH. URL : https://patchwork.freedesktop.org/series/25066/ State : failure == Summary == CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK

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

Jani, Daniel, could I merge the 5 patches already after CI respond? I rebased and retest here on CNL But I'd like to start merging so we unblock CFL as well, maybe on top of this CNP before CNL... Jani, also I believe you would be the best reviewer for this 6th patch here, could you please

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

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. v2: Don't drop "_BXT" as the indicator of the

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

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 has changed in CNP PCH. All of these

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

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 the fractional portion of reference

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

As for BXT, PP_DIVISOR was removed from CNP PCH and power cycle delay has been moved to PP_CONTROL. Cc: Jani Nikula Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_dp.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-)

[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 4/6] drm/i915/cnp: Backlight support for CNP.

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. v2: Reuse BXT functions with controller 0

Re: [Intel-gfx] [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

On 05/30/2017 10:32 PM, Clint Taylor wrote: On 05/30/2017 09:54 AM, Hans Verkuil wrote: On 05/30/2017 06:49 PM, Hans Verkuil wrote: On 05/30/2017 04:19 PM, Clint Taylor wrote: On 05/30/2017 12:11 AM, Jani Nikula wrote: On Tue, 30 May 2017, Hans Verkuil wrote: On

[Intel-gfx] [PATCH i-g-t v2] tests/kms_setmode: increase MAX_CRTCS to 6

AMD GPUs can have 6 CRTCs. This requires us to allocate the combinations on the heap. v2: Of course We should free the new allocation. Thanks, Alex. Signed-off-by: Harry Wentland --- tests/kms_setmode.c | 28 ++-- 1 file changed, 18

Re: [Intel-gfx] [PATCH 19/37] drm/fsl: Drop drm_vblank_cleanup

On 2017-05-26 00:00, Daniel Vetter wrote: > On Thu, May 25, 2017 at 10:18 AM, Stefan Agner wrote: >> On 2017-05-24 07:51, Daniel Vetter wrote: >>> Again cleanup before irq disabling doesn't really stop the races, >>> so just drop it. Proper fix would be to put

Re: [Intel-gfx] [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

On 05/30/2017 09:54 AM, Hans Verkuil wrote: On 05/30/2017 06:49 PM, Hans Verkuil wrote: On 05/30/2017 04:19 PM, Clint Taylor wrote: On 05/30/2017 12:11 AM, Jani Nikula wrote: On Tue, 30 May 2017, Hans Verkuil wrote: On 05/29/2017 09:00 PM, Daniel Vetter wrote: On

Re: [Intel-gfx] [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

On 05/30/2017 09:49 AM, Hans Verkuil wrote: On 05/30/2017 04:19 PM, Clint Taylor wrote: On 05/30/2017 12:11 AM, Jani Nikula wrote: On Tue, 30 May 2017, Hans Verkuil wrote: On 05/29/2017 09:00 PM, Daniel Vetter wrote: On Fri, May 26, 2017 at 12:20:48PM +0200, Hans

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_setmode: increase MAX_CRTCS to 6

On Tue, May 30, 2017 at 4:01 PM, Harry Wentland wrote: > AMD GPUs can have 6 CRTCs. > > This requires us to allocate the combinations on the heap. > > Signed-off-by: Harry Wentland > --- > tests/kms_setmode.c | 25 +++-- > 1

[Intel-gfx] [PULL] topic/e1000e-fix

Hi Dave (both of them), topic/e1000e-fix-2017-05-30: Just an e1000e crash fix that somehow got stuck in a trivial bikeshed, see https://patchwork.ozlabs.org/patch/729312/ Sending this your way since not even the intel-internal escalation seems to have worked out. If the e1000e maintainer wants

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Short-circuit i915_gem_wait_for_idle() if already idle

On Tue, May 30, 2017 at 07:18:20PM +, Saarinen, Jani wrote: > Hi, > > -Original Message- > > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > > Of > > Chris Wilson > > Sent: Tuesday, May 30, 2017 7:21 PM > > To: intel-gfx@lists.freedesktop.org > > Subject:

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Short-circuit i915_gem_wait_for_idle() if already idle

Hi, > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of > Chris Wilson > Sent: Tuesday, May 30, 2017 7:21 PM > To: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] > drm/i915:

Re: [Intel-gfx] [PATCH v14 13/14] drm/i915/perf: reprogram NOA muxes at the beginning of each workload

There is pretty obvious bug with this patch as some OA configs spans more registers write than what MI_LOAD_REGISTER_IMM can do (> 128). I'll send an updated patch. That doesn't affect patch 14 though. - Lionel On 26/05/17 12:56, Lionel Landwerlin wrote: Dynamic slices/subslices shutdown

Re: [Intel-gfx] [PATCH] drm/i915/psr: disable psr2 for resolution greater than 32X20

Patch merged to dinq, thanks. I didn't put on fixes nor Cc'ed stable after chatting with Daniel about that. Since PSR is currently disabled on 4.11 there is no risk of this blowing anything nor changing the expected default behaviour. So dinq seemed to be the right place for this patch. Thanks,

Re: [Intel-gfx] [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

On 05/30/2017 06:49 PM, Hans Verkuil wrote: On 05/30/2017 04:19 PM, Clint Taylor wrote: On 05/30/2017 12:11 AM, Jani Nikula wrote: On Tue, 30 May 2017, Hans Verkuil wrote: On 05/29/2017 09:00 PM, Daniel Vetter wrote: On Fri, May 26, 2017 at 12:20:48PM +0200, Hans

Re: [Intel-gfx] [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

On 05/30/2017 04:19 PM, Clint Taylor wrote: On 05/30/2017 12:11 AM, Jani Nikula wrote: On Tue, 30 May 2017, Hans Verkuil wrote: On 05/29/2017 09:00 PM, Daniel Vetter wrote: On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote: On 05/26/2017 09:15 AM, Daniel

Re: [Intel-gfx] [PATCH v2 05/11] drm: create hdmi output property

Regards Shashank On 5/30/2017 10:06 PM, Ville Syrjälä wrote: On Tue, May 30, 2017 at 05:43:44PM +0530, Shashank Sharma wrote: HDMI displays can support various output types, based on the color space and subsampling type. The possible outputs from a HDMI 2.0 monitor could be: - RGB -

Re: [Intel-gfx] [PATCH v2 05/11] drm: create hdmi output property

On Tue, May 30, 2017 at 05:43:44PM +0530, Shashank Sharma wrote: > HDMI displays can support various output types, based on > the color space and subsampling type. The possible > outputs from a HDMI 2.0 monitor could be: > - RGB > - YCBCR 444 > - YCBCR 422 > - YCBCR 420 > > This patch adds a

Re: [Intel-gfx] [PATCH v2 04/11] drm: parse ycbcr 420 deep color information

On Tue, May 30, 2017 at 05:43:43PM +0530, Shashank Sharma wrote: > 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

Re: [Intel-gfx] [PATCH v2 01/11] drm: Add HDMI 2.0 VIC support for AVI info-frames

Regards Shashank On 5/30/2017 9:43 PM, Ville Syrjälä wrote: On Tue, May 30, 2017 at 05:43:40PM +0530, Shashank Sharma wrote: 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

Re: [Intel-gfx] [PATCH v2 03/11] drm: parse ycbcr420 cmdb block

On Tue, May 30, 2017 at 05:43:42PM +0530, Shashank Sharma wrote: > HDMI 2.0 spec adds support for ycbcr420 sub-sampled output. > CEA-861-F adds two new blocks in EDID, to provide information > about sink's support for ycbcr420 output. > > One of these new blocks is: ycbcr420cmdb(ycbcr 420

Re: [Intel-gfx] [PATCH v2 02/11] drm/edid: Complete CEA modedb(VIC 1-107)

Regards Shashank On 5/30/2017 9:48 PM, Ville Syrjälä wrote: On Tue, May 30, 2017 at 05:43:41PM +0530, Shashank Sharma wrote: 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

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Short-circuit i915_gem_wait_for_idle() if already idle

On Tue, May 30, 2017 at 02:09:53PM -, Patchwork wrote: > == Series Details == > > Series: series starting with [1/3] drm/i915: Short-circuit > i915_gem_wait_for_idle() if already idle > URL : https://patchwork.freedesktop.org/series/25039/ > State : success > > == Summary == > > Series

Re: [Intel-gfx] [PATCH v2 02/11] drm/edid: Complete CEA modedb(VIC 1-107)

On Tue, May 30, 2017 at 05:43:41PM +0530, Shashank Sharma wrote: > 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

Re: [Intel-gfx] [PATCH v2 01/11] drm: Add HDMI 2.0 VIC support for AVI info-frames

On Tue, May 30, 2017 at 05:43:40PM +0530, Shashank Sharma wrote: > 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

Re: [Intel-gfx] [PATCH 2/3] drm/i915/glk: WA#0893: Also apply memory bw wa to Geminilake.

On Mon, 2017-05-29 at 11:26 +0300, Ander Conselvan De Oliveira wrote: > On Fri, 2017-05-26 at 16:23 -0700, Rodrigo Vivi wrote: > > According to spec this WA is needed for every gen9. > > Actually GLK has a gen10 display, so the gen9 workarounds don't apply. Oh, indeed! Please ignore this

Re: [Intel-gfx] [RFC] drm: Optimise drm_ioctl() for small user args

On Tue, May 30, 2017 at 01:55:20PM +0100, Chris Wilson wrote: > When looking at simple ioctls coupled with conveniently small user > parameters, the overhead of the syscall and drm_ioctl() present large > low hanging fruit. Profiling trivial microbenchmarks around > i915_gem_busy_ioctl, the low

Re: [Intel-gfx] [PATCH 3/4] drm/dp: start a DPCD based DP sink/branch device quirk database

On 05/29/2017 04:06 AM, Jani Nikula wrote: On Thu, 18 May 2017, Clint Taylor wrote: On 05/18/2017 04:10 AM, Jani Nikula wrote: Face the fact, there are Display Port sink and branch devices out there in the wild that don't follow the Display Port specifications,

Re: [Intel-gfx] [PATCH 1/3] drm/i915/skl+: Don't trust cached ddb values

Mahesh Kumar schreef op di 30-05-2017 om 18:26 [+0530]: > Hi Maarten, > > Thanks for review :) > > > On Tuesday 30 May 2017 03:30 PM, Maarten Lankhorst wrote: > > Op 26-05-17 om 17:15 schreef Mahesh Kumar: > > > Don't trust cached DDB values. Recalculate the ddb value if > > > cached value > >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Optimise drm_ioctl() for small user args

== Series Details == Series: drm: Optimise drm_ioctl() for small user args URL : https://patchwork.freedesktop.org/series/25044/ State : success == Summary == Series 25044v1 drm: Optimise drm_ioctl() for small user args https://patchwork.freedesktop.org/api/1.0/series/25044/revisions/1/mbox/

Re: [Intel-gfx] [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

On 05/30/2017 12:11 AM, Jani Nikula wrote: On Tue, 30 May 2017, Hans Verkuil wrote: On 05/29/2017 09:00 PM, Daniel Vetter wrote: On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote: On 05/26/2017 09:15 AM, Daniel Vetter wrote: Did you look into also wiring

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Short-circuit i915_gem_wait_for_idle() if already idle

== Series Details == Series: series starting with [1/3] drm/i915: Short-circuit i915_gem_wait_for_idle() if already idle URL : https://patchwork.freedesktop.org/series/25039/ State : success == Summary == Series 25039v1 Series without cover letter

[Intel-gfx] ✗ Fi.CI.BAT: failure for HDMI YCBCR output handling in DRM layer (rev2)

== Series Details == Series: HDMI YCBCR output handling in DRM layer (rev2) URL : https://patchwork.freedesktop.org/series/22684/ State : failure == Summary == Series 22684v2 HDMI YCBCR output handling in DRM layer https://patchwork.freedesktop.org/api/1.0/series/22684/revisions/2/mbox/ Test

Re: [Intel-gfx] [RFC] drm: Optimise drm_ioctl() for small user args

On ti, 2017-05-30 at 13:55 +0100, Chris Wilson wrote: > When looking at simple ioctls coupled with conveniently small user > parameters, the overhead of the syscall and drm_ioctl() present large > low hanging fruit. Profiling trivial microbenchmarks around > i915_gem_busy_ioctl, the low hanging

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915/gvt: Add gvt options sanitize function

On ti, 2017-05-30 at 13:45 +0100, Chris Wilson wrote: > On Sat, May 27, 2017 at 10:01:48AM -, Patchwork wrote: > > > > == Series Details == > > > > Series: series starting with [v2,1/3] drm/i915/gvt: Add gvt options > > sanitize function > > URL   :

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Hold a wakeref for probing the ring registers

On 30/05/2017 13:50, Chris Wilson wrote: On Tue, May 30, 2017 at 01:37:23PM +0100, Tvrtko Ursulin wrote: On 30/05/2017 13:13, Chris Wilson wrote: Allow intel_engine_is_idle() to be called outside of the GT wakeref by acquiring the device runtime pm for ourselves. This allows the function to

[Intel-gfx] [RFC] drm: Optimise drm_ioctl() for small user args

When looking at simple ioctls coupled with conveniently small user parameters, the overhead of the syscall and drm_ioctl() present large low hanging fruit. Profiling trivial microbenchmarks around i915_gem_busy_ioctl, the low hanging fruit comprises of the call to copy_user(). Those calls are only

Re: [Intel-gfx] [PATCH 1/3] drm/i915/skl+: Don't trust cached ddb values

Hi Maarten, Thanks for review :) On Tuesday 30 May 2017 03:30 PM, Maarten Lankhorst wrote: Op 26-05-17 om 17:15 schreef Mahesh Kumar: Don't trust cached DDB values. Recalculate the ddb value if cached value is zero. If i915 is build as a module, there may be a race condition when

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Hold a wakeref for probing the ring registers

On Tue, May 30, 2017 at 01:37:23PM +0100, Tvrtko Ursulin wrote: > > On 30/05/2017 13:13, Chris Wilson wrote: > >Allow intel_engine_is_idle() to be called outside of the GT wakeref by > >acquiring the device runtime pm for ourselves. This allows the function > >to act as check after we assume the

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Short-circuit i915_gem_wait_for_idle() if already idle

On Tue, May 30, 2017 at 03:41:15PM +0300, Joonas Lahtinen wrote: > On ti, 2017-05-30 at 13:13 +0100, Chris Wilson wrote: > > If the device is asleep (no GT wakeref), we know the GPU is already idle. > > If we add an early return, we can avoid touching registers and checking > > hw state outside of

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915/gvt: Add gvt options sanitize function

On Sat, May 27, 2017 at 10:01:48AM -, Patchwork wrote: > == Series Details == > > Series: series starting with [v2,1/3] drm/i915/gvt: Add gvt options sanitize > function > URL : https://patchwork.freedesktop.org/series/24982/ > State : success Sigh. Had to resort to checking pw, but it

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Short-circuit i915_gem_wait_for_idle() if already idle

On ti, 2017-05-30 at 13:13 +0100, Chris Wilson wrote: > If the device is asleep (no GT wakeref), we know the GPU is already idle. > If we add an early return, we can avoid touching registers and checking > hw state outside of the assumed GT wakelock. This prevents causing such > errors whilst

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Hold a wakeref for probing the ring registers

On 30/05/2017 13:13, Chris Wilson wrote: Allow intel_engine_is_idle() to be called outside of the GT wakeref by acquiring the device runtime pm for ourselves. This allows the function to act as check after we assume the engine is idle and we release the GT wakeref held whilst we have requests.

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Short-circuit i915_gem_wait_for_idle() if already idle

On Tue, May 30, 2017 at 01:21:29PM +0100, Tvrtko Ursulin wrote: > > On 30/05/2017 13:13, Chris Wilson wrote: > >If the device is asleep (no GT wakeref), we know the GPU is already idle. > >If we add an early return, we can avoid touching registers and checking > >hw state outside of the assumed

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Short-circuit i915_gem_wait_for_idle() if already idle

On 30/05/2017 13:13, Chris Wilson wrote: If the device is asleep (no GT wakeref), we know the GPU is already idle. If we add an early return, we can avoid touching registers and checking hw state outside of the assumed GT wakelock. This prevents causing such errors whilst debugging: [

[Intel-gfx] [PATCH 2/3] drm/i915: Hold a wakeref for probing the ring registers

Allow intel_engine_is_idle() to be called outside of the GT wakeref by acquiring the device runtime pm for ourselves. This allows the function to act as check after we assume the engine is idle and we release the GT wakeref held whilst we have requests. [ 2613.401647] RPM wakelock ref not held

[Intel-gfx] [PATCH 1/3] drm/i915: Short-circuit i915_gem_wait_for_idle() if already idle

If the device is asleep (no GT wakeref), we know the GPU is already idle. If we add an early return, we can avoid touching registers and checking hw state outside of the assumed GT wakelock. This prevents causing such errors whilst debugging: [ 2613.401647] RPM wakelock ref not held during HW

[Intel-gfx] [PATCH 3/3] drm/i915: Check the ring is empty when declaring the engines are idle

As another precaution when testing whether the CS engine is actually idle, also inspect the ring's HEAD/TAIL registers, which should be equal when there are no commands left to execute by the GPU. Signed-off-by: Chris Wilson Cc: Mika Kuoppala

[Intel-gfx] [PATCH v2 10/11] drm/i915: prepare ycbcr420 modeset

To get a ycbcr420 output from intel platforms, there are two major steps: - RGB->YCBCR conversion using a pipe CSC. - Program PIPE_MISC register to generate a ycbcr420 output. - Scaling down YCBCR444 samples to YCBCR420 samples using a pipe scaler. This patch: - Does scaler allocation for HDMI

[Intel-gfx] [PATCH v2 03/11] drm: parse ycbcr420 cmdb block

HDMI 2.0 spec adds support for ycbcr420 sub-sampled output. CEA-861-F adds two new blocks in EDID, to provide information about sink's support for ycbcr420 output. One of these new blocks is: ycbcr420cmdb(ycbcr 420 capability map data block). This gives information about video modes which can

Re: [Intel-gfx] [PATCH] drm/i915: Consistent ordering of tracepoint binary data

On 11/05/2017 14:16, Tvrtko Ursulin wrote: On 11/05/2017 14:07, Chris Wilson wrote: On Thu, May 11, 2017 at 02:00:45PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin For userspace receiving binary data it is easier if all related request tracepoints emit the

[Intel-gfx] [PATCH v2 09/11] drm/i915: handle csc for ycbcr HDMI output

To support ycbcr HDMI output, we need a pipe CSC block to do the RGB->YCBCR conversion, as the blender output is in RGB. 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,

[Intel-gfx] [PATCH v2 06/11] drm: set output colorspace in AVI infoframe

HDMI source must set output colorspace information in AVI infoframes, so that the sink can decode upcoming frames accordingly. As this patch series is adding support for HDMI output modes other than RGB, this patch adds a function in DRM layer, to add the output colorspace information in the AVI

  1   2   >