Zhenyu,
Overall I think the impact to AcrnGT is not big, we can modify our code to adapt
to the new interfaces.
But I have some comments embedded.
> -Original Message-
> From: Zhenyu Wang [mailto:zhen...@linux.intel.com]
> Sent: Thursday, December 6, 2018 12:28 PM
> To: Yuan, Hang ;
On 12/6/2018 7:50 PM, Daniel Vetter wrote:
On Tue, Nov 27, 2018 at 04:13:31PM +0530, Ramalingam C wrote:
Implement the required WA sequence for KBL to fix the
incorrect positioning of the window of oppurtunity and enc_en
signalling.
Signed-off-by: Ramalingam C
---
On 12/6/2018 6:57 PM, Daniel Vetter wrote:
On Tue, Nov 27, 2018 at 04:13:07PM +0530, Ramalingam C wrote:
Implements the link integrity check once in 500mSec.
Once encryption is enabled, an ongoing Link Integrity Check is
performed by the HDCP Receiver to check that cipher synchronization
is
On 12/6/2018 4:00 PM, Daniel Vetter wrote:
On Tue, Nov 27, 2018 at 04:13:04PM +0530, Ramalingam C wrote:
Considering that HDCP2.2 is more secure than HDCP1.4, When a setup
supports HDCP2.2 and HDCP1.4, HDCP2.2 will be enabled.
When HDCP2.2 enabling fails and HDCP1.4 is supported, HDCP1.4 is
On 12/6/2018 3:53 PM, Daniel Vetter wrote:
On Tue, Nov 27, 2018 at 04:13:03PM +0530, Ramalingam C wrote:
Defining the mei-i915 interface functions and initialization of
the interface.
Signed-off-by: Ramalingam C
Signed-off-by: Tomas Winkler
---
drivers/gpu/drm/i915/i915_drv.h | 2 +
== Series Details ==
Series: Enable Y210, Y212, Y216 formats for ICL (rev4)
URL : https://patchwork.freedesktop.org/series/48729/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5274_full -> Patchwork_11033_full
Summary
On 12/6/2018 3:33 PM, Daniel Vetter wrote:
On Tue, Nov 27, 2018 at 04:13:02PM +0530, Ramalingam C wrote:
Add the HDCP2.2 initialization to the existing HDCP1.4 stack.
With the comments below addressed the commit message is a bit untrue,
since this just wires up a basic hdcp2_supported flag in
Hi,
As I was hoping to possibly merge more new stuff for next kernel e.g
CFL support, etc, but seems those're still not stable enough so better
wait for next cycle, so sorry for the late.
This includes mostly one regression fix for drm-intel-next when we
introduced during previous shadow ctx
== Series Details ==
Series: drm/i915: Fix IGT kms_color/gamma subtest SKIP for GLK
URL : https://patchwork.freedesktop.org/series/53629/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5272_full -> Patchwork_11032_full
== Series Details ==
Series: Use intel_* types more consistently
URL : https://patchwork.freedesktop.org/series/53705/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5279 -> Patchwork_11042
Summary
---
**SUCCESS**
== Series Details ==
Series: Use intel_* types more consistently
URL : https://patchwork.freedesktop.org/series/53705/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Use intel_ types more consistently for watermark code
== Series Details ==
Series: Use intel_* types more consistently
URL : https://patchwork.freedesktop.org/series/53705/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3b3378ade6f9 drm/i915: Use intel_ types more consistently for watermark code
3c31c0ac3fda drm/i915: Use intel_
Try to be more consistent about intel_* types rather than drm_* types
for lower-level driver functions. While we're at it, let's also be more
consistent with state variable naming (half of the platforms use the
name 'state' whereas the other half used 'crtc_state').
Signed-off-by: Matt Roper
Try to be more consistent about intel_* types rather than drm_* types
for lower-level driver functions.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_drv.h | 5 +-
drivers/gpu/drm/i915/intel_display.c | 32 ++---
drivers/gpu/drm/i915/intel_drv.h | 10 +-
The i915 codebase usually tries to use intel_* types rather than drm_*
types as parameters for internal driver functions that are only called
by other i915 code. However I've noticed that the watermark code and
the color management code are two places where we haven't been as
careful about
== Series Details ==
Series: series starting with [1/3] drm/i915: Skip the ERR_PTR error state
URL : https://patchwork.freedesktop.org/series/53625/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5272_full -> Patchwork_11031_full
== Series Details ==
Series: New DDB allocation algorithm (rev2)
URL : https://patchwork.freedesktop.org/series/53682/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5279 -> Patchwork_11041
Summary
---
**SUCCESS**
== Series Details ==
Series: New DDB allocation algorithm (rev2)
URL : https://patchwork.freedesktop.org/series/53682/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Remove a very stale FIXME
Okay!
Commit: drm/i915: Don't use DDB allocation
== Series Details ==
Series: drm/i915/icl: Skip DSI path in DDI vswing programming.
URL : https://patchwork.freedesktop.org/series/53703/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5279 -> Patchwork_11040
Summary
On Thu, Dec 06, 2018 at 02:48:36PM +0530, Swati Sharma wrote:
> Fix the skip for kms_color/gamma subtest
>
> Test requirement not met in function run_tests_for_pipe, file kms_color.c:858:
> Test requirement: igt_pipe_obj_has_prop(>display.pipes[p],
> IGT_CRTC_DEGAMMA_LUT_SIZE)
> Subtest
The DDB allocation algorithm currently used by the driver grants each
plane a very small minimum allocation of DDB blocks and then divies up
all of the remaining blocks based on the percentage of the total data
rate that the plane makes up. It turns out that this proportional
allocation approach
This is a maintenance release of Intel740 DDX.
For those who do not know what Intel740 is (was), as of now, it is the only
Intel
discrete graphics chip to officially ship ever since Intel got deeply involved
in
the x86 PC system business with the likes of PCI bus and USB.
And yes, that was
DSI implements it's own pre_enable hook, encoder output type is never
DSI.
Cc: Manasi Navare
Cc: Paulo Zanoni
Cc: James Ausmus
Fixes: fb5c8e9d4350 ("drm/i915/icl: Implement voltage swing programming
sequence for Combo PHY DDI")
Signed-off-by: Dhinakaran Pandiyan
---
== Series Details ==
Series: Change KVMGT into self loadable module (rev3)
URL : https://patchwork.freedesktop.org/series/53379/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5272_full -> Patchwork_11030_full
Summary
This is to suppress a compilation warning when compiling against
newer X Servers.
Signed-off-by: Kevin Brace
---
src/i740_driver.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/i740_driver.c b/src/i740_driver.c
index 7c1051d..a3675b6 100644
--- a/src/i740_driver.c
+++
Quoting Tvrtko Ursulin (2018-12-06 15:18:13)
>
> On 04/12/2018 14:15, Chris Wilson wrote:
> > Ignore trying to shrink from i915 if we fail to acquire the struct_mutex
> > in the shrinker while performing direct-reclaim. The trade-off being
> > (much) lower latency for non-i915 clients at an
Quoting Tvrtko Ursulin (2018-12-06 13:12:35)
>
> On 06/12/2018 08:44, Chris Wilson wrote:
> > Braswell is really picky about having our writes posted to memory before
> > we execute or else the GPU may see stale values. A wmb() is insufficient
> > as it only ensures the writes are visible to
Quoting Tvrtko Ursulin (2018-12-06 12:57:23)
>
> On 06/12/2018 08:44, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> > b/drivers/gpu/drm/i915/i915_gpu_error.c
> > index 07465123c166..7ca6f3f31d41 100644
> > --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> > +++
== Series Details ==
Series: Make GEN macros more similar (rev3)
URL : https://patchwork.freedesktop.org/series/51860/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5272_full -> Patchwork_11029_full
Summary
---
On Thu, Dec 06, 2018 at 12:25:48PM +1000, Dave Airlie wrote:
> I merged the i915 tree into drm-next this morning, but got a major
> conflict on the drm-tip rebuild in intel_workarounds.c.
>
> I'm not sure if I did wrong thing, but there were a couple of places
> where the code seemed inconsistent
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/selftests: verify_gt_engine_wa()
needs rpm wakeref
URL : https://patchwork.freedesktop.org/series/53687/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5277 -> Patchwork_11039
We can move the remaining RCS workarounds applied to only gen8 to the
engine->wa_list, and then reduce all engine->init_hw callbacks to common
code. The benefit of using the new wa_list is that we verify that the
registers are indeed restored and keep their magic values.
v2: INSTPM_FORCE_ORDERING
The mmio readback for verify_gt_engine_wa() also needs a runtime-pm
wakeref, so effectively do the entirety of both engine workarounds
tests. As such simplify the rpm behaviour here by acquiring the wakeref
for the whole of each subtest. It would be still useful to later verify
the registers
== Series Details ==
Series: New DDB allocation algorithm
URL : https://patchwork.freedesktop.org/series/53682/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5277 -> Patchwork_11038
Summary
---
**FAILURE**
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/selftests: verify_gt_engine_wa()
needs rpm wakeref
URL : https://patchwork.freedesktop.org/series/53673/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5277 -> Patchwork_11037
== Series Details ==
Series: New DDB allocation algorithm
URL : https://patchwork.freedesktop.org/series/53682/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Remove a very stale FIXME
Okay!
Commit: drm/i915: Don't use DDB allocation when
== Series Details ==
Series: New DDB allocation algorithm
URL : https://patchwork.freedesktop.org/series/53682/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2a7cd471873a drm/i915: Remove a very stale FIXME
e52095e73e0d drm/i915: Don't use DDB allocation when choosing gen9
The DDB allocation algorithm currently used by the driver grants each
plane a very small minimum allocation of DDB blocks and then divies up
all of the remaining blocks based on the percentage of the total data
rate that the plane makes up. It turns out that this proportional
allocation approach
The bspec gives an if/else chain for choosing whether to use "method 1"
or "method 2" for calculating the watermark "Selected Result Blocks"
value for a plane. One of the branches of the if chain is:
"Else If ('plane buffer allocation' is known and (plane buffer
allocation /
SKL watermark calculations can and do trigger atomic transaction
rejection if no valid set of watermarks can be found. This FIXME
comment in the code hasn't been relevant for a very long time.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 4
1 file changed, 4
Our current algorithm for partitioning a pipe's DDB allocation bases
plane allocations exclusively on the proportion of the pipe's data rate
that the plane contributes. This is a simple heuristic that works
pretty well in a lot of cases, but it breaks down when there's a large
difference in plane
We can move the remaining RCS workarounds applied to only gen8 to the
engine->wa_list, and then reduce all engine->init_hw callbacks to common
code. The benefit of using the new wa_list is that we verify that the
registers are indeed restored and keep their magic values.
v2: INSTPM_FORCE_ORDERING
The mmio readback for verify_gt_engine_wa() also needs a runtime-pm
wakeref, so effectively do the entirety of both engine workarounds
tests. As such simplify the rpm behaviour here by acquiring the wakeref
for the whole of each subtest. It would be still useful to later verify
the registers
Thanks for the patch and the review, pushed to dinq
Manasi`
On Thu, Nov 29, 2018 at 02:00:58PM -0800, Manasi Navare wrote:
> From: Matt Atwood
>
> According to DP spec (2.9.3.1 of DP 1.4) if
> EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in DPCD
> 02200h through 0220Fh shall
On 04/12/2018 14:15, Chris Wilson wrote:
Ignore trying to shrink from i915 if we fail to acquire the struct_mutex
in the shrinker while performing direct-reclaim. The trade-off being
(much) lower latency for non-i915 clients at an increased risk of being
unable to obtain a page from
== Series Details ==
Series: series starting with [1/2] drm/i915/selftests: verify_gt_engine_wa()
needs rpm wakeref
URL : https://patchwork.freedesktop.org/series/53666/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5275 -> Patchwork_11036
== Series Details ==
Series: series starting with [v2,1/3] ACPI / PMIC: Add support for executing
PMIC MIPI sequence elements
URL : https://patchwork.freedesktop.org/series/53662/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5275 -> Patchwork_11035
On 06/12/2018 14:18, Chris Wilson wrote:
The mmio readback for verify_gt_engine_wa() also needs a runtime-pm
wakeref, so effectively do the entirety of both engine workarounds
tests. As such simplify the rpm behaviour here by acquiring the wakeref
for the whole of each subtest. It would be
On Tue, Nov 27, 2018 at 04:12:58PM +0530, Ramalingam C wrote:
> This series enables the HDCP2.2 for I915. The sequence for HDCP2.2
> authentication and encryption is implemented as a generic flow
> between HDMI and DP. Encoder specific implementations are moved
> into hdcp_shim.
>
> Intel HWs
On Tue, Nov 27, 2018 at 04:13:31PM +0530, Ramalingam C wrote:
> Implement the required WA sequence for KBL to fix the
> incorrect positioning of the window of oppurtunity and enc_en
> signalling.
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_hdcp.c | 29
On Tue, Nov 27, 2018 at 04:13:30PM +0530, Ramalingam C wrote:
> Commits the content protection change of a connector,
> without crtc modeset. This improves the user experience.
>
> Originally proposed by Sean Paul at v3 of HDCP1.4 framework
> https://patchwork.freedesktop.org/patch/191759/. For
We can move the remaining RCS workarounds applied to only gen8 to the
engine->wa_list, and then reduce all engine->init_hw callbacks to common
code. The benefit of using the new wa_list is that we verify that the
registers are indeed restored and keep their magic values.
Signed-off-by: Chris
The mmio readback for verify_gt_engine_wa() also needs a runtime-pm
wakeref, so effectively do the entirety of both engine workarounds
tests. As such simplify the rpm behaviour here by acquiring the wakeref
for the whole of each subtest. It would be still useful to later verify
the registers
On Tue, Nov 27, 2018 at 04:13:11PM +0530, Ramalingam C wrote:
> Implements the HDMI adaptation specific HDCP2.2 operations.
>
> Basically these are DDC read and write for authenticating through
> HDCP2.2 messages.
>
> v2:
> Rebased.
> v3:
> No Changes.
> v4:
> No more special handling of
== Series Details ==
Series: drm/i915/execlists: Move RCS mmio workaround to new common wa_list
URL : https://patchwork.freedesktop.org/series/53656/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5275 -> Patchwork_11034
On Tue, Nov 27, 2018 at 04:13:10PM +0530, Ramalingam C wrote:
> Implements the DP adaptation specific HDCP2.2 functions.
>
> These functions perform the DPCD read and write for communicating the
> HDCP2.2 auth message back and forth.
>
> v2:
> wait for cp_irq is merged with this patch.
DSI LCD panels describe an initialization sequence in the Video BIOS
Tables using so called MIPI sequences. One possible element in these
sequences is a PMIC specific element of 15 bytes.
Although this is not really an ACPI opregion, the ACPI opregion code is the
closest thing we have. We need to
Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove
PMIC.
On some CHT devices this fixes the LCD panel not lighting up when it was
not initialized by the GOP, because an external monitor was plugged in and
the GOP initialized only the external monitor.
Signed-off-by: Hans
Add support for PMIC mipi sequences using the new
intel_soc_pmic_exec_mipi_pmic_seq_element function.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi_vbt.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c
On Tue, Nov 27, 2018 at 04:13:09PM +0530, Ramalingam C wrote:
> On DP HDCP1.4 and 2.2, when CP_IRQ is received, start the link
> integrity check for the HDCP version that is enabled.
>
> v2:
> Rebased. Function name is changed.
> v3:
> No Changes.
> v4:
> No Changes.
> v5:
> No Changes.
>
On Tue, Nov 27, 2018 at 04:13:08PM +0530, Ramalingam C wrote:
> When repeater notifies a downstream topology change, this patch
> reauthenticate the repeater alone without disabling the hdcp
> encryption. If that fails then complete reauthentication is executed.
>
> v2:
> Rebased.
> v3:
> No
On Thu, Dec 06, 2018 at 02:27:21PM +0100, Daniel Vetter wrote:
> On Tue, Nov 27, 2018 at 04:13:07PM +0530, Ramalingam C wrote:
> > Implements the link integrity check once in 500mSec.
> >
> > Once encryption is enabled, an ongoing Link Integrity Check is
> > performed by the HDCP Receiver to
On Tue, Nov 27, 2018 at 04:13:07PM +0530, Ramalingam C wrote:
> Implements the link integrity check once in 500mSec.
>
> Once encryption is enabled, an ongoing Link Integrity Check is
> performed by the HDCP Receiver to check that cipher synchronization
> is maintained between the HDCP
On 06/12/2018 08:44, Chris Wilson wrote:
Braswell is really picky about having our writes posted to memory before
we execute or else the GPU may see stale values. A wmb() is insufficient
as it only ensures the writes are visible to other cores, we need a full
mb() to ensure the writes are in
On 06/12/2018 08:44, Chris Wilson wrote:
Currently we face a severe problem on Braswell that manifests as invalid
ppGTT accesses. The code tries to maintain the PDP (page directory
pointers) inside the context in two ways, direct write into the context
and a pipelined LRI update. The direct
On 06/12/2018 12:56, Chris Wilson wrote:
We can move the remaining RCS workarounds applied to only gen8 to the
engine->wa_list, and then reduce all engine->init_hw callbacks to common
code. The benefit of using the new wa_list is that we verify that the
registers are indeed restored and keep
On 06/12/2018 08:44, Chris Wilson wrote:
Although commit fb6f0b64e455 ("drm/i915: Prevent machine hang from
Broxton's vtd w/a and error capture") applied cleanly after a 24 month
hiatus, the code had moved on with new methods for peeking and fetching
the captured gpu info. Make sure we catch
We can move the remaining RCS workarounds applied to only gen8 to the
engine->wa_list, and then reduce all engine->init_hw callbacks to common
code. The benefit of using the new wa_list is that we verify that the
registers are indeed restored and keep their magic values.
Signed-off-by: Chris
On Thu, Dec 06, 2018 at 02:23:00PM +0200, Imre Deak wrote:
> On Wed, Dec 05, 2018 at 10:20:23PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The DMC firmware is confused and forces on the BIOS and debug
> > power well requests for PW1 and MISC IO on some platforms. On
> > BXT I
On 06/12/2018 06:11, Lucas De Marchi wrote:
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of
gen_mask to do the comparison. Now callers can pass then gen as a parameter,
Since you are calling it out here, I assume there is some good reason to
replace gen_mask with gen?
On 06/12/2018 06:11, Lucas De Marchi wrote:
RANGE makes it longer, but clearer. We are also going to add a macro to
check an individual gen, so add the _RANGE prefix here.
Diff generated with:
sed 's/IS_GEN(/IS_GEN_RANGE(/g' drivers/gpu/drm/i915/{*/,}*.{c,h} -i
v2: use IS_GEN rather than
On Wed, Dec 05, 2018 at 10:20:23PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The DMC firmware is confused and forces on the BIOS and debug
> power well requests for PW1 and MISC IO on some platforms. On
> BXT I measured this to waste about 10mW in the freeze system
> suspend state
== Series Details ==
Series: drm/i915/dsc: Add Per connector debugfs node for DSC support/enable
(rev4)
URL : https://patchwork.freedesktop.org/series/53449/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5269_full -> Patchwork_11028_full
== Series Details ==
Series: Enable Y210, Y212, Y216 formats for ICL (rev4)
URL : https://patchwork.freedesktop.org/series/48729/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5274 -> Patchwork_11033
Summary
---
From: Tvrtko Ursulin
...
Signed-off-by: Tvrtko Ursulin
---
tests/i915/gem_shrink.c | 213
1 file changed, 213 insertions(+)
diff --git a/tests/i915/gem_shrink.c b/tests/i915/gem_shrink.c
index c8e05814ee70..acc12efed15e 100644
---
From: Tvrtko Ursulin
...
Signed-off-by: Tvrtko Ursulin
---
tests/i915/gem_shrink.c | 213
1 file changed, 213 insertions(+)
diff --git a/tests/i915/gem_shrink.c b/tests/i915/gem_shrink.c
index c8e05814ee70..d838a750fe68 100644
---
On Tue, Nov 27, 2018 at 04:13:06PM +0530, Ramalingam C wrote:
> Implements the HDCP2.2 repeaters authentication steps such as verifying
> the downstream topology and sending stream management information.
>
> v2:
> Rebased.
> v3:
> No Changes.
> v4:
> -EINVAL is returned for topology error
== Series Details ==
Series: Enable Y210, Y212, Y216 formats for ICL (rev4)
URL : https://patchwork.freedesktop.org/series/48729/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7ad9e3b1affc drm: Add Y210, Y212, Y216 format definitions and fourcc
-:46: WARNING:LONG_LINE: line
On Tue, Nov 27, 2018 at 04:13:04PM +0530, Ramalingam C wrote:
> Considering that HDCP2.2 is more secure than HDCP1.4, When a setup
> supports HDCP2.2 and HDCP1.4, HDCP2.2 will be enabled.
>
> When HDCP2.2 enabling fails and HDCP1.4 is supported, HDCP1.4 is
> enabled.
>
> This change implements a
On Tue, Nov 27, 2018 at 04:13:03PM +0530, Ramalingam C wrote:
> Defining the mei-i915 interface functions and initialization of
> the interface.
>
> Signed-off-by: Ramalingam C
> Signed-off-by: Tomas Winkler
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +
> drivers/gpu/drm/i915/intel_drv.h
On Tue, Nov 27, 2018 at 04:13:02PM +0530, Ramalingam C wrote:
> Add the HDCP2.2 initialization to the existing HDCP1.4 stack.
With the comments below addressed the commit message is a bit untrue,
since this just wires up a basic hdcp2_supported flag in a few places.
Please make that clear.
>
>
== Series Details ==
Series: drm/i915: Fix IGT kms_color/gamma subtest SKIP for GLK
URL : https://patchwork.freedesktop.org/series/53629/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5272 -> Patchwork_11032
Summary
Hi Dave,
Final pull request for -next targeting v4.21.
Most of the changes are small and all over the place, so I didn't enumerate
them all.
drm-misc-next-2018-12-06:
Final changes to drm-misc-next for v4.21:
UAPI Changes:
Core Changes:
- Add dma_fence_get_stub to dma-buf, and use it in
== Series Details ==
Series: drm/i915: Fix IGT kms_color/gamma subtest SKIP for GLK
URL : https://patchwork.freedesktop.org/series/53629/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8664eef5c26a drm/i915: Fix IGT kms_color/gamma subtest SKIP for GLK
-:8:
Added needed plane control flag definitions for Y210, Y212 and
Y216 formats.
v3: no change
v4: rebase
Signed-off-by: Swati Sharma
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
The following pixel formats are packed format that follows 4:2:2
chroma sampling. For memory represenation each component is
allocated 16 bits each. Thus each pixel occupies 32bit.
Y210: Valid data occupies MSB 10 bits.
LSB 6 bits are filled with zeroes.
Y212: Valid data occupies MSB 12
v3: case handling checking INTEL_GEN(dev_priv) < 11 added for these 3
new pixel formats (juha)
v4: rebase
Signed-off-by: Swati Sharma
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/intel_display.c | 9 +
drivers/gpu/drm/i915/intel_sprite.c | 3 +++
2 files changed, 12
These patches enable packed format YUV422-Y210, Y212 and Y216
for 10, 12 and 16 bit respectively for ICL.
For user space component IGT
IGT needs libraries for Pixman and Cairo to support more than 8bpc.
Work going on from Maarten Lankhorst.
v2: addressed review comments of mahesh and alexandru
In this patch, a list for icl specific pixel formats is created
in which Y210, Y212 and Y216 pixel formats are added along with
legacy pixel formats for primary and sprite plane.
v3: since support for planar formats on ICL was getting totally
skipped, added support for the same in
== Series Details ==
Series: drm/i915/cnl: Fix the formulae for register offsets (rev3)
URL : https://patchwork.freedesktop.org/series/52960/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5267_full -> Patchwork_11027_full
Looks good to me. Thanks.
Reviewed-by: Yuan, Hang
> -Original Message-
> From: Zhenyu Wang [mailto:zhen...@linux.intel.com]
> Sent: Thursday, December 6, 2018 4:03 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel-gvt-...@lists.freedesktop.org; Yuan, Hang ;
> Alex Williamson
>
Fix the skip for kms_color/gamma subtest
Test requirement not met in function run_tests_for_pipe, file kms_color.c:858:
Test requirement: igt_pipe_obj_has_prop(>display.pipes[p],
IGT_CRTC_DEGAMMA_LUT_SIZE)
Subtest pipe-A-gamma: SKIP
Test requirement not met in function run_tests_for_pipe, file
== Series Details ==
Series: series starting with [1/3] drm/i915: Skip the ERR_PTR error state
URL : https://patchwork.freedesktop.org/series/53625/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5272 -> Patchwork_11031
== Series Details ==
Series: series starting with [1/3] drm/i915: Skip the ERR_PTR error state
URL : https://patchwork.freedesktop.org/series/53625/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
47d5e8ffa422 drm/i915: Skip the ERR_PTR error state
26553eeb0969 drm/i915:
== Series Details ==
Series: Change KVMGT into self loadable module (rev3)
URL : https://patchwork.freedesktop.org/series/53379/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5272 -> Patchwork_11030
Summary
---
Hi Ville,
Thank you for the review.
On 05-12-18 22:25, Ville Syrjälä wrote:
On Wed, Dec 05, 2018 at 10:03:09PM +0100, Hans de Goede wrote:
Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove
PMIC.
On some CHT devices this fixes the LCD panel not lighting up when it was
Although commit fb6f0b64e455 ("drm/i915: Prevent machine hang from
Broxton's vtd w/a and error capture") applied cleanly after a 24 month
hiatus, the code had moved on with new methods for peeking and fetching
the captured gpu info. Make sure we catch all uses of the stashed error
state and avoid
Braswell is really picky about having our writes posted to memory before
we execute or else the GPU may see stale values. A wmb() is insufficient
as it only ensures the writes are visible to other cores, we need a full
mb() to ensure the writes are in memory and visible to the GPU.
The most
Currently we face a severe problem on Braswell that manifests as invalid
ppGTT accesses. The code tries to maintain the PDP (page directory
pointers) inside the context in two ways, direct write into the context
and a pipelined LRI update. The direct write into the context is
fundamentally racy as
On Wed, Dec 05, 2018 at 05:14:39PM +0530, Ramalingam C wrote:
> Couple of more HDCP1.4 fixes on
> - Key load process for CFL
> - Encryption status change time
> - debug log addition
> - active platform coverage
>
> v1 and v2 went into old series
1 - 100 of 101 matches
Mail list logo
