On 04.05.22 08:48, Juergen Gross wrote:
> On 04.05.22 07:46, Thorsten Leemhuis wrote:
>> Hi, this is your Linux kernel regression tracker. Sending this just to
>> CC the developers of the culprit mentioned below (bdd8b6c98239cad
>> ("drm/i915: replace X86_FEATURE_PAT with pat_enabled()")) and the
>
Hi, this is your Linux kernel regression tracker. Sending this just to
CC the developers of the culprit mentioned below (bdd8b6c98239cad
("drm/i915: replace X86_FEATURE_PAT with pat_enabled()")) and the
maintainers for the subsystem.
While at it a quick note: I wonder if this is problem a similar
== Series Details ==
Series: drm/i915/guc: Support programming the EU priority in the GuC descriptor
URL : https://patchwork.freedesktop.org/series/103515/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11599 -> Patchwork_103515v1
===
== Series Details ==
Series: drm/i915/dmc: Add MMIO range restrictions (rev6)
URL : https://patchwork.freedesktop.org/series/102168/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11599 -> Patchwork_102168v6
Summary
---
On 5/3/2022 5:44 PM, Daniele Ceraolo Spurio wrote:
From: Matthew Brost
The EU priority register must be updated by the GuC rather than the
driver as it is context specific and only the GuC knows which context
is currently executing.
Cc: John Harrison
Cc: Matt Roper
Signed-off-by: Matthew
From: Matthew Brost
The EU priority register must be updated by the GuC rather than the
driver as it is context specific and only the GuC knows which context
is currently executing.
Cc: John Harrison
Cc: Matt Roper
Signed-off-by: Matthew Brost
Signed-off-by: Aravind Iddamsetty
---
drivers/g
== Series Details ==
Series: DG2 DMC Support
URL : https://patchwork.freedesktop.org/series/103513/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11599 -> Patchwork_103513v1
Summary
---
**SUCCESS**
No regressions
On Tue, May 03, 2022 at 04:57:28PM -0700, Anusha Srivatsa wrote:
> While DG2 supports DC5 and DC9, some of the tests in
> fast-feedback blew up DG2 when the tests forced transition
> from dc5->dc9 on suspend and dc9->dc5 on resume. Some local
> experiments performed with Rodrigo on a RIL system sh
> -Original Message-
> From: De Marchi, Lucas
> Sent: Tuesday, May 3, 2022 5:31 PM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org; sta...@vger.kernel.org
> Subject: Re: [PATCH] drm/i915/dmc: Add MMIO range restrictions
>
> On Tue, May 03, 2022 at 05:13:46PM -0700, Anusha
On Tue, May 03, 2022 at 05:13:46PM -0700, Anusha Srivatsa wrote:
Bspec has added some steps that check forDMC MMIO range before
programming them
v2: Fix for CI
v3: move register defines to .h (Anusha)
- Check MMIO restrictions per pipe
- Add MMIO restricton for v1 dmc header as well (Lucas)
v4:
Bspec has added some steps that check forDMC MMIO range before
programming them
v2: Fix for CI
v3: move register defines to .h (Anusha)
- Check MMIO restrictions per pipe
- Add MMIO restricton for v1 dmc header as well (Lucas)
v4: s/_PICK/_PICK_EVEN and use it only for Pipe DMC scenario.
- clean u
While DG2 supports DC5 and DC9, some of the tests in
fast-feedback blew up DG2 when the tests forced transition
from dc5->dc9 on suspend and dc9->dc5 on resume. Some local
experiments performed with Rodrigo on a RIL system showed promising
results when dc5 was completely diabled and i915 took only
Add Support for DC states on Dg2.
v2: Add dc9 as the max supported DC states and disable DC5.
Cc: Rodrigo Vivi
Signed-off-by: Anusha Srivatsa
Reviewed-by: Rodrigo Vivi (v1)
---
drivers/gpu/drm/i915/display/intel_display_power.c | 4 +++-
drivers/gpu/drm/i915/display/intel_dmc.c | 10
== Series Details ==
Series: drm/i915/dmc: Add MMIO range restrictions (rev5)
URL : https://patchwork.freedesktop.org/series/102168/
State : failure
== Summary ==
Error: make failed
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include
Bspec has added some steps that check forDMC MMIO range before
programming them
v2: Fix for CI
v3: move register defines to .h (Anusha)
- Check MMIO restrictions per pipe
- Add MMIO restricton for v1 dmc header as well (Lucas)
v4: s/_PICK/_PICK_EVEN and use it only for Pipe DMC scenario.
- clean u
== Series Details ==
Series: drm/i915/dmc: Add MMIO range restrictions (rev4)
URL : https://patchwork.freedesktop.org/series/102168/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11599 -> Patchwork_102168v4
Summary
---
== Series Details ==
Series: drm/i915/dmc: Add MMIO range restrictions (rev4)
URL : https://patchwork.freedesktop.org/series/102168/
State : warning
== Summary ==
Error: dim checkpatch failed
7948f39ab7c9 drm/i915/dmc: Add MMIO range restrictions
-:74: WARNING:LONG_LINE: line length of 101 exc
Bspec has added some steps that check forDMC MMIO range before
programming them
v2: Fix for CI
v3: move register defines to .h (Anusha)
- Check MMIO restrictions per pipe
- Add MMIO restricton for v1 dmc header as well (Lucas)
v4: s/_PICK/_PICK_EVEN and use it only for Pipe DMC scenario.
- clean u
== Series Details ==
Series: ttm for internal
URL : https://patchwork.freedesktop.org/series/103492/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11599 -> Patchwork_103492v1
Summary
---
**FAILURE**
Serious unknow
On Tue, May 03, 2022 at 09:42:52AM +0100, Tvrtko Ursulin wrote:
On 02/05/2022 23:18, Umesh Nerlige Ramappa wrote:
Current implementation of Wa_22011802037 is limited to the GuC backend
and gen12. Add support for execlist backend and gen11 as well.
Is the implication f6aa0d713c88 ("drm/i915: A
== Series Details ==
Series: drm/i915: Make fastset not suck and allow seamless M/N changes
URL : https://patchwork.freedesktop.org/series/103491/
State : failure
== Summary ==
Error: make failed
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
C
Internal gem objects will soon just be volatile system memory region
objects.
To enable this, create a separate dummy object creation function
for gen6 ppgtt
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 43 ++--
1 file changed, 40 insertions(+)
internal buffers should be shmem backed.
if a volatile buffer is requested, allow ttm to use the pool allocator
to provide volatile pages as backing
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/dri
refactor internal buffer backend to allocate volatile pages via
ttm pool allocator
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 264 ---
drivers/gpu/drm/i915/gem/i915_gem_internal.h | 5 -
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 12 +-
reorder scratch page allocation so that memory regions are available
to allocate the buffers
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gt/intel_gt_gmch.c | 20 ++--
drivers/gpu/drm/i915/gt/intel_gt_gmch.h | 6 ++
drivers/gpu/drm/i915/i915_driver.c | 16
This series refactors i915's internal buffer backend to use ttm.
It uses ttm's pool allocator to allocate volatile pages in place of the
old code which rolled its own via alloc_pages.
This is continuing progress to align all backends on using ttm.
Robert Beckett (4):
drm/i915: add gen6 ppgtt dum
From: Ville Syrjälä
Use round-to-nearest behavour when calculating the TMDS clock.
Matches what we co for most other clock related things.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
2 files changed, 3 in
From: Ville Syrjälä
Windows/BIOS always uses fixed N values. Let's match that
behaviour.
Allows us to also get rid of that constant_n quirk stuff.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 36 +---
drivers/gpu/drm/i915/display/intel_displa
From: Ville Syrjälä
Rounding to nearest is what we do for most other clock calculations
so should probably do that for M/N too.
TODO: GOP seems to truncate instead so fastboot is going to be
a PITA to get right. Not sure what to do about it yet.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/dr
From: Ville Syrjälä
On BDW+ M/N are double buffered and so we can easily reprogram them
during a fastset. So for eDP panels that support seamless DRRS we
can just change these without a full modeset.
For earlier platforms we'd need to play tricks with M1/N1 vs.
M2/N2 during the fastset to make s
From: Ville Syrjälä
No idea why the DG2 PLL DP link frequency calculation is allowing
a non-exact match. That makes no sense so get rid of it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_snps_phy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driv
From: Ville Syrjälä
No sense in calling intel_modeset_pipe_config_late() for a disabled
pipe.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
From: Ville Syrjälä
Add a function to get the fixed_mode with the highest clock.
The plan is to use this for the link bw calculation on seamless
DRRS panels so that we alwasy end up with the same link params
regardless of the requested refresh rate. This will allow fastset
to do seamless refresh
From: Ville Syrjälä
Don't see a real reson not to check hw.active and hw.enable in
intel_pipe_config_compare(). We do have some checks for them
at a higher level, but I think better check them also in
intel_pipe_config_compare() in case something else doesn't
do a thorough enough job.
Also shuff
From: Ville Syrjälä
Now that we no longer do the fuzzy clock and M/N checks we can
get rid of the fastset state copy hacks.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 28 +++-
1 file changed, 3 insertions(+), 25 deletions(-)
diff --git a/dr
From: Ville Syrjälä
To make the fastboot checks at least somewhat sensible let's mark
the expected DPLL as the active one right after we finished the
state computation. Otherwise intel_pipe_config_compare() will
always be comparing things against NULL/0.
TODO: This is still not really right. If
From: Ville Syrjälä
Now that we backfeed the actual DPLL frequency into the
compute crtc state all our clocks should come out exact.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 22 +---
1 file changed, 5 insertions(+), 17 deletions(-)
diff -
From: Ville Syrjälä
Now that we no longer fuzz M/N during fastset these should
match exctly.
TODO: we may need to do something for fastboot here as the
VBIOS/GOP may not compute M/N exactly the same way we do.
Though I guess we could try to match the VBIOS/GOP exactly.
Signed-off-by: Ville Syrj
From: Ville Syrjälä
The VBIOS/GOP may not program the FDI M/n vs. dotclock entirely
consistently. Eg. on a SNB Thinkpad X220 LVDS I see dotclock of
69.286 MHz (the best the DPLL can do) vs. FDI M/N 69.3 MHz
(matches what the EDID actually declares).
Signed-off-by: Ville Syrjälä
---
drivers/gpu
From: Ville Syrjälä
Do the DPLL computation before fastset checks. This should
allow us to get rid of all that horrible fuzzy clock handling
for fastsets. Who knows how many bugs there are caused by our
state not actually matching what the hardware will generate.
Signed-off-by: Ville Syrjälä
--
From: Ville Syrjälä
Fill port_clock and hw.adjusted_mode.crtc_clock with the actual
frequency we're going to be getting from the hardware. This will
let us accurately compute all derived state that depends on those.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_crt.c
From: Ville Syrjälä
Pull the various iCLKIP parameters into a struct. Later on
we'll reuse this during the state computation to determine
the exact dotclock the hardware will be generating for us.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_crt.c | 1 +
.../gpu/dr
From: Ville Syrjälä
Rename some of the 'pipe_config's to the more modern
'crtc_state'.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 62 ++--
1 file changed, 31 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dis
From: Ville Syrjälä
Extract intel_crtc_dotclock() from ddi_dotclock_get(). We'll reuse
this during state computation in order to determine the actual final
dotclcok after the DPLL computation has been done (which may not give
us the exact same port_clock that we fed in).
Signed-off-by: Ville Syr
From: Ville Syrjälä
Use the "[CRTC:%d:%s]'/etc. format for some of the modeset debugs
so we know more about what has happened during the modeset state
computation.
Also tweak the connector bpp debug message a bit to make it less
confusing.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915
From: Ville Syrjälä
Deduplicate the drm_rect comparisons.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i91
From: Ville Syrjälä
Use the state+crtc calling convention for intel_modeset_pipe_config()
and othere related functions. Many of these need the full atomic state
anyway so passing it all the way through is just nicer than having to
worry about whether it can actually be extracted from eg. the crtc
From: Ville Syrjälä
Deduplicate the crtc_ timigns comparisons.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 45
1 file changed, 18 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/dr
From: Ville Syrjälä
Only reassign the pipe's DPLL if it's going through a full
.compute_config() cycle. If OTOH it's just getting modeset
eg. in order to change cdclk there doesn't seem much point in
picking a new DPLL for it.
This should also prevent .get_dplls() from seeing a funky port_clock
From: Ville Syrjälä
The debugs in lower level DPLL code don't really provide any
useful extra information AFAICS. Better just streamline the
code and just put the necessary debugs (to identify at which
step the modeset failed) into the higher level code. In
addition we'll get the full state dump
From: Ville Syrjälä
Currently we calculate a lot of things (pixel rate, watermarks,
cdclk) trusting that the DPLL can generate the exact frequency
we ask it. In practice that is not true and there can be
certain amount of rounding involved.
To allow us to eventually get accurate numbers for all
From: Ville Syrjälä
Split the DPLL state computation into a separate function
from the current .get_dplls() which currently serves a dual duty
by also reserving the shared DPLLs.
v2: s/false/-EINVAL/ (Jani)
Cc: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_d
From: Ville Syrjälä
Here's a (still somewhat rough) series to get rid of al those horrible
fuzzy clock checks in the fastset code. We achieve that by feeding back
the actual DPLL frequency and actual dotclock into the crtc state.
And with fastset made to not suck we can consider allowing
seamele
== Series Details ==
Series: drm/i915: Fix race in __i915_vma_remove_closed (rev4)
URL : https://patchwork.freedesktop.org/series/102845/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11597 -> Patchwork_102845v4
Summary
---
On Mon, May 02, 2022 at 10:58:32PM +, Patchwork wrote:
> == Series Details ==
>
> Series: i915: Introduce Ponte Vecchio
> URL : https://patchwork.freedesktop.org/series/103443/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_11588_full -> Patchwork_103443v1_full
>
On Tue, May 03, 2022 at 01:55:16PM +0300, Jani Nikula wrote:
> On Tue, 26 Apr 2022, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Modern VBTs no longer contain the LFP data table pointers
> > block (41). We are expecting to have one in order to be able
> > to parse the LFP data block (42),
== Series Details ==
Series: drm/i915: use IOMEM_ERR_PTR() directly
URL : https://patchwork.freedesktop.org/series/103485/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11597 -> Patchwork_103485v1
Summary
---
**SUCCE
On Tue, May 03, 2022 at 02:46:35PM +0300, Jani Nikula wrote:
> On Tue, 26 Apr 2022, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > During the eDP probe we may not yet know the panel_type used
> > to index the VBT panel tables. So the initial eDP probe will have
> > to be done without that,
On Tue, 2022-05-03 at 08:20 -0400, Josh Boyer wrote:
> On Mon, May 2, 2022 at 3:56 PM Tolakanahalli Pradeep, Madhumitha
> wrote:
> >
> > The following changes since commit c3624ebd67c68722e0fabc9cae01397b15310239:
> >
> > Merge branch 'ath10k-20220423' of
> > git://git.kernel.org/pub/scm/linux
== Series Details ==
Series: drm/i915: use IOMEM_ERR_PTR() directly
URL : https://patchwork.freedesktop.org/series/103485/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
On 03/05/2022 15:56, Matt Roper wrote:
On Tue, May 03, 2022 at 09:21:04AM +0100, Tvrtko Ursulin wrote:
On 02/05/2022 17:34, Matt Roper wrote:
Ponte Vecchio (PVC) is a new GPU based on the Xe_HPC architecture. As a
compute-focused platform, PVC has compute engines and enhanced copy
engines,
On Tue, May 03, 2022 at 09:21:04AM +0100, Tvrtko Ursulin wrote:
>
> On 02/05/2022 17:34, Matt Roper wrote:
> > Ponte Vecchio (PVC) is a new GPU based on the Xe_HPC architecture. As a
> > compute-focused platform, PVC has compute engines and enhanced copy
> > engines, but no render engine (there i
From: Kefeng Wang
Use IOMEM_ERR_PTR() instead of self defined IO_ERR_PTR().
Signed-off-by: Kefeng Wang
Reviewed-by: Jani Nikula
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_vma.c | 4 ++--
drivers/gpu/drm/i915/i915_vma.h | 1 -
2 files changed, 2 insertions(+), 3 deletions(-)
Hi,
On 29/04/2022 16:11, Adrian Larumbe wrote:
I915_PARAM_HAS_CONTEXT_ISOLATION was already being used as a boolean by
both Iris and Vulkan , and stood for the guarantee that, when creating a
new context, all state set by it will not leak to any other context.
However the actual return value
On 28/04/2022 12:11, Tvrtko Ursulin wrote:
On 28/04/2022 11:25, Matthew Auld wrote:
On 28/04/2022 09:55, Tvrtko Ursulin wrote:
On 27/04/2022 18:36, Matthew Auld wrote:
On 27/04/2022 09:36, Tvrtko Ursulin wrote:
On 20/04/2022 18:13, Matthew Auld wrote:
Add an entry for the new uapi needed
On 03/05/2022 17:27, Matthew Auld wrote:
On 03/05/2022 11:39, Lionel Landwerlin wrote:
On 03/05/2022 13:22, Matthew Auld wrote:
On 02/05/2022 09:53, Lionel Landwerlin wrote:
On 02/05/2022 10:54, Lionel Landwerlin wrote:
On 20/04/2022 20:13, Matthew Auld wrote:
Add an entry for the new uapi n
On 03/05/2022 11:39, Lionel Landwerlin wrote:
On 03/05/2022 13:22, Matthew Auld wrote:
On 02/05/2022 09:53, Lionel Landwerlin wrote:
On 02/05/2022 10:54, Lionel Landwerlin wrote:
On 20/04/2022 20:13, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Som
== Series Details ==
Series: drm/i915/bios: add helper for reading SPI
URL : https://patchwork.freedesktop.org/series/103480/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11595 -> Patchwork_103480v1
Summary
---
**SU
== Series Details ==
Series: drm/i915: Fix assert in i915_ggtt_pin (rev2)
URL : https://patchwork.freedesktop.org/series/103339/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11592_full -> Patchwork_103339v2_full
Summary
--
== Series Details ==
Series: drm/i915: Fix race in __i915_vma_remove_closed (rev3)
URL : https://patchwork.freedesktop.org/series/102845/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11595 -> Patchwork_102845v3
Summary
---
== Series Details ==
Series: drm/msm/dp: implement HPD notifications handling
URL : https://patchwork.freedesktop.org/series/103478/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/103478/revisions/1/mbox/ not
applied
Applying: drm/bridge_connector
Add helper for reading SPI to not duplicate the write&read combo
everywhere.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_bios.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers
== Series Details ==
Series: drm/edid: CEA data block iterators, and more (rev3)
URL : https://patchwork.freedesktop.org/series/102703/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11595 -> Patchwork_102703v3
Summary
-
== Series Details ==
Series: drm/edid: CEA data block iterators, and more (rev3)
URL : https://patchwork.freedesktop.org/series/102703/
State : warning
== Summary ==
Error: dim checkpatch failed
aadd541b02ce drm/edid: reset display info in drm_add_edid_modes() for NULL edid
046cc3c84c91 drm/ed
== Series Details ==
Series: drm/i915: warn about missing ->get_buf_trans initialization
URL : https://patchwork.freedesktop.org/series/103473/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11595 -> Patchwork_103473v1
Summa
On Mon, May 2, 2022 at 3:56 PM Tolakanahalli Pradeep, Madhumitha
wrote:
>
> The following changes since commit c3624ebd67c68722e0fabc9cae01397b15310239:
>
> Merge branch 'ath10k-20220423' of
> git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/linux-firmware into main
> (2022-05-02 08:31:40 -04
On Mon 02 May 15:49 PDT 2022, Kuogee Hsieh wrote:
>
> On 5/2/2022 3:29 PM, Bjorn Andersson wrote:
> > On Mon 02 May 13:59 PDT 2022, Kuogee Hsieh wrote:
> >
> > > On 5/2/2022 9:53 AM, Bjorn Andersson wrote:
> > > > The Qualcomm DisplayPort driver contains traces of the necessary
> > > > plumbing
The Qualcomm DisplayPort driver contains traces of the necessary
plumbing to hook up USB HPD, in the form of the dp_hpd module and the
dp_usbpd_cb struct. Use this as basis for implementing the
hpd_notify() callback, by amending the dp_hpd module with the
missing logic.
Overall the solution is sim
From: Dmitry Baryshkov
In some cases the bridge drivers would like to receive hotplug events
even in the case new status is equal to the old status. In the DP case
this is used to deliver "attention" messages to the DP host. Stop
filtering the events in the drm_bridge_connector_hpd_cb() and let
d
On Mon 02 May 15:29 PDT 2022, Bjorn Andersson wrote:
> On Mon 02 May 13:59 PDT 2022, Kuogee Hsieh wrote:
>
> >
> > On 5/2/2022 9:53 AM, Bjorn Andersson wrote:
> > > The Qualcomm DisplayPort driver contains traces of the necessary
> > > plumbing to hook up USB HPD, in the form of the dp_hpd modul
Le 30/04/2022 à 22:04, Mauro Carvalho Chehab a écrit :
> Sometimes, device drivers are bound into each other via try_module_get(),
> making such references invisible when looking at /proc/modules or lsmod.
>
> Add a function to allow setting up module references for such
> cases, and call it whe
From: Dmitry Baryshkov
Implement the oob_hotplug_event() callback. Translate it to the HPD
notification sent to the HPD bridge in the chain.
Signed-off-by: Dmitry Baryshkov
Signed-off-by: Bjorn Andersson
---
Changes since v3:
- New patch
drivers/gpu/drm/drm_bridge_connector.c | 12 +
On 5/2/2022 9:53 AM, Bjorn Andersson wrote:
The Qualcomm DisplayPort driver contains traces of the necessary
plumbing to hook up USB HPD, in the form of the dp_hpd module and the
dp_usbpd_cb struct. Use this as basis for implementing the
hpd_notify() callback, by amending the dp_hpd module with
On 5/2/2022 3:29 PM, Bjorn Andersson wrote:
On Mon 02 May 13:59 PDT 2022, Kuogee Hsieh wrote:
On 5/2/2022 9:53 AM, Bjorn Andersson wrote:
The Qualcomm DisplayPort driver contains traces of the necessary
plumbing to hook up USB HPD, in the form of the dp_hpd module and the
dp_usbpd_cb struct.
From: Dmitry Baryshkov
Remove most of remains of downstream usbpd code. Mainline kernel uses
different approach for managing Type-C / USB-PD, so this remains unused.
Do not touch usbpd callbacks for now, since they look useful enough as
an example of how to handle connect/disconnect (to be rewrit
On Mon 02 May 13:59 PDT 2022, Kuogee Hsieh wrote:
>
> On 5/2/2022 9:53 AM, Bjorn Andersson wrote:
> > The Qualcomm DisplayPort driver contains traces of the necessary
> > plumbing to hook up USB HPD, in the form of the dp_hpd module and the
> > dp_usbpd_cb struct. Use this as basis for implementi
USB altmodes code would send OOB notifications to the drm_connector
specified in the device tree. However as the MSM DP driver uses
drm_bridge_connector, there is no way to receive these event directly.
Implement a bridge between oob_hotplug_event and drm_bridge's hpd_notify
and use it to deliver a
In some implementations, such as the Qualcomm platforms, the display
driver has no way to query the current HPD state and as such it's
impossible to distinguish between disconnect and attention events.
Add a parameter to drm_connector_oob_hotplug_event() to pass the HPD
state.
Also push the test
On Tue, 26 Apr 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> During the eDP probe we may not yet know the panel_type used
> to index the VBT panel tables. So the initial eDP probe will have
> to be done without that, and thus we won't yet have the PPS delays
> from the VBT. Once the VBT ha
== Series Details ==
Series: series starting with [1/2] drm/i915: Enable THP on Icelake and beyond
(rev2)
URL : https://patchwork.freedesktop.org/series/103330/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11594 -> Patchwork_103330v2
=
On Tue, 26 Apr 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Make sure we don't cause memory leaks/etc. by parsing panel_type
> specific parts multiple times. The real solution would be to stop
> stuffing panel specific stuff into i915->vbt, but in the meantime
> let's just make sure we do
On Tue, 26 Apr 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Move the panel specific VBT parsing to happen during the
> output probing stage. Needs to be done because the VBT
> parsing will need to look at the EDID to determine
> the correct panel_type on some machines.
>
> v2: Do intel_bi
On 03/05/2022 11:22, Matthew Auld wrote:
On 02/05/2022 09:53, Lionel Landwerlin wrote:
On 02/05/2022 10:54, Lionel Landwerlin wrote:
On 20/04/2022 20:13, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Ake
== Series Details ==
Series: series starting with [1/2] drm/i915: Enable THP on Icelake and beyond
(rev2)
URL : https://patchwork.freedesktop.org/series/103330/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separatel
On Tue, 26 Apr 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Document the fact that struct lvds_lfp_data_entry can't be used
> directly and instead must be accessed via the data table pointers.
>
> Also remove the bogus comment implying that there might be a
> variable number of panel entr
On Tue, 26 Apr 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Modern VBTs no longer contain the LFP data table pointers
> block (41). We are expecting to have one in order to be able
> to parse the LFP data block (42), so let's make one up.
>
> Since the fp_timing table has variable size we
On 03/05/2022 13:22, Matthew Auld wrote:
On 02/05/2022 09:53, Lionel Landwerlin wrote:
On 02/05/2022 10:54, Lionel Landwerlin wrote:
On 20/04/2022 20:13, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem
On 02/05/2022 09:53, Lionel Landwerlin wrote:
On 02/05/2022 10:54, Lionel Landwerlin wrote:
On 20/04/2022 20:13, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture inter
== Series Details ==
Series: drm/i915: Fix assert in i915_ggtt_pin (rev2)
URL : https://patchwork.freedesktop.org/series/103339/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11592 -> Patchwork_103339v2
Summary
---
*
On 20/04/2022 10:57, Karol Herbst wrote:
i915_vma_reopen checked if the vma is closed before without taking the
lock. So multiple threads could attempt removing the vma.
Instead the lock needs to be taken before actually checking.
v2: move struct declaration
Fix looks correct to me. In whic
1 - 100 of 134 matches
Mail list logo
