On 10/3/2018 10:36 AM, Vivi, Rodrigo wrote:
On Oct 2, 2018, at 9:20 PM, Yadav, Jyoti R wrote:
DC5 and DC6 counter register tells about residency of DC5 and DC6.
These registers are same for SKL and ICL.
v2 : Remove csr_version check.
Added generic check regarding DC counters for
== Series Details ==
Series: drm/i915: Fix the HDMI hot plug disconnection failure
URL : https://patchwork.freedesktop.org/series/50477/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4916 -> Patchwork_10333 =
== Summary - SUCCESS ==
No regressions found.
External
== Series Details ==
Series: drm/i915: Fix the HDMI hot plug disconnection failure
URL : https://patchwork.freedesktop.org/series/50477/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
de3c5d5af683 drm/i915: Fix the HDMI hot plug disconnection failure
-:60: CHECK:BRACES:
On some platforms, slowly unplugging (wiggling) the HDMI cable makes
the kernel to believe the HDMI display still connected. This is because
the HDMI DDC lines are disconnected sometimes later after the hot-plug
interrupt triggered. Use the hot plug live states to honor HDMI hot plug
status in
> On Oct 2, 2018, at 9:20 PM, Yadav, Jyoti R wrote:
>
> DC5 and DC6 counter register tells about residency of DC5 and DC6.
> These registers are same for SKL and ICL.
>
> v2 : Remove csr_version check.
> Added generic check regarding DC counters for Gen9 onwards. (Rodrigo)
> v3 :
== Series Details ==
Series: drm/i915/csr Added DC5 and DC6 counter register for ICL in debugfs
entry. (rev3)
URL : https://patchwork.freedesktop.org/series/49800/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4916 -> Patchwork_10332 =
== Summary - FAILURE ==
Serious
DC5 and DC6 counter register tells about residency of DC5 and DC6.
These registers are same for SKL and ICL.
v2 : Remove csr_version check.
Added generic check regarding DC counters for Gen9 onwards. (Rodrigo)
v3 : Simplified gen checks. (Chris)
Signed-off-by: Jyoti Yadav
---
== Series Details ==
Series: series starting with [1/4] drm/i915: Replace some open-coded
i915_map_coherent_type() (rev2)
URL : https://patchwork.freedesktop.org/series/50408/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4915_full -> Patchwork_10324_full =
== Summary -
On 02/10/18 15:39, Patchwork wrote:
== Series Details ==
Series: series starting with [v2,1/3] drm/i915/guc: init GuC descriptors after
GuC load
URL : https://patchwork.freedesktop.org/series/50464/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4915 -> Patchwork_10331
On Tue, 2018-10-02 at 12:37 -0700, Souza, Jose wrote:
> On Thu, 2018-09-27 at 23:11 -0700, Dhinakaran Pandiyan wrote:
> > We have new tests and fixes in place since the feature was last
> > disabled. Try again for gen-9+ hardware and enable only PSR1 by
> > default as
> > a first step.
> > v2:
== Series Details ==
Series: series starting with [v2,1/3] drm/i915/guc: init GuC descriptors after
GuC load
URL : https://patchwork.freedesktop.org/series/50464/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4915 -> Patchwork_10331 =
== Summary - FAILURE ==
Serious
== Series Details ==
Series: series starting with [v2,1/3] drm/i915/guc: init GuC descriptors after
GuC load
URL : https://patchwork.freedesktop.org/series/50464/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9830698b9d34 drm/i915/guc: init GuC descriptors after GuC load
== Series Details ==
Series: drm: Fix kernel doc for DRM_MODE_PROP_IMMUTABLE
URL : https://patchwork.freedesktop.org/series/50462/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4915 -> Patchwork_10330 =
== Summary - WARNING ==
Minor unknown changes coming with
GuC stores some data in there, which might be stale after a reset.
We already reset the WQ head and tail, but more things are being moved
to the descriptor with the interface updates. Instead of trying to track
them one by one, always memset and init the descriptors from scratch
after GuC is
From: Michal Wajdeczko
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_params.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 7e56c516c815..c681537bcb92 100644
---
If the HW has not processed the db invalidation request yet, clearing
the cookie can generate a db ring. We clear the cookie when we
(re-)allocate the doorbell so no need to do it on destroy as well as no
one is going to look at it while the doorbell is inactive
v2: fix typo in patch title
This patch explains the DRM_MODE_PROP_IMMUTABLE flag a bit better
by telling which function to call if kernel wants to update
drm object's immutable properties.
Suggested-by: Daniel Vetter
Cc: Daniel Vetter
Signed-off-by: Manasi Navare
---
include/drm/drm_property.h | 3 ++-
1 file changed, 2
On Tue, Oct 02, 2018 at 10:50:47AM -0700, José Roberto de Souza wrote:
> For ICL type-c ports there is a aux power restriction, it can only be
> enabled while there is sink connected.
>
> BSpec: 21750
>
> v2:
> - rebased on top of the refactored version of intel_dp_detect()
> - fixing CI errors
== Series Details ==
Series: drm/i915: Show actual along side request frequency in
debugfs/i915_rps_boost_info (rev2)
URL : https://patchwork.freedesktop.org/series/50431/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4914_full -> Patchwork_10323_full =
== Summary -
On Tue, Oct 02, 2018 at 10:50:50AM -0700, José Roberto de Souza wrote:
> Before enter in power saving states or before unload the driver
> spec states that display driver is required to to mark TC ports as
> safe so hardware can do the disconnection flow without wait for
> display driver
On Tue, Oct 02, 2018 at 10:50:49AM -0700, José Roberto de Souza wrote:
> intel_dp_sink_dpms() is also called in the DP port disconnection
> flow, causing the DPCD transactions to fail due obvious reaons.
> So lets check the connector state before waste any time trying
> to do DPCD in a
On 02/10/18 01:30, Joonas Lahtinen wrote:
Quoting Antonio Argenziano (2018-10-01 22:53:46)
Fair enough.
Acked-by: Antonio Argenziano
for the series.
Please, read the following chapters (they're applicable for the patch
tag meanings in IGT, too):
On Tue, Oct 02, 2018 at 10:50:47AM -0700, José Roberto de Souza wrote:
> For ICL type-c ports there is a aux power restriction, it can only be
> enabled while there is sink connected.
>
> BSpec: 21750
>
> v2:
> - rebased on top of the refactored version of intel_dp_detect()
> - fixing CI errors
== Series Details ==
Series: drm/i915: Optionally disable automatic recovery after a GPU reset
URL : https://patchwork.freedesktop.org/series/50458/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4915 -> Patchwork_10329 =
== Summary - WARNING ==
Minor unknown changes
When RECOVERABLE is set, the kernel will attempt to automatically recover
a context after a hang. But if it is unset, the kernel will ban the
guilty context on a hang, preventing subsequent execution.
Signed-off-by: Chris Wilson
---
tests/gem_ctx_exec.c | 38
On Thu, 2018-09-27 at 23:11 -0700, Dhinakaran Pandiyan wrote:
> We have new tests and fixes in place since the feature was last
> disabled. Try again for gen-9+ hardware and enable only PSR1 by
> default as
> a first step.
> v2: Remove typo fix and comment improvements (Rodrigo)
Reviewed-by: José
Some clients, such as mesa, may only emit minimal incremental batches
that rely on the logical context state from previous batches. They know
that recovery is impossible after a hang as their required GPU state is
lost, and that each in flight and subsequent batch will hang (resetting
the context
== Series Details ==
Series: series starting with [01/10] drm: Do not call drm_dp_cec_set_edid()
while registering DP connectors
URL : https://patchwork.freedesktop.org/series/50456/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4915 -> Patchwork_10328 =
== Summary -
On Tue, Oct 02, 2018 at 02:45:23PM +0300, Imre Deak wrote:
> Thanks, found the note now. So all the EDP/MIPI VDSC regs and
> functionality are in PG2.
Yes so if cpu transcoder is eDP then we need to enable the PG2 power well
>
> On Mon, Oct 01, 2018 at 09:32:48PM +0300, Runyan, Arthur J wrote:
== Series Details ==
Series: series starting with [01/10] drm: Do not call drm_dp_cec_set_edid()
while registering DP connectors
URL : https://patchwork.freedesktop.org/series/50456/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm: Do not call drm_dp_cec_set_edid()
== Series Details ==
Series: series starting with [01/10] drm: Do not call drm_dp_cec_set_edid()
while registering DP connectors
URL : https://patchwork.freedesktop.org/series/50456/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c5f04ccd7a0a drm: Do not call
== Series Details ==
Series: drm/i915: Rename full ppgtt configuration to be more generic (rev5)
URL : https://patchwork.freedesktop.org/series/49021/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4915 -> Patchwork_10327 =
== Summary - WARNING ==
Minor unknown changes
Before enter in power saving states or before unload the driver
spec states that display driver is required to to mark TC ports as
safe so hardware can do the disconnection flow without wait for
display driver handshake.
When driver is resumed or loaded again, if the TC live state is
still set as
Some USB type-C dongles requires some time to power on before being
able to process aux channel transactions.
It was not a problem for older gens because there was a bridge
between DP port and USB-C controller adding some delay but ICL
handles type-C native.
So here trying to do a aux channel
Otherwise it would be in a inconsistent state as port is disconnected
but with a valid tc type.
Also setting it to unknown will earlier return
icl_tc_phy_disconnect() for any future calls to
intel_digital_port_connected(), this way we don't need to check if
port is marked as safe everytime.
Cc:
intel_dp_sink_dpms() is also called in the DP port disconnection
flow, causing the DPCD transactions to fail due obvious reaons.
So lets check the connector state before waste any time trying
to do DPCD in a disconnected sink.
Signed-off-by: José Roberto de Souza
---
It is only used by eDP ports so no need to initialize it for each DP
port.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_dp.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index
Otherwise it would be in a inconsistent state as port is disconnected
but with a valid tc type.
Cc: Paulo Zanoni
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_dp.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
Moving all the error handling to the end of the function and ealier
returning for connected MST ports make this function way more easy to
read.
No functional changed is intended here.
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: Dhinakaran Pandiyan
Signed-off-by: José Roberto de Souza
---
For ICL type-c ports there is a aux power restriction, it can only be
enabled while there is sink connected.
BSpec: 21750
v2:
- rebased on top of the refactored version of intel_dp_detect()
- fixing CI errors by getting runtime_pm(), for VLV/CHV it is also
necessary get the DPIO power well
Besides of give the expected output of i915_display_info it will also
avoid some aux ch transactions that would timeout by obvious reasons.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_debugfs.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
drm_dp_cec_register_connector() is called when registering each DP
connector in DRM, while sounds a good idea register CEC adapters as
earlier as possible, it causes some driver initialization delay
trying to do DPCD transactions in disconnected connectors.
This change will cause no regressions
== Series Details ==
Series: drm/i915: Rename full ppgtt configuration to be more generic (rev5)
URL : https://patchwork.freedesktop.org/series/49021/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Make 48bit full ppgtt configuration generic (v6)
== Series Details ==
Series: drm/i915: fix wrong error number report (rev2)
URL : https://patchwork.freedesktop.org/series/50406/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4913_full -> Patchwork_10321_full =
== Summary - SUCCESS ==
No regressions found.
==
Quoting Bob Paauwe (2018-10-02 18:39:14)
> 48 bit ppgtt device configuration is really just extended address
> range full ppgtt and may actually be something other than 48 bits.
>
> Change HAS_FULL_48BIT_PPGTT() to HAS_4LVL_PPGTT() to better
> describe that a 4 level walk table extended range
Quoting Bob Paauwe (2018-09-14 16:51:34)
> On Thu, 13 Sep 2018 20:22:14 +0300
> Ville Syrjälä wrote:
>
> > On Thu, Sep 13, 2018 at 10:12:06AM -0700, Bob Paauwe wrote:
> > > On Thu, 13 Sep 2018 20:05:54 +0300
> > > Ville Syrjälä wrote:
> > >
> > > > On Thu, Sep 13, 2018 at 10:02:57AM -0700,
On Mon, 2018-10-01 at 15:17 -0700, Rodrigo Vivi wrote:
> On Thu, Sep 27, 2018 at 11:11:17PM -0700, Dhinakaran Pandiyan wrote:
> > We have new tests and fixes in place since the feature was last
> > disabled. Try again for gen-9+ hardware and enable only PSR1 by
> > default as
> > a first step.
> >
48 bit ppgtt device configuration is really just extended address
range full ppgtt and may actually be something other than 48 bits.
Change HAS_FULL_48BIT_PPGTT() to HAS_4LVL_PPGTT() to better
describe that a 4 level walk table extended range PPGTT is being
used. Add a new device info field that
On Tue, Oct 02, 2018 at 04:36:31PM +, Thomas Hellstrom wrote:
> On 10/02/2018 05:15 PM, Ville Syrjälä wrote:
> > On Tue, Oct 02, 2018 at 03:35:12PM +0200, Daniel Vetter wrote:
> >> The core _does_ the call to drm_atomic_commit for you. That's pretty
> >> much the entire point of having the
Hi, Daniel,
On 10/02/2018 03:35 PM, Daniel Vetter wrote:
> The idea behind allowing drivers to override legacy ioctls (instead of
> using the generic implementations unconditionally) is to handle bugs
> in old driver-specific userspace. Like e.g. vmw_kms_set_config does,
> to work around some
On 10/02/2018 05:15 PM, Ville Syrjälä wrote:
> On Tue, Oct 02, 2018 at 03:35:12PM +0200, Daniel Vetter wrote:
>> The core _does_ the call to drm_atomic_commit for you. That's pretty
>> much the entire point of having the fancy new atomic_set/get_prop
>> callbacks.
>>
>> Signed-off-by: Daniel
On Tue, Oct 02, 2018 at 04:36:07PM +0100, Chris Wilson wrote:
> If KMS is not supported, drmGetResources() will return NULL so be
> careful not to dereference it. However, we still insist that runtime pm
> works, so keep on testing.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Ville Syrjälä
>
Quoting Ville Syrjälä (2018-10-02 16:46:55)
> On Tue, Oct 02, 2018 at 12:11:51PM +0100, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-10-02 12:02:26)
> > >
> > > On 02/10/2018 09:36, Chris Wilson wrote:
> > > > Previously we hesitated in adding the hw probe for the actual GPU
> > > >
On Tue, Oct 02, 2018 at 12:11:51PM +0100, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-10-02 12:02:26)
> >
> > On 02/10/2018 09:36, Chris Wilson wrote:
> > > Previously we hesitated in adding the hw probe for the actual GPU
> > > frequency for rps_boost as it is quite cumbersome, but given
On Tue, Oct 02, 2018 at 03:35:11PM +0200, Daniel Vetter wrote:
> We already have a separate overview doc for this, makes sense to
> untangle it from the overall atomic helpers.
>
> v2: Rebase
>
> v3: Rebase more.
Hopefully the rebases didn't leave any code changes behind...
Too lazy to read in
On Tue, Oct 02, 2018 at 03:35:14PM +0200, Daniel Vetter wrote:
> Motivated by vmwgfx digging around in core uapi bits it shouldn't dig
> around in.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Ville Syrjälä
> ---
> include/drm/drm_atomic.h | 10 +-
> 1 file changed, 9 insertions(+),
On Tue, Oct 02, 2018 at 03:35:18PM +0200, Daniel Vetter wrote:
> drm_plane_helper_disable is a non-atomic drivers only function, and
> will blow up (since no one passes the locking context it needs).
>
> Atomic drivers which want to quiescent their hw on unload should
> use
If KMS is not supported, drmGetResources() will return NULL so be
careful not to dereference it. However, we still insist that runtime pm
works, so keep on testing.
Signed-off-by: Chris Wilson
---
tests/pm_rpm.c | 71 +++---
1 file changed, 44
On Tue, Oct 02, 2018 at 03:35:16PM +0200, Daniel Vetter wrote:
> These do absolutely nothing for atomic drivers.
>
> Signed-off-by: Daniel Vetter
> Cc: Alexey Brodkin
> ---
> drivers/gpu/drm/arc/arcpgu_crtc.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git
On Tue, Oct 02, 2018 at 03:35:17PM +0200, Daniel Vetter wrote:
> These do absolutely nothing for atomic drivers.
>
> Signed-off-by: Daniel Vetter
> Cc: Boris Brezillon
> Cc: Nicolas Ferre
> Cc: Alexandre Belloni
> Cc: linux-arm-ker...@lists.infradead.org
Reviewed-by: Ville Syrjälä
> ---
>
Take the device fd from the caller as to which card we should try and
enable connectors for (or else we may not enable the right connectors
for the test!) and fail gracefully if there is no kms support on the
device.
Signed-off-by: Chris Wilson
---
lib/igt_kms.c| 10 +++---
Hi,
On Tue, Oct 02, 2018 at 02:15:42PM +0300, Stanislav Lisovskiy wrote:
> v5: This is YUV444 packed format same as AYUV, but without alpha,
> as supported by i915.
>
> v6: Removed unneeded initializer for new XYUV format.
>
> v7: Added is_yuv field initialization according to latest
>
Quoting Mika Kuoppala (2018-10-02 15:05:52)
> Don't keep master disabled while we handle the current
> interrupts. This should help a little on latency of
> generating the next interrupt.
>
> Suggested-by: Chris Wilson
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
> ---
>
Quoting Mika Kuoppala (2018-10-02 15:05:51)
> Disable master interrupt before reading level indications.
> This will close a race where we get a level indication between
> reading and disabling, generating an extra interrupt where we
> could have avoided one.
>
> Further, as the reading acts also
Quoting Mika Kuoppala (2018-10-02 15:05:49)
> Disable master interrupt before reading level indications.
> This will close a race where we get a level indication between
> reading and disabling, generating an extra interrupt where we
> could have avoided one.
>
> Further, as the reading acts also
On Tue, Oct 02, 2018 at 03:35:12PM +0200, Daniel Vetter wrote:
> The core _does_ the call to drm_atomic_commit for you. That's pretty
> much the entire point of having the fancy new atomic_set/get_prop
> callbacks.
>
> Signed-off-by: Daniel Vetter
> Cc: VMware Graphics
> Cc: Sinclair Yeh
> Cc:
Hi,
How is this going on, anything holding it back from getting merged ?
I'm interested in adding/using P010, [1]
Thank you,
Alex Gheorghe
[1] https://lists.freedesktop.org/archives/dri-devel/2018-August/186963.html
On Thu, Aug 30, 2018 at 03:41:11PM +0300, Juha-Pekka Heikkila wrote:
> Add
On Tue, Oct 02, 2018 at 02:21:32PM +0200, Daniel Vetter wrote:
> On Mon, Oct 01, 2018 at 05:31:27PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Print the plane hw state readout results in the common format
> > we already use for pipes and encoders. Also print some clearer
> >
== Series Details ==
Series: series starting with [1/4] drm/i915/gen8: Disable master intr before
reading
URL : https://patchwork.freedesktop.org/series/50446/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4915 -> Patchwork_10326 =
== Summary - WARNING ==
Minor unknown
On 02/10/2018 14:52, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-10-02 14:46:10)
On 02/10/2018 14:22, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-10-02 14:13:14)
On 02/10/2018 13:24, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-10-02 13:20:05)
On 01/10/2018 20:44, Chris
On Tue, Oct 02, 2018 at 02:11:34PM +0200, Daniel Vetter wrote:
> On Mon, Oct 01, 2018 at 05:31:20PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > When we decide that a plane is attached to the wrong pipe we try
> > to turn off said plane. However we are passing around the crtc we
>
== Series Details ==
Series: drm/i915/selftests: Hold task_struct ref for smoking kthread
URL : https://patchwork.freedesktop.org/series/50441/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4915 -> Patchwork_10325 =
== Summary - WARNING ==
Minor unknown changes coming
All other master control register bits, except the enable,
are read only and they are level indications of the second
level interrupt status. Only touch enable bit and rectify
the comment.
Cc: Chris Wilson
Cc: Dhinakaran Pandiyan
Signed-off-by: Mika Kuoppala
---
Don't keep master disabled while we handle the current
interrupts. This should help a little on latency of
generating the next interrupt.
Suggested-by: Chris Wilson
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_irq.c | 4 +---
1 file changed, 1 insertion(+), 3
Disable master interrupt before reading level indications.
This will close a race where we get a level indication between
reading and disabling, generating an extra interrupt where we
could have avoided one.
Further, as the reading acts also as a post, replace the
write/post on the irq reset with
Disable master interrupt before reading level indications.
This will close a race where we get a level indication between
reading and disabling, generating an extra interrupt where we
could have avoided one.
Further, as the reading acts also as a post, replace the
write/post on the irq reset with
Hi Daniel,
Thank you for the patch.
On Tuesday, 2 October 2018 16:35:10 EEST Daniel Vetter wrote:
> It's the default. The exported version was kinda a transition state,
> before we made this the default.
>
> To stop new atomic drivers from using it (instead of just relying on
> the default)
== Series Details ==
Series: drm/i915/selftests: Hold task_struct ref for smoking kthread
URL : https://patchwork.freedesktop.org/series/50441/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
35b442e8bb4d drm/i915/selftests: Hold task_struct ref for smoking kthread
-:10:
Quoting Tvrtko Ursulin (2018-10-02 14:46:10)
>
> On 02/10/2018 14:22, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-10-02 14:13:14)
> >>
> >> On 02/10/2018 13:24, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2018-10-02 13:20:05)
>
> On 01/10/2018 20:44, Chris Wilson wrote:
>
== Series Details ==
Series: series starting with [1/4] drm/i915: Replace some open-coded
i915_map_coherent_type() (rev2)
URL : https://patchwork.freedesktop.org/series/50408/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4915 -> Patchwork_10324 =
== Summary - WARNING ==
On 02/10/2018 14:22, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-10-02 14:13:14)
On 02/10/2018 13:24, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-10-02 13:20:05)
On 01/10/2018 20:44, Chris Wilson wrote:
The final call to zlib_deflate(Z_FINISH) may require more output
space to be
On Tue, Oct 02, 2018 at 12:56:02PM +0300, Joonas Lahtinen wrote:
> The following patches with Fixes: do not cleanly apply
> to drm-intel-next-fixes:
>
> 47658556da85 ("drm/i915/dp: Do not grab crtc modeset lock in
> intel_dp_detect()")
>
> Please provide a backported patch ASAP, if they are
These do absolutely nothing for atomic drivers.
Signed-off-by: Daniel Vetter
Cc: Boris Brezillon
Cc: Nicolas Ferre
Cc: Alexandre Belloni
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 2 --
1 file changed, 2 deletions(-)
diff --git
drm_plane_helper_disable is a non-atomic drivers only function, and
will blow up (since no one passes the locking context it needs).
Atomic drivers which want to quiescent their hw on unload should
use drm_atomic_helper_shutdown() instead.
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
The idea behind allowing drivers to override legacy ioctls (instead of
using the generic implementations unconditionally) is to handle bugs
in old driver-specific userspace. Like e.g. vmw_kms_set_config does,
to work around some vmwgfx userspace not clearing its ioctl structs
properly.
But you
These do absolutely nothing for atomic drivers.
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu_crtc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index 965cda48dc13..26cb2800f3ad
That's purely for the uapi layer to implement the ALLOW_MODESET flag.
Drivers should instead look at the state, e.g. through
drm_atomic_crtc_needs_modeset(), which vmwgfx already does. Also remove
the confusing comment, since checking allow_modeset is at best a micro
optimization.
Signed-off-by:
Motivated by vmwgfx digging around in core uapi bits it shouldn't dig
around in.
Signed-off-by: Daniel Vetter
---
include/drm/drm_atomic.h | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index
Hi all,
Here's a pile of atomic helper cleanups. Big chunk is shredding the
transitional helpers, I don't think they're useful anymore. armada is
converted, vboxvideo is getting converted as we speak for 4.20, anything
that's left is probably better to just move over to a simple display pipe
For atomic driver this is the default, no need to reimplement it. We
still need to keep the copypasta for not-atomic drivers though, since
no one polished the legacy crtc helpers as much as the atomic ones.
v2: amdgpu uses ->best_encoder internally, give it a local copy. It
might be a good idea
The core _does_ the call to drm_atomic_commit for you. That's pretty
much the entire point of having the fancy new atomic_set/get_prop
callbacks.
Signed-off-by: Daniel Vetter
Cc: VMware Graphics
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 6 --
1 file
It's the default. The exported version was kinda a transition state,
before we made this the default.
To stop new atomic drivers from using it (instead of just relying on
the default) let's unexport it.
Signed-off-by: Daniel Vetter
Cc: Gustavo Padovan
Cc: Maarten Lankhorst
Cc: Sean Paul
Cc:
We already have a separate overview doc for this, makes sense to
untangle it from the overall atomic helpers.
v2: Rebase
v3: Rebase more.
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms-helpers.rst | 19 +-
drivers/gpu/drm/Makefile | 3 +-
== Series Details ==
Series: series starting with [1/4] drm/i915: Replace some open-coded
i915_map_coherent_type() (rev2)
URL : https://patchwork.freedesktop.org/series/50408/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Handle incomplete Z_FINISH for
As the kthread may terminate itself, the parent must hold a task_struct
reference for it to call kthread_stop().
<4> [498.827675] stack segment: [#1] PREEMPT SMP PTI
<4> [498.827683] CPU: 0 PID: 3872 Comm: drv_selftest Tainted: G U
4.19.0-rc6-CI-CI_DRM_4915+ #1
<4>
Quoting Tvrtko Ursulin (2018-10-02 14:13:14)
>
> On 02/10/2018 13:24, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-10-02 13:20:05)
> >>
> >> On 01/10/2018 20:44, Chris Wilson wrote:
> >>> The final call to zlib_deflate(Z_FINISH) may require more output
> >>> space to be allocated and so
On 02/10/2018 13:24, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-10-02 13:20:05)
On 01/10/2018 20:44, Chris Wilson wrote:
The final call to zlib_deflate(Z_FINISH) may require more output
space to be allocated and so needs to re-invoked. Failure to do so in
the current code leads to
Quoting Chris Wilson (2018-10-02 12:18:49)
> Quoting Andi Shyti (2018-10-02 10:20:47)
> > During driver load it's considered that the i915_driver_create()
> > function fails only in case of insufficient memory. Indeed, in
> > case of failure of i915_driver_create(), the load function
> > returns
The final call to zlib_deflate(Z_FINISH) may require more output
space to be allocated and so needs to re-invoked. Failure to do so in
the current code leads to incomplete zlib streams (albeit intact due to
the use of Z_SYNC_FLUSH) resulting in the occasional short object
capture.
v2: Check
On 01/10/2018 20:44, Chris Wilson wrote:
We do not need to continually clear our dedicated PTE for error capture
as it will be updated and invalidated to the next object. Only at the
end do we wish to be sure that the PTE doesn't point back to any buffer.
Signed-off-by: Chris Wilson
---
1 - 100 of 144 matches
Mail list logo
