== Series Details ==
Series: drm/i915/bios: Define (almost) all BDB blocks
URL : https://patchwork.freedesktop.org/series/133169/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14706_full -> Patchwork_133169v1_full
Summary
On Tue, 30 Apr 2024 17:38:09 + Easwar Hariharan wrote:
> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
> with more appropriate terms. Inspired by and following on to Wolfram's
> series to fix drivers/i2c/[1], fix the terminology for users of
> I2C_ALGOBIT
On Fri, May 03, 2024 at 02:04:15PM -0700, Easwar Hariharan wrote:
> On 5/3/2024 12:34 PM, Rodrigo Vivi wrote:
> > On Fri, May 03, 2024 at 06:13:24PM +, Easwar Hariharan wrote:
> >> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced
> >> "master/slave"
> >> with more appropriate
On 5/3/2024 12:34 PM, Rodrigo Vivi wrote:
> On Fri, May 03, 2024 at 06:13:24PM +, Easwar Hariharan wrote:
>> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
>> with more appropriate terms. Inspired by and following on to Wolfram's
>> series to fix drivers/i2c/[1],
On Fri, May 03, 2024 at 06:13:24PM +, Easwar Hariharan wrote:
> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
> with more appropriate terms. Inspired by and following on to Wolfram's
> series to fix drivers/i2c/[1], fix the terminology for users of
> I2C_ALGOBIT
== Series Details ==
Series: Make I2C terminology more inclusive for I2C Algobit and consumers (rev3)
URL : https://patchwork.freedesktop.org/series/131867/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/131867/revisions/3/mbox/ not
applied
Em Fri, 29 Mar 2024 17:00:28 +
Easwar Hariharan escreveu:
> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
> with more appropriate terms. Inspired by and following on to Wolfram's
> series to fix drivers/i2c/[1], fix the terminology for users of
> I2C_ALGOBIT
On Tue, Apr 30, 2024 at 10:28:48AM GMT, Radhakrishna Sripada wrote:
From: Nirmoy Das
Display surfaces can be tagged as transient by mapping it using one of
the various L3:XD PAT index modes on Xe2. The expectation is that KMD
needs to request transient data flush at the start of flip sequence
On Tue, Apr 30, 2024 at 10:28:47AM GMT, Radhakrishna Sripada wrote:
From: Matthew Auld
Needed in an upcoming patch, where we want GT level print, but only
which to trigger once to avoid flooding dmesg.
Signed-off-by: Matthew Auld
Signed-off-by: Balasubramani Vivekanandan
Reviewed-by: Nirmoy
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the
age exists
in the specification.
Compile tested, no functionality changes intended
Please chime in with your opinions and suggestions.
This series is based on 3d25a941ea50 ("Merge tag 'block-6.9-20240503' of
git://git.kernel.dk/linux")
[1]:
https://lore.kernel.org/all/20240322132619.638
On 5/3/2024 12:39 AM, Thomas Zimmermann wrote:
> Hi
>
> Am 03.05.24 um 00:26 schrieb Easwar Hariharan:
>> On 5/2/2024 3:46 AM, Thomas Zimmermann wrote:
>>>
>>> Am 30.04.24 um 19:38 schrieb Easwar Hariharan:
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced
"master/slave"
== Series Details ==
Series: drm/i915/guc: Fix UB due to signed int overflow (rev2)
URL : https://patchwork.freedesktop.org/series/132446/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14707 -> Patchwork_132446v2
Summary
== Series Details ==
Series: drm/i915/guc: Fix UB due to signed int overflow (rev2)
URL : https://patchwork.freedesktop.org/series/132446/
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: drm/i915/bios: Define (almost) all BDB blocks
URL : https://patchwork.freedesktop.org/series/133169/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14706 -> Patchwork_133169v1
Summary
---
== Series Details ==
Series: drm/i915/bios: Define (almost) all BDB blocks
URL : https://patchwork.freedesktop.org/series/133169/
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: drm/i915/bios: Define (almost) all BDB blocks
URL : https://patchwork.freedesktop.org/series/133169/
State : warning
== Summary ==
Error: dim checkpatch failed
da729809e1d5 drm/i915/bios: Define eDP DSC disable bit
b3bf97c68e98 drm/i915/bios: Remove version number
On 5/3/2024 10:42 AM, Greg KH wrote:
Ok, I'm getting tired of seeing these for the USB portion of the tree,
so I went to look for:
On Fri, May 03, 2024 at 04:44:42AM +0800, kernel test robot wrote:
|-- arc-randconfig-002-20240503
| `-- drivers-usb-dwc3-core.c:warning:variable-hw_mode-set
On Mon, Apr 29, 2024 at 1:39 PM Jim Cromie wrote:
>
> Tell the compiler about our vectors (array,length), in 2 places:
>
these are not flex-arrays, using counted-by is wrong here.
Ive dropped this commit, series rebases clean wo it.
> h: struct _ddebug_info, which keeps refs to the
Fix compile errors of the form "FIELD_PREP: mask is not constant" caused
by signed integer constant overflow. Files affected:
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
Reproducible with gcc 7.5
See https://lore.kernel.org/r/ykwq6%2btih8gqp...@zn.tnic for the gory
details as to why it
> On Jul 24, 2023, at 2:14 PM, Michał Winiarski
> wrote:
>
> 64 DRM device nodes is not enough for everyone.
> Upgrade it to ~512K (which definitely is more than enough).
>
> To allow testing userspace support for >64 devices, add additional DRM
> modparam (force_extended_minors) which
test robot wrote:
|-- arc-randconfig-002-20240503
| `-- drivers-usb-dwc3-core.c:warning:variable-hw_mode-set-but-not-used
This warning (same for all arches), but can't seem to find it anywhere.
Any hints as to where it would be?
Hi Greg,
I think the hw_mode was not removed
From: Ville Syrjälä
Define the contents of VBT block 253 (PRD Table).
Unfortunately the block has two definitions, with the cutoff
supposedly happening on ICL vs. TGL. Also according to some
notes it might be that the VBIOS (if that's still a thing)
still uses the old definition even on TGL+.
From: Ville Syrjälä
Declare that VBT block 252 is the "int15 hook". This is some
VBIOS only juju so don't bother with a full definition.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 1 +
1 file changed, 1 insertion(+)
diff --git
From: Ville Syrjälä
Define the contents of the obsolete VBT block 55 (Compression
Parameters).
This was some early attempt at defining the compression
parameters. However the spec says:
"This block is obsolete and should not be consumed for any
compression programming."
Block 56 is the
From: Ville Syrjälä
Define the contents of VBT block 50 (MIPI).
This was some easly attempt at a MIPI DSI stuff. I'm not sure
this was ever actually used (I certainly don't have any VBTs
with this block), but here's some kind of definition for it
anyway.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Define the contents of VBT block 57 (Vswing PreEmphasis Table).
The contents is highly platform specific. The columns of the
table corresponding to some set of PHY/etc registers. The rows
corresponding to all legal vswing+pre-emphasis combinations
(ie. should be 10 rows in
From: Ville Syrjälä
Define the contents of VBT block 55 (RGB Palette Table).
Note that I've not actually seen any real world VBTs with this
block.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 12
1 file changed, 12 insertions(+)
diff --git
From: Ville Syrjälä
Define the contents of VBT block 51 (Fixed Set Mode Table).
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
From: Ville Syrjälä
Define the contents of VBT block 46 (Chromaticity For Narrow Gamut
Panel). One entry per panel.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 26 +++
1 file changed, 26 insertions(+)
diff --git
From: Ville Syrjälä
Define the contents of VBT block 45 (eDP BFI).
Note that I've not actually seen any real world VBTs with this
block.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 17 +
1 file changed, 17 insertions(+)
diff --git
From: Ville Syrjälä
Define the contents of VBT block 28 (EFP DTD).
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
From: Ville Syrjälä
Define the contents of VBT block 26 (TV Options).
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
From: Ville Syrjälä
Define the contents of VBT block 25 (SDVO LVDS PPS).
Not 100% sure about the order of the fields as this is not
documented in the VBT spec anymore, but this order matches
what is included as part of the power sequencing SDVO commands
(struct sdvo_panel_power_sequencing).
From: Ville Syrjälä
Define the contents of VBT block 24 (SDVO LVDS PnP ID).
The descriotion is not part of the VBT spec anymore, but the layout
is rather obsvious.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 8
1 file changed, 8 insertions(+)
From: Ville Syrjälä
Define the contents of VBT block 21 (EFP List). Specs are nowhere
to be found, but real world data suggests that each entry is just
the first four bytes of the EDID PnP ID structure.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 15
From: Ville Syrjälä
Define the contents of VBT block 20 (OEM Customizable Modes).
Each entry is either 26 or 28 bytes, depending on the BDB version.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 24 +++
1 file changed, 24 insertions(+)
diff
From: Ville Syrjälä
Define the contenst is VBT blocks 19,30,32 (Display Configuration
Removal Table) contents. There are three variants of this block:
pre-IVB, IVB, HSW+, with each having slightly different entries.
Curiously many HSW/BDW machines seem to have both the IVB and HSW+
variants in
From: Ville Syrjälä
Define the contenst is VBT blocks 16,19,31 (Toggle List).
There are three variants of this block: pre-IVB, IVB, HSW+,
with each having slightly different entries.
Curiously many HSW/BDW machines seem to have both the IVB and
HSW+ variants in their VBTs simultanously. No idea
From: Ville Syrjälä
For some reason ALM VBT has two dot clock override tables.
One as the normal block 15 and a second one as block 9.
The table in block 9 has no row_size/num_rows information.
On my Fujitsu Lifebook S6010 only the block 9 table has actual
data in it. Block 15 is present but
From: Ville Syrjälä
Define the contents of block 18 (Driver Rotation).
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
From: Ville Syrjälä
Define the contents of VBT block 17 (SV Test Functions).
Nothing real here for us, but might as well define it for
completeness.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 9 +
1 file changed, 9 insertions(+)
diff --git
From: Ville Syrjälä
Define the contents of VBT block 15 (Dot Clock Override Table)
The contents were reverse engineered by intuition. The gen2 stuff
seems solid as I can verify that against real world VBT data. The
gen3 stuff less so as all the gen3+ VBTs I have just filla the
entire block with
From: Ville Syrjälä
Define the contents of VBT block 12 (Driver Persistent Algorithm).
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
From: Ville Syrjälä
Define the contents of VBT block 10 (Mode Removal Table).
There seem to be two variants:
- 8 byte entries for desktop systems
- 10 byte entries for mobile systems, with the extra
panel_flags being a bitmask of LFPs
It seems starting from HSW only the mobile variant is
From: Ville Syrjälä
Define the contents for VBT blocks:
- Block 6 (Extended MMIO Register Table)
- Block 7 (IO Software Flag Table)
- Block 8 (MMIO SWF Register Table)
All of these use the same basic layout, with two known variants:
- data_access_size==0xce -> offset,value tuples are u8,u8
-
From: Ville Syrjälä
Define the contents of VBT block 5 (Generic Mode Table).
Details were mostly gleaned from some VBIOS sources.
There are apparently two variants of the block: ALM only
vs. MGM, defined here as bdb_generic_mode_table_alm
and bdb_generic_mode_table_mgm. And those are the only
From: Ville Syrjälä
Define the contents of VBT block 4 (Mode Support List).
Slightly crazy layout with a variable length list at the start,
followed by the length of said list.
No real idea what these "Intel mode numbers" really are. What
I see in real world VBTs seems to be always the same
From: Ville Syrjälä
Define the contents of VBT block 3 (Display Toggle Option).
On modern VBTs this is just a single byte, but on ALM there is
also some extra to do with toggle lists or something.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 12
From: Ville Syrjälä
Document which VBT blocks were defined in which BDB version,
for the cases where the spec actually states this accurately.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff
From: Ville Syrjälä
Several data blocks are mean to be consumbed by VBIOS only.
Flag them as such.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git
From: Ville Syrjälä
Child device 0x2 used to be "TV" until redefined to mean
EFP5 in version 215. Add a define for the old meaning as well.
Technically it was probably deprecated a lot before version
215 since native TV encoders were last seen on CTG, and SDVO
was fully gone by HSW. So
From: Ville Syrjälä
The SDVO LVDS blocks are specifically about LVDS, so stick
to naming that reflects that. This also makes the names match
the spec.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 23 +--
From: Ville Syrjälä
The LFP data applies to all kinds of display interfaces, so
stop calling things by the "LVDS" name.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 178 +-
.../drm/i915/display/intel_display_types.h| 2 +-
From: Ville Syrjälä
VBT reuses a bunch of EDID data structures. Flag those as such
for clarity.
I chose "bdb_edid_" as the namespace for these.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 28 +++---
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 95
From: Ville Syrjälä
DEVICE_HANDLE_EFP4 has actually been in use since the very beginning,
or at least something has been occupying that bit because old
VBTs actually use it, and it definitely looks to be about external
displays given how its used. So let's ignore what the current spec
claims and
From: Ville Syrjälä
There's a new "DSC disable" bit in the eDP VBT block. Define it.
TODO: actually use it?
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
From: Ville Syrjälä
I got curious about what gems (or turds) might be hiding
inside the BDB blocks we aren't parsing. So I undertook the
effort to dig up the definition for pretty much all of them.
Unfortunately I didn't find anything really interesting, but
might as well stick the definitions
On Fri, May 03, 2024 at 12:36:14PM +0200, Peter Zijlstra wrote:
> On Fri, May 03, 2024 at 11:37:25AM +0200, Christian Brauner wrote:
> > On Thu, May 02, 2024 at 05:41:23PM -0700, Kees Cook wrote:
> > > On Fri, May 03, 2024 at 01:14:45AM +0100, Al Viro wrote:
> > > > On Thu, May 02, 2024 at
On Thu, May 02, 2024 at 04:17:16PM +0300, Mika Kahola wrote:
> With HDMI monitors we bumped up a case where the crtc clock rate
> caused a mismatch on state verification. This was due to
> assumption that the SW clock rate from PLL structure would match
> the calculated counterpart from HW. This
On Fri, May 03, 2024 at 11:37:25AM +0200, Christian Brauner wrote:
> On Thu, May 02, 2024 at 05:41:23PM -0700, Kees Cook wrote:
> > On Fri, May 03, 2024 at 01:14:45AM +0100, Al Viro wrote:
> > > On Thu, May 02, 2024 at 05:10:18PM -0700, Kees Cook wrote:
> > >
> > > > But anyway, there needs to be
On Thu, 2024-04-25 at 00:08 +0530, Animesh Manna wrote:
> Link Off Between Active Frames (LOBF) allows an eDP link to be turned
> Off and On
> durning long VBLANK durations without enabling any of the PSR/PSR2/PR
> modes of operation.
You could describe a bit more about what this patch set is
On Fri, 2024-05-03 at 08:42 +, Manna, Animesh wrote:
>
>
> > -Original Message-
> > From: Hogander, Jouni
> > Sent: Friday, May 3, 2024 12:49 PM
> > To: Manna, Animesh ; intel-
> > g...@lists.freedesktop.org
> > Cc: dri-de...@lists.freedesktop.org; Murthy, Arun R
> > ; Nikula, Jani
On Fri, 2024-05-03 at 08:30 +, Manna, Animesh wrote:
>
>
> > -Original Message-
> > From: Hogander, Jouni
> > Sent: Friday, May 3, 2024 1:02 PM
> > To: Manna, Animesh ; intel-
> > g...@lists.freedesktop.org
> > Cc: dri-de...@lists.freedesktop.org; Murthy, Arun R
> > ; Nikula, Jani
On Thu, May 02, 2024 at 05:41:23PM -0700, Kees Cook wrote:
> On Fri, May 03, 2024 at 01:14:45AM +0100, Al Viro wrote:
> > On Thu, May 02, 2024 at 05:10:18PM -0700, Kees Cook wrote:
> >
> > > But anyway, there needs to be a general "oops I hit 0"-aware form of
> > > get_file(), and it seems like
On Fri, 2024-05-03 at 08:19 +, Manna, Animesh wrote:
>
>
> > -Original Message-
> > From: Hogander, Jouni
> > Sent: Friday, May 3, 2024 1:18 PM
> > To: Manna, Animesh ; intel-
> > g...@lists.freedesktop.org
> > Cc: dri-de...@lists.freedesktop.org; Murthy, Arun R
> > ; Nikula, Jani
On Thu, May 02, 2024 at 04:03:24PM -0700, Kees Cook wrote:
> On Fri, May 03, 2024 at 12:53:56AM +0200, Jann Horn wrote:
> > On Fri, May 3, 2024 at 12:34 AM Kees Cook wrote:
> > > If f_count reaches 0, calling get_file() should be a failure. Adjust to
> > > use atomic_long_inc_not_zero() and
> -Original Message-
> From: Hogander, Jouni
> Sent: Friday, May 3, 2024 12:49 PM
> To: Manna, Animesh ; intel-
> g...@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; Murthy, Arun R
> ; Nikula, Jani
> Subject: Re: [PATCH v3 4/6] drm/i915/alpm: Add compute config for lobf
>
> -Original Message-
> From: Hogander, Jouni
> Sent: Friday, May 3, 2024 1:02 PM
> To: Manna, Animesh ; intel-
> g...@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; Murthy, Arun R
> ; Nikula, Jani
> Subject: Re: [PATCH v3 6/6] drm/i915/alpm: Add debugfs for LOBF
>
> On
> -Original Message-
> From: Hogander, Jouni
> Sent: Friday, May 3, 2024 1:18 PM
> To: Manna, Animesh ; intel-
> g...@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; Murthy, Arun R
> ; Nikula, Jani
> Subject: Re: [PATCH v3 5/6] drm/i915/alpm: Enable lobf from source in
>
On Thu, 2024-04-25 at 00:08 +0530, Animesh Manna wrote:
> Set the Link Off Between Frames Enable bit in ALPM_CTL register.
>
> Note: Lobf need to be enabled adaptive sync fixed refresh mode
> where vmin = vmax = flipline, which will arise after cmmr feature
> enablement. Will add enabling
Hi
Am 03.05.24 um 00:26 schrieb Easwar Hariharan:
On 5/2/2024 3:46 AM, Thomas Zimmermann wrote:
Am 30.04.24 um 19:38 schrieb Easwar Hariharan:
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
On Thu, 2024-04-25 at 00:08 +0530, Animesh Manna wrote:
> For validation purpose add debugfs for LOBF.
>
> Signed-off-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/display/intel_alpm.c | 48
> +++
> drivers/gpu/drm/i915/display/intel_alpm.h | 2 +
>
On Tue, 30 Apr 2024 17:38:02 +
Easwar Hariharan wrote:
> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced
> "master/slave" with more appropriate terms. Inspired by and following
> on to Wolfram's series to fix drivers/i2c/[1], fix the terminology
> for users of I2C_ALGOBIT
== Series Details ==
Series: Panel replay selective update support (rev10)
URL : https://patchwork.freedesktop.org/series/128193/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14701 -> Patchwork_128193v10
Summary
---
On Thu, 2024-04-25 at 00:08 +0530, Animesh Manna wrote:
> Link Off Between Active Frames, is a new feature for eDP
> that allows the panel to go to lower power state after
> transmission of data. This is a feature on top of ALPM, AS SDP.
> Add compute config during atomic-check phase.
>
> v1: RFC
== Series Details ==
Series: Panel replay selective update support (rev10)
URL : https://patchwork.freedesktop.org/series/128193/
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: Panel replay selective update support (rev10)
URL : https://patchwork.freedesktop.org/series/128193/
State : warning
== Summary ==
Error: dim checkpatch failed
4015b924c87d drm/i915/psr: Rename has_psr2 as has_sel_update
e080275710d0 drm/i915/display: Do not print
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Tuesday, April 30, 2024 3:27 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH v2 4/5] drm/i915: Eliminate extra frame from skl-glk sync-
> >async flip change
>
> From: Ville Syrjälä
>
> On bdw-glk
== Series Details ==
Series: LunarLake IO and Fast Wake changes
URL : https://patchwork.freedesktop.org/series/133160/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14701 -> Patchwork_133160v1
Summary
---
== Series Details ==
Series: LunarLake IO and Fast Wake changes
URL : https://patchwork.freedesktop.org/series/133160/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bitops.h:116:1:
== Series Details ==
Series: LunarLake IO and Fast Wake changes
URL : https://patchwork.freedesktop.org/series/133160/
State : warning
== Summary ==
Error: dim checkpatch failed
ce27af43583c drm/i915/psr: LunarLake IO and Fast Wake time line count maximums
are 63
b85a97f53836 drm/i915/psr:
Add panel replay selective update support to debugfs status interface. In
case of sink supporting panel replay we will print out:
Sink support: PSR = no, Panel Replay = yes, Panel Replay Selective Update = yes
and PSR mode will look like this if printing out enabled panel replay
selective
Currently intel_dp_get_su_granularity doesn't support panel replay.
This fix modifies it to support panel replay as well.
v4:
- use drm_dp_dpcd_readb instead of drm_dp_dpcd_read
- ensure return value is 0 if drm_dp_dpcd_readb fails
v3: use correct offset for DP_PANEL_PANEL_REPLAY_CAPABILITY
Part of intel_psr2_config_valid is valid for panel replay. rename it as
intel_sel_update_config_valid. Split psr2 specific part and name it as
intel_psr2_config_valid.
v3:
- move early transport check to psr2 specific check
- check intel_psr2_config_valid only for non-Panel Replay case
v2:
We are re-using PSR module parameters for panel replay. Update module
parameter descriptions with panel replay information:
enable_psr:
-1 (default) == follow what is in VBT
0 == disable PSR/PR
1 == Allow PSR1 and PR full frame update
2 == allow PSR1/PSR2 and PR Selective Update
There are some workarounds that are not applicable for panel replay. Do not
apply these if panel replay is used.
Bspec: 66624, 50422
Signed-off-by: Jouni Högander
---
drivers/gpu/drm/i915/display/intel_fbc.c | 5 +++--
drivers/gpu/drm/i915/display/intel_hdmi.c | 3 ++-
DP Panel replay uses SRD_STATUS to track it's status despite selective
update mode.
Bspec: 53370, 68920
v3:
- do not use PSR2_STATUS for PSR1
v2:
- use intel_dp_is_edp to differentiate
- modify debugfs status as well
Signed-off-by: Jouni Högander
---
Add new boolean to store panel replay selective update support of sink into
intel_psr struct. Detect panel replay selective update support and store
it into this new boolean.
v3: Clear sink_panel_replay_su_support in intel_dp_detect
v2: Merge adding new boolean into this patch
Signed-off-by:
1 - 100 of 111 matches
Mail list logo
