> Subject: [PATCH 8/8] drm/i915/dsc: use REG_BIT, REG_GENMASK, and friends
> for PPS0 and PPS1
>
> Use the register helper macros for PPS0 and PPS1 register contents.
>
LGTM.
Reviewed-by: Suraj Kandpal
> Cc: Suraj Kandpal
> Cc: Ankit Nautiyal
> Signed-off-by: Jani Nikula
> ---
>
> Subject: [PATCH 7/8] drm/i915/dsc: add the PPS number to the register content
> macros
>
> Improve clarity by specifying the PPS number in the register content macros.
> It's
> easier to notice if macros are being used for the wrong register.
>
LGTM.
Reviewed-by: Suraj Kandpal
> Cc: Suraj
> Subject: [PATCH 7/8] drm/i915/dsc: add the PPS number to the register content
> macros
>
> Improve clarity by specifying the PPS number in the register content macros.
> It's
> easier to notice if macros are being used for the wrong register.
LGTM.
Reviewed-by : Suraj Kandpal
>
> Cc:
On Wed, 2023-09-06 at 17:15 -0700, Teres Alexis, Alan Previn wrote:
> Update the GSC-fw input/output HECI packet size to match
> updated internal fw specs.
alan:snip
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
> @@ -14,8 +14,8 @@
>
> +/* PXP-Packet sizes for MTL's GSCCS-HECI
> Subject: [PATCH 6/8] drm/i915/dsc: clean up pps comments
>
> Unify comments to be the simple "PPS n" instead of all sorts of variants.
>
LGTM.
Reviewed-by: Suraj Kandpal
> Cc: Suraj Kandpal
> Cc: Ankit Nautiyal
> Signed-off-by: Jani Nikula
> ---
>
> Subject: [PATCH 4/8] drm/i915/dsc: rename pps write to intel_dsc_pps_write()
>
> Make the function name conform to existing style better.
>
LGTM.
Reviewed-by: Suraj Kandpal
> Cc: Suraj Kandpal
> Cc: Ankit Nautiyal
> Signed-off-by: Jani Nikula
> ---
>
> Subject: [PATCH 3/8] drm/i915/dsc: have intel_dsc_pps_read() return the value
>
> Register read functions usually return the value instead of passing via
> pointer
> parameters. Return the multiple register verification results via a pointer
> parameter, which can also be NULL to skip the
== Series Details ==
Series: series starting with [v1,1/1] drm/i915/pxp: Add drm_dbgs for critical
PXP events.
URL : https://patchwork.freedesktop.org/series/123370/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13605_full -> Patchwork_123370v1_full
> Subject: [PATCH 2/8] drm/i915/dsc: have intel_dsc_pps_read_and_verify()
> return the value
>
> Register read functions usually return the value instead of passing via
> pointer
> parameters. The calling code becomes easier to read.
>
> Make the name conform to existing style better while at
> Subject: [PATCH 1/8] drm/i915/dsc: improve clarify of the pps reg read/write
> helpers
Should be clarity here in the commit header
With that fixed
Reviewed-by: Suraj Kandpal
>
> Make it clear what's the number of vdsc per pipe, and what's the number of
> registers to grab. Have
== Series Details ==
Series: drm/i915/pxp/mtl: Update gsc-heci cmd submission to align with fw/hw
spec
URL : https://patchwork.freedesktop.org/series/123368/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13605_full -> Patchwork_123368v1_full
== Series Details ==
Series: series starting with [v1,1/1] drm/i915/pxp: Add drm_dbgs for critical
PXP events.
URL : https://patchwork.freedesktop.org/series/123370/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13605 -> Patchwork_123370v1
== Series Details ==
Series: series starting with [v1,1/1] drm/i915/pxp: Add drm_dbgs for critical
PXP events.
URL : https://patchwork.freedesktop.org/series/123370/
State : warning
== Summary ==
Error: dim checkpatch failed
5dcdd6c035e0 drm/i915/pxp: Add drm_dbgs for critical PXP events.
== Series Details ==
Series: drm/i915/pxp/mtl: Update gsc-heci cmd submission to align with fw/hw
spec
URL : https://patchwork.freedesktop.org/series/123368/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13605 -> Patchwork_123368v1
== Series Details ==
Series: drm/i915/pxp/mtl: Update gsc-heci cmd submission to align with fw/hw
spec
URL : https://patchwork.freedesktop.org/series/123368/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
Hi,
On 2023/9/6 17:40, Christian König wrote:
Am 06.09.23 um 11:08 schrieb suijingfeng:
Well, welcome to correct me if I'm wrong.
You seem to have some very basic misunderstandings here.
The term framebuffer describes some VRAM memory used for scanout.
This framebuffer is exposed to
Hi Rodrigo/Andi,
> -Original Message-
> From: Vivi, Rodrigo
> Sent: Wednesday, September 6, 2023 7:38 PM
> To: Andi Shyti
> Cc: Sripada, Radhakrishna ; intel-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/mtl: Drop force_probe
== Series Details ==
Series: Separate display workarounds from clock gating (rev2)
URL : https://patchwork.freedesktop.org/series/123363/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13605 -> Patchwork_123363v2
Summary
On 2023/9/7 00:00, Alex Deucher wrote:
On Tue, Sep 5, 2023 at 1:25 PM suijingfeng wrote:
Hi,
On 2023/9/5 13:50, Christian König wrote:
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over
which one
is primary at
== Series Details ==
Series: Separate display workarounds from clock gating (rev2)
URL : https://patchwork.freedesktop.org/series/123363/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: Separate display workarounds from clock gating (rev2)
URL : https://patchwork.freedesktop.org/series/123363/
State : warning
== Summary ==
Error: dim checkpatch failed
800b3050d8c1 drm/i915: Stop forcing clock gating init for future platforms
84633924336c
== Series Details ==
Series: drm/i915/mtl: Drop Wa_14017240301
URL : https://patchwork.freedesktop.org/series/123366/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13605 -> Patchwork_123366v1
Summary
---
**FAILURE**
Debugging PXP issues can't even begin without understanding precedding
sequence of events. Add drm_dbg into the most important PXP events.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c | 2 ++
drivers/gpu/drm/i915/pxp/intel_pxp.c | 10 --
Update the GSC-fw input/output HECI packet size to match
updated internal fw specs.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
Update the max GSC-fw response time to match updated internal
fw specs. Because this response time is an SLA on the firmware,
not inclusive of i915->GuC->HW handoff latency, when submitting
requests to the GSC fw via intel_gsc_uc_heci_cmd_submit helpers,
start the count after the request hits the
For MTL, update the GSC-HECI packet size and the max firmware
response timeout to match internal fw specs. Enforce setting
run-alone bit in LRC for protected contexts.
Changes from prio revs:
v3: - Patch #1. Only start counting the request completion
timeout from after the request has
On Meteorlake onwards, HW specs require that all user contexts that
run on render or compute engines and require PXP must enforce
run-alone bit in lrc. Add this enforcement for protected contexts.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 23 +++
1
Several of the register updates that are currently done in the clock
gating init functions are actually display workarounds that should move
into the display-specific part of the code. Furthermore, some of the
registers being programmed don't even have anything to do with clock
gating at all.
Acked-by: Anitha Chrisanthus
> -Original Message-
> From: Jim Cromie
> Sent: Wednesday, September 6, 2023 12:02 PM
> To: linux-ker...@vger.kernel.org; dri-de...@lists.freedesktop.org; amd-
> g...@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org; intel-
>
Drop Wa_14017240301, which is only relevant to pre-production MTL
hardware. Although we usually wait a little bit longer to start
dropping pre-production workarounds for a platform, it was suggested to
eliminate this one slightly earlier because it's a bit unusual/ugly:
this workaround is a
== Series Details ==
Series: drm/drm_dbg: add trailing newlines where missing
URL : https://patchwork.freedesktop.org/series/123351/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13605_full -> Patchwork_123351v1_full
== Series Details ==
Series: Separate display workarounds from clock gating
URL : https://patchwork.freedesktop.org/series/123363/
State : failure
== Summary ==
Error: make failed
CALLscripts/checksyscalls.sh
DESCEND objtool
INSTALL libsubcmd_headers
CC [M]
For MTL, update the GSC-HECI packet size and the max firmware
response timeout to match internal fw specs. Enforce setting
run-alone bit in LRC for protected contexts.
Changes from prio revs:
v3: - Patch #1. Only start counting the request completion
timeout from after the request has
Several of the register updates that are currently done in the clock
gating init functions are actually display workarounds that should move
into the display-specific part of the code. Furthermore, some of the
registers being programmed don't even have anything to do with clock
gating at all.
The only programming that happens in gen12lp_init_clock_gating is for
display workarounds that are specific to display version 12 and are not
relevant to ADL-P's display version 13.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_clock_gating.c | 2 --
1 file changed, 2 deletions(-)
Rather than applying display workarounds as part of
intel_clock_gating_init() (which in turn is confusingly called from
i915_gem_init during device probe), handle them at the point we're
actually initializing the display hardware. This will also ensure that
these workarounds are properly applied
In the early days of i915, pretty much every platform needed to
initialize _something_ in the clock gating init functions. In some
cases the items initialized were inside the GT (and really should have
been initialized through the GT workaround infrastructure instead).
In other cases they were
The clock gating init hooks in i915 are a bit jumbled. The current
implementation includes a mix of GT workarounds (which really should
have been in the GT workaround file instead), SoC/sgunit clock gating
workarounds, and display workarounds (some of which are entirely
unrelated to clock
== Series Details ==
Series: drm/drm_dbg: add trailing newlines where missing
URL : https://patchwork.freedesktop.org/series/123351/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13605 -> Patchwork_123351v1
Summary
---
== Series Details ==
Series: drm/drm_dbg: add trailing newlines where missing
URL : https://patchwork.freedesktop.org/series/123351/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
== Series Details ==
Series: Apply Wa_16018031267 / Wa_16018063123 (rev3)
URL : https://patchwork.freedesktop.org/series/123306/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13605 -> Patchwork_123306v3
Summary
---
== Series Details ==
Series: Apply Wa_16018031267 / Wa_16018063123 (rev3)
URL : https://patchwork.freedesktop.org/series/123306/
State : warning
== Summary ==
Error: dim checkpatch failed
aac4252cdeda drm/i915: Add WABB blit for Wa_16018031267 / Wa_16018063123
-:10: WARNING:BAD_SIGN_OFF:
== Series Details ==
Series: Apply Wa_16018031267 / Wa_16018063123 (rev3)
URL : https://patchwork.freedesktop.org/series/123306/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
The following changes since commit ad03b851816cc6868f27a29732489fc565739368:
Merge branch 'rb12-fw-v2' into 'main' (2023-09-06 20:40:34 +)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-firmware mtl_huc_8.5.4
for you to fetch changes up to
Hi Jim
On 9/6/2023 12:02 PM, Jim Cromie wrote:
By at least strong convention, a print-buffer's trailing newline says
"message complete, send it". The exception (no TNL, followed by a call
to pr_cont) proves the general rule.
Most DRM.debug calls already comport with this: 207 DRM_DEV_DEBUG,
On Wed, 6 Sep 2023 11:51:59 +0800
Sui Jingfeng wrote:
> Hi,
>
>
> On 2023/9/5 22:52, Alex Williamson wrote:
> > On Tue, 5 Sep 2023 03:57:15 +0800
> > Sui Jingfeng wrote:
> >
> >> From: Sui Jingfeng
> >>
> >> On a machine with multiple GPUs, a Linux user has no control over which
> >> one
By at least strong convention, a print-buffer's trailing newline says
"message complete, send it". The exception (no TNL, followed by a call
to pr_cont) proves the general rule.
Most DRM.debug calls already comport with this: 207 DRM_DEV_DEBUG,
1288 drm_dbg. Clean up the remainders, in
Incorrect CFLAGS- usage failed to add -DDYNAMIC_DEBUG_MODULE when needed,
which broke builds with:
CONFIG_DRM_USE_DYNAMIC_DEBUG=Y
CONFIG_DYNAMIC_DEBUG_CORE=Y
CONFIG_DYNAMIC_DEBUG=N
Also add subdir-ccflags so that all drivers pick up the addition.
Fixes: 84ec67288c10 ("drm_print: wrap drm_*_dbg
By at least strong convention, a print-buffer's trailing newline says
"message complete, send it". The exception (no TNL, followed by a call
to pr_cont) proves the general rule.
Most DRM.debug calls already comport with this: 207 DRM_DEV_DEBUG,
1288 drm_dbg. Clean up the remainders, in
By at least strong convention, a print-buffer's trailing newline says
"message complete, send it". The exception (no TNL, followed by a call
to pr_cont) proves the general rule.
Most DRM.debug calls already comport with this: 207 DRM_DEV_DEBUG,
1288 drm_dbg. Clean up the remainders, in
By at least strong convention, a print-buffer's trailing newline says
"message complete, send it". The exception (no TNL, followed by a call
to pr_cont) proves the general rule.
Most DRM.debug calls already comport with this: 207 DRM_DEV_DEBUG,
1288 drm_dbg. Clean up the remainders, in
By at least strong convention, a print-buffer's trailing newline says
"message complete, send it". The exception (no TNL, followed by a call
to pr_cont) proves the general rule.
Most DRM.debug calls already comport with this rule/convention:
207 DRM_DEV_DEBUG, 1288 drm_dbg. Clean up the
On 9/6/2023 02:17, Andi Shyti wrote:
Hi John,
static void guc_cancel_busyness_worker(struct intel_guc *guc)
{
- cancel_delayed_work_sync(>timestamp.work);
+ /*
+* When intel_gt_reset was called, task will hold a lock.
+* To cacel delayed work here, the
On 9/5/2023 23:50, Daniel Vetter wrote:
On Mon, Aug 28, 2023 at 04:01:38PM -0700, John Harrison wrote:
On 8/23/2023 10:37, John Harrison wrote:
On 8/23/2023 09:00, Daniel Vetter wrote:
On Tue, Aug 22, 2023 at 11:53:24AM -0700, John Harrison wrote:
On 8/11/2023 11:20, Zhanjun Dong wrote:
On Wed, Sep 6, 2023 at 10:42 AM Rodrigo Vivi wrote:
>
> On Mon, Sep 04, 2023 at 08:32:40AM +0200, Andi Shyti wrote:
> > Hi Jim,
> >
> > On Sun, Sep 03, 2023 at 12:46:00PM -0600, Jim Cromie wrote:
> > > By at least strong convention, a print-buffer's trailing newline says
> > > "message complete,
On Thu, Aug 31, 2023 at 07:40:55PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/cx0: Check and increase msgbus timeout threshold (rev3)
> URL : https://patchwork.freedesktop.org/series/122982/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from
On Mon, Sep 04, 2023 at 08:32:40AM +0200, Andi Shyti wrote:
> Hi Jim,
>
> On Sun, Sep 03, 2023 at 12:46:00PM -0600, Jim Cromie wrote:
> > By at least strong convention, a print-buffer's trailing newline says
> > "message complete, send it". The exception (no TNL, followed by a call
> > to
Hi Suraj,
> -Original Message-
> From: Kandpal, Suraj
> Sent: 05 September 2023 14:47
> To: Golani, Mitulkumar Ajitkumar ;
> intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: RE: [Intel-gfx] [PATCH 3/3] drm/i915/display: Configure and
> initialize
> HDMI audio capabilities
On Tue, Sep 5, 2023 at 1:25 PM suijingfeng wrote:
>
> Hi,
>
>
> On 2023/9/5 13:50, Christian König wrote:
> > Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
> >> From: Sui Jingfeng
> >>
> >> On a machine with multiple GPUs, a Linux user has no control over
> >> which one
> >> is primary at boot
== Series Details ==
Series: Drop caches per GT (rev2)
URL : https://patchwork.freedesktop.org/series/123301/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13602_full -> Patchwork_123301v2_full
Summary
---
== Series Details ==
Series: Apply Wa_16018031267 / Wa_16018063123 (rev2)
URL : https://patchwork.freedesktop.org/series/123306/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13602 -> Patchwork_123306v2
Summary
---
== Series Details ==
Series: Apply Wa_16018031267 / Wa_16018063123 (rev2)
URL : https://patchwork.freedesktop.org/series/123306/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: Apply Wa_16018031267 / Wa_16018063123 (rev2)
URL : https://patchwork.freedesktop.org/series/123306/
State : warning
== Summary ==
Error: dim checkpatch failed
d58e47a53a80 drm/i915: Add WABB blit for Wa_16018031267 / Wa_16018063123
-:10: WARNING:BAD_SIGN_OFF:
On Wed, Sep 06, 2023 at 11:25:35AM +0200, Andi Shyti wrote:
> Hi Radhakrishna,
>
> On Tue, Sep 05, 2023 at 12:36:24PM -0700, Radhakrishna Sripada wrote:
> > Meteorlake has been very usable for a while now, all of uapi changes
> > related to fundamental platform usage have been finalized and all
>
== Series Details ==
Series: Update GGTT with MI_UPDATE_GTT on MTL
URL : https://patchwork.freedesktop.org/series/123329/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13602 -> Patchwork_123329v1
Summary
---
== Series Details ==
Series: Update GGTT with MI_UPDATE_GTT on MTL
URL : https://patchwork.freedesktop.org/series/123329/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: Update GGTT with MI_UPDATE_GTT on MTL
URL : https://patchwork.freedesktop.org/series/123329/
State : warning
== Summary ==
Error: dim checkpatch failed
0fa027cb3bb7 drm/i915: Lift runtime-pm acquire callbacks out of
intel_wakeref.mutex
-:56: WARNING:AVOID_BUG: Do
MTL can hang because of a HW bug while parallel reading/writing
from/to LMEM/GTTMMADR BAR so try to reduce GGTT update
related pci transactions with blitter command as recommended
for Wa_13010847436 and Wa_14019519902.
To issue gpu commands, the driver must be primed to receive
requests. Maintain
Implement GGTT update method with blitter command, MI_UPDATE_GTT
and install those handlers if a platform requires that.
v2: Make sure we hold the GT wakeref and Blitter engine wakeref before
we call mutex_lock/intel_context_enter below. When GT/engine are not
awake, the intel_context_enter calls
Implement a way to iterate over sgt with pre-initialized
sgt_iter state.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/i915_scatterlist.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_scatterlist.h
b/drivers/gpu/drm/i915/i915_scatterlist.h
index
Create a separate kernel context if a platform requires
GGTT updates using MI_UPDATE_GTT blitter command.
Subsequent patch will introduce methods to update
GGTT using this bind context and MI_UPDATE_GTT blitter
command.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gt/intel_engine.h
From: Chris Wilson
When runtime pm is first woken, it will synchronously call the
registered callbacks for the device and bug. These callback
may pull in their own forest of locks, which we do not want to
conflate with the intel_wakeref.mutex. A second minor beneft to
reducing the coverage of
Implement a way to update GGTT using MI_UPDATE_GTT command
when possible for MTL as a suggested work around for
a HW bug.
Chris Wilson (1):
drm/i915: Lift runtime-pm acquire callbacks out of intel_wakeref.mutex
Nirmoy Das (4):
drm/i915: Create a kernel context for GGTT updates
drm/i915:
== Series Details ==
Series: Drop caches per GT (rev2)
URL : https://patchwork.freedesktop.org/series/123301/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13602 -> Patchwork_123301v2
Summary
---
**SUCCESS**
No
On Wed, Sep 06, 2023 at 01:45:51PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 04, 2023 at 01:22:27PM +0300, Imre Deak wrote:
> > On Mon, Sep 04, 2023 at 05:53:11AM +0300, Ville Syrjälä wrote:
> > > On Thu, Aug 24, 2023 at 11:05:04AM +0300, Imre Deak wrote:
> > > > For fractional bpp values passed
Hi
Am 06.09.23 um 11:48 schrieb suijingfeng:
[...]
There's 'nomodeset', which disables all native drivers. It's useful
for debugging or as a quick-fix if the graphics driver breaks. If you
want to disable a specific driver, please use one of the options for
blacklisting.
Yeah, the
On Wed, Sep 06, 2023 at 01:04:06PM +0300, Jani Nikula wrote:
> On Wed, 06 Sep 2023, Andi Shyti wrote:
> > It's the developer's responsibility to test its code with
> > debug_lockdep and fix all the potential deadlocks and ignore the
> > false ones.
>
> No. Manual validation of lockdep reports is
Am 06.09.23 um 12:31 schrieb Sui Jingfeng:
Hi,
On 2023/9/6 14:45, Christian König wrote:
Firmware framebuffer device already get killed by the
drm_aperture_remove_conflicting_pci_framebuffers()
function (or its siblings). So, this series is definitely not to
interact with the firmware
On Mon, Sep 04, 2023 at 01:22:27PM +0300, Imre Deak wrote:
> On Mon, Sep 04, 2023 at 05:53:11AM +0300, Ville Syrjälä wrote:
> > On Thu, Aug 24, 2023 at 11:05:04AM +0300, Imre Deak wrote:
> > > For fractional bpp values passed to the function in a .4 fixed point
> > > format, the fractional part is
Hi,
On 2023/9/6 14:45, Christian König wrote:
Firmware framebuffer device already get killed by the
drm_aperture_remove_conflicting_pci_framebuffers()
function (or its siblings). So, this series is definitely not to
interact with the firmware framebuffer
(or more intelligent framebuffer
On Wed, 06 Sep 2023, Andi Shyti wrote:
>> > I was actually thinking why not leave things as they are and just
>> > disable lockdep from CI. This doesn't look like a relevant report
>> > to me.
>> >
>> > Andi
>> Disable lockdep? The whole of lockdep? We absolutely do not want to disable
>> an
Hi,
On 2023/9/6 16:05, Thomas Zimmermann wrote:
Hi
Am 05.09.23 um 17:59 schrieb suijingfeng:
[...]
FYI: per-driver modeset parameters are deprecated and not to be
used. Please don't promote them.
Well, please wait, I want to explain.
drm/nouveau already promote it a little bit.
Am 06.09.23 um 11:08 schrieb suijingfeng:
Well, welcome to correct me if I'm wrong.
You seem to have some very basic misunderstandings here.
The term framebuffer describes some VRAM memory used for scanout.
This framebuffer is exposed to userspace through some framebuffer
driver, on UEFI
> > Meteorlake has been very usable for a while now, all of uapi changes
> > related to fundamental platform usage have been finalized and all
> > required firmware blobs are available. Recent CI results have also
> > been healthy, so we're ready to drop the force_probe requirement and
> > enable
Hi Radhakrishna,
On Tue, Sep 05, 2023 at 12:36:24PM -0700, Radhakrishna Sripada wrote:
> Meteorlake has been very usable for a while now, all of uapi changes
> related to fundamental platform usage have been finalized and all
> required firmware blobs are available. Recent CI results have also
>
Hi John,
> > > > > > static void guc_cancel_busyness_worker(struct intel_guc *guc)
> > > > > > {
> > > > > > - cancel_delayed_work_sync(>timestamp.work);
> > > > > > + /*
> > > > > > +* When intel_gt_reset was called, task will hold a lock.
> > > > > > +* To cacel delayed work
Hi,
On 2023/9/6 14:45, Christian König wrote:
Am 05.09.23 um 15:30 schrieb suijingfeng:
Hi,
On 2023/9/5 18:45, Thomas Zimmermann wrote:
Hi
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over
which
one is
://lore.kernel.org/r/20230905073551.958368-4-animesh.manna%40intel.com
patch subject: [Intel-gfx] [PATCH v5 3/6] drm/i915/panelreplay: Initializaton
and compute config for panel replay
config: i386-randconfig-141-20230906
(https://download.01.org/0day-ci/archive/20230906/202309060644.uwp5zw4i
Hi
Am 05.09.23 um 17:59 schrieb suijingfeng:
[...]
FYI: per-driver modeset parameters are deprecated and not to be used.
Please don't promote them.
Well, please wait, I want to explain.
drm/nouveau already promote it a little bit.
Despite no code of conduct or specification guiding how
Hi
Am 06.09.23 um 05:08 schrieb suijingfeng:
Hi,
On 2023/9/5 23:05, Thomas Zimmermann wrote:
However, on modern Linux systems the primary display does not really
exist. 'Primary' is the device that is available via VGA, VESA or EFI.
I may miss the point, what do you means by choose the
Hi
Am 06.09.23 um 04:34 schrieb suijingfeng:
On 2023/9/5 23:05, Thomas Zimmermann wrote:
Hi
Am 05.09.23 um 15:30 schrieb suijingfeng:
Hi,
On 2023/9/5 18:45, Thomas Zimmermann wrote:
Hi
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a
Hi
Am 06.09.23 um 04:14 schrieb suijingfeng:
Hi,
On 2023/9/5 23:05, Thomas Zimmermann wrote:
However, on modern Linux systems the primary display does not really
exist.
No, it do exist. X server need to know which one is the primary GPU.
The '*' character at the of (4@0:0:0) PCI device
On Mon, Aug 28, 2023 at 04:01:38PM -0700, John Harrison wrote:
> On 8/23/2023 10:37, John Harrison wrote:
> > On 8/23/2023 09:00, Daniel Vetter wrote:
> > > On Tue, Aug 22, 2023 at 11:53:24AM -0700, John Harrison wrote:
> > > > On 8/11/2023 11:20, Zhanjun Dong wrote:
> > > > > This attempts to
Am 05.09.23 um 16:28 schrieb Sui Jingfeng:
Hi,
On 2023/9/5 21:28, Christian König wrote:
2) Typically, those non-86 machines don't have a good UEFI firmware
support, which doesn't support select primary GPU as firmware
stage.
Even on x86, there are old UEFI firmwares which already
Am 05.09.23 um 15:30 schrieb suijingfeng:
Hi,
On 2023/9/5 18:45, Thomas Zimmermann wrote:
Hi
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve above
On Tue, 2023-09-05 at 19:49 -0700, Lucas De Marchi wrote:
> On Fri, Aug 25, 2023 at 11:16:34AM +0300, Luca Coelho wrote:
> > Hi,
> >
> > Here are four patches with some clean-ups in the code that handles the
> > max lane count of Type-C connections.
> >
> > This is done mostly in preparation for
On Tue, 2023-09-05 at 08:52 +, Manna, Animesh wrote:
>
>
> > -Original Message-
> > From: Intel-gfx On Behalf
> > Of Jouni
> > Högander
> > Sent: Monday, August 28, 2023 2:01 PM
> > To: intel-gfx@lists.freedesktop.org
> > Subject: [Intel-gfx] [PATCH] drm/i915/psr: Add psr sink error
97 matches
Mail list logo
