History log of /openbmc/linux/drivers/gpu/drm/i915/display/intel_display.c (Results 76 – 100 of 1521)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 0f752b21 23-Mar-2023 Imre Deak <imre.deak@intel.com>

drm/i915: Remove the encoder update_prepare()/complete() hooks

The encoder update_prepare()/complete() hooks were added to hold a
TC port link reference for all outputs in the atomic state around th

drm/i915: Remove the encoder update_prepare()/complete() hooks

The encoder update_prepare()/complete() hooks were added to hold a
TC port link reference for all outputs in the atomic state around the
whole modeset enable sequence - thus locking the ports' TC mode - and
set the TBT/DP-alt PLL type corresponding to the current TC mode.

Since nothing depends on the PLL selection before/after then encoder's
pre_pll_enable/post_pll_disable hooks are called, the above steps can be
moved to these hooks, so do that and remove the
update_prepare()/complete() hooks.

Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230323142035.1432621-30-imre.deak@intel.com

show more ...


# b108bdd0 23-Mar-2023 Imre Deak <imre.deak@intel.com>

drm/i915: Disable DPLLs before disconnecting the TC PHY

Bspec requires disabling the DPLLs on TC ports before disconnecting the
port's PHY. Add a post_pll_disable encoder hook and move the call to
d

drm/i915: Disable DPLLs before disconnecting the TC PHY

Bspec requires disabling the DPLLs on TC ports before disconnecting the
port's PHY. Add a post_pll_disable encoder hook and move the call to
disconnect the port's PHY from the post_disable hook to the new hook.

Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230323142035.1432621-28-imre.deak@intel.com

show more ...


# 3acac2d0 23-Mar-2023 Imre Deak <imre.deak@intel.com>

drm/i915: Move shared DPLL disabling into CRTC disable hook

The spec requires disabling the PLL on TC ports before disconnecting the
port's PHY. Prepare for that by moving the PLL disabling to the C

drm/i915: Move shared DPLL disabling into CRTC disable hook

The spec requires disabling the PLL on TC ports before disconnecting the
port's PHY. Prepare for that by moving the PLL disabling to the CRTC
disable hook, while disconnecting the PHY will be moved to the
post_pll_disable() encoder hook in the next patch.

v2: Move the call from intel_crtc_disable_noatomic() as well.

Reviewed-by: Mika Kahola <mika.kahola@intel.com> # v1
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230323142035.1432621-27-imre.deak@intel.com

show more ...


# a2b6e99d 20-Mar-2023 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Disable DC states for all commits

Keeping DC states enabled is incompatible with the _noarm()/_arm()
split we use for writing pipe/plane registers. When DC5 and PSR
are enabled, all pipe/p

drm/i915: Disable DC states for all commits

Keeping DC states enabled is incompatible with the _noarm()/_arm()
split we use for writing pipe/plane registers. When DC5 and PSR
are enabled, all pipe/plane registers effectively become self-arming
on account of DC5 exit arming the update, and PSR exit latching it.

What probably saves us most of the time is that (with PIPE_MISC[21]=0)
all pipe register writes themselves trigger PSR exit, and then
we don't re-enter PSR until the idle frame count has elapsed.
So it may be that the PSR exit happens already before we've
updated the state too much.

Also the PSR1 panel (at least on this KBL) seems to discard the first
frame we trasmit, presumably still scanning out from its internal
framebuffer at that point. So only the second frame we transmit is
actually visible. But I suppose that could also be panel specific
behaviour. I haven't checked out how other PSR panels behave, nor
did I bother to check what the eDP spec has to say about this.

And since this really is all about DC states, let's switch from
the MODESET domain to the DC_OFF domain. Functionally they are
100% identical. We should probably remove the MODESET domain...

And for good measure let's toss in an assert to the place where
we do the _noarm() register writes to make sure DC states are
in fact off.

v2: Just use intel_display_power_is_enabled() (Imre)

Cc: <stable@vger.kernel.org> #v5.17+
Cc: Manasi Navare <navaremanasi@google.com>
Cc: Drew Davenport <ddavenport@chromium.org>
Cc: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Fixes: d13dde449580 ("drm/i915: Split pipe+output CSC programming to noarm+arm pair")
Fixes: f8a005eb8972 ("drm/i915: Optimize icl+ universal plane programming")
Fixes: 890b6ec4a522 ("drm/i915: Split skl+ plane update into noarm+arm pair")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230320183532.17727-1-ville.syrjala@linux.intel.com
(cherry picked from commit 41b4c7fe72b6105a4b49395eea9aa40cef94288d)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

show more ...


# c880f855 20-Mar-2023 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Add a .color_post_update() hook

We're going to need stuff after the color management
register latching has happened. Add a corresponding hook.

Cc: <stable@vger.kernel.org> #v5.19+
Cc: Man

drm/i915: Add a .color_post_update() hook

We're going to need stuff after the color management
register latching has happened. Add a corresponding hook.

Cc: <stable@vger.kernel.org> #v5.19+
Cc: Manasi Navare <navaremanasi@google.com>
Cc: Drew Davenport <ddavenport@chromium.org>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230320095438.17328-4-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
(cherry picked from commit 3962ca4e080a525fc9eae87aa6b2286f1fae351d)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

show more ...


# c5de2484 20-Mar-2023 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915/dpt: Add a modparam to disable DPT via the chicken bit

Add i915.enable_dpt modparam to allow disabling the DPT
usage in hardware via the chicken bit. Useful when debugging
potential DPT iss

drm/i915/dpt: Add a modparam to disable DPT via the chicken bit

Add i915.enable_dpt modparam to allow disabling the DPT
usage in hardware via the chicken bit. Useful when debugging
potential DPT issues.

Quickly smoke tested on ADL.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230320090522.9909-6-ville.syrjala@linux.intel.com
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>

show more ...


# 41b4c7fe 20-Mar-2023 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Disable DC states for all commits

Keeping DC states enabled is incompatible with the _noarm()/_arm()
split we use for writing pipe/plane registers. When DC5 and PSR
are enabled, all pipe/p

drm/i915: Disable DC states for all commits

Keeping DC states enabled is incompatible with the _noarm()/_arm()
split we use for writing pipe/plane registers. When DC5 and PSR
are enabled, all pipe/plane registers effectively become self-arming
on account of DC5 exit arming the update, and PSR exit latching it.

What probably saves us most of the time is that (with PIPE_MISC[21]=0)
all pipe register writes themselves trigger PSR exit, and then
we don't re-enter PSR until the idle frame count has elapsed.
So it may be that the PSR exit happens already before we've
updated the state too much.

Also the PSR1 panel (at least on this KBL) seems to discard the first
frame we trasmit, presumably still scanning out from its internal
framebuffer at that point. So only the second frame we transmit is
actually visible. But I suppose that could also be panel specific
behaviour. I haven't checked out how other PSR panels behave, nor
did I bother to check what the eDP spec has to say about this.

And since this really is all about DC states, let's switch from
the MODESET domain to the DC_OFF domain. Functionally they are
100% identical. We should probably remove the MODESET domain...

And for good measure let's toss in an assert to the place where
we do the _noarm() register writes to make sure DC states are
in fact off.

v2: Just use intel_display_power_is_enabled() (Imre)

Cc: <stable@vger.kernel.org> #v5.17+
Cc: Manasi Navare <navaremanasi@google.com>
Cc: Drew Davenport <ddavenport@chromium.org>
Cc: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Fixes: d13dde449580 ("drm/i915: Split pipe+output CSC programming to noarm+arm pair")
Fixes: f8a005eb8972 ("drm/i915: Optimize icl+ universal plane programming")
Fixes: 890b6ec4a522 ("drm/i915: Split skl+ plane update into noarm+arm pair")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230320183532.17727-1-ville.syrjala@linux.intel.com

show more ...


# 3962ca4e 20-Mar-2023 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Add a .color_post_update() hook

We're going to need stuff after the color management
register latching has happened. Add a corresponding hook.

Cc: <stable@vger.kernel.org> #v5.19+
Cc: Man

drm/i915: Add a .color_post_update() hook

We're going to need stuff after the color management
register latching has happened. Add a corresponding hook.

Cc: <stable@vger.kernel.org> #v5.19+
Cc: Manasi Navare <navaremanasi@google.com>
Cc: Drew Davenport <ddavenport@chromium.org>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230320095438.17328-4-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>

show more ...


# 3a84f2c6 23-Feb-2023 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Preserve crtc_state->inherited during state clearing

intel_crtc_prepare_cleared_state() is unintentionally losing
the "inherited" flag. This will happen if intel_initial_commit()
is forced

drm/i915: Preserve crtc_state->inherited during state clearing

intel_crtc_prepare_cleared_state() is unintentionally losing
the "inherited" flag. This will happen if intel_initial_commit()
is forced to go through the full modeset calculations for
whatever reason.

Afterwards the first real commit from userspace will not get
forced to the full modeset path, and thus eg. audio state may
not get recomputed properly. So if the monitor was already
enabled during boot audio will not work until userspace itself
does an explicit full modeset.

Cc: stable@vger.kernel.org
Tested-by: Lee Shawn C <shawn.c.lee@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230223152048.20878-1-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
(cherry picked from commit 2553bacaf953b48c59357f5a622282bc0c45adae)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

show more ...


# 84f4ebe8 10-Mar-2023 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Relocate intel_crtc_update_active_timings()

Move intel_crtc_update_active_timings() into intel_vblank.c
where it more properly belongs.

Also do the s/dev_priv/i915/ modernization rename w

drm/i915: Relocate intel_crtc_update_active_timings()

Move intel_crtc_update_active_timings() into intel_vblank.c
where it more properly belongs.

Also do the s/dev_priv/i915/ modernization rename while at it.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230310235828.17439-3-ville.syrjala@linux.intel.com

show more ...


# 6e8acb66 10-Mar-2023 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Add belts and suspenders locking for seamless M/N changes

Add some (probably overkill) locking to protect the vblank
timestamping constants updates during seamless M/N fastsets.

As everyt

drm/i915: Add belts and suspenders locking for seamless M/N changes

Add some (probably overkill) locking to protect the vblank
timestamping constants updates during seamless M/N fastsets.

As everything should be naturally aligned I think the individual
pieces should probably end up updating atomically enough. So this
is only really meant to guarantee everyone sees a consistent whole.

All the drm_vblank.c usage is covered by vblank_time_lock,
and uncore.lock will take care of __intel_get_crtc_scanline()
that can also be called from outside the core vblank functionality.

Currently only crtc_clock and framedur_ns can change, but in
the future might fastset also across eg. vtotal/vblank_end
changes, so let's just grab the locks across the whole thing.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230310235828.17439-2-ville.syrjala@linux.intel.com

show more ...


# 0ec2a5b2 14-Mar-2023 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Relocate intel_plane_check_src_coordinates()

Move intel_plane_check_src_coordinates() from the pre-skl sprite
plane specific code to a more suitable place for common plane code.

Signed-of

drm/i915: Relocate intel_plane_check_src_coordinates()

Move intel_plane_check_src_coordinates() from the pre-skl sprite
plane specific code to a more suitable place for common plane code.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230314130255.23273-9-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

show more ...


# c931ef00 14-Mar-2023 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Program VLV/CHV PIPE_MSA_MISC register

VLV/CHV have an extra register to configure some stereo3d
signalling details via DP MSA. Make sure we reset that
register to zero (since we don't do

drm/i915: Program VLV/CHV PIPE_MSA_MISC register

VLV/CHV have an extra register to configure some stereo3d
signalling details via DP MSA. Make sure we reset that
register to zero (since we don't do any stereo3d stuff).

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230314130255.23273-5-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

show more ...


# c640f6c5 14-Mar-2023 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: s/PIPEMISC/PIPE_MISC/

This PIPEMISC vs. PIPE_MISC inconsitency is ugly. Unify
the naming (PIPE_MISC is also what bspec has always called it).

Signed-off-by: Ville Syrjälä <ville.syrjala@l

drm/i915: s/PIPEMISC/PIPE_MISC/

This PIPEMISC vs. PIPE_MISC inconsitency is ugly. Unify
the naming (PIPE_MISC is also what bspec has always called it).

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230314130255.23273-3-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

show more ...


# 673515ba 08-Mar-2023 Imre Deak <imre.deak@intel.com>

drm/i915/opregion: Register display debugfs later, after initialization steps

Move the display debugfs registration later, after initializing steps
for opregion/acpi/audio. These latter ones don't d

drm/i915/opregion: Register display debugfs later, after initialization steps

Move the display debugfs registration later, after initializing steps
for opregion/acpi/audio. These latter ones don't depend on the debugfs
entries, OTOH some debugfs entries may depend on the initialized state.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230308162503.3219200-3-imre.deak@intel.com

show more ...


# 2553baca 23-Feb-2023 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Preserve crtc_state->inherited during state clearing

intel_crtc_prepare_cleared_state() is unintentionally losing
the "inherited" flag. This will happen if intel_initial_commit()
is forced

drm/i915: Preserve crtc_state->inherited during state clearing

intel_crtc_prepare_cleared_state() is unintentionally losing
the "inherited" flag. This will happen if intel_initial_commit()
is forced to go through the full modeset calculations for
whatever reason.

Afterwards the first real commit from userspace will not get
forced to the full modeset path, and thus eg. audio state may
not get recomputed properly. So if the monitor was already
enabled during boot audio will not work until userspace itself
does an explicit full modeset.

Cc: stable@vger.kernel.org
Tested-by: Lee Shawn C <shawn.c.lee@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230223152048.20878-1-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>

show more ...


# c3f05948 01-Mar-2023 Jani Nikula <jani.nikula@intel.com>

drm/i915/display: split out DSC and DSS registers

Relatively few places need the DSC and DSS register definitions. Move
them to intel_vdsc_regs.h.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: split out DSC and DSS registers

Relatively few places need the DSC and DSS register definitions. Move
them to intel_vdsc_regs.h.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230301151949.1591501-1-jani.nikula@intel.com

show more ...


# 9548fefc 13-Feb-2023 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Remove pointless register read

We just wrote the EDP transcoder's VTOTAL register a few lines
earlier, so instead of reading it back out again let's just
generate the same value for the tr

drm/i915: Remove pointless register read

We just wrote the EDP transcoder's VTOTAL register a few lines
earlier, so instead of reading it back out again let's just
generate the same value for the transocder B/C register.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230213225258.2127-13-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

show more ...


# 1552dd6e 13-Feb-2023 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Sprinkle some FIXMEs about TGL+ DSI transcoder timing mess

The DSI code has some local hacks to program TRANS_VBLANK on
TGL+ (ICL DSI transcoders didn't have this register). That
will not

drm/i915: Sprinkle some FIXMEs about TGL+ DSI transcoder timing mess

The DSI code has some local hacks to program TRANS_VBLANK on
TGL+ (ICL DSI transcoders didn't have this register). That
will not work when we need to start using the delayed vblank
(for DSB purposes). Too lazy to figure out what the is going
on there, so just sprinkle FIXMEs in the hopes someone else
will spot them eventually.

v2: Only TRANS_{HBLANK,SET_CONTEXT_LATENCY} still no not
exist for DSI transcoders, only TRANS_VBLANK

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230213225258.2127-12-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>

show more ...


# 2846cf3f 13-Feb-2023 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Configure TRANS_SET_CONTEXT_LATENCY correctly on ADL+

On TGL VBLANK.VBLANK_START was the mechanism by which we can
delay the pipe's internal vblank in relation to the transcoder's
vblank.

drm/i915: Configure TRANS_SET_CONTEXT_LATENCY correctly on ADL+

On TGL VBLANK.VBLANK_START was the mechanism by which we can
delay the pipe's internal vblank in relation to the transcoder's
vblank. On ADL+ that no longer does anything. Instead we must
now use the new TRANS_SET_CONTEXT_LATENCY register. Program it
accordingly.

And since VBLANK.VBLANK_START is no longer used by the hardware
on ADL+ let's just zero it out to make it stand out in register
dumps. Seeing the zeroed value should hopefully remind people
to check the other register instead.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230213225258.2127-11-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>

show more ...


# 050db7d7 13-Feb-2023 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Define transcoder timing register bitmasks

Define the contents of the transcoder timing registers using
REG_GENMASK() & co. For ease of maintenance let's just define
the bitmasks with the

drm/i915: Define transcoder timing register bitmasks

Define the contents of the transcoder timing registers using
REG_GENMASK() & co. For ease of maintenance let's just define
the bitmasks with the full 16bit width (also used by the
current hand rolled stuff) even though not all bits are actually
used. None of the unsued bits have ever contained anything.

Jani spotted that the CRT load detection code did use narrower
bitmasks, so that is now going to change. But that is fine
since any garbage in the high bits would have been caught by
the state checker that always used the full 16bit masks.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230213225258.2127-10-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

show more ...


# 9c0cd4bb 13-Feb-2023 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Add local adjusted_mode variable

Clean up the eyesore in intel_get_transcoder_timings() a
bit by adding a local 'adjusted_mode' variable.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux

drm/i915: Add local adjusted_mode variable

Clean up the eyesore in intel_get_transcoder_timings() a
bit by adding a local 'adjusted_mode' variable.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230213225258.2127-9-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

show more ...


# 3eb08ea5 13-Feb-2023 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: s/PIPECONF/TRANSCONF/

Rename PIPECONF to TRANSCONF to make it clear what it actually
applies to.

While the usual convention is to pick the earliers name I think
in this case it's more cle

drm/i915: s/PIPECONF/TRANSCONF/

Rename PIPECONF to TRANSCONF to make it clear what it actually
applies to.

While the usual convention is to pick the earliers name I think
in this case it's more clear to use the later name. Especially
as even the register offset is in the wrong range (0x70000 vs.
0x60000) and thus makes it look like this is per-pipe.

There is one place in gvt that's doing something with TRANSCONF
while iterating with for_each_pipe(). So that might not be doing
the right thing for TRANSCODER_EDP, dunno. Not knowing what it
does I left it as is to avoid breakage.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230213225258.2127-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

show more ...


# 5ac421a9 13-Feb-2023 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Give CPU transcoder timing registers TRANS_ prefix

Name the CPU transcoder timing registers TRANS_FOO rather than
just FOO. This is the modern name, after the pipe/transcoder split
happene

drm/i915: Give CPU transcoder timing registers TRANS_ prefix

Name the CPU transcoder timing registers TRANS_FOO rather than
just FOO. This is the modern name, after the pipe/transcoder split
happened. Makes it a bit more obvious whether you pass in a pipe or
a transcoder.

PIPESRC is a bit special as it's a pipe register, even though it
lives in the transcoder registers range (0x60000 instead of 0x70000).

And BCLRPAT I suppose is a transcoder register (since it has something
to do with the timing generator), but it doesn't even exist after gen4
so I left it to use the only name it ever had in bspec.

And while at it let's pass in the correct enum in few more
places why don't we. Although in all those places the distinction
doesn't matter.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230213225258.2127-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

show more ...


# 46b3c0f6 15-Feb-2023 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Reduce ELD hex dumps a bit

Do the ELD hexdumps only up to the last differing byte.
The rest is typically all zeroes anyway so not much point
in dumping it.

Couldn't find anything for memc

drm/i915: Reduce ELD hex dumps a bit

Do the ELD hexdumps only up to the last differing byte.
The rest is typically all zeroes anyway so not much point
in dumping it.

Couldn't find anything for memcmp_diff_len() so
rolled my own.

v2: Use semantics and function name suggested by Jani

Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230215150129.13288-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

show more ...


12345678910>>...61