[why]
How we determine the dsc_aux used for dsc decompression in
drm_dp_mst_dsc_aux_for_port() today has defects:
1. The method how we determine a connected peer device is virtual or not
in drm_dp_mst_is_virtual_dpcd() is not always correct. There are DP1.4
products
in the market which don'
The patch series is to refactor existing dsc determination policy for
dsc decompression and dsc passthrough given a mst output port.
Original routine was written based on different peer device types
which is not accurate and shows difficulty when expanding support of
products that do not fully com
[why]
Starting from dp2 where dsc passthrough is introduced, it is required to
identify
the dsc passthrough aux, apart from dsc decompression aux. Existing
drm_dp_mst_port function
that returns dsc_aux alone is not sufficient.
[how]
1. Interface change in drm_dp_mst_dsc_aux_for_port, and depende
On Fri, Nov 01, 2024 at 03:43:40PM +0200, Imre Deak wrote:
> On Fri, Nov 01, 2024 at 11:22:13AM +0200, Jani Nikula wrote:
> > On Thu, 31 Oct 2024, Imre Deak wrote:
> > > On Thu, Oct 31, 2024 at 05:12:45PM +0200, Abel Vesa wrote:
> > >> According to the DisplayPort standard, LTTPRs have two operati
On Thu, Oct 31, 2024 at 10:24:45AM -0700, Alexander Coffin wrote:
>
>Hello again,
Hi Alexander,
> I attempted to send a potential deadlock issue from my work email
> (acof...@sfcompute.com) and suspect that using gmail with a very long email
> was causing issues as it didn't seem to s
On Mon, 2024-10-21 at 19:27 -0300, Gustavo Sousa wrote:
> Some display MMIO transactions for offsets in the range that requires
> the DMC wakelock happen in atomic context (this has been confirmed
> during tests on PTL). That means that we need to use a non-sleeping
> variant of MMIO waiting functi
On Tue, Oct 29, 2024 at 02:24:15PM +0200, Jouni Högander wrote:
> We are currently seeing unexpected link trainings with several different
> eDP panels. These are caused by these panels stating bad link status in
> their dpcd registers. This can be observed by doing following test:
>
> 1. Boot up
On Fri, Nov 01, 2024 at 12:29:03PM +0200, Jani Nikula wrote:
> On Thu, 31 Oct 2024, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We'll be wanting reprogram the PIPE_MBUS_DBOX_CTL registers
>
> wanting *to* reprogram
>
> I would've wanted to see conversion to struct intel_display here to
On Mon, 2024-10-21 at 19:27 -0300, Gustavo Sousa wrote:
> Although Bspec doesn't explicitly mentions that, as of Xe3_LPD, using
> DMC wakelock is the officially recommended way of accessing registers
> that would be off during DC5/DC6 and the legacy method (where the DMC
> intercepts MMIO to wake u
There is a HW issue that arises when there are race conditions
between TCSS entering/exiting TC7 or TC10 states while the
driver is asserting/deasserting TCSS power request. As a
workaround, Display driver will implement a mailbox sequence
to ensure that the TCSS is in TC0 when TCSS power request i
On Mon, 2024-10-21 at 19:27 -0300, Gustavo Sousa wrote:
> Instead of checking for HAS_DMC_WAKELOCK() multiple times, let's use it
> to sanitize the enable_dmc_wl parameter and use that variable when
> necessary.
>
> Signed-off-by: Gustavo Sousa
> ---
Reviewed-by: Luca Coelho
--
Cheers,
Luca.
On Mon, 2024-10-21 at 19:27 -0300, Gustavo Sousa wrote:
> Enabling and disabling the DMC wakelock should be done as part of
> enabling and disabling of dynamic DC states, respectively. We should not
> enable or disable DMC wakelock independently of DC states, otherwise we
> would risk ending up wit
On Mon, 2024-10-21 at 19:27 -0300, Gustavo Sousa wrote:
> It is possible that there are active wakelock references at the time we
> are disabling the DMC wakelock mechanism. We need to deal with that in
> two ways:
>
> (A) Implement the missing step from Bspec:
>
> The Bspec instructs us to c
Let's start using struct intel_display instead of struct drm_i915_private
when introducing new code. No functional changes.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/display/intel_tc.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/dr
There is a HW issue that arises when there are race conditions
between TCSS entering/exiting TC7 or TC10 states while the
driver is asserting/deasserting TCSS power request. As a
workaround, Display driver will implement a mailbox sequence
to ensure that the TCSS is in TC0 when TCSS power request i
On Fri, Nov 01, 2024 at 11:22:13AM +0200, Jani Nikula wrote:
> On Thu, 31 Oct 2024, Imre Deak wrote:
> > On Thu, Oct 31, 2024 at 05:12:45PM +0200, Abel Vesa wrote:
> >> According to the DisplayPort standard, LTTPRs have two operating
> >> modes:
> >> - non-transparent - it replies to DPCD LTTPR f
On Mon, 2024-10-21 at 19:27 -0300, Gustavo Sousa wrote:
> There are extra registers that require the DMC wakelock when specific
> dynamic DC states are in place. Add the table ranges for them and use
> the correct table depending on the allowed DC states.
>
> Bspec: 71583
> Signed-off-by: Gustavo
On Mon, 2024-10-21 at 19:27 -0300, Gustavo Sousa wrote:
> Allow simpler syntax for defining entries for single registers in range
> tables. That makes them easier to type as well as to read, allowing one
> to quickly tell whether a range actually refers to a single register or
> a "true range".
>
On Thu, 31 Oct 2024, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Implement xelpdp_is_only_pipe_per_dbuf_bank() in a slightly
> more straightforward way.
>
> Signed-off-by: Ville Syrjälä
Matter of taste, but at least this is less repetitive.
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/dr
On Mon, 2024-10-21 at 19:27 -0300, Gustavo Sousa wrote:
> We are currently using ARRAY_SIZE() to iterate address ranges in
> intel_dmc_wl_check_range(). In upcoming changes, we will be using more
> than a single table and will extract the range checking logic into a
> dedicated function that takes
On Mon, 2024-10-21 at 19:27 -0300, Gustavo Sousa wrote:
> Bspec says that disabling dynamic DC states require taking the DMC
> wakelock to cause an DC exit before writing to DC_STATE_EN. Implement
> that.
>
> In fact, testing on PTL revealed we end up failing to exit DC5/6 without
> this step.
>
On Mon, 2024-10-21 at 19:27 -0300, Gustavo Sousa wrote:
> When the DMC wakelock refcount reaches zero, we know that there are no
> users and that we can do the actual release operation on the hardware,
> which is queued with a delayed work. The idea of the delayed work is to
> avoid performing the
> -Original Message-
> From: Jadav, Raag
> Sent: Thursday, 31 October 2024 17.13
> To: Kahola, Mika
> Cc: intel-gfx@lists.freedesktop.org; Sousa, Gustavo ;
> jani.nik...@linux.intel.com
> Subject: Re: [PATCH v3 1/2] drm/i915/xe3lpd: Power request
> asserting/deasserting
>
> On Thu, Oct 3
On Tue, 2024-10-22 at 07:55 -0300, Gustavo Sousa wrote:
> Quoting Jani Nikula (2024-10-22 06:34:44-03:00)
> > On Mon, 21 Oct 2024, Gustavo Sousa wrote:
> > > Some display MMIO transactions for offsets in the range that requires
> > > the DMC wakelock happen in atomic context (this has been confirm
On Mon, 2024-10-21 at 19:27 -0300, Gustavo Sousa wrote:
> In upcoming display changes, we will modify the DMC wakelock MMIO
> waiting code to choose a non-sleeping variant implementation, because
> the wakelock is also taking in atomic context.
>
> While xe provides an explicit parameter (namely "
To initialize hrtimer, hrtimer_init() needs to be called and also
hrtimer::function must be set. This is error-prone and awkward to use.
Introduce hrtimer_setup() which does both of these things, so that users of
hrtimer can be simplified.
The new setup function also has a sanity check for the pr
Hi Dave and Simona,
drm-xe-fixes for 6.12-rc6. Two important fixes for LNL and one missing
hpd enabling. This last one brought in a refactor as dependency,
otherwise it would cause some headache with conflicts.
thanks
Lucas De Marchi
drm-xe-fixes-2024-10-31:
Driver Changes:
- Fix missing HPD in
On Thu, 31 Oct 2024, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> If the system boots with MBUS joining enabled but we disable
> the relevant pipe during sanitaion we later get into trouble
*sanitation
> as the rest of the code doesn't expect MBUS joining to be
> enabled unless the set of act
hrtimer_setup_sleeper_on_stack() replaces hrtimer_init_sleeper_on_stack()
to keep the naming convention consistent.
Convert the usage sites over to it. The conversion was done with
Coccinelle.
Signed-off-by: Nam Cao
---
kernel/time/hrtimer.c | 5 ++---
kernel/time/sleep_timeout.c | 2 +-
On Thu, 31 Oct 2024, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We'll be wanting reprogram the MBUS_CTL register during an
*to* :)
And the same nitpick about intel_display.
Reviewed-by: Jani Nikula
> upcoming MBUS sanitation stage. Extract the reprogramming
> into a helper that doesn't
On Thu, 31 Oct 2024, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We'll be wanting reprogram the PIPE_MBUS_DBOX_CTL registers
wanting *to* reprogram
I would've wanted to see conversion to struct intel_display here too, or
at least a mention we're keeping it this way for backports, or
somethin
On Thu, 31 Oct 2024, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We'll be wanting reprogram the PIPE_MBUS_DBOX_CTL registers
wanting *to* reprogram
Reviewed-by: Jani Nikula
> during an upcoming MBUS sanitation stage. To make that easier
> extract a helper that computes the full register va
hrtimer_setup_sleeper_on_stack() replaces hrtimer_init_sleeper_on_stack()
to keep the naming convention consistent.
Convert the usage site over to it. The conversion was done with Coccinelle.
Signed-off-by: Nam Cao
Cc: Peter Zijlstra
---
kernel/futex/core.c | 6 +++---
1 file changed, 3 insert
On Thu, 31 Oct 2024, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> In order to add more MBUS sanitation into the code we'll want
> to reuse a bunch of the code that performs the MBUS/related
> hardware programming. Currently that code comes after the
> main skl_wm_get_hw_state_and_sanitize() ent
To initialize hrtimer on stack, hrtimer_init_on_stack() needs to be called
and also hrtimer::function must be set. This is error-prone and awkward to
use.
Introduce hrtimer_setup_on_stack() which does both of these things, so that
users of hrtimer can be simplified.
The new setup function also ha
On Thu, 31 Oct 2024, Imre Deak wrote:
> On Thu, Oct 31, 2024 at 05:12:45PM +0200, Abel Vesa wrote:
>> According to the DisplayPort standard, LTTPRs have two operating
>> modes:
>> - non-transparent - it replies to DPCD LTTPR field specific AUX
>>requests, while passes through all other AUX re
Hello again,
I attempted to send a potential deadlock issue from my work email
(acof...@sfcompute.com) and suspect that using gmail with a very long email was
causing issues as it didn't seem to show up from what I can see on the mailing
list. I am retrying from my personal e
hrtimer_setup_sleeper_on_stack() replaces hrtimer_init_sleeper_on_stack()
to keep the naming convention consistent.
Convert the usage site over to it.
Signed-off-by: Nam Cao
Cc: Peter Zijlstra
---
include/linux/wait.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/incl
When a request is created, the hrtimer is not initialized and only its
'function' field is set to NULL. The hrtimer is only initialized when the
request is enqueued. The point of setting 'function' to NULL is that, it
can be used to check whether hrtimer_try_to_cancel() should be called while
retir
Some users of hrtimer need to change the callback function after the
initial setup. They write to hrtimer::function directly.
That's not safe under all circumstances as the write is lockless and a
concurrent timer expiry might end up using the wrong function pointer.
Introduce hrtimer_update_func
hrtimer_setup_sleeper_on_stack() replaces hrtimer_init_sleeper_on_stack()
to keep the naming convention consistent.
Convert the usage site over to it. The conversion was done with Coccinelle.
Signed-off-by: Nam Cao
Cc: Christian Brauner
---
fs/aio.c | 2 +-
1 file changed, 1 insertion(+), 1 de
Control: forwarded -1
https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12246
On Mon, 29 Jul 2024 13:19:06 +0300 Jani Nikula wrote:
[...]
> There are a number of reasons why email and mailing lists are really bad
> for reporting bugs, from our perspective, which is why we've asked
> peopl
Looking at both i915 and nouveau DP drivers, both are setting the first
LTTPR (if found) in transparent mode first and then in non-transparent
mode, just like the DP v2.0 specification mentions in section 3.6.6.1.
Being part of the standard, setting the LTTPR in a specific operation mode
can be ea
hrtimer_init_on_stack() is now unused. Delete it.
Signed-off-by: Nam Cao
---
include/linux/hrtimer.h | 2 --
kernel/time/hrtimer.c | 17 -
2 files changed, 19 deletions(-)
diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
index 4e4f04b3c0c2..7ef5f7ef31a9 100644
-
(resend due to broken emails)
This is a follow up to version 1, which can be found here:
https://lore.kernel.org/lkml/cover.1729864615.git.nam...@linutronix.de/
hrtimers must be initialized with a hrtimer_init() variant, and after that
the timer's callback function must be setup separately.
On 10/28/2024 12:51 PM, Jani Nikula wrote:
We stopped using the driver initialized date in commit 7fb8af6798e8
("drm: deprecate driver date") and (eventually) started returning "0"
for drm_version ioctl instead.
Finish the job, and remove the unused date member from struct
drm_driver, its initia
The IORING_OP_TIMEOUT command uses hrtimer underneath. The timer's callback
function is setup in io_timeout(), and then the callback function is setup
again when the timer is rearmed.
Since the callback function is the same for both cases, the latter setup is
redundant, therefore remove it.
Signe
hrtimer_setup_on_stack() takes the callback function pointer as argument
and initializes the timer completely.
Replace hrtimer_init_on_stack() and the open coded initialization of
hrtimer::function with the new setup mechanism.
The conversion was done with Coccinelle.
Signed-off-by: Nam Cao
Cc:
rt2x00usb_probe() executes a hrtimer_init() for txstatus_timer. Afterwards,
rt2x00lib_probe_dev() is called which also initializes this txstatus_timer
with the same settings.
Remove the redundant hrtimer_init() call in rt2x00usb_probe().
Signed-off-by: Nam Cao
Acked-by: Kalle Valo
Cc: linux-wir
This is a follow up to version 1, which can be found here:
https://lore.kernel.org/lkml/cover.1729864615.git.nam...@linutronix.de/
hrtimers must be initialized with a hrtimer_init() variant, and after that
the timer's callback function must be setup separately.
This seperate initialization i
hrtimer_setup() and hrtimer_setup_on_stack() take the callback function
pointer as argument and initialize the timer completely.
Replace the hrtimer_init*() variants and the open coded initialization of
hrtimer::function with the new setup mechanism.
Switch to use the new functions.
Signed-off-b
hrtimer_setup_on_stack() takes the callback function pointer as argument
and initializes the timer completely.
Replace hrtimer_init_on_stack() and the open coded initialization of
hrtimer::function with the new setup mechanism.
Signed-off-by: Nam Cao
Cc: Jens Axboe
---
io_uring/io_uring.c | 7
The hrtimer_init*() API is replaced by hrtimer_setup*() variants to
initialize the timer including the callback function at once.
hrtimer_init_sleeper_on_stack() does not need user to setup the callback
function separately, so a new variant would not be strictly necessary.
Nonetheless, to keep th
Link Training Tunable PHY Repeaters (LTTPRs) are defined in DisplayPort
1.4a specification. As the name suggests, these PHY repeaters are
capable of adjusting their output for link training purposes.
The msm DP driver is currently lacking any handling of LTTPRs.
This means that if at least one LTT
hrtimer_init_sleeper_on_stack() is now unused. Delete it.
Signed-off-by: Nam Cao
---
include/linux/hrtimer.h | 3 ---
kernel/time/hrtimer.c | 14 --
2 files changed, 17 deletions(-)
diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
index 6e026730e803..4e4f04b3c0c2 10
hrtimer_init*_on_stack() is not covered by tracing when
CONFIG_DEBUG_OBJECTS_TIMERS=y.
Rework the functions similar to hrtimer_init() and hrtimer_init_sleeper()
so that the hrtimer_init() tracepoint is unconditionally available.
The rework makes hrtimer_init_sleeper() unused. Delete it.
Signed-o
hrtimer_setup_sleeper_on_stack() replaces hrtimer_init_sleeper_on_stack()
to keep the naming convention consistent.
Convert the usage site over to it. The conversion was done with Coccinelle.
Signed-off-by: Nam Cao
Cc: Jakub Kicinski
---
net/core/pktgen.c | 2 +-
1 file changed, 1 insertion(+)
The hrtimer is initialized in the KVM_XEN_VCPU_SET_ATTR ioctl. That caused
problem in the past, because the hrtimer can be initialized multiple times,
which was fixed by commit af735db31285 ("KVM: x86/xen: Initialize Xen timer
only once"). This commit avoids initializing the timer multiple times by
LTTPRs operating modes are defined by the DisplayPort standard and the
generic framework now provides a helper to switch between them.
So use the drm generic helper instead as it makes the code a bit cleaner.
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2
I just learned the hard way that git-send-email doesn't work for a .mbox
file including multiple emails. Sorry for the noises, please ignore this
one. I will resend it shortly.
On Thu, Oct 31, 2024 at 03:19:21PM +0100, Nam Cao wrote:
> This is a follow up to version 1, which can be found here:
>
According to the DisplayPort standard, LTTPRs have two operating
modes:
- non-transparent - it replies to DPCD LTTPR field specific AUX
requests, while passes through all other AUX requests
- transparent - it passes through all AUX requests.
Switching between this two modes is done by the DPT
LTTPRs operating modes are defined by the DisplayPort standard and the
generic framework now provides a helper to switch between them.
So use the drm generic helper instead as it makes the code a bit cleaner.
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 9 +++--
1 file
62 matches
Mail list logo
