>-Original Message-
>From: Zhenyu Wang [mailto:zhen...@linux.intel.com]
>Sent: Wednesday, May 31, 2017 2:30 PM
>To: Chen, Xiaoguang
>Cc: Tian, Kevin ; intel-gfx@lists.freedesktop.org; linux-
>ker...@vger.kernel.org; ch...@chris-wilson.co.uk; alex.william...@redhat.com;
>kra...@redhat.com
>-Original Message-
>From: Zhenyu Wang [mailto:zhen...@linux.intel.com]
>Sent: Wednesday, May 31, 2017 1:12 PM
>To: Chen, Xiaoguang
>Cc: alex.william...@redhat.com; kra...@redhat.com; ch...@chris-wilson.co.uk;
>intel-gfx@lists.freedesktop.org; linux-ker...@vger.kernel.org;
>zhen...@linux
On 05/31/2017 01:57 AM, Clint Taylor wrote:
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.
Unfor
On 05/31/2017 01:25 AM, Clint Taylor wrote:
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
On 2017.05.31 06:22:28 +, Chen, Xiaoguang wrote:
> >> @@ -467,6 +555,15 @@ static int intel_vgpu_create(struct kobject *kobj,
> >struct mdev_device *mdev)
> >>vgpu->vdev.mdev = mdev;
> >>mdev_set_drvdata(mdev, vgpu);
> >>
> >> + ret = intel_vgpu_reg_init_opregion(vgpu);
> >> + if (ret
Hi
>-Original Message-
>From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
>Behalf Of Zhenyu Wang
>Sent: Wednesday, May 31, 2017 12:47 PM
>To: Chen, Xiaoguang
>Cc: Tian, Kevin ; intel-gfx@lists.freedesktop.org; linux-
>ker...@vger.kernel.org; zhen...@linux.intel.
Hi,
>-Original Message-
>From: Gerd Hoffmann [mailto:kra...@redhat.com]
>Sent: Monday, May 29, 2017 3:20 PM
>To: Chen, Xiaoguang ;
>alex.william...@redhat.com; ch...@chris-wilson.co.uk; intel-
>g...@lists.freedesktop.org; linux-ker...@vger.kernel.org;
>zhen...@linux.intel.com; Lv, Zhiyuan
Hi,
memory bandwidth WA is not applicable for GEN10 but below WA is needed
for CNL-A.
-Mahesh
On Saturday 27 May 2017 04:53 AM, Rodrigo Vivi wrote:
Based on patch submited to intel-gfx:
"drm/i915/cnl: don't apply the GEN9/CNL:A WM WAs to CNL:B+"
and subsequential tests on CNL, it seems that
On Wed, May 31, 2017 at 7:54 AM, Daniel Vetter wrote:
> 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 stateme
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
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 statements
>>> this simple way, that's imo on him to change the color
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 +-
> drivers/gpu/drm/i915/gvt/display.h
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.
>
> Signed-
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 Voravoot
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 DPCD
-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 automatic N/M.
On Fri, 26 May 2017, "Wang, Qua
== 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
https://patch
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 model
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 th
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; linux-ker...@vger.kernel.org;
>zhen
> -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 v3] drm/i915: Enable gues
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
== 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 gem_exe
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 incorre
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 abddff
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 DisplayPort/USB-C to HDMI a
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, Ha
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.
>
> That's not how things work.
>
> If the maint
== 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
https://patchwork.freedesktop.org/api/1.0/series/25070/revisions/1/m
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 changes
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 b/drivers/gpu/drm/i915/i9
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 IDs
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(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/dr
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, 2 insertions(+), 1 deletion(-)
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
ind
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 frequ
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 +
drivers/gpu/drm/i915/intel
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
---
drivers/gpu/drm/i915/i915_gem_gtt.c| 2 +-
drivers/gpu/drm/i915/intel_engine_cs.c
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
--- a/drivers/gpu/drm/i915/i915_pci.c
+++
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 platforms. Introduce a 9 bit extended
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 inste
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
---
drivers/gpu/drm/i915/intel_ddi.c | 6
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 f
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
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 b/tests/kms_setmode.c
index 430568a1c24
== 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
https://patchwork.freedesktop.org/api/1.0/series/25068/revisions/1/mbo
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(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/dr
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 changes
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 frequ
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 f
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 platforms. Introduce a 9 bit extended
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 inste
== 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 include/genera
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 co
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 f
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 changes
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 frequ
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(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/dr
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 platforms. Introduce a 9 bit extended
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 inste
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 05/29/2017 09:00 PM, Dan
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 insertions(+), 10 deletions(-)
dif
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 drm_atomic_helper_shutdown
>>> before
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 Fri, May 26, 2017 at 12
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 Verkuil wrote:
On 05/26
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 file changed, 15 insertions(+), 10 deletions(-)
>
>
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 t
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:
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: Sho
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 will
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,
R
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 Verkuil wrote:
On 05/26/2
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 Vetter wrote:
Did you l
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
- YCBCR
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 d
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 i
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 vid
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 capabili
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 mo
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 25
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 CEA
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 to
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 patch.
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 han
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, or they
have bugs, or just oth
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
> > >
== 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/
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 this up for dp mst chain
== 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
https://patchwork.freedesktop.org/api/1.0/ser
== 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
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 fru
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 : https://patchwork.freedesktop.org/series/2
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 a
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
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
cursor_disa
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 e
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
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 lgt
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 debug
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.
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 GT
1 - 100 of 139 matches
Mail list logo
