On Wed, 2021-12-01 at 02:33 -0800, Anusha Srivatsa wrote:
> Though, RPL-S is defined as subplatform of ADL-S, unlike
> ADL-S, it has GuC submission by default.
>
> v2: Remove extra parenthesis (Jani)
> v3: s/IS_RAPTORLAKE/IS_ADLS_RPLS (Jani)
>
Reviewed-by: José Roberto de Souza
> Cc: Jani
On Wed, 2021-12-01 at 17:25 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> There is no real point in having this two stage
> skl_program_plane*() vs. skl_plane_update*() wrapper stuff.
> All we need to do is determine the correct color plane and
> we're done.
Reviewed-by: José Roberto de
On Wed, 2021-12-01 at 17:25 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add a few small helpers to calculate the color key register
> values. Cleans up skl_program_plane_arm() a bit.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
> ---
>
On Wed, 2021-12-01 at 17:25 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Extract the PLANE_AUX_DIST stuff into a small helper to
> dclutter skl_program_plane_arm() a bit.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
> ---
>
On Wed, 2021-12-01 at 17:25 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Polish the skl+ universal plane register defines by
> using REG_BIT() & co.
>
> The defines are also currently spread around in some
> semi-random fashion. Collect them up into one place.
>
> Signed-off-by: Ville
On Wed, 2021-12-01 at 17:25 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Replace the "sizes are 0 based" stuff with just straight
> up -1 where needed. Less confusing all around.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_sprite.c | 26
On Wed, 2021-12-01 at 17:25 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Rename the PLANE_CUS_CTL Y plane selection bits to actually
> say "Y plane".
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 8
On Wed, 2021-12-01 at 17:25 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's just stick to 32bit mmio accesses so we can get rid
> of the bare "uncore" reg access in display code. The register
> are defined as 32bit in the spec anyway.
>
> We could define a 64bit "de" variant I
On Wed, 2021-12-01 at 17:25 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Rename the YUV byte order bits to be a bit more consistent.
Why rename bits not used? Would be better already nuke it.
Anyways up to you.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
>
On Sun, 2021-10-10 at 17:40 +0530, Animesh Manna wrote:
> As panel replay feature similar to PSR feature of EDP panel, so currently
> utilized existing psr framework for panel replay.
>
> v1: RFC version.
> v2: optimized code, pr_enabled and pr_dpcd variable removed. [Jose]
> v3:
> - code
On Sun, 2021-10-10 at 17:40 +0530, Animesh Manna wrote:
> DPCD register definition added to check and enable panel replay
> capability of the sink.
>
> Signed-off-by: Animesh Manna
> ---
> include/drm/drm_dp_helper.h | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git
On Tue, 2021-11-16 at 09:48 -0800, Matt Roper wrote:
> From: Matt Atwood
>
> Extend existing workaround 1409120013 to DG2.
>
> Cc: José Roberto de Souza
> Signed-off-by: Matt Atwood
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/intel_pm.c | 4 ++--
> 1 file changed, 2
On Fri, 2021-11-19 at 06:09 -0800, José Roberto de Souza wrote:
> This workarounds are causing hangs, because I missed the fact that it
> needs to be enabled for all cases and disabled when doing a resolve
> pass.
>
> So KMD only needs to whitelist it and UMD will be the one setting it
> on per
On Wed, 2021-11-10 at 16:05 +, Hogander, Jouni wrote:
> On Tue, 2021-11-09 at 18:17 +0000, Souza, Jose wrote:
> > On Tue, 2021-11-09 at 10:31 +, Hogander, Jouni wrote:
> > > On Mon, 2021-11-08 at 13:38 -0800, José Roberto de Souza wrote:
> > > > When a p
On Fri, 2021-11-05 at 19:55 +0200, Ville Syrjälä wrote:
> On Fri, Nov 05, 2021 at 05:44:21PM +0000, Souza, Jose wrote:
> > On Fri, 2021-11-05 at 15:46 +0200, Ville Syrjälä wrote:
> > > On Thu, Nov 04, 2021 at 05:56:52PM +, Souza, Jose wrote:
> > > > On Thu, 20
On Tue, 2021-11-09 at 10:31 +, Hogander, Jouni wrote:
> On Mon, 2021-11-08 at 13:38 -0800, José Roberto de Souza wrote:
> > When a plane with a multiplanar format is added to the state by
> > drm_atomic_add_affected_planes(), only the UV plane is
> > added, so a
On Mon, 2021-11-08 at 22:46 +, Sripada, Radhakrishna wrote:
> CI IGT reported some failures but they do not look to be related to the
> changes proposed.
Pushed to drm-intel-next.
>
> Thanks,
> Radhakrishna(RK) Sripada
>
> From: Patchwork
> Sent: Friday, November 5, 2021 6:51 PM
> To:
On Fri, 2021-11-05 at 17:37 -0700, Radhakrishna Sripada wrote:
> The earlier update to BW formulae broke ADL-P. Include
> GEN13 to use TGL path for BW parameters.
include display 13.
With that:
Reviewed-by: José Roberto de Souza
>
> Fixes: c64a9a7c05be drm/i915: Update memory bandwidth
On Thu, 2021-11-04 at 06:40 +, Patchwork wrote:
> Patch Details
> Series: drm/i915/display/adlp: Disable underrun recovery
> URL: https://patchwork.freedesktop.org/series/96548/
> State:success
> Details:
>
On Fri, 2021-11-05 at 15:46 +0200, Ville Syrjälä wrote:
> On Thu, Nov 04, 2021 at 05:56:52PM +0000, Souza, Jose wrote:
> > On Thu, 2021-11-04 at 16:10 +0200, Ville Syrjälä wrote:
> > > On Tue, Nov 02, 2021 at 12:32:14PM -0700, José Roberto de Souza wrote:
> > > > Cha
On Thu, 2021-11-04 at 16:10 +0200, Ville Syrjälä wrote:
> On Tue, Nov 02, 2021 at 12:32:14PM -0700, José Roberto de Souza wrote:
> > Changing the buffer in the middle of the scanout then entering an
> > period of flip idleness will cause part of the previous buffer being
> > diplayed to user when
On Wed, 2021-10-20 at 05:10 +, Patchwork wrote:
> Patch Details
> Series: series starting with [1/3] drm/i915: Add struct to hold IP
> version
> URL: https://patchwork.freedesktop.org/series/96038/
> State:failure
> Details:
>
On Mon, 2021-10-25 at 12:04 +0300, Jani Nikula wrote:
> On Fri, 22 Oct 2021, Lucas De Marchi wrote:
> > On Thu, Oct 21, 2021 at 04:11:26PM +0300, Jani Nikula wrote:
> > > On Wed, 20 Oct 2021, "Souza, Jose" wrote:
> > > > On Wed, 2021-10-20 at 12:47 +0300,
On Mon, 2021-11-01 at 16:36 -0400, Rodrigo Vivi wrote:
> On Fri, Oct 29, 2021 at 05:18:01PM -0700, José Roberto de Souza wrote:
> > Changing the buffer in the middle of the scanout then entering an
> > period of flip idleness will cause part of the previous buffer being
> > diplayed to user when
On Mon, 2021-11-01 at 12:11 +0200, Ville Syrjälä wrote:
> On Fri, Oct 29, 2021 at 09:57:02PM +0000, Souza, Jose wrote:
> > On Wed, 2021-10-06 at 23:49 +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Prepare for per-lane drive settings by que
On Sat, 2021-10-30 at 07:44 +, Patchwork wrote:
> Patch Details
> Series: drm/i915/display: Check async flip state of every crtc and
> plane once (rev2)
> URL: https://patchwork.freedesktop.org/series/96402/
> State:success
> Details:
>
On Fri, 2021-10-29 at 22:55 +, Souza, Jose wrote:
> On Fri, 2021-10-29 at 09:22 +0300, Ville Syrjälä wrote:
> > On Thu, Oct 28, 2021 at 08:18:48PM +0000, Souza, Jose wrote:
> > > On Thu, 2021-10-28 at 20:46 +0300, Ville Syrjälä wrote:
> > > > On Thu, Oct 28, 2
On Fri, 2021-10-29 at 09:22 +0300, Ville Syrjälä wrote:
> On Thu, Oct 28, 2021 at 08:18:48PM +0000, Souza, Jose wrote:
> > On Thu, 2021-10-28 at 20:46 +0300, Ville Syrjälä wrote:
> > > On Thu, Oct 28, 2021 at 05:43:51PM +, Souza, Jose wrote:
> > > > On Thu, 20
On Wed, 2021-10-06 at 23:49 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Now that the link buf_trans, link training, and the
> combo/mg/dkl/snps phy programming are all fixed up we can
> allow per-lane DP drive settings on icl+. Make it so.
Reviewed-by: José Roberto de Souza
>
>
On Wed, 2021-10-06 at 23:49 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Streamline the code by using intel_de_rmw().
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 44 ++--
> 1 file
On Wed, 2021-10-06 at 23:49 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Streamline the code by using intel_de_rmw().
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 36 +++-
> 1 file
On Wed, 2021-10-06 at 23:49 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Streamline the code by using intel_de_rmw().
Some lines above 100 cols, other than that:
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c |
On Wed, 2021-10-06 at 23:49 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Prepare for per-lane drive settings by querying the desired vswing
> level per-lane.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_snps_phy.c |
On Wed, 2021-10-06 at 23:49 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Prepare for per-lane drive settings by querying the desired vswing
> level per-lane.
>
> Note that the code only does two loops, with each one writing the
> levels for two TX lanes. The register offsets also look
On Wed, 2021-10-06 at 23:49 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Prepare for per-lane drive settings by querying the desired vswing
> level per-lane.
>
> Note that the code only does two loops, with each one writing the
> levels for two TX lanes.
>
> Signed-off-by: Ville
On Wed, 2021-10-06 at 23:49 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Prepare for per-lane drive settings by querying the desired vswing
> level per-lane.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 7 ++-
> 1 file changed, 6
On Wed, 2021-10-06 at 23:49 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Program each TX lane individually so that we can start to use per-lane
> drive settings.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 28 ++--
> 1 file
On Fri, 2021-10-29 at 08:23 +, Patchwork wrote:
Patch Details
Series: drm/i915/adlp: Implement workaround 16013190616
URL:https://patchwork.freedesktop.org/series/96405/
State: failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21482/index.html
CI Bug Log -
On Fri, 2021-10-22 at 15:56 +, Patchwork wrote:
Patch Details
Series: Selective fetch support for biplanar formats
URL:https://patchwork.freedesktop.org/series/96113/
State: success
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21401/index.html
CI Bug Log - changes
On Thu, 2021-10-21 at 13:10 +0300, Jouni Högander wrote:
> This reverts commit 1f61f0655b95d5b89589390e6f83c4a61d9b1e8d.
>
> Now we are supporting selective fetch for biplanar formats. We can revert WA
> patch which forced using full fetch for biplanar formats.
>
Reviewed-by: José Roberto de
On Thu, 2021-10-21 at 13:10 +0300, Jouni Högander wrote:
> Biplanar formats are using two planes (Y and UV). This patch adds handling
> of Y selective fetch area by utilizing existing linked plane mechanism.
> Also UV plane Y offset configuration is modified according to Bspec.
>
> Signed-off-by:
On Fri, 2021-10-29 at 09:24 +0300, Ville Syrjälä wrote:
> On Thu, Oct 28, 2021 at 01:34:18PM -0700, José Roberto de Souza wrote:
> > For every crtc in state, intel_atomic_check_async() was checking all
> > the crtc and plane states again.
> >
> > Cc: Karthik B S
> > Cc: Vandita Kulkarni
> > Cc:
On Fri, 2021-10-22 at 21:26 +, Yokoyama, Caz wrote:
> On Wed, 2021-10-20 at 19:19 +0000, Souza, Jose wrote:
> > On Wed, 2021-10-20 at 15:00 +, Yokoyama, Caz wrote:
> > > On Tue, 2021-10-19 at 17:23 -0700, José Roberto de Souza wrote:
> > > > Adding a structu
On Thu, 2021-10-28 at 20:46 +0300, Ville Syrjälä wrote:
> On Thu, Oct 28, 2021 at 05:43:51PM +0000, Souza, Jose wrote:
> > On Thu, 2021-10-28 at 20:38 +0300, Ville Syrjälä wrote:
> > > On Thu, Oct 28, 2021 at 05:02:41PM +, Souza, Jose wrote:
> > > > On Thu, 20
On Thu, 2021-10-28 at 20:38 +0300, Ville Syrjälä wrote:
> On Thu, Oct 28, 2021 at 05:02:41PM +0000, Souza, Jose wrote:
> > On Thu, 2021-10-28 at 16:32 +0300, Ville Syrjälä wrote:
> > > On Wed, Oct 27, 2021 at 11:48:55AM -0700, José Roberto de Souza wrote:
> > > >
On Thu, 2021-10-28 at 16:32 +0300, Ville Syrjälä wrote:
> On Wed, Oct 27, 2021 at 11:48:55AM -0700, José Roberto de Souza wrote:
> > Async flips are not supported by selective fetch and we had a check
> > for that but that check was only executed when doing modesets.
> > So moving this check to
On Fri, 2021-10-22 at 13:32 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's disable planes on all pipes affected by the modeset before
> we start doing the actual modeset. This means we have less
> random planes enabled during the modeset, and it also mirrors
> what we already do
On Fri, 2021-10-22 at 13:32 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Disabling planes in the middle of the modeset seuqnece does not make
> sense since userspace can anyway disable planes before the modeset
> even starts. So when the modeset seuqence starts the set of enabled
>
On Wed, 2021-10-06 at 06:49 +, Patchwork wrote:
> Patch Details
> Series: drm/i915/display: Wait PSR2 get out of deep sleep to update
> pipe (rev3)
> URL: https://patchwork.freedesktop.org/series/95309/
> State:failure
> Details:
>
On Wed, 2021-10-20 at 05:49 +, Patchwork wrote:
> Patch Details
> Series: series starting with [1/2] drm/i915/display: Rename
> POWER_DOMAIN_DPLL_DC_OFF to POWER_DOMAIN_DC_OFF
> URL: https://patchwork.freedesktop.org/series/96039/
> State:failure
> Details:
>
On Wed, 2021-10-20 at 12:47 +0300, Jani Nikula wrote:
> On Tue, 19 Oct 2021, José Roberto de Souza wrote:
> > The constant platform display version is not using this new struct but
> > the runtime variant will definitely use it.
>
> Cc: Some more folks to hijack this thread. Sorry! ;)
>
> We
On Wed, 2021-10-20 at 15:00 +, Yokoyama, Caz wrote:
> On Tue, 2021-10-19 at 17:23 -0700, José Roberto de Souza wrote:
> > Adding a structure to standardize access to IP versioning as future
> > platforms will have this information populated at runtime.
> >
> > The constant platform display
On Tue, 2021-10-19 at 14:43 +0300, Jani Nikula wrote:
> This reverts commit 05734ca2a8f76c9eb3890b3c9dfc3467f03105c1.
>
> It's not graceful, instead it leads to boot time warning splats in the
> case it is supposed to handle gracefully. Apparently the BIOS/GOP
> enabling the port we end up
On Fri, 2021-10-15 at 15:10 +0300, Imre Deak wrote:
> Reading out the DP encoders' DPCD during booting or resume is only
> required for enabled encoders: such encoders may be modesetted during
> the initial commit and the link training this involves depends on an
> initialized DPCD. For DDI
On Wed, 2021-10-13 at 23:39 +0300, Gwan-gyeong Mun wrote:
>
> On 10/11/21 11:53 PM, Souza, Jose wrote:
> > On Thu, 2021-10-07 at 12:31 +0300, Gwan-gyeong Mun wrote:
> > >
> > > On 10/6/21 11:04 PM, Souza, Jose wrote:
> > > > On Wed, 2021-1
On Wed, 2021-10-13 at 22:31 +0300, Ville Syrjälä wrote:
> On Wed, Oct 13, 2021 at 07:17:14PM +0000, Souza, Jose wrote:
> > On Wed, 2021-10-13 at 12:32 +0300, Ville Syrjälä wrote:
> > > On Tue, Oct 12, 2021 at 06:00:46PM -0700, José Roberto de Souza wrote:
> > > > Th
On Wed, 2021-10-13 at 12:32 +0300, Ville Syrjälä wrote:
> On Tue, Oct 12, 2021 at 06:00:46PM -0700, José Roberto de Souza wrote:
> > This memory frequency calculated is only used to check if it is zero,
> > what is not useful as it will never actually be zero.
> >
> > Also the calculation is
On Tue, 2021-10-12 at 18:00 -0700, José Roberto de Souza wrote:
> This memory frequency calculated is only used to check if it is zero,
> what is not useful as it will never actually be zero.
>
> Also the calculation is wrong, we should be checking other bit to
> select the appropriate frequency
On Tue, 2021-10-12 at 14:20 -0700, Matt Roper wrote:
> On Fri, Oct 08, 2021 at 01:58:55PM -0700, José Roberto de Souza wrote:
> > All display 9 and display 10 platforms has only 4 bits for the memory
> > frequency but display 11 platforms it changes to 8 bits.
> >
> > Display 9 platforms has
On Thu, 2021-10-07 at 12:31 +0300, Gwan-gyeong Mun wrote:
>
> On 10/6/21 11:04 PM, Souza, Jose wrote:
> > On Wed, 2021-10-06 at 11:50 +0300, Gwan-gyeong Mun wrote:
> > >
> > > On 10/6/21 2:18 AM, José Roberto de Souza wrote:
> > > > Alderlake-P was gett
On Fri, 2021-10-08 at 13:58 -0700, José Roberto de Souza wrote:
> All display 9 and display 10 platforms has only 4 bits for the memory
> frequency but display 11 platforms it changes to 8 bits.
>
> Display 9 platforms has another register in bits 7:4 that prevents us
> to have a single mask.
>
On Thu, 2021-10-07 at 16:32 -0700, Lucas De Marchi wrote:
> Nothing from intel-mid.h and this is only available on x86, so remove it
> as we prepare support for other architectures.
Whole series is
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Lucas De Marchi
> ---
>
On Wed, 2021-10-06 at 11:50 +0300, Gwan-gyeong Mun wrote:
>
> On 10/6/21 2:18 AM, José Roberto de Souza wrote:
> > Alderlake-P was getting 'max time under evasion' messages when PSR2
> > is enabled, this is due PIPE_SCANLINE/PIPEDSL returning 0 over a
> > period of time longer than
On Tue, 2021-10-05 at 23:38 +0300, Jani Nikula wrote:
> On Tue, 05 Oct 2021, "Souza, Jose" wrote:
> > On Tue, 2021-10-05 at 20:56 +0300, Jani Nikula wrote:
> > > For the time being, neither the power sequencer nor the backlight code
> > > properly support
On Tue, 2021-10-05 at 20:56 +0300, Jani Nikula wrote:
> For the time being, neither the power sequencer nor the backlight code
> properly support two eDP panels simultaneously. While the software
> states will be independent, the same sets of registers will be used for
> both eDP panels,
On Thu, 2021-09-30 at 20:36 +, Patchwork wrote:
Patch Details
Series: drm/i915/bdb: Fix version check (rev3)
URL:https://patchwork.freedesktop.org/series/94871/
State: success
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21205/index.html
CI Bug Log - changes from
On Thu, 2021-09-30 at 10:35 +0300, Gwan-gyeong Mun wrote:
>
> On 9/30/21 3:14 AM, José Roberto de Souza wrote:
> > The Wa_14014971508 is required to fix scanout when a feature that i915
> > do not support is enabled and this feature is not planned to be enabled
> > for adlp.
> >
> > Keeping this
On Thu, 2021-09-30 at 10:17 +0300, Gwan-gyeong Mun wrote:
>
> On 9/30/21 3:14 AM, José Roberto de Souza wrote:
> > When PSR2 selective fetch is enabled writes to CURSURFLIVE alone do
> > not causes the panel to be updated when doing frontbuffer rendering.
> >
> > From what I was able to figure
On Thu, 2021-09-30 at 15:46 +0200, Lukasz Majczak wrote:
> With patch "drm/i915/vbt: Fix backlight parsing for VBT 234+"
> the size of bdb_lfp_backlight_data structure has been increased,
> causing if-statement in the parse_lfp_backlight function
> that comapres this structure size to the one
On Wed, 2021-09-29 at 16:28 +0300, Imre Deak wrote:
> Atm during driver loading and system resume TypeC ports are accessed
> before their HW/SW state is synced. Move the TypeC port sanitization to
> the encoder's sync_state hook to fix this.
>
> v2: Handle the encoder disabled case in
On Thu, 2021-09-23 at 18:49 +0200, Lukasz Majczak wrote:
> With patch "drm/i915/vbt: Fix backlight parsing for VBT 234+"
> the size of bdb_lfp_backlight_data structure has been increased,
> causing if-statement in the parse_lfp_backlight function
> that comapres this structure size to the one
On Tue, 2021-09-28 at 23:38 +0300, Imre Deak wrote:
> On Tue, Sep 28, 2021 at 11:29:49PM +0300, Souza, Jose wrote:
> > On Tue, 2021-09-28 at 23:08 +0300, Imre Deak wrote:
> > > On Tue, Sep 28, 2021 at 11:02:37PM +0300, Souza, Jose wrote:
> > > > On Tue, 2021-09-28 a
On Tue, 2021-09-21 at 03:23 +0300, Imre Deak wrote:
> The PHY ownership release->AUX PW disable steps during a modeset
> disable->PHY disconnect sequence can hang the system if the PHY
> disconnect happens after disabling the PHY's PLL. The spec doesn't
> require a specific order for these two
On Tue, 2021-09-21 at 03:23 +0300, Imre Deak wrote:
> After the previous patch the driver holds a power domain blocking
> TC-cold whenever the port is locked, so we can remove the extra blocking
> around the lock/unlock sequence.
Reviewed-by: José Roberto de Souza
>
> Cc: José Roberto de Souza
On Tue, 2021-09-21 at 03:23 +0300, Imre Deak wrote:
> So far TC-cold was blocked only for the duration of TypeC mode resets.
> The DP-alt and legacy modes require TC-cold to be blocked also whenever
> the port is in use (AUX transfers, enable modeset), and this was ensured
> by the held PHY
On Tue, 2021-09-28 at 13:52 +0300, Imre Deak wrote:
> On Tue, Sep 28, 2021 at 01:02:21AM +0300, Souza, Jose wrote:
> > On Tue, 2021-09-21 at 03:23 +0300, Imre Deak wrote:
> > > While a TypeC port mode is locked a DISPLAY_CORE power domain reference
> > > is held, whi
On Tue, 2021-09-21 at 03:23 +0300, Imre Deak wrote:
> For the ADL-P TBT mode the spec doesn't require blocking TC-cold by
> using the legacy AUX power domain. To avoid the timeouts that this would
> cause during PHY disconnect/reconnect sequences (which will be more
> frequent after a follow-up
On Tue, 2021-09-28 at 23:08 +0300, Imre Deak wrote:
> On Tue, Sep 28, 2021 at 11:02:37PM +0300, Souza, Jose wrote:
> > On Tue, 2021-09-28 at 22:55 +0300, Imre Deak wrote:
> > > On Tue, Sep 28, 2021 at 10:45:50PM +0300, Souza, Jose wrote:
> > > > > > [...]
>
On Tue, 2021-09-28 at 22:55 +0300, Imre Deak wrote:
> On Tue, Sep 28, 2021 at 10:45:50PM +0300, Souza, Jose wrote:
> > > > [...]
> > > > Would not be possible to use TC_PORT_DISCONNECTED when really
> > > > disconnected
On Tue, 2021-09-28 at 22:34 +0300, Imre Deak wrote:
> On Tue, Sep 28, 2021 at 10:18:25PM +0300, Souza, Jose wrote:
> > On Tue, 2021-09-28 at 00:46 +0300, Imre Deak wrote:
> > > On Tue, Sep 28, 2021 at 12:16:45AM +0300, Souza, Jose wrote:
> > > > On Tue, 2021-09-21 a
On Tue, 2021-09-28 at 00:46 +0300, Imre Deak wrote:
> On Tue, Sep 28, 2021 at 12:16:45AM +0300, Souza, Jose wrote:
> > On Tue, 2021-09-21 at 03:23 +0300, Imre Deak wrote:
> > > A follow-up change will start to disconnect/re-connect PHYs around AUX
> > > transfers
On Tue, 2021-09-28 at 03:45 +0300, Imre Deak wrote:
> On Tue, Sep 28, 2021 at 03:14:45AM +0300, Souza, Jose wrote:
> > On Tue, 2021-09-28 at 02:51 +0300, Imre Deak wrote:
> > > On Tue, Sep 28, 2021 at 02:33:27AM +0300, Souza, Jose wrote:
> > > > On Tue, 2021-09-28 a
On Tue, 2021-09-28 at 02:51 +0300, Imre Deak wrote:
> On Tue, Sep 28, 2021 at 02:33:27AM +0300, Souza, Jose wrote:
> > On Tue, 2021-09-28 at 01:28 +0300, Imre Deak wrote:
> > > On Tue, Sep 28, 2021 at 01:21:21AM +0300, Souza, Jose wrote:
> > > > On Tue, 2021-09-28 a
On Tue, 2021-09-28 at 01:28 +0300, Imre Deak wrote:
> On Tue, Sep 28, 2021 at 01:21:21AM +0300, Souza, Jose wrote:
> > On Tue, 2021-09-28 at 01:13 +0300, Imre Deak wrote:
> > > On Tue, Sep 28, 2021 at 12:56:24AM +0300, Souza, Jose wrote:
> > > > On Tue, 2021-09-21 a
On Tue, 2021-09-28 at 01:13 +0300, Imre Deak wrote:
> On Tue, Sep 28, 2021 at 12:56:24AM +0300, Souza, Jose wrote:
> > On Tue, 2021-09-21 at 03:23 +0300, Imre Deak wrote:
> > > A follow-up change will select the TC-cold blocking power domain based
> > > on the TypeC
On Tue, 2021-09-21 at 03:23 +0300, Imre Deak wrote:
> While a TypeC port mode is locked a DISPLAY_CORE power domain reference
> is held, which implies a runtime PM ref. By removing the ICL !legacy
> port special casing, a TC_COLD_OFF power domain reference will be taken
> for such ports, which
On Tue, 2021-09-21 at 03:23 +0300, Imre Deak wrote:
> A follow-up change will select the TC-cold blocking power domain based
> on the TypeC mode, prepare for that here.
>
> Also bring intel_tc_cold_requires_aux_pw() earlier to its logical place
> for readability.
>
> No functional change.
>
>
On Tue, 2021-09-21 at 03:23 +0300, Imre Deak wrote:
> A follow-up change will start to disconnect/re-connect PHYs around AUX
> transfers and modeset enable/disables. To prepare for that add a new
> TypeC PHY disconnected mode, to help tracking the TC-cold blocking power
> domain status (no power
On Tue, 2021-09-21 at 03:23 +0300, Imre Deak wrote:
> A follow-up patch will disconnect/reconnect PHYs around AUX transfers
> and modeset enable/disables. To prepare for that and make things
> consistent for all TypeC modes stop connecting the PHY in legacy mode
> without a sink being connected.
On Tue, 2021-09-21 at 03:23 +0300, Imre Deak wrote:
> Instead of directly accessing the TypeC port internal struct members,
> add/use helpers to retrieve the corresponding properties.
>
> No functional change.
Reviewed-by: José Roberto de Souza
>
> Cc: José Roberto de Souza
> Signed-off-by:
On Fri, 2021-09-24 at 17:39 +0300, Ville Syrjälä wrote:
> On Thu, Sep 23, 2021 at 12:46:13PM -0700, José Roberto de Souza wrote:
> > intel_prepare_plane_fb() was calling i915_gem_object_flush_frontbuffer()
> > with the generic ORIGIN_DIRTYFB, what was causing
> > PSR, FBC and DRRS to do their
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
> > was enabled, this is due PIPE_SCANLINE/PIPEDSL returning 0 over a
> > period of time longer
On Tue, 2021-09-21 at 03:23 +0300, Imre Deak wrote:
> On ADL-P the PHY ready/complete flag is always set even in TBT-alt mode.
> To avoid taking the PHY ownership and the following spurious "PHY sudden
> disconnect" messages on this platform when connecting the PHY in TBT
> mode, check if there is
On Tue, 2021-09-21 at 03:23 +0300, Imre Deak wrote:
> Waiting for the PHY complete flag to clear when releasing the PHY
> ownership was add in
>
> commit ddec362724f9 ("drm/i915: Wait for TypeC PHY complete flag to clear in
> safe mode")
>
> This isn't required by the spec, the vague idea was
On Tue, 2021-09-21 at 03:23 +0300, Imre Deak wrote:
> On ADL-P the PHY ready (aka status complete on other platforms) flag is
> always set, besides when a DP-alt, legacy sink is connected also when a
> TBT sink is connected or nothing is connected. So assume the PHY to be
> connected when both the
On Tue, 2021-09-21 at 03:23 +0300, Imre Deak wrote:
> Atm during driver loading and system resume TypeC ports are accessed
> before their HW/SW state is synced. Move the TypeC port sanitization to
> the encoder's sync_state hook to fix this.
>
> Fixes: f9e76a6e68d3 ("drm/i915: Add an encoder hook
On Thu, 2021-09-23 at 16:27 +0300, Gwan-gyeong Mun wrote:
>
> On 9/17/21 11:52 PM, José Roberto de Souza wrote:
> > Alderlake-P was getting 'max time under evasion' messages when PSR2
> > was enabled, this is due PIPE_SCANLINE/PIPEDSL returning 0 over a
> > period of time longer than
On Wed, 2021-09-22 at 16:41 +0300, Ville Syrjälä wrote:
> On Tue, Sep 21, 2021 at 10:37:53PM +0000, Souza, Jose wrote:
> > On Tue, 2021-09-21 at 16:35 +0300, Ville Syrjälä wrote:
> > > On Fri, Sep 17, 2021 at 09:33:59PM +, Souza, Jose wrote:
> > > > On Fri, 20
; Sent: Tuesday, September 21, 2021 6:11 AM
> > > To: intel-gfx@lists.freedesktop.org
> > > Cc: Mun, Gwan-gyeong ; Souza, Jose
> > >
> > > Subject: [Intel-gfx] [PATCH v3 3/3] drm/i915/display/psr: Do full fetch
> > > when
> > > handling biplanar format
On Tue, 2021-09-21 at 16:35 +0300, Ville Syrjälä wrote:
> On Fri, Sep 17, 2021 at 09:33:59PM +0000, Souza, Jose wrote:
> > On Fri, 2021-09-17 at 20:49 +0300, Ville Syrjälä wrote:
> > > On Fri, Sep 17, 2021 at 05:02:21PM +, Souza, Jose wrote:
> > > > On Fri, 20
201 - 300 of 1595 matches
Mail list logo
