On Thu, Sep 23, 2021 at 11:01:07PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's introduce a compute_config() helper for fixed mode panels.
> For now all it does is the fixed_mode->adjusted_mode copy.
>
> Note that with sDVO we have to ask the external
,6 +282,7 @@ int __intel_wait_for_register_fw(struct intel_uncore
> *uncore,
>unsigned int fast_timeout_us,
>unsigned int slow_timeout_ms,
>u32 *out_value);
> +
> static inline int
> intel_wait_for_register_fw(struct intel_uncore *uncore,
> i915_reg_t reg,
> @@ -293,6 +294,12 @@ intel_wait_for_register_fw(struct intel_uncore *uncore,
> 2, timeout_ms, NULL);
> }
>
> +int intel_wait_for_condition(struct intel_uncore *uncore,
> + bool (*func)(void *data),
> + void *data,
> + unsigned int fw,
> + unsigned int timeout_ms);
> +
> /* register access functions */
> #define __raw_read(x__, s__) \
> static inline u##x__ __raw_uncore_read##x__(const struct intel_uncore
> *uncore, \
> --
> 2.33.0
--
Ville Syrjälä
Intel
B.
>
> Cc: Gwan-gyeong Mun
> Cc: Ville Syrjälä
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> drivers/gpu/drm/i915/display/intel_drrs.c| 5 -
> drivers/gpu/drm/i915/display/intel_drrs.h| 4 +++
st.x1 < 0 ||
> plane_state->scaler_id >= 0 ||
> + plane_state->hw.fb->format->is_yuv ||
is_yuv != planar
> plane_state->uapi.rotation != DRM_MODE_ROTATE_0)
> return false;
>
> --
> 2.33.0
--
Ville Syrjälä
Intel
On Fri, Sep 24, 2021 at 03:46:46PM +0100, Matthew Auld wrote:
> Seems to fix some object-debug splat which appeared while debugging
> something unrelated.
>
> v2: s/guc_blocked/guc_state.blocked/
>
> Signed-off-by: Matthew Auld
> Cc: Ville Syrjälä
> Cc: Matthew Brost
On Fri, Sep 24, 2021 at 05:10:44PM +, Souza, Jose wrote:
> On Fri, 2021-09-24 at 17:35 +0300, Ville Syrjälä wrote:
> > On Thu, Sep 23, 2021 at 12:46:11PM -0700, José Roberto de Souza wrote:
> > > Alderlake-P was getting 'max time under evasion' messages when PSR2
&g
On Mon, Sep 27, 2021 at 11:23:35AM -0700, Matt Roper wrote:
> On Thu, Sep 23, 2021 at 06:49:59PM +0300, Ville Syrjälä wrote:
> > On Thu, Sep 23, 2021 at 11:48:58AM +0300, Stanislav Lisovskiy wrote:
> > > TileF(Tile4 in bspec) format is 4K tile organized into
> > > 6
ndex ef594df039db..7b3eed5b4e42 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4272,6 +4272,7 @@ enum {
> #define DPF_GATING_DIS (1 << 10)
> #define DPF_RAM_GATING_DIS (1 << 9)
> #define DPFR_GATING_DIS(1 << 8)
> +#define CURSOR_GATING_DIS REG_BIT(28)
Please keep the bits in order.
Otherwise lgtm
Reviewed-by: Ville Syrjälä
>
> #define CLKGATE_DIS_PSL(pipe) \
> _MMIO_PIPE(pipe, _CLKGATE_DIS_PSL_A, _CLKGATE_DIS_PSL_B)
> --
> 2.31.1
--
Ville Syrjälä
Intel
On Tue, Sep 28, 2021 at 03:49:11PM +0300, Lisovskiy, Stanislav wrote:
> On Mon, Sep 27, 2021 at 10:24:11PM -0700, Matt Roper wrote:
> > On Mon, Sep 27, 2021 at 09:29:07PM +0300, Ville Syrjälä wrote:
> > > On Mon, Sep 27, 2021 at 11:23:35AM -0700, Matt Roper wrote:
> > >
On Tue, Sep 28, 2021 at 11:36:51PM +0300, Lisovskiy, Stanislav wrote:
> On Tue, Sep 28, 2021 at 10:02:34PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 28, 2021 at 03:49:11PM +0300, Lisovskiy, Stanislav wrote:
> > > On Mon, Sep 27, 2021 at 10:24:11PM -0700, Matt Roper wrote:
>
On Thu, Apr 01, 2021 at 02:49:13PM -0700, Navare, Manasi wrote:
> On Fri, Mar 26, 2021 at 06:15:22PM +0200, Ville Syrjälä wrote:
> > On Thu, Mar 25, 2021 at 03:01:29PM -0700, Navare, Manasi wrote:
> > > On Fri, Mar 19, 2021 at 11:27:59PM +0200, Ville Syrjälä wrote:
> > >
te->uapi.dst.y1 < 0 ||
> > - new_plane_state->uapi.dst.x1 < 0) {
> > + if (!psr2_sel_fetch_plane_state_supported(new_plane_state)) {
> > full_update = true;
> > break;
> > }
> > @@ -1703,6 +1705,11 @@ int intel_psr2_sel_fetch_update(struct
> > intel_atomic_state *state,
> > if (!drm_rect_intersect(&inter, &new_plane_state->uapi.dst))
> > continue;
> >
> > + if (!psr2_sel_fetch_plane_state_supported(new_plane_state)) {
> > + full_update = true;
> > + break;
> > + }
> > +
> > sel_fetch_area = &new_plane_state->psr2_sel_fetch_area;
> > sel_fetch_area->y1 = inter.y1 - new_plane_state->uapi.dst.y1;
> > sel_fetch_area->y2 = inter.y2 - new_plane_state->uapi.dst.y1;
> >
--
Ville Syrjälä
Intel
On Thu, Sep 30, 2021 at 08:35:01AM +0300, Gwan-gyeong Mun wrote:
>
>
> On 9/29/21 9:20 PM, Ville Syrjälä wrote:
> > On Wed, Sep 29, 2021 at 08:50:12PM +0300, Gwan-gyeong Mun wrote:
> >>
> >>
> >> On 9/23/21 10:46 PM, José Roberto de Souza wrote:
> >
On Wed, Sep 29, 2021 at 11:26:02PM +0300, Imre Deak wrote:
> On Wed, Sep 29, 2021 at 07:54:52PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Adjust the link training code to accommodate per-lane drive settings,
> > if supported by the platform. Actually
On Wed, Sep 29, 2021 at 10:17:52PM +0300, Imre Deak wrote:
> On Mon, Sep 27, 2021 at 09:24:48PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Currently .set_signal_levels() is only used by encoders in DP mode.
> > For most modern platforms there is no e
nd at this point the power-saving
> features are not even enabled.
>
> And the last one intelfb_create(), is also not required as at this
> point the fbdev was just allocated, userspace will draw on
> it what will trigger frontbuffer invalidates and flushes later on.
>
> Cc:
ring(psr_force_hw_tracking_exit()), that is not the
> most optimal for power-savings but is the solution that we have until
> mailbox style updates is implemented.
>
> Also removing the cursor workaround as not it is properly undestand
> the issue and is know that it will never co
On Wed, Sep 29, 2021 at 05:14:09PM -0700, José Roberto de Souza wrote:
> Not waiting for vblank counter to increment could potentialy cause
> issues as commits after the one that needs a modeset could change
> state of entities that are not committed into hardware yet.
>
> Cc
ines would be less
loc overall, while still wouldn't need any extra struct definitions/etc.
in the header. But not performance sensitive so from that pov static
inline is pointless.
Anyways, this approach seems fine to me. For the series
Reviewed-by: Ville Syrjälä
--
Ville Syrjälä
Intel
On Thu, Sep 30, 2021 at 12:32:29PM +0300, Jani Nikula wrote:
> Using standard -EAGAIN should be perfectly fine instead of using a
> special case value.
Can't immediately spot any uses of -EAGAIN which would conflict here.
Reviewed-by: Ville Syrjälä
>
> Signed-of
be something different
might make sense to indicate that it's the hw telling us nonsense
(or the driver is actually missing some necessaty stuff).
But boesn't really matter since it's just a bogus value.
Series is
Reviewed-by: Ville Syrjälä
> }
>
as such formats.
>
> Cc: Ville Syrjälä
> Signed-off-by: Gwan-gyeong Mun
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
&
On Thu, Sep 30, 2021 at 07:09:03PM +0300, Imre Deak wrote:
> On Thu, Sep 30, 2021 at 04:43:09PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Setting DP_PORT_EN in intel_dp->DP is already handled by
> > intel_dp_enable_port() so there is no point i
TRL, _AUD_TCB_DP_2DOT0_CTRL)
> +#define AUD_ENABLE_SDP_SPLITREG_BIT(31)
Don't need the other bits? Most of the do say we don't need to
program then. But the hblank guardband thing looks like maybe
we might need it in some cases?
Either way, what you have here matches
ush_work(i915);
> 4026
> 4027drm_encoder_cleanup(encoder);
> 4028if (dig_port)
>
> But the existing code checked for NULL.
That check is nonsense. Feel free to nuke it.
>
> 4029kfree(dig_port
else
> - voltage_tries = 1;
> + /* FIXME: 128b/132b needs better abstractions here. */
> + if (!intel_dp_is_uhbr(crtc_state)) {
> + if ((intel_dp->train_set[0] &
> DP_TRAIN_VOLTAGE_SWING_MASK) ==
> + voltage)
> + ++voltage_tries;
> + else
> + voltage_tries = 1;
Unfortunately the spec seems to totally lack any description of
128b/132b link training sequence. So I have no idea if we should
consider the entire tx_ffe here as the voltage and still do the
"no more than five times with the same setting" thing.
Ugh. Also just realized this code needs further surgery for the
per-lane drive settings...
Ugh2. This code looks totally wrong anyway. At least DP2.0 seems
to say that we should check whether the _request_ stays the same
five times in a row, not whether we happen to transmit the
same voltage level five times...
Also we seem to be missing the 128b/132b AUX_RD_INTERVAL stuff...
--
Ville Syrjälä
Intel
: [Intel-gfx] [PATCH] drm/i915: Stop force enabling pipe bottom color
> > gammma/csc
> >
> > From: Ville Syrjälä
> >
> > While sanitizing the hardware state we're currently forcing the pipe bottom
> > color
> > legacy csc/gamma bits on. That is no
On Fri, Oct 01, 2021 at 08:45:49PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 01, 2021 at 05:12:03PM +, Shankar, Uma wrote:
> >
> >
> > > -Original Message-
> > > From: Intel-gfx On Behalf Of
> > > Ville Syrjala
> > > Sent: Wednesd
k_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/i915: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/i915: cleanup: drm_modeset_lock_all() -->
> > DRM_MODESET_LOCK_ALL_BEGIN() part 2
> > drm/gma500: cleanup: drm_modeset_lock_all()
On Fri, Oct 01, 2021 at 02:08:15PM -0700, Matt Roper wrote:
> On Thu, Sep 30, 2021 at 10:09:42PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Looks like skl/bxt/derivatives also need the plane stride
> > stretch w/a when using async flips and VT-d is
On Fri, Oct 01, 2021 at 04:48:15PM -0400, Sean Paul wrote:
> On Fri, Oct 01, 2021 at 10:00:50PM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 01, 2021 at 02:36:55PM -0400, Sean Paul wrote:
> > > On Fri, Sep 24, 2021 at 08:43:07AM +0200, Fernando Ramos wrote:
> > > > H
On Sat, Oct 02, 2021 at 01:01:31AM +0300, Ville Syrjälä wrote:
> On Fri, Oct 01, 2021 at 02:08:15PM -0700, Matt Roper wrote:
> > On Thu, Sep 30, 2021 at 10:09:42PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Looks like skl/bxt/de
On Sat, Oct 02, 2021 at 01:05:47AM +0300, Ville Syrjälä wrote:
> On Fri, Oct 01, 2021 at 04:48:15PM -0400, Sean Paul wrote:
> > On Fri, Oct 01, 2021 at 10:00:50PM +0300, Ville Syrjälä wrote:
> > > On Fri, Oct 01, 2021 at 02:36:55PM -0400, Sean Paul wrote:
> > > > On F
ncs.read_fw_domains);
> GEM_BUG_ON(intel_uncore_has_forcewake(uncore) !=
> !!uncore->funcs.write_fw_domains);
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.h
> b/drivers/gpu/drm/i915/intel_uncore.h
> index 2f31c50eeae2..3248e4e2c540 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.h
> +++ b/drivers/gpu/drm/i915/intel_uncore.h
> @@ -84,12 +84,12 @@ enum forcewake_domains {
> FORCEWAKE_ALL = BIT(FW_DOMAIN_ID_COUNT) - 1,
> };
>
> -struct intel_uncore_funcs {
> +struct intel_uncore_fw_get {
> void (*force_wake_get)(struct intel_uncore *uncore,
> enum forcewake_domains domains);
> - void (*force_wake_put)(struct intel_uncore *uncore,
> -enum forcewake_domains domains);
> +};
>
> +struct intel_uncore_funcs {
> enum forcewake_domains (*read_fw_domains)(struct intel_uncore *uncore,
> i915_reg_t r);
> enum forcewake_domains (*write_fw_domains)(struct intel_uncore *uncore,
> @@ -150,6 +150,7 @@ struct intel_uncore {
> unsigned int shadowed_reg_table_entries;
>
> struct notifier_block pmic_bus_access_nb;
> + const struct intel_uncore_fw_get *fw_get_funcs;
> struct intel_uncore_funcs funcs;
>
> unsigned int fifo_count;
> --
> 2.30.2
--
Ville Syrjälä
Intel
On Sat, Oct 02, 2021 at 07:28:02PM +0200, Fernando Ramos wrote:
> On 21/10/02 09:13AM, Fernando Ramos wrote:
> > On 21/10/02 05:30AM, Ville Syrjälä wrote:
> > > On Sat, Oct 02, 2021 at 01:05:47AM +0300, Ville Syrjälä wrote:
> > > > On Fri, Oct 01, 2021 at 04:
re are significant
changes coming in via drm-misc they usually will cause conflicts for
people during drm-tip rebuild. Also I would expect to see an ack
requested from i915 maintainers for merging anything significant via
drm-misc, which I don't think happened in this case.
--
Ville Syrjälä
Intel
On Tue, Apr 27, 2021 at 10:58:07AM +0200, Daniel Vetter wrote:
> On Mon, Apr 26, 2021 at 08:18:39PM +0300, Ville Syrjälä wrote:
> > On Mon, Apr 26, 2021 at 06:08:59PM +0200, Daniel Vetter wrote:
> > > On Thu, Apr 22, 2021 at 04:11:22PM +0300, Ville Syrjälä wrote:
> > > &
one actually thought what happens if you first use
MST on the port, and then later switch to SST on the same port?
--
Ville Syrjälä
Intel
On Tue, Jul 20, 2021 at 03:44:49PM +0200, Daniel Vetter wrote:
> On Thu, Jul 15, 2021 at 09:49:51PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Quite a few places are hand rolling the modeset lock backoff dance.
> > Let's suck that into a he
don't understand what you're trying to say
here.
The only internal thing that could alter the set of enabled crtcs
on the uapi level is update_connector_routing(true), but that is
always called before drm_atomic_check_only().
>
> Cc: Ville Syrjälä
> Cc: Simon Ser
> Cc: Pekka
o_client_probe_defer(pdev))
> + return true;
> +
> + return false;
> +}
Seems fine. Presumably Jani isn't too grumpy about it :P
Reviewed-by: Ville Syrjälä
> +
> void intel_display_driver_register(struct drm_i915_private *i915)
> {
> if
r NULL. */
> + struct drm_privacy_screen *privacy_screen;
> +
> + /** @privacy_screen_notifier: privacy-screen notifier_block */
> + struct notifier_block privacy_screen_notifier;
> +
> /**
>* @privacy_screen_sw_state_property: Optional atomic property for the
>* connector to control the integrated privacy screen.
> @@ -1788,6 +1796,9 @@ int drm_connector_attach_max_bpc_property(struct
> drm_connector *connector,
> int min, int max);
> void drm_connector_create_privacy_screen_properties(struct drm_connector
> *conn);
> void drm_connector_attach_privacy_screen_properties(struct drm_connector
> *conn);
> +void drm_connector_attach_privacy_screen_provider(
> + struct drm_connector *connector, struct drm_privacy_screen *priv);
> +void drm_connector_update_privacy_screen(const struct drm_connector_state
> *connector_state);
>
> /**
> * struct drm_tile_group - Tile group metadata
> --
> 2.31.1
--
Ville Syrjälä
Intel
reen = drm_privacy_screen_get(dev->dev, NULL);
> + if (!IS_ERR(privacy_screen)) {
> + drm_connector_attach_privacy_screen_provider(connector,
> + privacy_screen);
> + } else if (PTR_ERR(privacy_screen) != -ENODEV) {
> + drm_warn(&dev_priv->drm, "Error getting privacy-screen\n");
> + }
I'm thinking this should go into intel_ddi_init_dp_connector()
on account of only the ddi codepaths having the
drm_connector_update_privacy_screen() calls.
Otherwise seems ok.
> +
> return true;
>
> out_vdd_off:
> --
> 2.31.1
--
Ville Syrjälä
Intel
On Mon, Oct 04, 2021 at 03:04:01PM +, Gupta, Anshuman wrote:
>
>
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: Monday, October 4, 2021 4:22 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Sean Paul ; Gupta, Anshuman
> > ; C,
On Mon, Oct 04, 2021 at 06:02:21PM +0200, Hans de Goede wrote:
> Hi,
>
> On 10/4/21 5:37 PM, Ville Syrjälä wrote:
> > On Sat, Oct 02, 2021 at 06:36:18PM +0200, Hans de Goede wrote:
> >> Add support for eDP panels with a built-in privacy screen using the
> >
On Mon, Oct 04, 2021 at 10:50:00AM -0700, Matt Roper wrote:
> On Sat, Oct 02, 2021 at 01:01:31AM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 01, 2021 at 02:08:15PM -0700, Matt Roper wrote:
> > > On Thu, Sep 30, 2021 at 10:09:42PM +0300, Ville Syrjala wrote:
> >
; in all the call sites.
Yeah, the on stack extra buffer is getting a bit annoying, especially
with the calls multiplying like rabbits in my recent patches.
Series is
Reviewed-by: Ville Syrjälä
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> driv
e
modeset_retry work) which presuambly was already running and told
fb_helper that stuff happened, then the fb_helper proceeds to do
a modeset while interrupts are already off and we're in the middle
of tearing down the driver, and all hell breaks loose as a result.
Unrelated to these patches, I *think*. I'll hit retest anyway to
make sure.
--
Ville Syrjälä
Intel
h eDP panels, clobbering the hardware state and leading to errors.
>
> Gracefully disable dual eDP until proper support has been added.
>
> Cc: José Roberto de Souza
> Cc: Uma Shankar
> Cc: Ville Syrjälä
> Cc: Swati Sharma
> Signed-off-by: Jani Nikula
> ---
> driv
)
> - kfree(dig_port->hdcp_port_data.streams);
> + kfree(dig_port->hdcp_port_data.streams);
> kfree(dig_port);
> }
>
> --
> 2.20.1
--
Ville Syrjälä
Intel
On Tue, Oct 05, 2021 at 10:30:04PM +0300, Jani Nikula wrote:
> On Tue, 05 Oct 2021, Ville Syrjälä wrote:
> > On Tue, Oct 05, 2021 at 08:56:36PM +0300, Jani Nikula wrote:
> >> For the time being, neither the power sequencer nor the backlight code
> >> properly support tw
ED(CONFIG_PREEMPT_RT))
> + local_irq_disable();
> }
>
> #if IS_ENABLED(CONFIG_DRM_I915_DEBUG_VBLANK_EVADE)
> @@ -566,7 +570,8 @@ void intel_pipe_update_end(struct intel_crtc_state
> *new_crtc_state)
> new_crtc_state->uapi.event = NULL;
> }
>
> - local_irq_enable();
> + if (!IS_ENABLED(CONFIG_PREEMPT_RT))
> + local_irq_enable();
>
> /* Send VRR Push to terminate Vblank */
> intel_vrr_send_push(new_crtc_state);
> --
> 2.33.0
--
Ville Syrjälä
Intel
index 806ad688274bf..773e7362c4442 100644
> --- a/drivers/gpu/drm/i915/i915_trace.h
> +++ b/drivers/gpu/drm/i915/i915_trace.h
> @@ -2,6 +2,10 @@
> #if !defined(_I915_TRACE_H_) || defined(TRACE_HEADER_MULTI_READ)
> #define _I915_TRACE_H_
>
> +#ifdef CONFIG_PREEMPT_RT
> +#define NOTRACE
> +#endif
> +
> #include
> #include
> #include
> --
> 2.33.0
--
Ville Syrjälä
Intel
if (ret)
> + if (ret) {
> + intel_dp->mst_mgr.cbs = NULL;
This is a bit ugly, but apart from that the idea seems good.
It *looks* like drm_dp_mst_topology_mgr_init() doesn't yet
invoke any of the callbacks so we could do the assignment after.
But that is a
quot;)) {
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index bd63760207b0..795775c9e2eb 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9734,6 +9734,10 @@ enum {
> #define AUD_PIN_BUF_CTL _MMIO(0x48414)
> #define AUD_PIN_BUF_ENABLE REG_BIT(31)
>
> +#define AUD_TS_CDCLK_M _MMIO(0x65ea0)
> +#define AUD_TS_CDCLK_M_EN REG_BIT(31)
> +#define AUD_TS_CDCLK_N _MMIO(0x65ea4)
> +
> /* Display Audio Config Reg */
> #define AUD_CONFIG_BE_MMIO(0x65ef0)
> #define HBLANK_EARLY_ENABLE_ICL(pipe)(0x1 << (20 - (pipe)))
> --
> 2.32.0
--
Ville Syrjälä
Intel
On Wed, May 05, 2021 at 11:54:35AM +0200, Werner Sembach wrote:
> Am 04.05.21 um 11:54 schrieb Ville Syrjälä:
>
> > On Mon, May 03, 2021 at 08:21:47PM +0200, Werner Sembach wrote:
> >> Couples the decission between RGB and YCbCr420 mode and the check if the
> >> p
On Wed, May 05, 2021 at 03:02:53PM +0200, Werner Sembach wrote:
>
> Am 05.05.21 um 14:15 schrieb Ville Syrjälä:
> > On Wed, May 05, 2021 at 11:54:35AM +0200, Werner Sembach wrote:
> >> Am 04.05.21 um 11:54 schrieb Ville Syrjälä:
> >>
> >>> On Mon, May 03
return 2;
> }
>
> There is no loop termination in the loop above, it will always read
> every member through the max level reported. And on GEN>=9 it will be 7, while
> the input array for several of the cases has only 5 me
On Thu, May 06, 2021 at 11:47:08AM +0300, Lisovskiy, Stanislav wrote:
> On Thu, May 06, 2021 at 10:38:36AM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > When scanning out NV12 if we at any time have the plane enabled
> > while the scaler is disabled we
ivers/gpu/drm/i915/i915_drv.h | 1 +
> 7 files changed, 59 insertions(+), 1 deletion(-)
>
> --
> 2.29.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailma
/* if we can't do 8,12bpc we may still be able to do 10bpc */
> - if (status != MODE_OK && DISPLAY_VER(dev_priv) >= 11)
> - status = hdmi_port_clock_valid(hdmi,
> intel_hdmi_port_clock(clock, 10),
> -true, has_hdmi_sink);
&g
r, pipe_config);
> + ret = intel_hdmi_compute_output_format(encoder, pipe_config,
> conn_state);
> if (ret)
> return ret;
>
> + if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420) {
> + ret = intel_pch_panel_fitting(pipe_config, conn_
if it is
> valid.
>
> This patchset is revision 7. Fixed a rebase issue in 1/3 and moved message
> from error output to debug output in 2/3.
Looks good and CI seem shappy.
Series pushed to drm-intel-next. Thanks.
--
Ville Syrjälä
Intel
_
--- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -11472,6 +11472,8 @@ void intel_modeset_init_hw(struct drm_i915_private
> *i915)
> {
> struct intel_cdclk_state *cdclk_state;
>
> + intel_dsm_enable_mux(i9
https://gitlab.freedesktop.org/drm/intel/-/issues/3081#note_890606
>
> Link contains details about the what and why of this change.
There's a patch on the list already
https://patchwork.freedesktop.org/patch/431109/?series=89502&rev=1
I suppose it needs a s/IVB_GT1/IVB/ to be co
pi if we had
multiple compositors signed up to implement it.
>
>
> Questions:
>
> I'm very curious about feedback from the dri-devel community. Would the
> concept outlaid above be accepted as new uAPI
> once it's fully implemented?
>
> Where would be the b
info [drm]] non_desktop set to 0
> kernel: i915 :00:02.0: [drm:intel_dp_set_edid [i915]] [CONNECTOR:95:DP-1]
> DFP max bpc 8, max dotclock 0, TMDS clock 25000-165000
That one seems to be saying that it's the adapter itself that's
telling us it can't handle >165MHz. W
v2: in the madvise ioctl we need to check if the object is currently
> shrinkable/purgeable, not if the object type supports shrinking
>
> Fixes: 0175969e489a ("drm/i915/gem: Use shrinkable status for unknown swizzle
> quirks")
> References: https://gitlab.freedes
tting(pipe_config, conn_state);
> + ret = intel_panel_fitting(pipe_config, conn_state);
Hmm. I though there was something a bit more subtle going on here...
Ah, I think I'm recalling the tv margin stuff that's still sitting
in my branch. That will
On Fri, May 14, 2021 at 05:28:40PM +, Souza, Jose wrote:
> On Tue, 2021-05-11 at 19:05 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Now that we have to tell intel_hdmi_mode_clock_valid() whether
> > we're asking about 4:4:4 or 4:2:0 output it c
1 = inb(VGA_SR_DATA);
> + outb(sr1 | 1 << 5, VGA_SR_DATA);
> + vga_put(pdev, VGA_RSRC_LEGACY_IO);
> + udelay(300);
> + }
>
> intel_de_write(dev_priv, vga_reg, VGA_DISP_DISABLE);
> intel_de_posting_re
t; - intel_psr_pause(): Pause current PSR. it deactivates current psr
> > > state.
> > > - intel_psr_resume(): Resume paused PSR without intel_crtc_state and
> > > drm_connector_state. It activates paused psr
> > > state.
> > &
On Tue, May 18, 2021 at 12:09:56PM +0100, Emil Velikov wrote:
> Hi Ville,
>
> On Mon, 17 May 2021 at 18:24, Ville Syrjälä
> wrote:
> >
> > On Sun, May 16, 2021 at 06:14:32PM +0100, Emil Velikov wrote:
> > > From: Vivek Das Mohapatra
> > >
> >
On Tue, May 18, 2021 at 04:24:26PM +0300, Jani Nikula wrote:
> Add a small helper to keep intel_plane_helper_funcs static.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/i9xx_plane.c | 2 +-
> drivers/gp
On Wed, May 19, 2021 at 12:34:05PM +0300, Pekka Paalanen wrote:
> On Wed, 12 May 2021 16:04:16 +0300
> Ville Syrjälä wrote:
>
> > On Wed, May 12, 2021 at 02:06:56PM +0200, Werner Sembach wrote:
> > > Hello,
> > >
> > > In addition to the existing &qu
On Wed, May 26, 2021 at 11:29:03AM +0300, Jani Nikula wrote:
> On ADL-P, it's possible to enable the stream splitter on pipe B in
> addition to pipe A.
>
> Bspec: 50174
> Cc: Uma Shankar
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
I have a feeling I reviewed t
ue, 0600) \
> - param(bool, enable_gvt, false, 0400)
> + param(bool, enable_gvt, false, IS_ENABLED(CONFIG_DRM_I915_GVT) ? 0400 :
> 0)
>
> #define MEMBER(T, member, ...) T member;
> struct i915_params {
> --
> 2.30.2
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
; > + struct drm_device *dev = &i915->drm;
> > + struct drm_crtc *crtc;
> > int i;
> >
> > + drm_for_each_crtc(crtc, dev)
> > + debugfs_create_file("dither", 0444, crtc->debugfs_entry, crtc,
> > +
REG_BIT(30)
> +#define UNDERRUN_RECOVERY_DISABLE_ADLP REG_BIT(30)
> +#define UNDERRUN_RECOVERY_ENABLE_DG2 REG_BIT(30)
> #define PIXEL_ROUNDING_TRUNC_FB_PASSTHRU (1 << 15)
> #define PER_PIXEL_ALPHA_BYPASS_EN (1 << 7)
>
> --
> 2.25.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
figuration, and typically on older panels
> + * these values correspond to the native resolution of the
> + * panel.
>*/
> limits.min_lane_count = limits.max_lane_count;
> limits.min_clock = limits.max_clock;
> --
> 2.31.1
--
Ville Syrjälä
Intel
y a no-op.
>
> Cc: Ville Syrjälä
> Cc: Jani Nikula
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 19 +++
> 1 file changed, 7 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/
ibly incomplete start at that:
git://github.com/vsyrjala/linux.git vbt_panel_type_pnp_id
Totally missing any and all restructuring of the VBT
parsing to happen after we have the EDID.
And apart from that we also have this horrible
chicken vs. egg issue:
1. need the panel type to get power sequencer delays
2. need to turn on the VDD to read the EDID
3. need the EDID to get the panel type
--
Ville Syrjälä
Intel
o IGT should be sent soon.
Blocking atomic commits instead of the current lightweight frontbuffer
interface sounds like a terrible plan. How unusable is X with this
approach?
--
Ville Syrjälä
Intel
On Wed, Aug 18, 2021 at 07:48:03PM +, Souza, Jose wrote:
> On Wed, 2021-08-18 at 17:55 +0300, Ville Syrjälä wrote:
> > On Tue, Aug 17, 2021 at 05:42:15PM -0700, José Roberto de Souza wrote:
> > > By now all the userspace applications should have migrated to atomic
> >
generally designed to support only a single
> + * clock and lane configuration, and typically on older panels
> + * these values correspond to the native resolution of the
> + * panel.
>*/
> limits.min_lane_count = limits.max_lane_count;
> limits.min_clock = limits.max_clock;
> --
> 2.32.0
--
Ville Syrjälä
Intel
static int ilk_check_fdi_lanes(struct drm_device *dev,
> enum pipe pipe,
> }
> }
>
> +u32 intel_fdi_link_freq(struct drm_i915_private *i915,
Could just change it to 'int' while at it.
Series is
Reviewed-by: Ville Syrjälä
> + const struct
return 135;
> + case DP_LINK_BW_20:
> + return 200;
> + default:
> + /* Spec says link_rate = link_bw * 0.27Gbps */
> + return link_bw * 27000;
> + }
> }
> EXPORT_SYMBOL(drm_dp_bw_code_to_link_rate);
>
> --
> 2.20.1
--
Ville Syrjälä
Intel
IZE])
> {
> - u8 dpcd_ext[6];
> + u8 dpcd_ext[DP_MAIN_LINK_CHANNEL_CODING + 1];
Why are we even reading less of this than the normal receiver caps?
> int ret;
>
> /*
> --
> 2.20.1
--
Ville Syrjälä
Intel
On Wed, Aug 18, 2021 at 09:10:39PM +0300, Jani Nikula wrote:
> The DP 2.0 128b/132b channel coding uses TX FFE presets instead of
> vswing and pre-emphasis.
>
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gp
bstraction than some obscure index.
>
> Rename the struct members while at it to ensure all the places are
> covered.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 30 -
> drivers/g
BUILD_BUG_ON(ARRAY_SIZE(sink_rates) >= ARRAY_SIZE(dp_rates)+3);
or something to remind people that we are dealing with a fixed size
array here?
Reviewed-by: Ville Syrjälä
> + }
> +
> intel_dp->num_sink_rates = i;
> }
>
> --
> 2.20.1
--
Ville Syrjälä
Intel
- link_config[1] = DP_SET_ANSI_8B10B;
> + link_config[1] = crtc_state->port_clock > 100 ?
Should this be >= ?
> + DP_SET_ANSI_128B132B : DP_SET_ANSI_8B10B;
> drm_dp_dpcd_write(&intel_dp->aux, DP_DOWNSPREAD_CTRL, link_config, 2);
>
> intel_dp->DP |= DP_PORT_EN;
> --
> 2.20.1
--
Ville Syrjälä
Intel
/* FDI */
> + pipe_config->output_types |= BIT(INTEL_OUTPUT_ANALOG);
> + break;
> + }
> + fallthrough; /* 128b/132b */
> case TRANS_DDI_MODE_SELECT_DP_MST:
> pipe_config->output_types |= BIT(INTEL_OUTPUT_DP_MST);
> pipe_config->lane_count =
> --
> 2.20.1
--
Ville Syrjälä
Intel
). Anyway, looking into it again the first bad commit is
>
> ef79d62b5ce5 ("drm/i915: Encapsulate dbuf state handling harder")
>
> With that commit the display is not detected anymore, one commit
> before that it still works. So this one seems to be broken.
>
> Ville,
l back to the old max strategy on failure")
> Fixes: a5c936add6a2 ("drm/i915/dp: Use slow and wide link training for
> everything")
> Suggested-by: Ville Syrjälä
> Signed-off-by: Kai-Heng Feng
Slapped a cc:stable on it and pushed to drm-intel-next. Thanks.
> -
land on upstream driver. The link train
> > failed
> > handling works for LTTPR only. But DPRX does not. Could you please consider
> > to have
> > this change as temporary solution? Thanks!
>
> I sent already fixing this, see
> https://lore.kernel.org/intel-gfx/202
On Mon, Aug 23, 2021 at 12:36:45PM +0300, Jani Nikula wrote:
> The unsigned doesn't help us here.
>
> Cc: Ville Syrjälä
> Suggested-by: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_fdi.c | 2
On Wed, Aug 25, 2021 at 12:49:25AM +, Souza, Jose wrote:
> On Thu, 2021-08-19 at 19:07 +0300, Ville Syrjälä wrote:
> > On Wed, Aug 18, 2021 at 07:48:03PM +, Souza, Jose wrote:
> > > On Wed, 2021-08-18 at 17:55 +0300, Ville Syrjälä wrote:
> > > > On Tue, Au
On Wed, Aug 25, 2021 at 03:47:12PM +0300, Ville Syrjälä wrote:
> On Wed, Aug 25, 2021 at 12:49:25AM +, Souza, Jose wrote:
> > On Thu, 2021-08-19 at 19:07 +0300, Ville Syrjälä wrote:
> > > On Wed, Aug 18, 2021 at 07:48:03PM +, Souza, Jose wrote:
> > > > On
gt; Cc: Stanislav Lisovskiy
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 4 +---
> drivers/gpu/drm/i915/i915_drv.h | 6 --
> 2 files changed, 1 insertion(+), 9 deletion
201 - 300 of 10908 matches
Mail list logo
