[Intel-gfx] [PATCH i-g-t v4] lib/i915/perf: Fix non-card0 processing

IGT i915/perf library functions now always operate on sysfs perf attributes of card0 device node, no matter which DRM device fd a user passes. The intention was to always switch to primary device node if a user passes a render device node fd, but that breaks handling of non-card0 devices. If a us

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Disable PSR2 sel fetch in TGL pre-production

== Series Details == Series: drm/i915/display: Disable PSR2 sel fetch in TGL pre-production URL : https://patchwork.freedesktop.org/series/89825/ State : success == Summary == CI Bug Log - changes from CI_DRM_10050_full -> Patchwork_20074_full ==

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove redundant DIRTYFB frontbuffer flushes

== Series Details == Series: drm/i915: Remove redundant DIRTYFB frontbuffer flushes URL : https://patchwork.freedesktop.org/series/89824/ State : success == Summary == CI Bug Log - changes from CI_DRM_10050_full -> Patchwork_20073_full Summ

Re: [Intel-gfx] [PATCH 02/11] drm/i915/xelpd: add XE_LPD display characteristics

On Wed, 2021-04-14 at 18:51 +0300, Imre Deak wrote: > From: Matt Roper > > Let's start preparing for upcoming platforms that will use an XE_LPD > design. > > v2: > - Use the now-preferred "XE_LPD" term to refer to this design > - Utilize DISPLAY_VER() rather than a feature flag > - Drop unuse

Re: [Intel-gfx] [PATCH 04/11] drm/i915/adl_p: ADL_P device info enabling

On Wed, 2021-04-14 at 18:52 +0300, Imre Deak wrote: > From: Clinton Taylor > > Add ADL-P to the device_info table and support MACROS. Reviewed-by: José Roberto de Souza > > Bspec: 49185, 55372, 55373 > Cc: Matt Atwood > Cc: Matt Roper > Signed-off-by: Clinton Taylor > Signed-off-by: Matt R

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/fbc: Don't nuke manually around flips

== Series Details == Series: drm/i915/fbc: Don't nuke manually around flips URL : https://patchwork.freedesktop.org/series/89823/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10050_full -> Patchwork_20072_full Summary

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Disable PSR2 sel fetch in TGL pre-production

== Series Details == Series: drm/i915/display: Disable PSR2 sel fetch in TGL pre-production URL : https://patchwork.freedesktop.org/series/89825/ State : success == Summary == CI Bug Log - changes from CI_DRM_10050 -> Patchwork_20074 Summar

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove redundant DIRTYFB frontbuffer flushes

== Series Details == Series: drm/i915: Remove redundant DIRTYFB frontbuffer flushes URL : https://patchwork.freedesktop.org/series/89824/ State : success == Summary == CI Bug Log - changes from CI_DRM_10050 -> Patchwork_20073 Summary --

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Nuke display error state

== Series Details == Series: drm/i915: Nuke display error state URL : https://patchwork.freedesktop.org/series/89822/ State : success == Summary == CI Bug Log - changes from CI_DRM_10050_full -> Patchwork_20071_full Summary --- **WAR

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/fbc: Don't nuke manually around flips

== Series Details == Series: drm/i915/fbc: Don't nuke manually around flips URL : https://patchwork.freedesktop.org/series/89823/ State : success == Summary == CI Bug Log - changes from CI_DRM_10050 -> Patchwork_20072 Summary --- **S

[Intel-gfx] [PATCH] drm/i915/display: Disable PSR2 sel fetch in TGL pre-production

The implementation of two workarounds are missing causing failures in CI with pre-production HW. Cc: Gwan-gyeong Mun Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/display/intel_psr.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_ps

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/fbc: Don't nuke manually around flips

== Series Details == Series: drm/i915/fbc: Don't nuke manually around flips URL : https://patchwork.freedesktop.org/series/89823/ State : warning == Summary == $ dim checkpatch origin/drm-tip dd1d012765cd drm/i915/fbc: Don't nuke manually around flips -:82: ERROR:MISSING_SIGN_OFF: Missing Sign

[Intel-gfx] [PATCH] drm/i915: Remove redundant DIRTYFB frontbuffer flushes

From: Ville Syrjälä The frontbuffer tracking code is supposed to handle plane updates via ORIGIN_FLIP. Right now we're also doing internal ORIGIN_DIRTYFB flushed as well. Can't see the point so get rid of them. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_display.c | 3 -

[Intel-gfx] [PATCH] drm/i915/fbc: Don't nuke manually around flips

From: Ville Syrjälä Apparently we have discovered another way to hit the dreaded top of screen FBC corruption on GLK. Previously we thought it was limited to some combination of FBC nuke+disable+plane update during the same frame, for which we have the extra vblank wait as a workaround. But looks

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Nuke display error state

== Series Details == Series: drm/i915: Nuke display error state URL : https://patchwork.freedesktop.org/series/89822/ State : success == Summary == CI Bug Log - changes from CI_DRM_10050 -> Patchwork_20071 Summary --- **SUCCESS**

Re: [Intel-gfx] [PATCH 2/3] Restructure output format computation for better expandability

Hi Werner, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on next-20210505] [cannot apply to v5.12] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use

Re: [Intel-gfx] [PATCH 8/8] drm/modifiers: Enforce consistency between the cap an IN_FORMATS

On Tue, Apr 27, 2021 at 11:20 AM Daniel Vetter wrote: > > It's very confusing for userspace to have to deal with inconsistencies > here, and some drivers screwed this up a bit. Most just ommitted the > format list when they meant to say that only linear modifier is > allowed, but some also meant t

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm + usb-type-c: Add support for out-of-band hotplug notification (rev3)

== Series Details == Series: drm + usb-type-c: Add support for out-of-band hotplug notification (rev3) URL : https://patchwork.freedesktop.org/series/89604/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10049_full -> Patchwork_20068_full ==

[Intel-gfx] [PATCH] drm/i915: Nuke display error state

From: Ville Syrjälä I doubt anyone has used the display error state since CS flips went the way of the dodo. Just nuke it. It might be semi interesting to have something like this for FIFO underruns and the like, but as it stands this wouldn't provide a sufficient amount of information. So would

Re: [Intel-gfx] [PATCH 2/3] Restructure output format computation for better expandability

Hi Werner, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on next-20210505] [cannot apply to v5.12] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use

Re: [Intel-gfx] [PATCH 0/3] Pipe DMC Prep patches

> -Original Message- > From: Jani Nikula > Sent: Tuesday, May 4, 2021 11:41 PM > To: Srivatsa, Anusha ; intel- > g...@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 0/3] Pipe DMC Prep patches > > On Mon, 03 May 2021, Jani Nikula wrote: > > On Wed, 28 Apr 2021, Anusha Srivatsa

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/display Try YCbCr420 color when RGB fails

== Series Details == Series: drm/i915/display Try YCbCr420 color when RGB fails URL : https://patchwork.freedesktop.org/series/89815/ State : failure == Summary == Applying: New function to avoid duplicate code in upcomming commits error: unrecognized input error: could not build fake ancestor

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/display Try YCbCr420 color when RGB fails

== Series Details == Series: drm/i915/display Try YCbCr420 color when RGB fails URL : https://patchwork.freedesktop.org/series/89814/ State : failure == Summary == Applying: New function to avoid duplicate code in upcomming commits error: unrecognized input error: could not build fake ancestor

[Intel-gfx] [PATCH 0/3] drm/i915/display Try YCbCr420 color when RGB fails

When encoder validation of a display mode fails, retry with less bandwidth heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups to support 4k60Hz output, which previously failed silently. AMDGPU had nearly the exact same issue. This problem description is therefore copied fro

[Intel-gfx] [PATCH 3/3] Use YCbCr420 as fallback when RGB fails

When encoder validation of a display mode fails, retry with less bandwidth heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups to support 4k60Hz output, which previously failed silently. AMDGPU had nearly the exact same issue. This problem description is therefore copied fro

[Intel-gfx] [PATCH 2/3] Restructure output format computation for better expandability

Couples the decission between RGB and YCbCr420 mode and the check if the port clock can archive the required frequency. Other checks and configuration steps that where previously done in between can also be done before or after. This allows for are cleaner implementation of retrying different colo

[Intel-gfx] [PATCH 1/3] New function to avoid duplicate code in upcomming commits

Moves some checks that later will be performed 2 times to an own fuction. This avoids duplicate code later on. Signed-off-by: Werner Sembach --- >From 42a4a3a7d9ea9948b4071f406e7fcae23bfa0bdf Mon Sep 17 00:00:00 2001 From: Werner Sembach Date: Mon, 3 May 2021 14:35:39 +0200 Subject: [PATCH 1/3]

[Intel-gfx] [PATCH 0/3] drm/i915/display Try YCbCr420 color when RGB fails

When encoder validation of a display mode fails, retry with less bandwidth heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups to support 4k60Hz output, which previously failed silently. AMDGPU had nearly the exact same issue. This problem description is therefore copied fro

[Intel-gfx] [PATCH 2/3] Restructure output format computation for better expandability

Couples the decission between RGB and YCbCr420 mode and the check if the port clock can archive the required frequency. Other checks and configuration steps that where previously done in between can also be done before or after. This allows for are cleaner implementation of retrying different colo

[Intel-gfx] [PATCH 3/3] Use YCbCr420 as fallback when RGB fails

When encoder validation of a display mode fails, retry with less bandwidth heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups to support 4k60Hz output, which previously failed silently. AMDGPU had nearly the exact same issue. This problem description is therefore copied fro

[Intel-gfx] [PATCH 1/3] New function to avoid duplicate code in upcomming commits

Moves some checks that later will be performed 2 times to an own fuction. This avoids duplicate code later on. Signed-off-by: Werner Sembach --- >From 42a4a3a7d9ea9948b4071f406e7fcae23bfa0bdf Mon Sep 17 00:00:00 2001 From: Werner Sembach Date: Mon, 3 May 2021 14:35:39 +0200 Subject: [PATCH 1/3]

[Intel-gfx] ✓ Fi.CI.BAT: success for drm + usb-type-c: Add support for out-of-band hotplug notification (rev3)

== Series Details == Series: drm + usb-type-c: Add support for out-of-band hotplug notification (rev3) URL : https://patchwork.freedesktop.org/series/89604/ State : success == Summary == CI Bug Log - changes from CI_DRM_10049 -> Patchwork_20068

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm + usb-type-c: Add support for out-of-band hotplug notification (rev3)

== Series Details == Series: drm + usb-type-c: Add support for out-of-band hotplug notification (rev3) URL : https://patchwork.freedesktop.org/series/89604/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked sep

[Intel-gfx] [PATCH 4/8] drm/connector: Add support for out-of-band hotplug notification (v3)

Add a new drm_connector_oob_hotplug_event() function and oob_hotplug_event drm_connector_funcs member. On some hardware a hotplug event notification may come from outside the display driver / device. An example of this is some USB Type-C setups where the hardware muxes the DisplayPort data and aux

[Intel-gfx] [PATCH 8/8] usb: typec: altmodes/displayport: Notify drm subsys of hotplug events

Use the new drm_connector_oob_hotplug_event() functions to let drm/kms drivers know about DisplayPort over Type-C hotplug events. Signed-off-by: Hans de Goede --- Changes in v3: - Only call drm_connector_oob_hotplug_event() on hpd status bit change - Adjust for drm_connector_oob_hotplug_event() n

[Intel-gfx] [PATCH 7/8] usb: typec: altmodes/displayport: Make dp_altmode_notify() more generic

Make dp_altmode_notify() handle the dp->data.conf == 0 case too, rather then having separate code-paths for this in various places which call it. Signed-off-by: Hans de Goede --- drivers/usb/typec/altmodes/displayport.c | 35 +--- 1 file changed, 13 insertions(+), 22 deletion

[Intel-gfx] [PATCH 6/8] drm/i915/dp: Add support for out-of-bound hotplug events

On some Cherry Trail devices, DisplayPort over Type-C is supported through a USB-PD microcontroller (e.g. a fusb302) + a mux to switch the superspeed datalines between USB-3 and DP (e.g. a pi3usb30532). The kernel in this case does the PD/alt-mode negotiation itself, rather then everything being ha

[Intel-gfx] [PATCH 5/8] drm/i915: Associate ACPI connector nodes with connector entries (v2)

From: Heikki Krogerus On Intel platforms we know that the ACPI connector device node order will follow the order the driver (i915) decides. The decision is made using the custom Intel ACPI OpRegion (intel_opregion.c), though the driver does not actually know that the values it sends to ACPI there

[Intel-gfx] [PATCH 3/8] drm/connector: Add drm_connector_find_by_fwnode() function (v2)

Add a function to find a connector based on a fwnode. This will be used by the new drm_connector_oob_hotplug_event() function which is added by the next patch in this patch-set. Changes in v2: - Complete rewrite to use a global connector list in drm_connector.c rather then using a class-dev-ite

[Intel-gfx] [PATCH 2/8] drm/connector: Add a fwnode pointer to drm_connector and register with ACPI (v2)

Add a fwnode pointer to struct drm_connector and register an acpi_bus_type for the connectors with the ACPI subsystem (when CONFIG_ACPI is enabled). The adding of the fwnode pointer allows drivers to associate a fwnode that represents a connector with that connector. When the new fwnode pointer p

[Intel-gfx] [PATCH 1/8] drm/connector: Give connector sysfs devices there own device_type

Give connector sysfs devices there own device_type, this allows us to check if a device passed to functions dealing with generic devices is a drm_connector or not. A check like this is necessary in the drm_connector_acpi_bus_match() function added in the next patch in this series. Signed-off-by:

[Intel-gfx] [PATCH 0/8] drm + usb-type-c: Add support for out-of-band hotplug notification (v3)

Hi All, Here is v3 of my patchset making DP over Type-C work on devices where the Type-C controller does not drive the HPD pin on the GPU, but instead we need to forward HPD events from the Type-C controller to the DRM driver. Changes in v3: - Base on top of latest drm-tip, which should fix the C

Re: [Intel-gfx] Enabling sample_c optimization for Broadwell GPUs

Hello, Yes, that bit only exists on Haswell. On Haswell, sample_c operations were processed at 1 pixel/clock unless you set that bit, in which case they get processed at 4 pixels/clock. The downside is that it breaks some obscure media feature that apparently no one used. Broadwell and later al

[Intel-gfx] [PATCH i-g-t v3] lib/i915/perf: Fix non-card0 processing

IGT i915/perf library functions now always operate on sysfs perf attributes of card0 device node, no matter which DRM device fd a user passes. The intention was to always switch to primary device node if a user passes a render device node fd, but that breaks handling of non-card0 devices. If a us

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/display Try YCbCr420 color when RGB fails

== Series Details == Series: drm/i915/display Try YCbCr420 color when RGB fails URL : https://patchwork.freedesktop.org/series/89808/ State : failure == Summary == Applying: New function to avoid duplicate code in upcomming commits error: unrecognized input error: could not build fake ancestor

Re: [Intel-gfx] [PATCH] i915: Increase *_latency array size

On Wed, May 05, 2021 at 07:18:30AM -0700, Andi Kleen wrote: > > > Increase all the latency fields to 8 members, which is enough for SKL. > > > > > > I don't know if they are correctly initialized upto 8, but dev_priv > > > should start out as zero, so presumably they will be zero. > > > > Thanks,

Re: [Intel-gfx] [PATCH] i915: Increase *_latency array size

> > Increase all the latency fields to 8 members, which is enough for SKL. > > > > I don't know if they are correctly initialized upto 8, but dev_priv > > should start out as zero, so presumably they will be zero. > > Thanks, the warning should be fixed by commit > > c6deb5e97ded ("drm/i915/pm: M

[Intel-gfx] [PATCH 3/3] Use YCbCr420 as fallback when RGB fails

When encoder validation of a display mode fails, retry with less bandwidth heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups to support 4k60Hz output, which previously failed silently. AMDGPU had nearly the exact same issue. This problem description is therefore copied fro

[Intel-gfx] [PATCH 2/3] Restructure output format computation for better expandability

Couples the decission between RGB and YCbCr420 mode and the check if the port clock can archive the required frequency. Other checks and configuration steps that where previously done in between can also be done before or after. This allows for are cleaner implementation of retrying different colo

[Intel-gfx] [PATCH 1/3] New function to avoid duplicate code in upcomming commits

Moves some checks that later will be performed 2 times to an own fuction. This avoids duplicate code later on. Signed-off-by: Werner Sembach --- PS.: I have no idea why git send-email is messing up this timestamp in "From" below. >From 42a4a3a7d9ea9948b4071f406e7fcae23bfa0bdf Mon Sep 17 00:00:0

[Intel-gfx] [PATCH 0/4] drm/i915/display Try YCbCr420 color when RGB fails

When encoder validation of a display mode fails, retry with less bandwidth heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups to support 4k60Hz output, which previously failed silently. AMDGPU had nearly the exact same issue. This problem description is therefore copied fro

Re: [Intel-gfx] [PATCH 3/4] Restructure output format computation for better expandability

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, 2021 at 08:21:47PM +0200, Werner Sembach w

Re: [Intel-gfx] [PATCH i-g-t v2] lib/i915/perf: Fix non-card0 processing

On 05/05/2021 15:41, Janusz Krzysztofik wrote: IGT i915/perf library functions now always operate on sysfs perf attributes of card0 device node, no matter which DRM device fd a user passes. The intention was to always switch to primary device node if a user passes a render device node fd, but th

Re: [Intel-gfx] [PATCH 4/4] Use YCbCr420 as fallback when RGB fails

Am 04.05.21 um 12:08 schrieb Ville Syrjälä: > On Mon, May 03, 2021 at 08:21:48PM +0200, Werner Sembach wrote: >> When encoder validation of a display mode fails, retry with less bandwidth >> heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups >> to support 4k60Hz output, whi

Re: [Intel-gfx] [PATCH 3/4] Restructure output format computation for better expandability

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, 2021 at 08:21:47PM +0200, Werner Sembach wrote: Couples the decission between RGB and YCbCr420 mode and the check

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Associate ACPI connector nodes with connector entries

On Wed, May 5, 2021 at 1:30 PM Hans de Goede wrote: > On 5/5/21 12:02 PM, Andy Shevchenko wrote: ... > But we do really need to document the behavior better here > in the kdoc for fwnode_get_next_child_node() and > device_get_next_child_node(). Totally agree! > of_get_next_child has this bit,

[Intel-gfx] [PATCH i-g-t v2] lib/i915/perf: Fix non-card0 processing

IGT i915/perf library functions now always operate on sysfs perf attributes of card0 device node, no matter which DRM device fd a user passes. The intention was to always switch to primary device node if a user passes a render device node fd, but that breaks handling of non-card0 devices. If a us

Re: [Intel-gfx] [PATCH 3/4] Restructure output format computation for better expandability

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 > >> port > >> clock can archive the re

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: drop the __i915_active_call pointer packing (rev2)

== Series Details == Series: drm/i915: drop the __i915_active_call pointer packing (rev2) URL : https://patchwork.freedesktop.org/series/89783/ State : success == Summary == CI Bug Log - changes from CI_DRM_10047_full -> Patchwork_20066_full

Re: [Intel-gfx] [PATCH 8/9] usb: typec: altmodes/displayport: Notify drm subsys of hotplug events

Hi Heikki, On 5/5/21 12:17 PM, Heikki Krogerus wrote: > Hi Hans, > > On Mon, May 03, 2021 at 05:46:46PM +0200, Hans de Goede wrote: >> Use the new drm_connector_find_by_fwnode() and >> drm_connector_oob_hotplug_event() functions to let drm/kms drivers >> know about DisplayPort over Type-C hotplug

Re: [Intel-gfx] [PATCH 4/9] drm/connector: Add support for out-of-band hotplug notification (v2)

Hi, On 5/5/21 11:50 AM, Heikki Krogerus wrote: > On Tue, May 04, 2021 at 05:35:49PM +0200, Hans de Goede wrote: >> Hi, >> >> On 5/4/21 5:10 PM, Heikki Krogerus wrote: +/** + * drm_connector_oob_hotplug_event - Report out-of-band hotplug event to connector + * @connector: conne

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: drop the __i915_active_call pointer packing (rev2)

== Series Details == Series: drm/i915: drop the __i915_active_call pointer packing (rev2) URL : https://patchwork.freedesktop.org/series/89783/ State : success == Summary == CI Bug Log - changes from CI_DRM_10047 -> Patchwork_20066 Summary

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Associate ACPI connector nodes with connector entries

Hi, On 5/5/21 12:02 PM, Andy Shevchenko wrote: > On Wed, May 5, 2021 at 12:28 PM Hans de Goede wrote: >> On 5/5/21 11:17 AM, Andy Shevchenko wrote: >>> On Wed, May 5, 2021 at 12:07 PM Hans de Goede wrote: On 5/4/21 9:52 AM, Andy Shevchenko wrote: > On Monday, May 3, 2021, Hans de Goede

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Associate ACPI connector nodes with connector entries

Hi Andy, Hans, On Wed, May 05, 2021 at 12:17:14PM +0300, Andy Shevchenko wrote: > On Wed, May 5, 2021 at 12:07 PM Hans de Goede wrote: > > On 5/4/21 9:52 AM, Andy Shevchenko wrote: > > > On Monday, May 3, 2021, Hans de Goede > > > wrote: > > ... > > > > +

Re: [Intel-gfx] [PATCH 8/9] usb: typec: altmodes/displayport: Notify drm subsys of hotplug events

Hi Hans, On Mon, May 03, 2021 at 05:46:46PM +0200, Hans de Goede wrote: > Use the new drm_connector_find_by_fwnode() and > drm_connector_oob_hotplug_event() functions to let drm/kms drivers > know about DisplayPort over Type-C hotplug events. > > Signed-off-by: Hans de Goede > --- > Changes in v

Re: [Intel-gfx] [PATCH] drm/i915: drop the __i915_active_call pointer packing

On Tue, May 04, 2021 at 05:41:36PM +0100, Matthew Auld wrote: > We use some of the lower bits of the retire function pointer for > potential flags, which is quite thorny, since the caller needs to > remember to give the function the correct alignment with > __i915_active_call, otherwise we might in

Re: [Intel-gfx] Enabling sample_c optimization for Broadwell GPUs

Hi Andre, I'm not familiar with the sample c message optimization. Probably Ken can comment. However I could check the internal spec here and I saw this bit only exists with this meaning in Haswell. For all the other platforms, including Broadwell it got re-purposed with a different meaning and

Re: [Intel-gfx] [PATCH 16/27] drm/i915/gem: Add an intermediate proto_context struct

On 03/05/2021 16:57, Jason Ekstrand wrote: The current context uAPI allows for two methods of setting context parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The former is allowed to be called at any time while the later happens as part of GEM_CONTEXT_CREATE. Currently, everyth

Re: [Intel-gfx] [PATCH 27/27] drm/i915/gem: Roll all of context creation together

On Mon, May 03, 2021 at 10:57:48AM -0500, Jason Ekstrand wrote: > Now that we have the whole engine set and VM at context creation time, > we can just assign those fields instead of creating first and handling > the VM and engines later. This lets us avoid creating useless VMs and > engine sets an

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: drop the __i915_active_call pointer packing (rev2)

== Series Details == Series: drm/i915: drop the __i915_active_call pointer packing (rev2) URL : https://patchwork.freedesktop.org/series/89783/ State : warning == Summary == $ dim checkpatch origin/drm-tip 41c6393f0704 drm/i915: drop the __i915_active_call pointer packing -:18: ERROR:GIT_COMMI

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Associate ACPI connector nodes with connector entries

On Wed, May 5, 2021 at 12:28 PM Hans de Goede wrote: > On 5/5/21 11:17 AM, Andy Shevchenko wrote: > > On Wed, May 5, 2021 at 12:07 PM Hans de Goede wrote: > >> On 5/4/21 9:52 AM, Andy Shevchenko wrote: > >>> On Monday, May 3, 2021, Hans de Goede >>> > wrote: > > > > .

Re: [Intel-gfx] [RFC PATCH i-g-t] lib/i915/perf: Fix non-card0 processing

Hi Lionel, On poniedziałek, 3 maja 2021 09:07:09 CEST Lionel Landwerlin wrote: > On 30/04/2021 19:18, Janusz Krzysztofik wrote: > > IGT i915/perf library functions now always operate on sysfs perf > > attributes of card0 device node, no matter which DRM device fd a user > > passes. The intention

Re: [Intel-gfx] [PATCH 12/27] drm/i915/gem: Disallow creating contexts with too many engines

On 03/05/2021 16:57, Jason Ekstrand wrote: There's no sense in allowing userspace to create more engines than it can possibly access via execbuf. Signed-off-by: Jason Ekstrand Reviewed-by: Daniel Vetter FWIW, again for the record, my advice is not to land this one. It makes no sense and i

Re: [Intel-gfx] [PATCH 3/4] Restructure output format computation for better expandability

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 port >> clock can archive the required frequency. Other checks and configuration >> steps >> that where previou

Re: [Intel-gfx] [PATCH 26/27] i915/gem/selftests: Assign the VM at context creation in igt_shared_ctx_exec

On Mon, May 03, 2021 at 10:57:47AM -0500, Jason Ekstrand wrote: > We want to delete __assign_ppgtt and, generally, stop setting the VM > after context creation. This is the one place I could find in the > selftests where we set a VM after the fact. > > Signed-off-by: Jason Ekstrand Reviewed-by:

Re: [Intel-gfx] [PATCH 18/27] drm/i915/gem: Optionally set SSEU in intel_context_set_gem

On 05/05/2021 10:47, Daniel Vetter wrote: On Wed, May 05, 2021 at 10:28:59AM +0100, Tvrtko Ursulin wrote: On 04/05/2021 20:00, Daniel Vetter wrote: On Mon, May 03, 2021 at 10:57:39AM -0500, Jason Ekstrand wrote: For now this is a no-op because everyone passes in a null SSEU but it lets us g

Re: [Intel-gfx] [PATCH 4/9] drm/connector: Add support for out-of-band hotplug notification (v2)

On Tue, May 04, 2021 at 05:35:49PM +0200, Hans de Goede wrote: > Hi, > > On 5/4/21 5:10 PM, Heikki Krogerus wrote: > >> +/** > >> + * drm_connector_oob_hotplug_event - Report out-of-band hotplug event to > >> connector > >> + * @connector: connector to report the event on > >> + * @data: data rel

Re: [Intel-gfx] [PATCH 25/27] drm/i915/selftests: Take a VM in kernel_context()

On Mon, May 03, 2021 at 10:57:46AM -0500, Jason Ekstrand wrote: > This better models where we want to go with contexts in general where > things like the VM and engine set are create parameters instead of being > set after the fact. > > Signed-off-by: Jason Ekstrand Looks reasonable. Reviewed-b

Re: [Intel-gfx] [PATCH 24/27] drm/i915/gem: Don't allow changing the engine set on running contexts

On Mon, May 03, 2021 at 10:57:45AM -0500, Jason Ekstrand wrote: > Signed-off-by: Jason Ekstrand Again needs some commit message, with that: Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/i915/gem/i915_gem_context.c | 304 > 1 file changed, 304 deletions(-) > > diff -

Re: [Intel-gfx] [PATCH 18/27] drm/i915/gem: Optionally set SSEU in intel_context_set_gem

On Wed, May 05, 2021 at 10:28:59AM +0100, Tvrtko Ursulin wrote: > > On 04/05/2021 20:00, Daniel Vetter wrote: > > On Mon, May 03, 2021 at 10:57:39AM -0500, Jason Ekstrand wrote: > > > For now this is a no-op because everyone passes in a null SSEU but it > > > lets us get some of the error handling

Re: [Intel-gfx] [PATCH 2/4] Add missing check

Am 04.05.21 um 11:41 schrieb Ville Syrjälä: > On Mon, May 03, 2021 at 08:21:46PM +0200, Werner Sembach wrote: >> Add a missing check that could potentially lead to an unarchivable mode being >> validated. >> >> Signed-off-by: Werner Sembach >> --- >> >> >From 54fa706f0a5f260a32af5d18b9622ceebb94c

Re: [Intel-gfx] [PATCH 18/27] drm/i915/gem: Optionally set SSEU in intel_context_set_gem

On 04/05/2021 20:00, Daniel Vetter wrote: On Mon, May 03, 2021 at 10:57:39AM -0500, Jason Ekstrand wrote: For now this is a no-op because everyone passes in a null SSEU but it lets us get some of the error handling and selftest refactoring plumbed through. Signed-off-by: Jason Ekstrand it

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Associate ACPI connector nodes with connector entries

Hi, On 5/5/21 11:17 AM, Andy Shevchenko wrote: > On Wed, May 5, 2021 at 12:07 PM Hans de Goede wrote: >> On 5/4/21 9:52 AM, Andy Shevchenko wrote: >>> On Monday, May 3, 2021, Hans de Goede >> > wrote: > > ... > >>> + fwnode = device_get_next_child_n

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Associate ACPI connector nodes with connector entries

On Wed, May 5, 2021 at 12:07 PM Hans de Goede wrote: > On 5/4/21 9:52 AM, Andy Shevchenko wrote: > > On Monday, May 3, 2021, Hans de Goede > > wrote: ... > > + fwnode = device_get_next_child_node(kdev, fwnode); > > Who is dropping reference countin

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Associate ACPI connector nodes with connector entries

Hi, On 5/4/21 9:52 AM, Andy Shevchenko wrote: > > > On Monday, May 3, 2021, Hans de Goede > wrote: > > From: Heikki Krogerus > > > On Intel platforms we know that the ACPI connector device > node order will follo

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Use correct downstream caps for check Src-Ctl mode for PCON (rev2)

== Series Details == Series: drm/i915: Use correct downstream caps for check Src-Ctl mode for PCON (rev2) URL : https://patchwork.freedesktop.org/series/89639/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10047 -> Patchwork_20065 =

[Intel-gfx] [PATCH v2] drm/i915: Use correct downstream caps for check Src-Ctl mode for PCON

Fix the typo in DPCD caps used for checking SRC CTL mode of HDMI2.1 PCON v2: Corrected Fixes tag (Jani Nikula). Fixes: 04b6603d13be ("drm/i915/display: Configure HDMI2.1 Pcon for FRL only if Src-Ctl mode is available") Cc: Ankit Nautiyal Cc: Uma Shankar Cc: Jani Nikula Cc: "Ville Syrj_l_" Cc:

Re: [Intel-gfx] [PATCH] drm/i915: Use correct downstream caps for check Src-Ctl mode for PCON

On 5/3/2021 11:03 PM, Jani Nikula wrote: On Thu, 29 Apr 2021, Ankit Nautiyal wrote: Fix the typo in DPCD caps used for checking SRC CTL mode of HDMI2.1 PCON Fixes: 04b6603d13be (drm/i915/display: Configure HDMI2.1 Pcon for FRL only if Src-Ctl mode is available) Correct format for Fixes: is

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/2] drm/i915: Don't include intel_de.h from intel_display_types.h (rev2)

== Series Details == Series: series starting with [v2,1/2] drm/i915: Don't include intel_de.h from intel_display_types.h (rev2) URL : https://patchwork.freedesktop.org/series/89698/ State : success == Summary == CI Bug Log - changes from CI_DRM_10039_full -> Patchwork_20053_full =