On Tue, May 28, 2024 at 02:27:52PM +0300, Imre Deak wrote:
> On Mon, May 13, 2024 at 08:59:37PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Different planes could have different alignment requirements
> > even for the same format/modifier. Collect the
On Tue, May 28, 2024 at 04:22:59PM +0300, Imre Deak wrote:
> On Mon, May 13, 2024 at 08:59:41PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Currently we still use the SKL+ PLANE_SURF alignment even
> > for TGL+ even though the hardware no longer needs i
On Thu, May 23, 2024 at 06:29:21PM +0300, Imre Deak wrote:
> On Thu, May 23, 2024 at 06:08:40PM +0300, Ville Syrjälä wrote:
> > On Mon, May 20, 2024 at 09:58:10PM +0300, Imre Deak wrote:
> > > Simplify things by retraining a DP link if a bad link is detected in the
> > &g
intel_connector *connector)
> {
> struct dentry *root = connector->base.debugfs_entry;
> @@ -1818,4 +1865,7 @@ void intel_dp_link_training_debugfs_add(struct
> intel_connector *connector)
>
> debugfs_create_file("i915_dp_max_lane_count", 0444, root,
> connector, _dp_max_lane_count_fops);
> +
> + debugfs_create_file("i915_dp_force_link_training_failure", 0644, root,
> + connector,
> _dp_force_link_training_failure_fops);
> }
> --
> 2.43.3
--
Ville Syrjälä
Intel
return;
> }
>
> - intel_dp_schedule_fallback_link_training(state, intel_dp, crtc_state);
> + if (intel_dp_schedule_fallback_link_training(state, intel_dp,
> crtc_state))
> + return;
> +
> + intel_dp->link.retrain_disabled = true;
> +
> + if (!passed)
> + lt_err(intel_dp, DP_PHY_DPRX, "Can't reduce link training
> parameters after failure\n");
> + else
> + lt_dbg(intel_dp, DP_PHY_DPRX, "Can't reduce link training
> parameters after forced failure\n");
The forced failure stuff is in later patch, is it not?
> }
>
> void intel_dp_128b132b_sdp_crc16(struct intel_dp *intel_dp,
> --
> 2.43.3
--
Ville Syrjälä
Intel
int lane_count;
> + int ret;
> +
> + lane_count = parse_lane_count(ubuf, len);
> + if (lane_count < 0)
> + return lane_count;
> +
> + ret =
> drm_modeset_lock_single_interruptible(>drm.mode_config.connection_mutex);
> + if (ret)
> + return ret;
> +
> + intel_dp = intel_connector_to_intel_dp(connector);
> +
> + intel_dp_reset_link_params(intel_dp);
> + intel_dp->link.requested_lane_count = lane_count;
> +
> + drm_modeset_unlock(>drm.mode_config.connection_mutex);
> +
> + *offp += len;
> +
> + return len;
> +}
> +DEFINE_SHOW_STORE_ATTRIBUTE(i915_dp_set_lane_count);
> +
> +void intel_dp_link_training_debugfs_add(struct intel_connector *connector)
> +{
> + struct dentry *root = connector->base.debugfs_entry;
> +
> + if (connector->base.connector_type != DRM_MODE_CONNECTOR_DisplayPort &&
> + connector->base.connector_type != DRM_MODE_CONNECTOR_eDP)
> + return;
> +
> + debugfs_create_file("i915_dp_set_link_rate", 0644, root,
> + connector, _dp_set_link_rate_fops);
> +
> + debugfs_create_file("i915_dp_set_lane_count", 0644, root,
> + connector, _dp_set_lane_count_fops);
> +}
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> index f658230960333..42e7fc6cb171a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> @@ -9,6 +9,7 @@
> #include
>
> struct intel_atomic_state;
> +struct intel_connector;
> struct intel_crtc_state;
> struct intel_dp;
>
> @@ -44,4 +45,7 @@ static inline u8 intel_dp_training_pattern_symbol(u8
> pattern)
>
> void intel_dp_128b132b_sdp_crc16(struct intel_dp *intel_dp,
>const struct intel_crtc_state *crtc_state);
> +
> +void intel_dp_link_training_debugfs_add(struct intel_connector *connector);
> +
> #endif /* __INTEL_DP_LINK_TRAINING_H__ */
> --
> 2.43.3
--
Ville Syrjälä
Intel
p_check_link_state(intel_dp);
I would like to see this hack nuked entirely. But that
could be a followup.
>
> /*
> * Clearing NACK and defer counts to get their exact values
> --
> 2.43.3
--
Ville Syrjälä
Intel
On Thu, May 23, 2024 at 05:54:10PM +0300, Ville Syrjälä wrote:
> On Thu, May 23, 2024 at 05:47:36PM +0300, Imre Deak wrote:
> > On Thu, May 23, 2024 at 05:41:17PM +0300, Ville Syrjälä wrote:
> > > On Mon, May 20, 2024 at 09:58:07PM +0300, Imre Deak wrote:
>
On Thu, May 23, 2024 at 05:47:36PM +0300, Imre Deak wrote:
> On Thu, May 23, 2024 at 05:41:17PM +0300, Ville Syrjälä wrote:
> > On Mon, May 20, 2024 at 09:58:07PM +0300, Imre Deak wrote:
> > > From: Imre Deak
> > >
> > > The next patch adds sending a modese
al_levels(struct intel_dp *intel_dp,
> const struct intel_crtc_state *crtc_state,
> enum drm_dp_phy dp_phy);
> -void intel_dp_start_link_train(struct intel_dp *intel_dp,
> +void intel_dp_start_link_train(struct intel_atomic_state *state,
> +struct intel_dp *intel_dp,
> const struct intel_crtc_state *crtc_state);
> void intel_dp_stop_link_train(struct intel_dp *intel_dp,
> const struct intel_crtc_state *crtc_state);
> --
> 2.43.3
--
Ville Syrjälä
Intel
On Thu, May 23, 2024 at 04:46:30PM +0300, Imre Deak wrote:
> On Thu, May 23, 2024 at 04:30:18PM +0300, Ville Syrjälä wrote:
> > On Mon, May 20, 2024 at 09:58:05PM +0300, Imre Deak wrote:
> > > Recheck the link state after a passing link training, with a 2 sec delay
> > >
On Thu, May 23, 2024 at 02:14:56PM +0100, Tvrtko Ursulin wrote:
>
> On 23/05/2024 13:24, Ville Syrjälä wrote:
> > On Thu, May 23, 2024 at 01:07:24PM +0100, Tvrtko Ursulin wrote:
> >>
> >> On 23/05/2024 12:19, Ville Syrjälä wrote:
> >>> On Thu, May 23
lttpr_count);
>
> + if (passed) {
> + intel_ddi_queue_link_check(dig_port, 2000);
> + return;
> + }
> +
> /*
>* Ignore the link failure in CI
>*
> @@ -1495,13 +1502,12 @@ void intel_dp_start_link_train(struct intel_dp
> *intel_dp,
>* For test cases which rely on the link training or processing of HPDs
>* ignore_long_hpd flag can unset from the testcase.
>*/
> - if (!passed && i915->display.hotplug.ignore_long_hpd) {
> + if (i915->display.hotplug.ignore_long_hpd) {
> lt_dbg(intel_dp, DP_PHY_DPRX, "Ignore the link failure\n");
> return;
> }
>
> - if (!passed)
> - intel_dp_schedule_fallback_link_training(intel_dp, crtc_state);
> + intel_dp_schedule_fallback_link_training(intel_dp, crtc_state);
> }
>
> void intel_dp_128b132b_sdp_crc16(struct intel_dp *intel_dp,
> --
> 2.43.3
--
Ville Syrjälä
Intel
On Thu, May 23, 2024 at 04:23:44PM +0300, Ville Syrjälä wrote:
> On Wed, May 22, 2024 at 04:38:54PM +0300, Imre Deak wrote:
> > On Mon, May 20, 2024 at 09:58:05PM +0300, Imre Deak wrote:
> > > [...]
> > > +static void intel_ddi_link_check_work_fn(struct work_struct *wo
; +_port->check_link_work,
> > msecs_to_jiffies(delay_ms));
> > +}
> > +
> > static int intel_hdmi_reset_link(struct intel_encoder *encoder,
> > struct drm_modeset_acquire_ctx *ctx)
> > {
> > @@ -4911,6 +4943,8 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
> >
> > dig_port->aux_ch = AUX_CH_NONE;
> >
> > + intel_ddi_init_link_check_work(dig_port);
> > +
> > encoder = _port->base;
> > encoder->devdata = devdata;
> >
--
Ville Syrjälä
Intel
v_priv, PIPEGCMAX(dev_priv, pipe, 1),
> + lut[i].green);
nit: the newline breaks the pattern in a somewhat ugly way
Series is
Reviewed-by: Ville Syrjälä
> + intel_de_write_fw(dev_priv, PIPEGCMAX(dev_priv, pipe, 2), lut[i].blue);
> }
>
> static void i965
crtc_state, INTEL_OUTPUT_DP_MST)) {
> + mst_output = true;
> + break;
> + }
I was pondering if we need a bit more care to make sure all
the pipes agree, but I suppose if that wasn't the case
check_digital_port_conflicts() would have a failed at its
j
On Thu, May 23, 2024 at 01:07:24PM +0100, Tvrtko Ursulin wrote:
>
> On 23/05/2024 12:19, Ville Syrjälä wrote:
> > On Thu, May 23, 2024 at 09:25:45AM +0100, Tvrtko Ursulin wrote:
> >>
> >> On 22/05/2024 16:29, Vidya Srinivas wrote:
> >>> In
On Thu, May 23, 2024 at 12:15:53PM +0300, Jani Nikula wrote:
> On Thu, 16 May 2024, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Instead of that huge _PICK() let's use PICK_EVEN_2RANGES()
> > for the SEL_FETCH_PLANE registers. A bit more tedious to have
&
gt; > + !obj->is_dpt;
>
> Is there a reason i915_gem_object_make_unshrinkable() cannot be used to
> mark the object at a suitable place?
Do you have a suitable place in mind?
i915_gem_object_make_unshrinkable() contains some magic
ingredients so doesn't look like it can be called willy
nilly.
Anyways, looks like I forgot to reply that I already pushed this
with this extra comment added:
/* TODO: make DPT shrinkable when it has no bound vmas */
--
Ville Syrjälä
Intel
On Mon, May 20, 2024 at 09:58:03PM +0300, Imre Deak wrote:
> Factor out a function to modeset commit a set of pipes, which a later
> patch will reuse for DP link retraining.
>
> Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/in
+ return current_lane_count >> 1;
> +
> + return -1;
whereas this is
if (ok)
success;
fail;
I'd rearrange one of them so the logic is the same way around in both.
Otherwise lgtm
Reviewed-by: Ville Syrjälä
> +}
>
On Mon, May 20, 2024 at 09:58:01PM +0300, Imre Deak wrote:
> Move the functions used to reduce the link parameters during link
> training to intel_dp_link_training.c .
>
> Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/int
> follow-up patch will remove the limitation for those.
>
> Bspec: 49266, 68922
>
> Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 27 ++---
> 1 file changed, 23 insertions(+), 4 delet
On Wed, May 22, 2024 at 11:01:32AM +0300, Lisovskiy, Stanislav wrote:
> On Tue, May 21, 2024 at 09:09:16PM +0300, Ville Syrjälä wrote:
> > On Tue, May 21, 2024 at 11:25:31AM +0300, Lisovskiy, Stanislav wrote:
> > > On Mon, May 20, 2024 at 09:24:45PM +0300, Ville Syrjälä wrote:
&
On Tue, May 21, 2024 at 02:09:19PM +0200, Daniel Vetter wrote:
> On Thu, May 16, 2024 at 08:33:24PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Make life easier for drivers by filtering out unwanted YCbCr 4:2:0
> > only modes prior to calling the c
On Tue, May 21, 2024 at 12:51:03PM +0300, Jani Nikula wrote:
> On Mon, 20 May 2024, Ville Syrjälä wrote:
> > On Mon, May 20, 2024 at 01:47:34PM +0300, Jani Nikula wrote:
> >> On Fri, 17 May 2024, Ville Syrjala wrote:
> >> > From: Ville Syrjälä
> >> >
On Tue, May 21, 2024 at 11:25:31AM +0300, Lisovskiy, Stanislav wrote:
> On Mon, May 20, 2024 at 09:24:45PM +0300, Ville Syrjälä wrote:
> > On Mon, May 20, 2024 at 10:38:36AM +0300, Stanislav Lisovskiy wrote:
> > > Lets implement or change basic functions required for ultrajoiner
perhaps need:
- all bigjoiner masters within the entire set of joined pipes
- all bigjoiner slaves within the entire set of joined pipes
(inverse of the above)
The one slight snag here is that the "bigjoiner" name is
a bit incorrect for uncompressed joiner, but unless we want to
come up with some other name for these then I guess we'll just
have to live with it.
The other option is we try to come up with some generic names
for the two levels of pipe roles.
--
Ville Syrjälä
Intel
On Mon, May 20, 2024 at 12:27:20PM +0300, Jani Nikula wrote:
> On Thu, 16 May 2024, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Split the cursor stuff from the rest of the selective fetch
> > plane registers so that we can collect all cursor registers
>
On Mon, May 20, 2024 at 01:37:26PM +0300, Jani Nikula wrote:
> On Thu, 16 May 2024, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Bspec lists the mas TMDS bitrate as 6 Gbps on ADL/DG2.
>
> *max
>
> There's also ADL-S with display 12 and 6 Gbps suppor
for this.
> - return i915_gem_object_type_has(obj, I915_GEM_OBJECT_IS_SHRINKABLE);
> + return i915_gem_object_type_has(obj, I915_GEM_OBJECT_IS_SHRINKABLE) &&
> + !obj->is_dpt;
> }
>
> static inline bool
> --
> 2.34.1
--
Ville Syrjälä
Intel
On Mon, May 20, 2024 at 12:10:30PM +0300, Jani Nikula wrote:
> On Thu, 16 May 2024, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Group the cursor register defines such that everything to
> > do with one register is in one place.
> >
> > Sign
On Mon, May 20, 2024 at 01:47:34PM +0300, Jani Nikula wrote:
> On Fri, 17 May 2024, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Extract a helper to check whether the source+sink combo
> > supports DSC. That basic check is needed both during mode
> > val
On Fri, May 17, 2024 at 06:33:46PM +0300, Jani Nikula wrote:
> On Thu, 16 May 2024, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Using PLANE_PRIMARY + PLANE_SPRITE? on skl+ results in a bunch
> > of unnecessary head scratching. Add aliases using the skl+ plane
c | 13 +---
> drivers/gpu/drm/i915/gvt/display.c| 8 ++---
> drivers/gpu/drm/i915/gvt/fb_decoder.c | 6 ++--
> drivers/gpu/drm/i915/intel_gvt_mmio_table.c | 24 +++---
> 7 files changed, 56 insertions(+), 48 deletions(-)
>
> --
> 2.39.2
--
Ville Syrjälä
Intel
On Mon, May 13, 2024 at 11:52:08PM +0300, Jani Nikula wrote:
> On Fri, 10 May 2024, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Having the plane WM/DDB regitster write functions in skl_watermarks.c
> > is rather annoying when trying to implement DSB based p
On Mon, May 13, 2024 at 02:28:11PM +0300, Jani Nikula wrote:
> On Fri, 10 May 2024, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Rearrange the plane skl+ universal plane register definitions:
> > - keep everything related to the same register in one place
&
On Mon, May 06, 2024 at 03:57:09PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> A bit of cleanup/refactoring around plane fb stuff.
> This is mainly prep work for a slightly bigger rework
> of alignment handling.
>
> Ville Syrjälä (9):
> drm/i915: Split g
On Fri, May 10, 2024 at 01:24:12PM +0300, Jani Nikula wrote:
> On Wed, 08 May 2024, Ville Syrjälä wrote:
> > On Wed, May 08, 2024 at 02:45:10PM +0300, Jani Nikula wrote:
> >> On Wed, 08 May 2024, Ville Syrjälä wrote:
> >> > On Tue, May 07, 2024 at 09:47:
> +#define DPLS_GATING_DISABLE REG_BIT(29)
> +
> /* Plane CSC Registers */
> #define _PLANE_CSC_RY_GY_1_A 0x70210
> #define _PLANE_CSC_RY_GY_2_A 0x70310
> --
> 2.43.2
--
Ville Syrjälä
Intel
On Tue, May 07, 2024 at 11:53:40AM +0300, Jani Nikula wrote:
> On Mon, 06 May 2024, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > For some reason xe and i915 each have an identical (fortunately)
> > copy of intel_fbdev_fb.h. The xe copy actually onl
On Wed, May 08, 2024 at 12:12:32PM +0300, Jani Nikula wrote:
> On Mon, 08 Apr 2024, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Replace the open coded drm_crtc_vblank_crtc() with the real
> > thing.
> >
> > Cc: intel-gfx@lists.freedeskt
On Wed, May 08, 2024 at 09:47:50AM -0400, Alex Deucher wrote:
> On Mon, Apr 8, 2024 at 3:06 PM Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > Replace the open coded drm_crtc_vblank_crtc() with the real
> > thing.
> >
> > Cc: Alex
On Wed, May 08, 2024 at 02:45:10PM +0300, Jani Nikula wrote:
> On Wed, 08 May 2024, Ville Syrjälä wrote:
> > On Tue, May 07, 2024 at 09:47:16AM -0400, Rodrigo Vivi wrote:
> >> On Tue, May 07, 2024 at 03:56:48PM +0300, Jani Nikula wrote:
> >> > It's confusing for INTE
could you have a DG2
> without the limitation? Do we need to check for that instead of blanket
> removal of UHBR 13.5 for DG2?
And if we do remove it entirely then we should do it fully.
That is, don't leave behind unused PLL tables and whatnot.
--
Ville Syrjälä
Intel
DS(info), \
> > - INTEL_CML_GT2_IDS(info), \
> > - INTEL_CML_U_GT1_IDS(info), \
> > - INTEL_CML_U_GT2_IDS(info)
> > + INTEL_AML_CFL_GT2_IDS(info)
>
> Why only CML and not AML and WHL as well?
Why do we even have CML as a separate platform? The only difference
I can see is is that we do allow_read_ctx_timestamp() for CML but
not for CFL. Does that even make sense?
--
Ville Syrjälä
Intel
pecting GOP to enable compression?
> break;
> default:
> drm_dbg(_priv->drm,
> --
> 2.43.2
--
Ville Syrjälä
Intel
t;modifier == I915_FORMAT_MOD_4_TILED) {
> + (fb->modifier == I915_FORMAT_MOD_4_TILED ||
> + fb->modifier == I915_FORMAT_MOD_4_TILED_XE2_CCS)) {
> plane_ctl |= PLANE_CTL_RENDER_DECOMPRESSION_ENABLE;
If we got to the trouble of adding a new modifier then we should
just let skl_plane_ctl_tiling() handle this, like it does for
every other platform.
> }
>
> --
> 2.43.2
--
Ville Syrjälä
Intel
gt;
> Fixes: 700034566d68 ("drm/i915/bios: Define more BDB contents")
> Cc: sta...@vger.kernel.org
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Signed-off-by: Karthikeyan Ramasubramanian
> ---
>
> Changes in v2:
> - removed checking the block size of the backlight
On Mon, May 06, 2024 at 07:51:47PM +0300, Ville Syrjälä wrote:
> On Mon, May 06, 2024 at 05:16:50PM +0300, Jani Nikula wrote:
> >
> > *return in subject
> >
> > On Mon, 06 May 2024, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> &g
On Mon, May 06, 2024 at 05:16:50PM +0300, Jani Nikula wrote:
>
> *return in subject
>
> On Mon, 06 May 2024, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Change intel_fbdev_fb_alloc() to return struct intel_fb instead
> > of struct drm_framebuff
On Mon, May 06, 2024 at 05:03:59PM +0300, Jani Nikula wrote:
> On Mon, 06 May 2024, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > skl_plane_max_stride() is pretty messy. Streamline it and
> > split it into clear skl+ vs. adl+ variants.
> >
> > TO
On Mon, May 06, 2024 at 12:15:13PM +, Murthy, Arun R wrote:
>
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: Monday, May 6, 2024 5:36 PM
> > To: Murthy, Arun R
> > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> > Subject:
On Mon, May 06, 2024 at 01:09:02PM +0300, Jani Nikula wrote:
> Avoid the implicit dev_priv local variable use, and pass dev_priv
> explicitly to the PIPE_CRC_CTL register macro.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/displa
e)),
I believe the _IVB variants could be defined without
needing dev_priv.
But this works as well so
Reviewed-by: Ville Syrjälä
>0, 0, 0, 0);
> }
>
> @@ -364,11 +364,11 @@ static void ivb_pipe_crc_irq_handler(struct
> drm_i915_private *dev_priv,
>
viewed-by: Ville Syrjälä
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_pipe_crc.c | 8
> drivers/gpu/drm/i915/i915_reg.h | 2 +-
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915
162000, 216000, 27, 324000, 432000, 54, 648000, 81,
> - 100, 135,
> + 100,
> };
> static const int bxt_rates[] = {
> 162000, 216000, 243000, 27, 324000, 432000, 54
> --
> 2.25.1
--
Ville Syrjälä
Intel
On Mon, May 06, 2024 at 12:42:03PM +0300, Jani Nikula wrote:
> On Fri, 03 May 2024, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Define the contents of VBT block 57 (Vswing PreEmphasis Table).
> >
> > The contents is highly platform specific. The colum
On Mon, May 06, 2024 at 12:19:01PM +0300, Jani Nikula wrote:
> On Fri, 03 May 2024, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The LFP data applies to all kinds of display interfaces, so
> > stop calling things by the "LVDS" name.
> >
>
On Fri, Apr 26, 2024 at 01:51:36PM +0300, Jani Nikula wrote:
> Clean up i915_reg.h.
>
> v2: Drop chicken regs and comments (Ville)
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c | 1 +
> driv
should be done in some other patch?
I think it should have been part of
commit f70a68bc1d18 ("drm/i915: convert vlv_dpio_read()/write() from
pipe to phy")
but got missed. This patch is basically what was left from a
similar change I had in my branch. I can split this hunk out
into a separate patch.
--
Ville Syrjälä
Intel
On Mon, Apr 22, 2024 at 03:46:01PM +0300, Jani Nikula wrote:
> On Mon, 22 Apr 2024, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Use REG_BIT() & co. for the vlv/chv DPIO PHY registers.
> >
> > Signed-off-by: Ville Syrjälä
>
> What a PITA p
omic check right after the
> + * hw state readout
> + */
> + bool force_check_qgv;
> +
> int min_cdclk[I915_MAX_PIPES];
> unsigned int data_rate[I915_MAX_PIPES];
> u8 num_active_planes[I915_MAX_PIPES];
> --
> 2.34.1
--
Ville Syrjälä
Intel
; @@ -681,6 +681,8 @@ void intel_dram_detect(struct drm_i915_private *i915)
> if (ret)
> return;
>
> + drm_dbg_kms(>drm, "Num qgv points %u\n",
> dram_info->num_qgv_points);
> +
This doesn't seem to belong here.
> drm_dbg_kms(>drm, "DRAM channels: %u\n", dram_info->num_channels);
>
> drm_dbg_kms(>drm, "Watermark level 0 adjustment needed: %s\n",
> --
> 2.34.1
--
Ville Syrjälä
Intel
> igt@i915_selftest@l...@gem.html
> >>
> >>
> >> [i915#10366]: https://gitlab.freedesktop.org/drm/intel/issues/10366
> >>
> >>
> >> Build changes
> >> -
> >>
> >> * Linux: CI_DRM_14597 -> Patchwork_132390v3
> >>
> >> CI-20190529: 20190529
> >> CI_DRM_14597: 64a20aacb61e4ce6d8a0b3dc6e4bff72e316ffa3 @
> >> git://anongit.freedesktop.org/gfx-ci/linux
> >> IGT_7810: 189483744e9ff56ea573e07a049c5365404c7ecb @
> >> https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
> >> Patchwork_132390v3: 64a20aacb61e4ce6d8a0b3dc6e4bff72e316ffa3 @
> >> git://anongit.freedesktop.org/gfx-ci/linux
> >>
> >> == Logs ==
> >>
> >> For more details see:
> >> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_132390v3/index.html
> >
> > --
> > Jani Nikula, Intel
>
> --
> Jani Nikula, Intel
--
Ville Syrjälä
Intel
6] drm/i915: Eliminate extra frame from skl-glk
> > sync->async
> > flip change
> >
> > From: Ville Syrjälä
> >
> > On bdw-glk the sync->async flip change takes an extra frame due to the
> > double
> > buffering behaviour of the async flip pl
drm/i915: Reject async flips if we need to change
> > DDB/watermarks
> >
> > From: Ville Syrjälä
> >
> > DDB/watermarks are always double buffered on the vblank, so we can't safely
> > change them during async flips. Currently this never happens, but we
1/6] drm/i915: Align PLANE_SURF to 16k on ADL for async
> > flips
> >
> > From: Ville Syrjälä
> >
> > On ADL async flips apparently generate DMAR and GGTT faults (with
> > accompanying visual glitches) unless PLANE_SURF is aligned to at least 16k.
> > Bump
On Tue, Apr 09, 2024 at 06:02:49PM +0300, Dmitry Baryshkov wrote:
> On Mon, Apr 08, 2024 at 10:06:07PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Make life easier by providing a function that hands
> > out the the correct drm_vblank_crtc for a give
On Mon, Apr 15, 2024 at 03:39:41PM +0300, Jani Nikula wrote:
> On Fri, 12 Apr 2024, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Since all of this lives in intel_dpio_phy.c let's rename the
> > bxt/glk functions to have bxt_dpio_phy_ namespace.
>
>
t rid rid of the async flip abuse in
xe.
> plane_config_fini(plane_config);
> }
> }
> --
> 2.34.1
--
Ville Syrjälä
Intel
_MMIO(0x45260)
> #define WM_MISC_DATA_PARTITION_5_6 (1 << 0)
>
> --
> 2.43.2
--
Ville Syrjälä
Intel
On Fri, Apr 12, 2024 at 06:50:57PM +0300, Jani Nikula wrote:
> On Fri, 12 Apr 2024, Ville Syrjälä wrote:
> > On Fri, Apr 12, 2024 at 05:52:55PM +0300, Jani Nikula wrote:
> >> +/*
> >> + * Framebuffer compression (915+ only)
> >> + */
> >
> &
V_CMN_DW13_CH00x8134
> -#define _CHV_CMN_DW0_CH1 0x8080
> -#define DPIO_CHV_S1_DIV_SHIFT 21
> -#define DPIO_CHV_P1_DIV_SHIFT 13 /* 3 bits */
> -#define DPIO_CHV_P2_DIV_SHIFT 8 /* 5 bits */
> -#define DPIO_CHV_K_DIV_SHIFT 4
> -#define DPIO_PLL_FREQLOCK (1 << 1)
> -#define DPIO_PLL_LOCK (1 << 0)
> -#define CHV_CMN_DW13(ch) _PIPE(ch, _CHV_CMN_DW13_CH0, _CHV_CMN_DW0_CH1)
> -
> -#define _CHV_CMN_DW14_CH00x8138
> -#define _CHV_CMN_DW1_CH1 0x8084
> -#define DPIO_AFC_RECAL (1 << 14)
> -#define DPIO_DCLKP_EN (1 << 13)
> -#define CHV_BUFLEFTENA2_DISABLE(0 << 17) /* CL2 DW1 only */
> -#define CHV_BUFLEFTENA2_NORMAL (1 << 17) /* CL2 DW1 only */
> -#define CHV_BUFLEFTENA2_FORCE (3 << 17) /* CL2 DW1 only */
> -#define CHV_BUFLEFTENA2_MASK (3 << 17) /* CL2 DW1 only */
> -#define CHV_BUFRIGHTENA2_DISABLE (0 << 19) /* CL2 DW1 only */
> -#define CHV_BUFRIGHTENA2_NORMAL(1 << 19) /* CL2 DW1 only */
> -#define CHV_BUFRIGHTENA2_FORCE (3 << 19) /* CL2 DW1 only */
> -#define CHV_BUFRIGHTENA2_MASK (3 << 19) /* CL2 DW1 only */
> -#define CHV_CMN_DW14(ch) _PIPE(ch, _CHV_CMN_DW14_CH0, _CHV_CMN_DW1_CH1)
> -
> -#define _CHV_CMN_DW19_CH00x814c
> -#define _CHV_CMN_DW6_CH1 0x8098
> -#define DPIO_ALLDL_POWERDOWN_SHIFT_CH1 30 /* CL2 DW6 only */
> -#define DPIO_ANYDL_POWERDOWN_SHIFT_CH1 29 /* CL2 DW6 only */
> -#define DPIO_DYNPWRDOWNEN_CH1 (1 << 28) /* CL2 DW6 only */
> -#define CHV_CMN_USEDCLKCHANNEL (1 << 13)
> -
> -#define CHV_CMN_DW19(ch) _PIPE(ch, _CHV_CMN_DW19_CH0, _CHV_CMN_DW6_CH1)
> -
> -#define CHV_CMN_DW28 0x8170
> -#define DPIO_CL1POWERDOWNEN(1 << 23)
> -#define DPIO_DYNPWRDOWNEN_CH0 (1 << 22)
> -#define DPIO_SUS_CLK_CONFIG_ON (0 << 0)
> -#define DPIO_SUS_CLK_CONFIG_CLKREQ (1 << 0)
> -#define DPIO_SUS_CLK_CONFIG_GATE (2 << 0)
> -#define DPIO_SUS_CLK_CONFIG_GATE_CLKREQ(3 << 0)
> -
> -#define CHV_CMN_DW30 0x8178
> -#define DPIO_CL2_LDOFUSE_PWRENB(1 << 6)
> -#define DPIO_LRC_BYPASS(1 << 3)
> -
> -#define _TXLANE(ch, lane, offset) ((ch ? 0x2400 : 0) + \
> - (lane) * 0x200 + (offset))
> -
> -#define CHV_TX_DW0(ch, lane) _TXLANE(ch, lane, 0x80)
> -#define CHV_TX_DW1(ch, lane) _TXLANE(ch, lane, 0x84)
> -#define CHV_TX_DW2(ch, lane) _TXLANE(ch, lane, 0x88)
> -#define CHV_TX_DW3(ch, lane) _TXLANE(ch, lane, 0x8c)
> -#define CHV_TX_DW4(ch, lane) _TXLANE(ch, lane, 0x90)
> -#define CHV_TX_DW5(ch, lane) _TXLANE(ch, lane, 0x94)
> -#define CHV_TX_DW6(ch, lane) _TXLANE(ch, lane, 0x98)
> -#define CHV_TX_DW7(ch, lane) _TXLANE(ch, lane, 0x9c)
> -#define CHV_TX_DW8(ch, lane) _TXLANE(ch, lane, 0xa0)
> -#define CHV_TX_DW9(ch, lane) _TXLANE(ch, lane, 0xa4)
> -#define CHV_TX_DW10(ch, lane) _TXLANE(ch, lane, 0xa8)
> -#define CHV_TX_DW11(ch, lane) _TXLANE(ch, lane, 0xac)
> -#define DPIO_FRC_LATENCY_SHFIT 8
> -#define CHV_TX_DW14(ch, lane) _TXLANE(ch, lane, 0xb8)
> -#define DPIO_UPAR_SHIFT30
> -
> /* BXT PHY registers */
> #define _BXT_PHY0_BASE 0x6C000
> #define _BXT_PHY1_BASE 0x162000
> --
> 2.39.2
--
Ville Syrjälä
Intel
w file mode 100644
> index ..caf4b58e9a27
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_sprite_regs.h
> @@ -0,0 +1,349 @@
> +/* SPDX-License-Identifier: MIT */
> +/* Copyright © 2024 Intel Corporation */
> +
> +#ifndef __INTEL_SPRITE_REGS__
> +#d
_PICK_EVEN_2RANGES(pipe, 2,
> \
> + _PALETTE_A, _PALETTE_B,
> \
> + _CHV_PALETTE_C,
> _CHV_PALETTE_C) + \
> + (i) * 4)
> +
>
On Fri, Apr 12, 2024 at 05:52:53PM +0300, Jani Nikula wrote:
> There are too few registers to warrant a dedicated file for LPE audio
> regs, but the audio reg file is better than i915_reg.h.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gp
)
> -#define CHICKEN_FBC_STRIDE(x)
> REG_FIELD_PREP(CHICKEN_FBC_STRIDE_MASK, (x))
> -
> #define _CHICKEN_PIPESL_1_A 0x420b0
> #define _CHICKEN_PIPESL_1_B 0x420b4
> #define CHICKEN_PIPESL_1(pipe) _MMIO_PIPE(pipe, _CHICKEN_PIPESL_1_A,
> _CHICKEN_PIPESL_1_B)
> diff --git a/drivers/gpu/drm/i915/intel_clock_gating.c
> b/drivers/gpu/drm/i915/intel_clock_gating.c
> index 7e70ee4fbd84..1dc5281b2ade 100644
> --- a/drivers/gpu/drm/i915/intel_clock_gating.c
> +++ b/drivers/gpu/drm/i915/intel_clock_gating.c
> @@ -28,6 +28,7 @@
> #include "display/intel_de.h"
> #include "display/intel_display.h"
> #include "display/intel_display_trace.h"
> +#include "display/intel_fbc_regs.h"
> #include "display/skl_watermark.h"
>
> #include "gt/intel_engine_regs.h"
> diff --git a/drivers/gpu/drm/i915/intel_gvt_mmio_table.c
> b/drivers/gpu/drm/i915/intel_gvt_mmio_table.c
> index 87ecc5104fd9..70d661bffcc2 100644
> --- a/drivers/gpu/drm/i915/intel_gvt_mmio_table.c
> +++ b/drivers/gpu/drm/i915/intel_gvt_mmio_table.c
> @@ -10,6 +10,7 @@
> #include "display/intel_dmc_regs.h"
> #include "display/intel_dp_aux_regs.h"
> #include "display/intel_dpio_phy.h"
> +#include "display/intel_fbc_regs.h"
> #include "display/intel_fdi_regs.h"
> #include "display/intel_lvds_regs.h"
> #include "display/intel_psr_regs.h"
> --
> 2.39.2
--
Ville Syrjälä
Intel
On Wed, Apr 10, 2024 at 10:09:32PM -0700, Dixit, Ashutosh wrote:
> On Wed, 10 Apr 2024 04:42:46 -0700, Ville Syrjälä wrote:
> >
> > On Tue, Apr 09, 2024 at 09:28:55PM -0700, Ashutosh Dixit wrote:
> > > There are no hwmon selftests so there is no need to enable hwmon for
&g
On Wed, Apr 10, 2024 at 05:34:13PM +0300, Ville Syrjälä wrote:
> On Tue, Apr 09, 2024 at 06:12:09PM -, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm/i915: Bigjoiner modeset sequence redesign and MST support (rev4)
> > URL : https://patchwork.fr
i915]:__live_retire [i915]
<3> [396.903434] i915 :00:02.0: [drm] *ERROR* live_active_wait count: 0
<3> [396.903443] i915 :00:02.0: [drm] *ERROR* live_active_wait
preallocated barriers? no
<3> [396.904085] i915/i915_active_live_selftests: live_active_wait failed with
error -22
Looks very much unrelated to these changes. Please wave this one through.
--
Ville Syrjälä
Intel
ntel_crtc_compute_config() in my current WIP DSB plane update
branch.
The problem with PSR is that it seems to want to use it
before that. The question no one has yet answered is
whether PSR actually wants to consult the undelayed
transcoder vblank or the delayed vblank. I'm think the
former is more likely (with PSR being a transcoder level
feature), in which case the chicken vs. egg sitation
will simply disappear. But someone will need to confirm
that.
The other potential chicken vs. egg looks to be VRR on
setups where TRANS_SET_CONTEXT_LATENCY isn't a thing.
The question there is how the vblank delay is configured
when using VRR. I'm pretty sure I did figure this out
already, but can't remember right now what the conclusion
was. So that needs to be double checked as well.
I was also pondering whether we should try to leave
adjusted_mode.crtc_vblank_start alone and instead just
reflect the delayed vblank in pipe_mode.crtc_vblank_start?
That might be useful if there are other places later on
in the atomic_check/etc. that needs to know the position
of the undelayed vblank. But that would have big implications
to eg. the vblank timestamping code, so probably not entirely
feasible.
--
Ville Syrjälä
Intel
intel_gt_driver_unregister(gt);
>
> - i915_hwmon_unregister(dev_priv);
> + if (!is_selftest())
> + i915_hwmon_unregister(dev_priv);
>
> i915_perf_unregister(dev_priv);
> i915_pmu_unregister(dev_priv);
> --
> 2.41.0
--
Ville Syrjälä
Intel
is that struct drm_edid_product_id and struct
> lvds_pnp_id describe identical data, albeit with slightly different
> member definitions.
>
> Cc: Ville Syrjälä
> Acked-by: Melissa Wen
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 43 ++
k to display substruct
> drm/xe/display: remove unused xe->enabled_irq_mask
Looks reasonable.
Series is
Reviewed-by: Ville Syrjälä
>
> drivers/gpu/drm/i915/display/intel_cdclk.c| 23
> drivers/gpu/drm/i915/display/intel_crt.c | 2 +-
> drivers/gpu/drm/i915/d
nector,
> const struct drm_edid *edid);
> int drm_edid_connector_add_modes(struct drm_connector *connector);
> bool drm_edid_is_digital(const struct drm_edid *drm_edid);
> +void drm_edid_get_product_id(const struct drm_edid *drm_edid,
> + struct drm_edid_product_id *id);
>
> const u8 *drm_find_edid_extension(const struct drm_edid *drm_edid,
> int ext_id, int *ext_index);
> --
> 2.39.2
--
Ville Syrjälä
Intel
d_modes(struct drm_connector
> *connector);
> bool drm_edid_is_digital(const struct drm_edid *drm_edid);
> void drm_edid_get_product_id(const struct drm_edid *drm_edid,
> struct drm_edid_product_id *id);
> +void drm_edid_print_product_id(struct drm_printer *p,
> +const struct drm_edid_product_id *id, bool raw);
>
> const u8 *drm_find_edid_extension(const struct drm_edid *drm_edid,
> int ext_id, int *ext_index);
> --
> 2.39.2
--
Ville Syrjälä
Intel
On Mon, Apr 08, 2024 at 08:28:27PM +0300, Ville Syrjälä wrote:
> On Mon, Apr 08, 2024 at 08:23:14PM +0300, Jani Nikula wrote:
> > The rawclk initialization is a bit out of place in
> > intel_device_info_runtime_init(). Move it to intel_cdclk_init(), with a
> &g
ice_info.c
> index a0a43ea07f11..48f0957392f9 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -370,10 +370,6 @@ void intel_device_info_runtime_init(struct
> drm_i915_private *dev_priv)
> "Disabling ppGTT for VT-d support\n");
> runtime->ppgtt_type = INTEL_PPGTT_NONE;
> }
> -
> - runtime->rawclk_freq = intel_read_rawclk(dev_priv);
> - drm_dbg(_priv->drm, "rawclk rate: %d kHz\n", runtime->rawclk_freq);
> -
> }
>
> /*
> --
> 2.39.2
--
Ville Syrjälä
Intel
On Mon, Apr 08, 2024 at 09:46:44AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 05.04.24 um 21:58 schrieb Ville Syrjälä:
> > On Fri, Apr 05, 2024 at 09:57:07AM +0200, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 04.04.24 um 22:33 schrieb Ville Syrjala:
ach
> an agreement.
>
> I raised the same question to Wolfram.
I don't know where that discussion happened, but my opinion
is NAK to "client". Life is already confusing enough with
these renames, so let's not make it even more confusing by
inventing new names nowhere to be found in the spec.
And let's especially not invent names that don't even fit
the purpose. "Client" makes me think of "client/server" or
some real world analogy. Neither of which seem to have any
resemblence to how the term would be used for i2c.
--
Ville Syrjälä
Intel
ogging of modes, in the right drm debug
> category, and inline with the rest of the logging instead of split to
> multiple lines.
>
> Suggested-by: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 6 +++---
>
1/17] drm/i915: Update pipes in reverse order for
> > bigjoiner
> >
> > From: Ville Syrjälä
> >
> > With bigjoiner the master crtc is the one that will send out the uapi
> > event/etc.
> > We want that to happen after all the slaves are done, so let's try to
drm_connector_for_each_possible_encoder(connector, encoder)
> return encoder;
>
> @@ -564,8 +566,6 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set,
> int ret;
> int i;
>
> - DRM_DEBUG_KMS("\n");
> -
>
private *dev_priv, enum pipe pipe)
> {
> i915_reg_t pp_reg;
> diff --git a/drivers/gpu/drm/i915/display/intel_pps.h
> b/drivers/gpu/drm/i915/display/intel_pps.h
> index a2c2467e3c22..07ef96ca8da2 100644
> --- a/drivers/gpu/drm/i915/display/intel_pps.h
> +++ b/drivers/gpu/drm/i915/display/intel_pps.h
> @@ -51,6 +51,8 @@ void vlv_pps_init(struct intel_encoder *encoder,
> void intel_pps_unlock_regs_wa(struct drm_i915_private *i915);
> void intel_pps_setup(struct drm_i915_private *i915);
>
> +void intel_pps_connector_debugfs_add(struct intel_connector *connector);
> +
> void assert_pps_unlocked(struct drm_i915_private *i915, enum pipe pipe);
>
> #endif /* __INTEL_PPS_H__ */
> --
> 2.39.2
--
Ville Syrjälä
Intel
On Fri, Apr 05, 2024 at 11:39:33PM +0300, Dmitry Baryshkov wrote:
> On Fri, 5 Apr 2024 at 22:17, Ville Syrjälä
> wrote:
> >
> > On Fri, Apr 05, 2024 at 06:24:01AM +0300, Dmitry Baryshkov wrote:
> > > On Thu, Apr 04, 2024 at 11:33:25PM +0300, Ville Syrjala wrote:
On Fri, Apr 05, 2024 at 11:23:01AM +0300, Jani Nikula wrote:
> On Thu, 04 Apr 2024, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Switch to the canonical [CONNECTOR:%d:%s] etc. format for
> > printing out kms objects.
>
> I've been pinging for reviews on
On Fri, Apr 05, 2024 at 09:57:07AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 04.04.24 um 22:33 schrieb Ville Syrjala:
> > From: Ville Syrjälä
> >
> > Get rid of all the redundant debugs and just wait until the end
> > to print which mode (and of which ty
7] drm/i915: Update pipes in reverse order for
> > bigjoiner
> >
> > From: Ville Syrjälä
> >
> > With bigjoiner the master crtc is the one that will send out the uapi
> > event/etc. We want that to happen after all the slaves are done, so let's
> > try
>
1 - 100 of 10614 matches
Mail list logo
