On 2021.08.17 09:08:55 +0800, Zhenyu Wang wrote:
> On 2021.08.16 19:34:58 +0200, Christoph Hellwig wrote:
> > On Wed, Aug 04, 2021 at 01:26:06PM +0800, Zhenyu Wang wrote:
> > > On 2021.08.03 11:30:58 -0300, Jason Gunthorpe wrote:
> > > > On Tue, Aug 03, 2021 at 05:43:15PM +0800, Zhenyu Wang wrote:
On Mon, 16 Aug 2021, Matt Roper wrote:
> On Fri, Aug 13, 2021 at 03:33:30PM +0300, Jani Nikula wrote:
>> DG2 has 243000 but not 648000.
>
> Am I looking in the wrong place? When I check the bspec page I still
> see:
>
> eDP/DP link bit rates: 1.62, 2.16, 2.7, 3.24, 4.32, 5.4, 6.48,
>
On 2021.08.16 19:34:58 +0200, Christoph Hellwig wrote:
> On Wed, Aug 04, 2021 at 01:26:06PM +0800, Zhenyu Wang wrote:
> > On 2021.08.03 11:30:58 -0300, Jason Gunthorpe wrote:
> > > On Tue, Aug 03, 2021 at 05:43:15PM +0800, Zhenyu Wang wrote:
> > > > Acked-by: Zhenyu Wang
> > > >
> > > > Thanks a
On Mon, Aug 16, 2021 at 10:22:29AM +0530, Ayaz A Siddiqui wrote:
> In order to program unused and reserved mocs entries to L3_WB,
> we need to create a separate mocs table for alderlake.
>
> This patch will also covers wa_1608975824.
>
> Cc: Chris P Wilson
> Cc: Lucas De Marchi
>
>
On Mon, Aug 16, 2021 at 10:22:28AM +0530, Ayaz A Siddiqui wrote:
> During to creation mocs table,used field of drm_i915_mocs_entry
> is being checked, if used field is 0, then it will check values
> of index 1. All the unspecified indexes of xxx_mocs_table[] will
> contain control value and l3cc
On Mon, Aug 16, 2021 at 10:22:27AM +0530, Ayaz A Siddiqui wrote:
> From: Apoorva Singh
>
> Blitter commands which does not have MOCS fields rely on
> cacheability of BlitterCacheControlRegister which was mapped
> to index 0 by default.Once we changed the MOCS value of
> index 0 to L3 WB, tests
On Mon, Aug 16, 2021 at 10:22:26AM +0530, Ayaz A Siddiqui wrote:
> From: Srinivasan Shanmugam
>
> Program CMD_CCTL to use a mocs entry for uncached access.
> This controls memory accesses by CS as it reads instructions
> from the ring and batch buffers.
>
> v2: Added CMD_CCTL in
On Fri, Aug 13, 2021 at 03:33:30PM +0300, Jani Nikula wrote:
> DG2 has 243000 but not 648000.
Am I looking in the wrong place? When I check the bspec page I still
see:
eDP/DP link bit rates: 1.62, 2.16, 2.7, 3.24, 4.32, 5.4, 6.48,
8.1 GHz, SSC and Non-SSC
which matches the ICL
One of the cases that the bspec lists for when underrun recovery must be
disabled is "COG;" that note actually refers to eDP multi-segmented
operation (MSO). Let's ensure the this additional restriction is
honored by the driver.
Bspec: 50351
Cc: Ville Syrjälä
Fixes: ba3b049f4774
On Mon, Aug 16, 2021 at 01:09:27PM +0300, Jani Nikula wrote:
> On Wed, 21 Jul 2021, José Roberto de Souza wrote:
> > VBT has support for up two integrated panels but i915 only supports one.
> >
> > So here stating to add the basic support for two integrated panels
> > and moving the DRRS to
On Wed, Jul 21, 2021 at 10:43:37PM -0700, José Roberto de Souza wrote:
> On newer platform this opregion call always fails, also it do not
> support multiple panels so dropping it.
We only use the panel type from opregion on specific machines based on
aa DMI match. So this patch is basically a
On Wed, Aug 04, 2021 at 01:26:06PM +0800, Zhenyu Wang wrote:
> On 2021.08.03 11:30:58 -0300, Jason Gunthorpe wrote:
> > On Tue, Aug 03, 2021 at 05:43:15PM +0800, Zhenyu Wang wrote:
> > > Acked-by: Zhenyu Wang
> > >
> > > Thanks a lot for this effort!
> >
> > Great, do we have a submission plan
It's only used by the for_i915_gem_ww() macro and we can use
the (typically) on-stack _err variable in its place.
v2:
- Don't clear the _err variable when entering the loop
(Matthew Auld, Maarten Lankhorst).
- Use parentheses around the _err macro argument.
- Fix up comment.
Cc: Matthew Auld
On Fri, Aug 13, 2021 at 04:24:37PM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 8/3/2021 6:23 PM, Matthew Brost wrote:
> > The i915 currently has 2k visible priority levels which are currently
> > unique. This is changing to statically map these 2k levels into 3
> > buckets:
> >
> > low: < 0
>
On Wed, Aug 04, 2021 at 11:24:02PM +0800, Kai-Heng Feng wrote:
> Users reported that after commit 2bbd6dba84d4 ("drm/i915: Try to use
> fast+narrow link on eDP again and fall back to the old max strategy on
> failure"), the screen starts to have wobbly effect.
>
> Commit a5c936add6a2
On 8/16/2021 8:15 AM, Daniel Vetter wrote:
On Fri, Aug 13, 2021 at 08:18:02AM -0700, Daniele Ceraolo Spurio wrote:
On 8/13/2021 7:37 AM, Daniel Vetter wrote:
On Wed, Jul 28, 2021 at 07:01:01PM -0700, Daniele Ceraolo Spurio wrote:
This api allow user mode to create protected buffers and to
On Fri, Aug 13, 2021 at 08:24:44AM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 8/13/2021 7:42 AM, Daniel Vetter wrote:
> > On Fri, Aug 13, 2021 at 04:37:53PM +0200, Daniel Vetter wrote:
> > > On Wed, Jul 28, 2021 at 07:01:01PM -0700, Daniele Ceraolo Spurio wrote:
> > > > This api allow user
== Series Details ==
Series: drm: avoid races with modesetting rights
URL : https://patchwork.freedesktop.org/series/93714/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10488_full -> Patchwork_20831_full
Summary
---
On Fri, Aug 13, 2021 at 08:18:02AM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 8/13/2021 7:37 AM, Daniel Vetter wrote:
> > On Wed, Jul 28, 2021 at 07:01:01PM -0700, Daniele Ceraolo Spurio wrote:
> > > This api allow user mode to create protected buffers and to mark
> > > contexts as making use
On Mon, Jul 26, 2021 at 11:00:46PM -0700, Matt Roper wrote:
> ADL_P requires that we disable underrun recovery when downscaling
Does that mean plane downsclaing or pipe downscaling or both?
> (or
> using the scaler for YUV420 pipe output), using DSC, or using PSR2.
> Otherwise we should be able
On Mon, Aug 16, 2021 at 12:31 PM Desmond Cheong Zhi Xi
wrote:
>
> On 16/8/21 5:04 pm, Daniel Vetter wrote:
> > On Mon, Aug 16, 2021 at 10:53 AM Desmond Cheong Zhi Xi
> > wrote:
> >> On 16/8/21 2:47 am, kernel test robot wrote:
> >>> Hi Desmond,
> >>>
> >>> Thank you for the patch! Yet something
Rework and simplify the locking with GuC subission. Drop
sched_state_no_lock and move all fields under the guc_state.sched_state
and protect all these fields with guc_state.lock . This requires
changing the locking hierarchy from guc_state.lock -> sched_engine.lock
to sched_engine.lock ->
A subsequent patch will flip the locking hierarchy from
ce->guc_state.lock -> sched_engine->lock to sched_engine->lock ->
ce->guc_state.lock. As such we need to release the submit fence for a
request from an IRQ to break a lock inversion - i.e. the fence must be
release went holding
Reset LRC descriptor if a context register returns -ENODEV as this means
we are mid-reset.
Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface")
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 6 --
1 file changed, 4
Move GuC management fields in context under guc_active struct as this is
where the lock that protects theses fields lives. Also only set guc_prio
field once during context init.
Fixes: ee242ca704d3 ("drm/i915/guc: Implement GuC priority management")
Signed-off-by: Matthew Brost
Cc:
---
Drop pin count check trick between a sched_disable and re-pin, now rely
on the lock and counter of the number of committed requests to determine
if scheduling should be disabled on the context.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 2 +
Move guc_blocked fence to struct guc_state as the lock which protects
the fence lives there.
s/ce->guc_blocked/ce->guc_state.blocked_fence/g
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c| 5 +++--
drivers/gpu/drm/i915/gt/intel_context_types.h | 5 ++---
It isn't safe to scrub for missing G2H or continue with the reset until
all G2H processing is complete. Flush the G2H work queue during reset to
ensure it is done running.
Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface")
Signed-off-by: Matthew Brost
---
Before we did some clever tricks to not use the a lock when touching
guc_state.sched_state in certain cases. Don't do that, enforce the use
of the lock.
Part of this is removing a dead code path from guc_lrc_desc_pin where a
context could be deregistered when the aforementioned function was
Add GuC kernel doc for all structures added thus far for GuC submission
and update the main GuC submission section with the new interface
details.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 42 +---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 19
A context can get destroyed after cancelling a request so take a
reference to context when cancelling a request.
Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation")
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 5 -
1 file changed, 4
Lock the xarray and take ref to the context if needed.
v2:
(Checkpatch)
- Add new line after declaration
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 84 ---
1 file changed, 73 insertions(+), 11 deletions(-)
diff --git
When unblocking a context, do not enable scheduling if the context is
banned, guc_id invalid, or not registered.
Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation")
Signed-off-by: Matthew Brost
Cc:
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 3 +++
1 file changed, 3
GuC submission has exposed an existing memory corruption in
live_lrc_isolation. We believe that some writes to the watchdog offsets
in the LRC (0x178 & 0x17c) can result in trashing of portions of the
address space. With GuC submission there are additional objects which
can move the context
Error captures can now be done in a work queue processing G2H messages.
These messages need to be completely done being processed in the reset
path, to avoid races in the missing G2H cleanup, which create a
dependency on memory allocations and dma fences (i915_requests).
Requests depend on resets,
Add a cancel request selftest that results in an engine reset to cancel
the request as it is non-preemptable. Also insert a NOP request after
the cancelled request and confirm that it completely successfully.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/selftests/i915_request.c | 100
If the context is reset as a result of the request cancelation the
context reset G2H is received after schedule disable done G2H which is
likely the wrong order. The schedule disable done G2H release the
waiting request cancelation code which resubmits the context. This races
with the context
Progagating errors to dependent fences is wrong, don't do it. Selftest
in following patch exposes this bug.
Fixes: 8e9f84cf5cac ("drm/i915/gt: Propagate change in error status to children
on unhold")
Signed-off-by: Matthew Brost
Cc:
---
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 4
While debugging an issue with full GT resets I went down a rabbit hole
thinking the scrubbing of lost G2H wasn't working correctly. This proved
to be incorrect as this was working just fine but this chase inspired me
to write a selftest to prove that this works. This simple selftest
injects errors
A small race that could result in incorrect accounting of the number
of outstanding G2H. Basically prior to this patch we did not increment
the number of outstanding G2H if we encoutered a GT reset while sending
a H2G. This was incorrect as the context state had already been updated
to anticipate
Don't drop ce->guc_active.lock when unwinding a context after reset.
At one point we had to drop this because of a lock inversion but that is
no longer the case. It is much safer to hold the lock so let's do that.
Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface")
Daniel Vetter pointed out that locking in the GuC submission code was
overly complicated, let's clean this up a bit before introducing more
features in the GuC submission backend.
Also fix some CI failures, port fixes from our internal tree, and add a
few more selftests for coverage.
Lastly, add
When unwinding requests on a reset context, if other requests in the
context are in the priority list the requests could be resubmitted out
of seqno order. Traverse the list of active requests in reverse and
append to the head of the priority list to fix this.
Fixes: eb5e7da736f3 ("drm/i915/guc:
Prior to this patch the blocked context counter was cleared on
init_sched_state (used during registering a context & resets) which is
incorrect. This state needs to be persistent or the counter can read the
incorrect value resulting in scheduling never getting enabled again.
Fixes: 62eaf0ae217d
On 8/16/21 3:34 PM, Maarten Lankhorst wrote:
Op 16-08-2021 om 15:30 schreef Thomas Hellström:
On 8/16/21 3:25 PM, Matthew Auld wrote:
On Mon, 16 Aug 2021 at 09:49, Thomas Hellström
wrote:
It's only used by the for_i915_gem_ww() macro and we can use
the (typically) on-stack _err variable in
Sync PCI IDs with Bspec.
Bspec:53655
Changes since V1:
- All POR and Non POR Ids needs to be upstreamed - James Asmus
Signed-off-by: Tejas Upadhyay
---
include/drm/i915_pciids.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/drm/i915_pciids.h
Op 16-08-2021 om 15:30 schreef Thomas Hellström:
>
> On 8/16/21 3:25 PM, Matthew Auld wrote:
>> On Mon, 16 Aug 2021 at 09:49, Thomas Hellström
>> wrote:
>>> It's only used by the for_i915_gem_ww() macro and we can use
>>> the (typically) on-stack _err variable in its place.
>>>
>>> While
On 8/16/21 3:25 PM, Matthew Auld wrote:
On Mon, 16 Aug 2021 at 09:49, Thomas Hellström
wrote:
It's only used by the for_i915_gem_ww() macro and we can use
the (typically) on-stack _err variable in its place.
While initially setting the _err variable to -EDEADLK to enter the
loop, we clear
On Mon, 16 Aug 2021 at 09:49, Thomas Hellström
wrote:
>
> It's only used by the for_i915_gem_ww() macro and we can use
> the (typically) on-stack _err variable in its place.
>
> While initially setting the _err variable to -EDEADLK to enter the
> loop, we clear it before actually entering using
On 16/8/21 5:04 pm, Daniel Vetter wrote:
On Mon, Aug 16, 2021 at 10:53 AM Desmond Cheong Zhi Xi
wrote:
On 16/8/21 2:47 am, kernel test robot wrote:
Hi Desmond,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on next-20210813]
[also build test ERROR on v5.14-rc5]
From: Ankit Nautiyal
commit abd9d66a055722393d33685214c08386694871d7 upstream.
Till DISPLAY12 the PIPE_MISC bits 5-7 are used to set the
Dithering BPC, with valid values of 6, 8, 10 BPC.
For ADLP+ these bits are used to set the PORT OUTPUT BPC, with valid
values of: 6, 8, 10, 12 BPC, and need
== Series Details ==
Series: drm/i915/selftest: Fix use of err in igt_reset_{fail, nop}_engine()
URL : https://patchwork.freedesktop.org/series/93713/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10487_full -> Patchwork_20830_full
== Series Details ==
Series: drm: avoid races with modesetting rights
URL : https://patchwork.freedesktop.org/series/93714/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10488 -> Patchwork_20831
Summary
---
On Mon, 16 Aug 2021, Imre Deak wrote:
> On Mon, Aug 16, 2021 at 10:17:37AM +0300, Jani Nikula wrote:
>> The symbol isn't needed outside of i915.ko.
>>
>> Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode link
>> training")
>> Fixes: 264613b406eb ("drm/i915: Disable LTTPR
On Mon, 16 Aug 2021, "Sharma, Swati2" wrote:
> On 16-Aug-21 5:40 PM, Jani Nikula wrote:
>> On Mon, 16 Aug 2021, "Sharma, Swati2" wrote:
>>> On 13-Aug-21 1:16 PM, Jani Nikula wrote:
On Thu, 12 Aug 2021, Swati Sharma wrote:
> drm_dp_dpcd_read/write already has debug error message.
>
On 16-Aug-21 5:40 PM, Jani Nikula wrote:
On Mon, 16 Aug 2021, "Sharma, Swati2" wrote:
On 13-Aug-21 1:16 PM, Jani Nikula wrote:
On Thu, 12 Aug 2021, Swati Sharma wrote:
drm_dp_dpcd_read/write already has debug error message.
Drop redundant error messages which gives false
status even if
== Series Details ==
Series: drm: avoid races with modesetting rights
URL : https://patchwork.freedesktop.org/series/93714/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
On Mon, 16 Aug 2021, "Sharma, Swati2" wrote:
> On 13-Aug-21 1:16 PM, Jani Nikula wrote:
>> On Thu, 12 Aug 2021, Swati Sharma wrote:
>>> drm_dp_dpcd_read/write already has debug error message.
>>> Drop redundant error messages which gives false
>>> status even if correct value is read in
== Series Details ==
Series: drm/i915: Ditch the i915_gem_ww_ctx loop member
URL : https://patchwork.freedesktop.org/series/93711/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10487_full -> Patchwork_20829_full
Summary
On Mon, Aug 16, 2021 at 05:23:00PM +0530, Sharma, Swati2 wrote:
> On 12-Aug-21 9:31 PM, Imre Deak wrote:
> > On Thu, Aug 12, 2021 at 06:41:07PM +0530, Swati Sharma wrote:
> > > drm_dp_dpcd_read/write already has debug error message.
> > > Drop redundant error messages which gives false
> > >
On 13-Aug-21 1:16 PM, Jani Nikula wrote:
On Thu, 12 Aug 2021, Swati Sharma wrote:
drm_dp_dpcd_read/write already has debug error message.
Drop redundant error messages which gives false
status even if correct value is read in drm_dp_dpcd_read().
I guess the only problem is it gets harder
On 12-Aug-21 9:31 PM, Imre Deak wrote:
On Thu, Aug 12, 2021 at 06:41:07PM +0530, Swati Sharma wrote:
drm_dp_dpcd_read/write already has debug error message.
Drop redundant error messages which gives false
status even if correct value is read in drm_dp_dpcd_read().
v2: -Added fixes tag (Ankit)
== Series Details ==
Series: drm/i915/dp: remove superfluous EXPORT_SYMBOL()
URL : https://patchwork.freedesktop.org/series/93708/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10487_full -> Patchwork_20828_full
Summary
== Series Details ==
Series: drm/i915/selftest: Fix use of err in igt_reset_{fail, nop}_engine()
URL : https://patchwork.freedesktop.org/series/93713/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10487 -> Patchwork_20830
On 8/16/2021 12:37 PM, Jani Nikula wrote:
On Fri, 13 Aug 2021, Ankit Nautiyal wrote:
From: Swati Sharma
Instead of re-writing the avi_infoframe_compute func in intel_dp;
exporting hdmi_compute_avi_infoframe func so that it can be called
directly while encapsulating AVI infoframes in GMP
== Series Details ==
Series: drm/i915: Ditch the i915_gem_ww_ctx loop member
URL : https://patchwork.freedesktop.org/series/93711/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10487 -> Patchwork_20829
Summary
---
On Wed, 21 Jul 2021, José Roberto de Souza wrote:
> VBT has support for up two integrated panels but i915 only supports one.
>
> So here stating to add the basic support for two integrated panels
> and moving the DRRS to ddi_vbt_port_info instead of keeping a global
> one.
> Other VBT blocks will
On Wed, 21 Jul 2021, José Roberto de Souza wrote:
> Allow MIPI DSI ports to be parsed like any other DDI port.
> This will be helpful to integrate into just one function the parse of
> information about integrated panels(eDP and DSI).
>
> Allow MIPI DSI ports to be parsed to be parsed like any
Hi everybody
I have a Mi Pad 2 and it is runing Android OS L.
When i tried to boot another Linux OS from usb, my tablet suspend and in screen
have notify : "fb0: switching to inteldrmfb from EFI VGA"
When i add "nomodeset" to boot option, the system is continue nomarly. And
this is
On 8/13/2021 4:31 AM, Dan Carpenter wrote:
Nathan has probably already sent fixes for these. Nathan, could you CC
kernel-janitors on static checker fixes? That way we wouldn't send so
many duplicate patches.
Sure. I did not send any fixes prior to this email but I just sent
On 13/8/21 11:49 pm, Daniel Vetter wrote:
On Fri, Aug 13, 2021 at 04:54:49PM +0800, Desmond Cheong Zhi Xi wrote:
In drm_client_modeset.c and drm_fb_helper.c,
drm_master_internal_{acquire,release} are used to avoid races with DRM
userspace. These functions hold onto drm_device.master_mutex while
Hi there
is there any progress in development a SR-IOV driver for Xe graphics in
tigerlake architecture für linux ?
Any comments are welcome.
I appreciate a driver to share my iGPU in KVM for other VMs like Windows.
Best wishes
Gregor
On 16/8/21 2:47 am, kernel test robot wrote:
Hi Desmond,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on next-20210813]
[also build test ERROR on v5.14-rc5]
[cannot apply to linus/master v5.14-rc5 v5.14-rc4 v5.14-rc3]
[If your patch is applied to the wrong git
Hello,
I have Fedora 33 running, and with the Fedore kernel update from 5.11
series to 5.12 my external monitor was not detected anymore. Same is
true with the Fedora supplied 5.13 kernel version.
So I tried with vanilla kernel 5.11 and latest git head from Linus'
tree. 5.11 works while latest
On 16/8/21 2:47 am, kernel test robot wrote:
Hi Desmond,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on next-20210813]
[also build test WARNING on v5.14-rc5]
[cannot apply to linus/master v5.14-rc5 v5.14-rc4 v5.14-rc3]
[If your patch is applied to the wrong
In drm_client_modeset.c and drm_fb_helper.c,
drm_master_internal_{acquire,release} are used to avoid races with DRM
userspace. These functions hold onto drm_device.master_mutex while
committing, and bail if there's already a master.
However, there are other places where modesetting rights can
Clang warns:
In file included from drivers/gpu/drm/i915/gt/intel_reset.c:1514:
drivers/gpu/drm/i915/gt/selftest_hangcheck.c:465:62: warning: variable
'err' is uninitialized when used here [-Wuninitialized]
pr_err("[%s] Create context failed: %d!\n", engine->name, err);
== Series Details ==
Series: drm/i915: Ditch the i915_gem_ww_ctx loop member
URL : https://patchwork.freedesktop.org/series/93711/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e82160475e8e drm/i915: Ditch the i915_gem_ww_ctx loop member
-:67: CHECK:MACRO_ARG_REUSE: Macro
== Series Details ==
Series: drm/i915/dp: remove superfluous EXPORT_SYMBOL()
URL : https://patchwork.freedesktop.org/series/93708/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10487 -> Patchwork_20828
Summary
---
On Mon, Aug 16, 2021 at 10:53 AM Desmond Cheong Zhi Xi
wrote:
> On 16/8/21 2:47 am, kernel test robot wrote:
> > Hi Desmond,
> >
> > Thank you for the patch! Yet something to improve:
> >
> > [auto build test ERROR on next-20210813]
> > [also build test ERROR on v5.14-rc5]
> > [cannot apply to
On Mon, Aug 16, 2021 at 10:17:37AM +0300, Jani Nikula wrote:
> The symbol isn't needed outside of i915.ko.
>
> Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode link
> training")
> Fixes: 264613b406eb ("drm/i915: Disable LTTPR support when the DPCD rev <
> 1.4")
> Cc: Imre
It's only used by the for_i915_gem_ww() macro and we can use
the (typically) on-stack _err variable in its place.
While initially setting the _err variable to -EDEADLK to enter the
loop, we clear it before actually entering using fetch_and_zero() to
avoid empty loops or code not setting the _err
The symbol isn't needed outside of i915.ko.
Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode link
training")
Fixes: 264613b406eb ("drm/i915: Disable LTTPR support when the DPCD rev < 1.4")
Cc: Imre Deak
Signed-off-by: Jani Nikula
---
== Series Details ==
Series: drm/i915/gt: Initialize unused MOCS entries to L3_WB
URL : https://patchwork.freedesktop.org/series/93706/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10485_full -> Patchwork_20827_full
On Fri, 13 Aug 2021, Ankit Nautiyal wrote:
> From: Swati Sharma
>
> Instead of re-writing the avi_infoframe_compute func in intel_dp;
> exporting hdmi_compute_avi_infoframe func so that it can be called
> directly while encapsulating AVI infoframes in GMP dip.
>
> This is required when HDMI 2.1
On Mon, Aug 16, 2021 at 10:45:34AM +0800, Zhenyu Wang wrote:
> Hi, Christoph, what platform is this?
Kaby Lake ( i7-8550U)
>
> And what's your guest i915 config?
guest config as in i915-related .config options?
snip
CONFIG_DRM_I915=y
86 matches
Mail list logo
