Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/utils: do not depend on config being defined

[Andrzej Hajda]

W dniu 29.09.2021 o 20:33, Lucas De Marchi pisze:
> Like the IS_ENABLED() counterpart, we can make IS_CONFIG_NONZERO() to
> return the right thing when the config is not defined rather than a
> build error, with the limitation that it can't be used on preprocessor
> context.
>
> The trick here is that macro names can't start with a number or dash, so
> we stringify the argument and check that the first char is a number != 0
> (or starting with a dash to cover negative numbers). Except for -O0
> builds the strings are all eliminated.
>
> Taking CONFIG_DRM_I915_REQUEST_TIMEOUT in
> drivers/gpu/drm/i915/gem/i915_gem_context.c as example, we have the
> following output of the preprocessor:
>
> old:
>   if (((2) != 0) &&
> new:
>   if (( ("2"[0] > '0' && "2"[0] < '9') || "2"[0] == '-' ) &&
>
> New one looks worse, but is also eliminated from the object:
>
> $ size drivers/gpu/drm/i915/gem/i915_gem_context.o.*
> textdata bss dec hex filename
>520211070 232   53323d04b 
> drivers/gpu/drm/i915/gem/i915_gem_context.o.new
>520211070 232   53323d04b 
> drivers/gpu/drm/i915/gem/i915_gem_context.o.old
>
> Signed-off-by: Lucas De Marchi 
> ---
>   drivers/gpu/drm/i915/i915_utils.h | 6 +-
>   1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_utils.h 
> b/drivers/gpu/drm/i915/i915_utils.h
> index 02bbfa4d68d3..436ce612c46a 100644
> --- a/drivers/gpu/drm/i915/i915_utils.h
> +++ b/drivers/gpu/drm/i915/i915_utils.h
> @@ -28,6 +28,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   #include 
>   #include 
>   
> @@ -469,6 +470,9 @@ static inline bool timer_expired(const struct timer_list 
> *t)
>*
>* Returns 0 if @config is 0, 1 if set to any value.
>*/
> -#define IS_CONFIG_NONZERO(config) ((config) != 0)
> +#define IS_CONFIG_NONZERO(config) (  
> \
> + (__stringify_1(config)[0] > '0' && __stringify_1(config)[0] < '9') ||   
> \
> + __stringify_1(config)[0] == '-' 
> \
> +)


Quite clever trick, but I see two issues:

- gcc < 8.1 treats expressions with string indices (ex. "abc"[0]) as 
non-constant expressions, so they cannot be used everywhere, for example 
in global variable initializations,

- it does not work with hex (0x1) or octal values (01)

It is probably OK for private macro, but it can hurt in kconfig.h, 
especially the 2nd issue


Regards

Andrzej

>   
>   #endif /* !__I915_UTILS_H */

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/utils: do not depend on config being defined

[Andrzej Hajda]

W dniu 30.09.2021 o 00:54, Lucas De Marchi pisze:
> On Wed, Sep 29, 2021 at 11:08:18PM +0200, Andrzej Hajda wrote:
>>
>> W dniu 29.09.2021 o 20:33, Lucas De Marchi pisze:
>>> Like the IS_ENABLED() counterpart, we can make IS_CONFIG_NONZERO() to
>>> return the right thing when the config is not defined rather than a
>>> build error, with the limitation that it can't be used on preprocessor
>>> context.
>>>
>>> The trick here is that macro names can't start with a number or 
>>> dash, so
>>> we stringify the argument and check that the first char is a number 
>>> != 0
>>> (or starting with a dash to cover negative numbers). Except for -O0
>>> builds the strings are all eliminated.
>>>
>>> Taking CONFIG_DRM_I915_REQUEST_TIMEOUT in
>>> drivers/gpu/drm/i915/gem/i915_gem_context.c as example, we have the
>>> following output of the preprocessor:
>>>
>>> old:
>>>   if (((2) != 0) &&
>>> new:
>>>   if (( ("2"[0] > '0' && "2"[0] < '9') || "2"[0] == '-' 
>>> ) &&
>>>
>>> New one looks worse, but is also eliminated from the object:
>>>
>>> $ size drivers/gpu/drm/i915/gem/i915_gem_context.o.*
>>>     text    data bss dec hex filename
>>>    52021    1070 232   53323    d04b 
>>> drivers/gpu/drm/i915/gem/i915_gem_context.o.new
>>>    52021    1070 232   53323    d04b 
>>> drivers/gpu/drm/i915/gem/i915_gem_context.o.old
>>>
>>> Signed-off-by: Lucas De Marchi 
>>> ---
>>>   drivers/gpu/drm/i915/i915_utils.h | 6 +-
>>>   1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_utils.h 
>>> b/drivers/gpu/drm/i915/i915_utils.h
>>> index 02bbfa4d68d3..436ce612c46a 100644
>>> --- a/drivers/gpu/drm/i915/i915_utils.h
>>> +++ b/drivers/gpu/drm/i915/i915_utils.h
>>> @@ -28,6 +28,7 @@
>>>   #include 
>>>   #include 
>>>   #include 
>>> +#include 
>>>   #include 
>>>   #include 
>>>
>>> @@ -469,6 +470,9 @@ static inline bool timer_expired(const struct 
>>> timer_list *t)
>>>    *
>>>    * Returns 0 if @config is 0, 1 if set to any value.
>>>    */
>>> -#define IS_CONFIG_NONZERO(config) ((config) != 0)
>>> +#define IS_CONFIG_NONZERO(config) (    \
>>> +    (__stringify_1(config)[0] > '0' && __stringify_1(config)[0] < 
>>> '9') ||    \
>>> +    __stringify_1(config)[0] == '-'    \
>>> +)
>>
>>
>> Quite clever trick, but I see two issues:
>>
>> - gcc < 8.1 treats expressions with string indices (ex. "abc"[0]) as
>> non-constant expressions, so they cannot be used everywhere, for example
>> in global variable initializations,
>
> ugh, that would kill the idea - having the strings and additional
> runtime checks would not be good. Maybe if we check with
> __builtin_constant_p() and do the simpler expansion if it's not
> constant?


I think it is just matter of disallowing such construct in places where 
compiler expects constant expression.

If accepted, the expression is apparently evaluated in compile time. See 
[1].

[1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960#c18


>
>>
>> - it does not work with hex (0x1) or octal values (01)
>
> indeed, but I guess that would be fixable by checking (s[0] == '0' && 
> s[1] == '\0')?
> However, it seems kconfig doesn't support setting int options to hex or
> octal.


I've spotted in include/generated/autoconf.h following line:

#define CONFIG_ILLEGAL_POINTER_VALUE 0xdead

It corresponds to following kconfig entry:

config ILLEGAL_POINTER_VALUE
    hex
    default 0 if X86_32
    default 0xdead if X86_64

Grepping shows more: grep -r --include=Kconfig -3 -P '^\s*hex' .

Anyway do you really need to handle undefined case? If not, the macro 
can stay simple, w/o hacky constructs.


Regards

Andrzej


>
> If I try an hex value in menuconfig it says "You have made an invalid 
> entry."
> If I try editing .config or setting via scripts/config --set-val, it
> just gets reset when trying to generate include/generated/autoconf.h
>
> Lucas De Marchi
>
>>
>> It is probably OK for private macro, but it can hurt in kconfig.h,
>> especially the 2nd issue
>>
>>
>> Regards
>>
>> Andrzej
>>
>>>
>>>   #endif /* !__I915_UTILS_H */
>

Re: [Intel-gfx] [PATCH 1/4] drm/edid: Pass connector to AVI inforframe functions

[Andrzej Hajda]

Quite late, hopefully not too late.


On 21.11.2018 12:51, Ville Syrjälä wrote:
> On Wed, Nov 21, 2018 at 01:40:43PM +0200, Jani Nikula wrote:
>>
>>> return;
>>> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
>>> b/drivers/gpu/drm/bridge/sil-sii8620.c
>>> index a6e8f4591e63..0cc293a6ac24 100644
>>> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
>>> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
>>> @@ -1104,8 +1104,7 @@ static void sii8620_set_infoframes(struct sii8620 
>>> *ctx,
>>> int ret;
>>>  
>>> ret = drm_hdmi_avi_infoframe_from_display_mode(&frm.avi,
>>> -  mode,
>>> -  true);
>>> +  NULL, mode);
>>> if (ctx->use_packed_pixel)
>>> frm.avi.colorspace = HDMI_COLORSPACE_YUV422;
>>>  
>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
>>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> index 64c3cf027518..88b720b63126 100644
>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> @@ -1344,7 +1344,8 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, 
>>> struct drm_display_mode *mode)
>>> u8 val;
>>>  
>>> /* Initialise info frame from DRM mode */
>>> -   drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
>>> +   drm_hdmi_avi_infoframe_from_display_mode(&frame,
>>> +&hdmi->connector, mode);
>>>  
>>> if (hdmi_bus_fmt_is_yuv444(hdmi->hdmi_data.enc_out_bus_format))
>>> frame.colorspace = HDMI_COLORSPACE_YUV444;
>>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>>> index b506e3622b08..501ac05ba7da 100644
>>> --- a/drivers/gpu/drm/drm_edid.c
>>> +++ b/drivers/gpu/drm/drm_edid.c
>>> @@ -4830,19 +4830,32 @@ void drm_set_preferred_mode(struct drm_connector 
>>> *connector,
>>>  }
>>>  EXPORT_SYMBOL(drm_set_preferred_mode);
>>>  
>>> +static bool is_hdmi2_sink(struct drm_connector *connector)
>> You're usually known for adding const all around, why not const pointer
>> here and in all the other drm_* functions that call this?
> My current approach is to constify states/fbs/etc. but not so much
> crtcs/connectors/etc. Too much const can sometimes get in the way
> of things requiring that you remove the const later. But I guess
> in this case the const shouldn't really get in the way of anything
> because these are pretty much supposed to be pure functions.
>
>>> +{
>>> +   /*
>>> +* FIXME: sil-sii8620 doesn't have a connector around when
>>> +* we need one, so we have to be prepared for a NULL connector.
>>> +*/
>>> +   if (!connector)
>>> +   return false;
>> This actually changes the is_hdmi2_sink value for sil-sii8620.
> Hmm. No idea why they would have set that to true when everyone else is
> passing false. 


Because false does not work :) More precisely MHLv3 (used in Sii8620)
uses CTA-861-F standard for infoframes, which is specific to HDMI2.0.

Unfortunately I have no access to MHL specs, but my experiments and
vendor drivers strongly suggests it is done this way.

This is important in case of 4K modes which are handled differently by
HDMI 1.4 and HDMI2.0.

The pipeline looks like (in parenthesis HDMI version on the stream):

exynos_hdmi --(1.4)--> SII8620 --(2.0)--> MHL_dongle --(1.4)--> TV


> I guess I can change this to true to not change it. IIRC
> that was the only driver that didn't have a connector around.
>
> That said, I was actually thinking of removing this hdmi2 vs. not
> stuff from drm_hdmi_avi_infoframe_from_display_mode(). We added it
> "just in case", but we already have a similar issue with earlier
> cea-861 revisions and haven't seen any bugs where an older monitor
> would get confused by a VIC not yet defined when the monitor was
> produced.
>
Are you sure this is a good idea? As I said earlier 4K modes are present
in HDMI 1.4 and 2.0 but they are handled differently, so this is not
only matter of unknown VIC in AVIF.


Regards

Andrzej

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/4] drm/edid: Pass connector to AVI inforframe functions

[Andrzej Hajda]

On 21.11.2018 19:19, Laurent Pinchart wrote:
> Hi Ville,
>
> Thank you for the patch.
>
> On Tuesday, 20 November 2018 18:13:42 EET Ville Syrjala wrote:
>> From: Ville Syrjälä 
>>
>> Make life easier for drivers by simply passing the connector
>> to drm_hdmi_avi_infoframe_from_display_mode() and
>> drm_hdmi_avi_infoframe_quant_range(). That way drivers don't
>> need to worry about is_hdmi2_sink mess.
> While this is good for display controller drivers, the change isn't great for 
> bridge drivers. Down the road we're looking at moving connector support out 
> of 
> the bridge drivers. Adding an additional dependency to connectors in the 
> bridges will make that more difficult. Ideally bridges should retrieve the 
> information from their sink, regardless of whether it is a connector or 
> another bridge.


I agree with it, and case of sii8620 shows that there are cases where
bridge has no direct access to the connector.

On the other side,  since you are passing connector to
drm_hdmi_avi_infoframe_from_display_mode(), you could drop mode
parameter and rename the function to
drm_hdmi_avi_infoframe_from_connector() then, unless mode passed and
mode set on the connector differs?


Regards

Andrzej


>
> Please see below for an additional comment.
>
>> Cc: Alex Deucher 
>> Cc: "Christian König" 
>> Cc: "David (ChunMing) Zhou" 
>> Cc: Archit Taneja 
>> Cc: Andrzej Hajda 
>> Cc: Laurent Pinchart 
>> Cc: Inki Dae 
>> Cc: Joonyoung Shim 
>> Cc: Seung-Woo Kim 
>> Cc: Kyungmin Park 
>> Cc: Russell King 
>> Cc: CK Hu 
>> Cc: Philipp Zabel 
>> Cc: Rob Clark 
>> Cc: Ben Skeggs 
>> Cc: Tomi Valkeinen 
>> Cc: Sandy Huang 
>> Cc: "Heiko Stübner" 
>> Cc: Benjamin Gaignard 
>> Cc: Vincent Abriou 
>> Cc: Thierry Reding 
>> Cc: Eric Anholt 
>> Cc: Shawn Guo 
>> Cc: Ilia Mirkin 
>> Cc: amd-...@lists.freedesktop.org
>> Cc: linux-arm-...@vger.kernel.org
>> Cc: freedr...@lists.freedesktop.org
>> Cc: nouv...@lists.freedesktop.org
>> Cc: linux-te...@vger.kernel.org
>> Signed-off-by: Ville Syrjälä 
>> ---
>>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
>>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
>>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c |  3 ++-
>>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
>>  drivers/gpu/drm/bridge/analogix-anx78xx.c |  5 ++--
>>  drivers/gpu/drm/bridge/sii902x.c  |  3 ++-
>>  drivers/gpu/drm/bridge/sil-sii8620.c  |  3 +--
>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  3 ++-
>>  drivers/gpu/drm/drm_edid.c| 33 ++-
>>  drivers/gpu/drm/exynos/exynos_hdmi.c  |  3 ++-
>>  drivers/gpu/drm/i2c/tda998x_drv.c |  3 ++-
>>  drivers/gpu/drm/i915/intel_hdmi.c | 14 +-
>>  drivers/gpu/drm/i915/intel_lspcon.c   | 15 ++-
>>  drivers/gpu/drm/i915/intel_sdvo.c | 10 ---
>>  drivers/gpu/drm/mediatek/mtk_hdmi.c   |  3 ++-
>>  drivers/gpu/drm/msm/hdmi/hdmi_bridge.c|  3 ++-
>>  drivers/gpu/drm/nouveau/dispnv50/disp.c   |  7 +++--
>>  drivers/gpu/drm/omapdrm/omap_encoder.c|  5 ++--
>>  drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
>>  drivers/gpu/drm/rockchip/inno_hdmi.c  |  4 ++-
>>  drivers/gpu/drm/sti/sti_hdmi.c|  3 ++-
>>  drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c|  3 ++-
>>  drivers/gpu/drm/tegra/hdmi.c  |  3 ++-
>>  drivers/gpu/drm/tegra/sor.c   |  3 ++-
>>  drivers/gpu/drm/vc4/vc4_hdmi.c| 11 +---
>>  drivers/gpu/drm/zte/zx_hdmi.c |  4 ++-
>>  include/drm/drm_edid.h|  8 +++---
>>  27 files changed, 94 insertions(+), 66 deletions(-)
> For dw-hdmi and omapdrm,
>
> Reviewed-by: Laurent Pinchart 
>

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [v2, 1/8] drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane

[Andrzej Hajda]

Hi Ville,

As Christoph cannot respond till middle next week I can try to respond
in his absence, as I am familiar with the subject.

On 30.11.2018 14:25, Ville Syrjälä wrote:
> On Fri, Nov 30, 2018 at 02:08:11PM +0100, Christoph Manszewski wrote:
>> Hi,
>>
>> I am looking for a way to export the color encoding and range selection
>> to user space. I came across those properties and am wondering, why
>> they are meant only for non RGB color encodings. Would it be okay, to
>> modify them and use with RGB formats as well?
> What you trying to do? Input limited range RGB data and expand to full
> range?


For example. But there are two more general questions, which
surprisingly we have not found answer for.

1. What color encoding and range drm should expect on its input RGB
buffers by default?

2. How userspace should inform drm that given buffer has specified
non-default color encoding and range?


Hopefully this patch introduces such properties but only for YCbCr
formats, the question is what should be the best way to expand it to RGB
formats:

A. Add another enums: DRM_COLOR_RGB_BT601 and friends.

B. Reuse current enums, but remove format information from them:
DRM_COLOR_YCBCR_BT601 => DRM_COLOR_BT601.


Regards

Andrzej

>
>> Regards,
>> Chris
>>
>>
>> On 02/19/2018 09:28 PM, Ville Syrjala wrote:
>>> From: Jyri Sarha 
>>>
>>> Add a standard optional properties to support different non RGB color
>>> encodings in DRM planes. COLOR_ENCODING select the supported non RGB
>>> color encoding, for instance ITU-R BT.709 YCbCr. COLOR_RANGE selects
>>> the value ranges within the selected color encoding. The properties
>>> are stored to drm_plane object to allow different set of supported
>>> encoding for different planes on the device.
>>>
>>> v2: Add/fix kerneldocs, verify bitmasks (danvet)
>>>
>>> Cc: Harry Wentland 
>>> Cc: Daniel Vetter 
>>> Cc: Daniel Stone 
>>> Cc: Russell King - ARM Linux 
>>> Cc: Ilia Mirkin 
>>> Cc: Hans Verkuil 
>>> Cc: Uma Shankar 
>>> Cc: Shashank Sharma 
>>> Reviewed-by: Ville Syrjälä 
>>> Signed-off-by: Jyri Sarha 
>>> [vsyrjala v2: Add/fix kerneldocs, verify bitmasks]
>>> Signed-off-by: Ville Syrjälä 
>>> Reviewed-by: Daniel Vetter 
>>> ---
>>>   drivers/gpu/drm/drm_atomic.c |   8 +++
>>>   drivers/gpu/drm/drm_color_mgmt.c | 103 
>>> +++
>>>   include/drm/drm_color_mgmt.h |  19 
>>>   include/drm/drm_plane.h  |  32 
>>>   4 files changed, 162 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>>> index 46733d534587..452a0b0bafbc 100644
>>> --- a/drivers/gpu/drm/drm_atomic.c
>>> +++ b/drivers/gpu/drm/drm_atomic.c
>>> @@ -759,6 +759,10 @@ static int drm_atomic_plane_set_property(struct 
>>> drm_plane *plane,
>>> state->rotation = val;
>>> } else if (property == plane->zpos_property) {
>>> state->zpos = val;
>>> +   } else if (property == plane->color_encoding_property) {
>>> +   state->color_encoding = val;
>>> +   } else if (property == plane->color_range_property) {
>>> +   state->color_range = val;
>>> } else if (plane->funcs->atomic_set_property) {
>>> return plane->funcs->atomic_set_property(plane, state,
>>> property, val);
>>> @@ -818,6 +822,10 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
>>> *val = state->rotation;
>>> } else if (property == plane->zpos_property) {
>>> *val = state->zpos;
>>> +   } else if (property == plane->color_encoding_property) {
>>> +   *val = state->color_encoding;
>>> +   } else if (property == plane->color_range_property) {
>>> +   *val = state->color_range;
>>> } else if (plane->funcs->atomic_get_property) {
>>> return plane->funcs->atomic_get_property(plane, state, 
>>> property, val);
>>> } else {
>>> diff --git a/drivers/gpu/drm/drm_color_mgmt.c 
>>> b/drivers/gpu/drm/drm_color_mgmt.c
>>> index 0d002b045bd2..4b83e078d3e9 100644
>>> --- a/drivers/gpu/drm/drm_color_mgmt.c
>>> +++ b/drivers/gpu/drm/drm_color_mgmt.c
>>> @@ -88,6 +88,20 @@
>>>* drm_mode_crtc_set_gamma_size(). Drivers which support both should use
>>>* drm_atomic_helper_legacy_gamma_set() to alias the legacy gamma ramp 
>>> with the
>>>* "GAMMA_LUT" property above.
>>> + *
>>> + * Support for different non RGB color encodings is controlled through
>>> + * &drm_plane specific COLOR_ENCODING and COLOR_RANGE properties. They
>>> + * are set up by calling drm_plane_create_color_properties().
>>> + *
>>> + * "COLOR_ENCODING"
>>> + * Optional plane enum property to support different non RGB
>>> + * color encodings. The driver can provide a subset of standard
>>> + * enum values supported by the DRM plane.
>>> + *
>>> + * "COLOR_RANGE"
>>> + * Optional plane enum property to support different non RGB
>>> + * color parameter ranges. The driver can provide a subset o

Re: [Intel-gfx] [v2, 1/8] drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane

[Andrzej Hajda]

On 30.11.2018 15:48, Hans Verkuil wrote:
> On 11/30/18 15:29, Ville Syrjälä wrote:
>> On Fri, Nov 30, 2018 at 03:20:59PM +0100, Andrzej Hajda wrote:
>>> Hi Ville,
>>>
>>> As Christoph cannot respond till middle next week I can try to respond
>>> in his absence, as I am familiar with the subject.
>>>
>>> On 30.11.2018 14:25, Ville Syrjälä wrote:
>>>> On Fri, Nov 30, 2018 at 02:08:11PM +0100, Christoph Manszewski wrote:
>>>>> Hi,
>>>>>
>>>>> I am looking for a way to export the color encoding and range selection
>>>>> to user space. I came across those properties and am wondering, why
>>>>> they are meant only for non RGB color encodings. Would it be okay, to
>>>>> modify them and use with RGB formats as well?
>>>> What you trying to do? Input limited range RGB data and expand to full
>>>> range?
>>>
>>> For example. But there are two more general questions, which
>>> surprisingly we have not found answer for.
>>>
>>> 1. What color encoding and range drm should expect on its input RGB
>>> buffers by default?
>> RGB is just RGB. There is no encoding. 


OK, Now I see I have confused encoding with colorspace, Hans thanks for
the documentation.

As I understand drm by default should expect sRGB colorspace, also for
Y'CbCr buffers, and currently there are no standard ways to specify
buffer colorspace.

Looking at current users of drm_plane_create_color_properties for Y'CbCr
buffers it seems default range should be LIMITED.

But default encoding is different: mali, armada, nouveau use
DRM_COLOR_YCBCR_BT601, i915 uses DRM_COLOR_YCBCR_BT709 - shouldn't this
be somehow standardized?


What I still do not understand is colorspace conversion(not encoding!) -
between pipeline input (framebuffers) and output (HDMI connector for
example):

1. Since sRGB, SMPTE170M/BT.601, BT.709 colorspaces are 'almost
identical in coverage' (according to wikipedia[1]) no colorspace
conversion is performed at all.

2. It is performed somewhere by HW, just my IP documentation is not
clear about it.


Another thing which still bothers me is RGB range in case of HDMI -
CEA-861 expects than on CEA modes limited RGB range should be sent, but
the pipeline on the particular hardware I have do not perform any
conversion of input buffers. So only limited range RGB buffers are
displayed correctly. In such case property describing plane with limited
RGB would be useful.


[1]: https://en.wikipedia.org/wiki/Rec._709#Primary_chromaticities


> It's assumed to be full range 
>> because no one really uses anything else.
> For simple desktop usage that's true. When dealing with video inputs,
> this becomes much more complicated.


As I said earlier there are cases where output stream should be limited
RGB, and no conversion in pipeline - thus framebuffers also should be
'limited RGB'.


Regards

Andrzej


>
>>> 2. How userspace should inform drm that given buffer has specified
>>> non-default color encoding and range?
>>>
>>>
>>> Hopefully this patch introduces such properties but only for YCbCr
>>> formats, the question is what should be the best way to expand it to RGB
>>> formats:
>>>
>>> A. Add another enums: DRM_COLOR_RGB_BT601 and friends.
>> BT.601 specifies how to encoder RGB data as YCbCr. So without
>> YCbCr BT.601 does not mean anything. Well, the standard does
>> contain other things as well I suppose, but for the purposes
>> of the color encoding prop only that one part is relevant.
> Ah, I misunderstood the meaning of DRM_COLOR_RGB_BT601.
> This is the equivalent of V4L2_YCBCR_ENC_601, and that's indeed
> only defined for Y'CbCr. But it is often (ab)used as an alias for
> the SMPTE170M colorspace (used by SDTV).
>
> V4L2 has the following defines for colorspaces, transfer functions,
> Y'CbCr (and HSV) encodings and quantization ranges:
>
> https://hverkuil.home.xs4all.nl/spec/uapi/v4l/colorspaces-defs.html
>
> Missing in this list is the color encoding (RGB vs YCbCr vs HSV) which
> is set through the pixelformat fourcc.
>
> And indeed, we don't have an RGB encoding define since RGB is just RGB :-)
>
> Regards,
>
>   Hans
>
>>> B. Reuse current enums, but remove format information from them:
>>> DRM_COLOR_YCBCR_BT601 => DRM_COLOR_BT601.
>>>
>>>
>>> Regards
>>>
>>> Andrzej
>>>
...
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [v2, 1/8] drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane

[Andrzej Hajda]

On 03.12.2018 12:52, Hans Verkuil wrote:
> On 12/03/2018 12:23 PM, Andrzej Hajda wrote:
>> On 30.11.2018 15:48, Hans Verkuil wrote:
>>> On 11/30/18 15:29, Ville Syrjälä wrote:
>>>> On Fri, Nov 30, 2018 at 03:20:59PM +0100, Andrzej Hajda wrote:
>>>>> Hi Ville,
>>>>>
>>>>> As Christoph cannot respond till middle next week I can try to respond
>>>>> in his absence, as I am familiar with the subject.
>>>>>
>>>>> On 30.11.2018 14:25, Ville Syrjälä wrote:
>>>>>> On Fri, Nov 30, 2018 at 02:08:11PM +0100, Christoph Manszewski wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I am looking for a way to export the color encoding and range selection
>>>>>>> to user space. I came across those properties and am wondering, why
>>>>>>> they are meant only for non RGB color encodings. Would it be okay, to
>>>>>>> modify them and use with RGB formats as well?
>>>>>> What you trying to do? Input limited range RGB data and expand to full
>>>>>> range?
>>>>> For example. But there are two more general questions, which
>>>>> surprisingly we have not found answer for.
>>>>>
>>>>> 1. What color encoding and range drm should expect on its input RGB
>>>>> buffers by default?
>>>> RGB is just RGB. There is no encoding. 
>>
>> OK, Now I see I have confused encoding with colorspace, Hans thanks for
>> the documentation.
>>
>> As I understand drm by default should expect sRGB colorspace, also for
>> Y'CbCr buffers, and currently there are no standard ways to specify
>> buffer colorspace.
>>
>> Looking at current users of drm_plane_create_color_properties for Y'CbCr
>> buffers it seems default range should be LIMITED.
> Right. There is support for YCbCr quantization range signaling in HDMI,
> but that is for all intents and purposes broken in the standard. Don't
> use it, just output limited range YCbCr.
>
> On the other hand, RGB Quantization range signaling should *always* be
> used if the EDID signals support for it. I believe that's what drm does
> today already (this certainly works for i915).
>
>> But default encoding is different: mali, armada, nouveau use
>> DRM_COLOR_YCBCR_BT601, i915 uses DRM_COLOR_YCBCR_BT709 - shouldn't this
>> be somehow standardized?
> According to CEA-861 bt.601 should be used for SDTV (PAL/NTSC), 709 for
> everything else. So this is resolution dependent.
>
> Although strictly speaking it is only userspace that knows the right
> encoding, since it depends on the source material. You can have SDTV
> video encoded with 709, or HDTV encoded with 601. But in the absence
> of any information, the default rule above is what should be used.


Since drm plane is not tied to specific crtc default encoding will not
be always known prior to setting mode on crtc and attaching plane to
crtc, probably DRM_COLOR_YCBCR_DEFAULT or similar would solve the issue.


>
>>
>> What I still do not understand is colorspace conversion(not encoding!) -
>> between pipeline input (framebuffers) and output (HDMI connector for
>> example):
>>
>> 1. Since sRGB, SMPTE170M/BT.601, BT.709 colorspaces are 'almost
>> identical in coverage' (according to wikipedia[1]) no colorspace
>> conversion is performed at all.
> That's correct. There is a slight difference between SMPTE170M and
> sRGB/Rec709, but basically invisible to the naked eye unless you see
> it side-by-side, and even then it's is hard to detect.
>
> However, sRGB uses a different transfer function compared to SMPTE170M
> and Rec709, and that difference *is* quite visible. Not all hardware
> (certainly not video capture hardware) is capable of converting between
> different transfer functions, though. I gather that this is more common
> for HDMI output hardware.
>
>> 2. It is performed somewhere by HW, just my IP documentation is not
>> clear about it.
>>
>>
>> Another thing which still bothers me is RGB range in case of HDMI -
>> CEA-861 expects than on CEA modes limited RGB range should be sent, but
>> the pipeline on the particular hardware I have do not perform any
>> conversion of input buffers. So only limited range RGB buffers are
>> displayed correctly. In such case property describing plane with limited
>> RGB would be useful.
> Are you sure? Usually the same block that does YCbCr encoding conversion
> (601 to 709 or vice versa), also deals with limited/full range conversion.
>
> It 

Re: [Intel-gfx] [PATCH 1/4] drm/edid: Pass connector to AVI inforframe functions

[Andrzej Hajda]

On 03.12.2018 22:48, Ville Syrjälä wrote:
> On Thu, Nov 29, 2018 at 09:46:16AM +0100, Andrzej Hajda wrote:
>> Quite late, hopefully not too late.
>>
>>
>> On 21.11.2018 12:51, Ville Syrjälä wrote:
>>> On Wed, Nov 21, 2018 at 01:40:43PM +0200, Jani Nikula wrote:
>>>>>   return;
>>>>> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
>>>>> b/drivers/gpu/drm/bridge/sil-sii8620.c
>>>>> index a6e8f4591e63..0cc293a6ac24 100644
>>>>> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
>>>>> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
>>>>> @@ -1104,8 +1104,7 @@ static void sii8620_set_infoframes(struct sii8620 
>>>>> *ctx,
>>>>>   int ret;
>>>>>  
>>>>>   ret = drm_hdmi_avi_infoframe_from_display_mode(&frm.avi,
>>>>> -mode,
>>>>> -true);
>>>>> +NULL, mode);
>>>>>   if (ctx->use_packed_pixel)
>>>>>   frm.avi.colorspace = HDMI_COLORSPACE_YUV422;
>>>>>  
>>>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
>>>>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>>>> index 64c3cf027518..88b720b63126 100644
>>>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>>>> @@ -1344,7 +1344,8 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, 
>>>>> struct drm_display_mode *mode)
>>>>>   u8 val;
>>>>>  
>>>>>   /* Initialise info frame from DRM mode */
>>>>> - drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
>>>>> + drm_hdmi_avi_infoframe_from_display_mode(&frame,
>>>>> +  &hdmi->connector, mode);
>>>>>  
>>>>>   if (hdmi_bus_fmt_is_yuv444(hdmi->hdmi_data.enc_out_bus_format))
>>>>>   frame.colorspace = HDMI_COLORSPACE_YUV444;
>>>>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>>>>> index b506e3622b08..501ac05ba7da 100644
>>>>> --- a/drivers/gpu/drm/drm_edid.c
>>>>> +++ b/drivers/gpu/drm/drm_edid.c
>>>>> @@ -4830,19 +4830,32 @@ void drm_set_preferred_mode(struct drm_connector 
>>>>> *connector,
>>>>>  }
>>>>>  EXPORT_SYMBOL(drm_set_preferred_mode);
>>>>>  
>>>>> +static bool is_hdmi2_sink(struct drm_connector *connector)
>>>> You're usually known for adding const all around, why not const pointer
>>>> here and in all the other drm_* functions that call this?
>>> My current approach is to constify states/fbs/etc. but not so much
>>> crtcs/connectors/etc. Too much const can sometimes get in the way
>>> of things requiring that you remove the const later. But I guess
>>> in this case the const shouldn't really get in the way of anything
>>> because these are pretty much supposed to be pure functions.
>>>
>>>>> +{
>>>>> + /*
>>>>> +  * FIXME: sil-sii8620 doesn't have a connector around when
>>>>> +  * we need one, so we have to be prepared for a NULL connector.
>>>>> +  */
>>>>> + if (!connector)
>>>>> + return false;
>>>> This actually changes the is_hdmi2_sink value for sil-sii8620.
>>> Hmm. No idea why they would have set that to true when everyone else is
>>> passing false. 
>>
>> Because false does not work :) More precisely MHLv3 (used in Sii8620)
>> uses CTA-861-F standard for infoframes, which is specific to HDMI2.0.
>>
>> Unfortunately I have no access to MHL specs, but my experiments and
>> vendor drivers strongly suggests it is done this way.
>>
>> This is important in case of 4K modes which are handled differently by
>> HDMI 1.4 and HDMI2.0.
> HDMI 2.0 handles 4k just like 1.4 handled it when you use one of
> the 4k modes defined in 1.4. Only if you use features beyond 1.4 do we
> switch over to the HDMI 2.0 specific signalling.


The difference is in infoframes:

HDMI 1.4 sets AVI infoframe VIC to 0, and sends HDMI_VIC in VSI.

HDMI 2.0 sets AVI infoframe to non zero VICs introduced by
HDMI2.0/CEA-861-F, VSI can be omitted if I remember correctly, unless 3d
is in use.


So setting VICs to non-zero in case of HDMI1.4 sinks an

Re: [Intel-gfx] [PATCH 1/4] drm/edid: Pass connector to AVI inforframe functions

[Andrzej Hajda]

On 03.12.2018 22:38, Ville Syrjälä wrote:
> On Thu, Nov 29, 2018 at 10:08:07AM +0100, Andrzej Hajda wrote:
>> On 21.11.2018 19:19, Laurent Pinchart wrote:
>>> Hi Ville,
>>>
>>> Thank you for the patch.
>>>
>>> On Tuesday, 20 November 2018 18:13:42 EET Ville Syrjala wrote:
>>>> From: Ville Syrjälä 
>>>>
>>>> Make life easier for drivers by simply passing the connector
>>>> to drm_hdmi_avi_infoframe_from_display_mode() and
>>>> drm_hdmi_avi_infoframe_quant_range(). That way drivers don't
>>>> need to worry about is_hdmi2_sink mess.
>>> While this is good for display controller drivers, the change isn't great 
>>> for 
>>> bridge drivers. Down the road we're looking at moving connector support out 
>>> of 
>>> the bridge drivers. Adding an additional dependency to connectors in the 
>>> bridges will make that more difficult. Ideally bridges should retrieve the 
>>> information from their sink, regardless of whether it is a connector or 
>>> another bridge.
>>
>> I agree with it, and case of sii8620 shows that there are cases where
>> bridge has no direct access to the connector.
> It's just a matter of plumbing it through.


What do you mean exactly?


>
>> On the other side,  since you are passing connector to
>> drm_hdmi_avi_infoframe_from_display_mode(), you could drop mode
>> parameter and rename the function to
>> drm_hdmi_avi_infoframe_from_connector() then, unless mode passed and
>> mode set on the connector differs?
> Connectors don't have a mode.


As they are passing video stream they should have it, even if not
directly, for example:

connector->state->crtc->mode

In moment of creating infoframe it should be set properly.


Regards

Andrzej


>
>>
>> Regards
>>
>> Andrzej
>>
>>
>>> Please see below for an additional comment.
>>>
>>>> Cc: Alex Deucher 
>>>> Cc: "Christian König" 
>>>> Cc: "David (ChunMing) Zhou" 
>>>> Cc: Archit Taneja 
>>>> Cc: Andrzej Hajda 
>>>> Cc: Laurent Pinchart 
>>>> Cc: Inki Dae 
>>>> Cc: Joonyoung Shim 
>>>> Cc: Seung-Woo Kim 
>>>> Cc: Kyungmin Park 
>>>> Cc: Russell King 
>>>> Cc: CK Hu 
>>>> Cc: Philipp Zabel 
>>>> Cc: Rob Clark 
>>>> Cc: Ben Skeggs 
>>>> Cc: Tomi Valkeinen 
>>>> Cc: Sandy Huang 
>>>> Cc: "Heiko Stübner" 
>>>> Cc: Benjamin Gaignard 
>>>> Cc: Vincent Abriou 
>>>> Cc: Thierry Reding 
>>>> Cc: Eric Anholt 
>>>> Cc: Shawn Guo 
>>>> Cc: Ilia Mirkin 
>>>> Cc: amd-...@lists.freedesktop.org
>>>> Cc: linux-arm-...@vger.kernel.org
>>>> Cc: freedr...@lists.freedesktop.org
>>>> Cc: nouv...@lists.freedesktop.org
>>>> Cc: linux-te...@vger.kernel.org
>>>> Signed-off-by: Ville Syrjälä 
>>>> ---
>>>>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
>>>>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
>>>>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c |  3 ++-
>>>>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
>>>>  drivers/gpu/drm/bridge/analogix-anx78xx.c |  5 ++--
>>>>  drivers/gpu/drm/bridge/sii902x.c  |  3 ++-
>>>>  drivers/gpu/drm/bridge/sil-sii8620.c  |  3 +--
>>>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  3 ++-
>>>>  drivers/gpu/drm/drm_edid.c| 33 ++-
>>>>  drivers/gpu/drm/exynos/exynos_hdmi.c  |  3 ++-
>>>>  drivers/gpu/drm/i2c/tda998x_drv.c |  3 ++-
>>>>  drivers/gpu/drm/i915/intel_hdmi.c | 14 +-
>>>>  drivers/gpu/drm/i915/intel_lspcon.c   | 15 ++-
>>>>  drivers/gpu/drm/i915/intel_sdvo.c | 10 ---
>>>>  drivers/gpu/drm/mediatek/mtk_hdmi.c   |  3 ++-
>>>>  drivers/gpu/drm/msm/hdmi/hdmi_bridge.c|  3 ++-
>>>>  drivers/gpu/drm/nouveau/dispnv50/disp.c   |  7 +++--
>>>>  drivers/gpu/drm/omapdrm/omap_encoder.c|  5 ++--
>>>>  drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
>>>>  drivers/gpu/drm/rockchip/inno_hdmi.c  |  4 ++-
>>>>  drivers/gpu/drm/sti/sti_hdmi.c|  3 ++-
>>>>  drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c|  3 ++-
>>>>  drivers/gpu/drm/tegra/hdmi.c  |  3 ++-
>>>>  drivers/gpu/drm/tegra/sor.c   |  3 ++-
>>>>  drivers/gpu/drm/vc4/vc4_hdmi.c| 11 +---
>>>>  drivers/gpu/drm/zte/zx_hdmi.c |  4 ++-
>>>>  include/drm/drm_edid.h|  8 +++---
>>>>  27 files changed, 94 insertions(+), 66 deletions(-)
>>> For dw-hdmi and omapdrm,
>>>
>>> Reviewed-by: Laurent Pinchart 
>>>

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/4] drm/edid: Pass connector to AVI inforframe functions

[Andrzej Hajda]

On 04.12.2018 20:02, Ville Syrjälä wrote:
> On Tue, Dec 04, 2018 at 08:03:53AM +0100, Andrzej Hajda wrote:
>> On 03.12.2018 22:48, Ville Syrjälä wrote:
>>> On Thu, Nov 29, 2018 at 09:46:16AM +0100, Andrzej Hajda wrote:
>>>> Quite late, hopefully not too late.
>>>>
>>>>
>>>> On 21.11.2018 12:51, Ville Syrjälä wrote:
>>>>> On Wed, Nov 21, 2018 at 01:40:43PM +0200, Jani Nikula wrote:
>>>>>>> return;
>>>>>>> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
>>>>>>> b/drivers/gpu/drm/bridge/sil-sii8620.c
>>>>>>> index a6e8f4591e63..0cc293a6ac24 100644
>>>>>>> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
>>>>>>> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
>>>>>>> @@ -1104,8 +1104,7 @@ static void sii8620_set_infoframes(struct sii8620 
>>>>>>> *ctx,
>>>>>>> int ret;
>>>>>>>  
>>>>>>> ret = drm_hdmi_avi_infoframe_from_display_mode(&frm.avi,
>>>>>>> -  mode,
>>>>>>> -  true);
>>>>>>> +  NULL, mode);
>>>>>>> if (ctx->use_packed_pixel)
>>>>>>> frm.avi.colorspace = HDMI_COLORSPACE_YUV422;
>>>>>>>  
>>>>>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
>>>>>>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>>>>>> index 64c3cf027518..88b720b63126 100644
>>>>>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>>>>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>>>>>> @@ -1344,7 +1344,8 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, 
>>>>>>> struct drm_display_mode *mode)
>>>>>>> u8 val;
>>>>>>>  
>>>>>>> /* Initialise info frame from DRM mode */
>>>>>>> -   drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
>>>>>>> +   drm_hdmi_avi_infoframe_from_display_mode(&frame,
>>>>>>> +&hdmi->connector, 
>>>>>>> mode);
>>>>>>>  
>>>>>>> if (hdmi_bus_fmt_is_yuv444(hdmi->hdmi_data.enc_out_bus_format))
>>>>>>> frame.colorspace = HDMI_COLORSPACE_YUV444;
>>>>>>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>>>>>>> index b506e3622b08..501ac05ba7da 100644
>>>>>>> --- a/drivers/gpu/drm/drm_edid.c
>>>>>>> +++ b/drivers/gpu/drm/drm_edid.c
>>>>>>> @@ -4830,19 +4830,32 @@ void drm_set_preferred_mode(struct 
>>>>>>> drm_connector *connector,
>>>>>>>  }
>>>>>>>  EXPORT_SYMBOL(drm_set_preferred_mode);
>>>>>>>  
>>>>>>> +static bool is_hdmi2_sink(struct drm_connector *connector)
>>>>>> You're usually known for adding const all around, why not const pointer
>>>>>> here and in all the other drm_* functions that call this?
>>>>> My current approach is to constify states/fbs/etc. but not so much
>>>>> crtcs/connectors/etc. Too much const can sometimes get in the way
>>>>> of things requiring that you remove the const later. But I guess
>>>>> in this case the const shouldn't really get in the way of anything
>>>>> because these are pretty much supposed to be pure functions.
>>>>>
>>>>>>> +{
>>>>>>> +   /*
>>>>>>> +* FIXME: sil-sii8620 doesn't have a connector around when
>>>>>>> +* we need one, so we have to be prepared for a NULL connector.
>>>>>>> +*/
>>>>>>> +   if (!connector)
>>>>>>> +   return false;
>>>>>> This actually changes the is_hdmi2_sink value for sil-sii8620.
>>>>> Hmm. No idea why they would have set that to true when everyone else is
>>>>> passing false. 
>>>> Because false does not work :) More precisely MHLv3 (used in Sii8620)
>>>> uses CTA-861-F standard for infofr

Re: [Intel-gfx] [PATCH 1/4] drm/edid: Pass connector to AVI inforframe functions

[Andrzej Hajda]

On 05.12.2018 07:32, Laurent Pinchart wrote:
> Hi Ville,
>
> On Tuesday, 4 December 2018 21:13:20 EET Ville Syrjälä wrote:
>> On Tue, Dec 04, 2018 at 08:46:53AM +0100, Andrzej Hajda wrote:
>>> On 03.12.2018 22:38, Ville Syrjälä wrote:
>>>> On Thu, Nov 29, 2018 at 10:08:07AM +0100, Andrzej Hajda wrote:
>>>>> On 21.11.2018 19:19, Laurent Pinchart wrote:
>>>>>> On Tuesday, 20 November 2018 18:13:42 EET Ville Syrjala wrote:
>>>>>>> From: Ville Syrjälä 
>>>>>>>
>>>>>>> Make life easier for drivers by simply passing the connector
>>>>>>> to drm_hdmi_avi_infoframe_from_display_mode() and
>>>>>>> drm_hdmi_avi_infoframe_quant_range(). That way drivers don't
>>>>>>> need to worry about is_hdmi2_sink mess.
>>>>>> While this is good for display controller drivers, the change isn't
>>>>>> great for bridge drivers. Down the road we're looking at moving
>>>>>> connector support out of the bridge drivers. Adding an additional
>>>>>> dependency to connectors in the bridges will make that more
>>>>>> difficult. Ideally bridges should retrieve the information from their
>>>>>> sink, regardless of whether it is a connector or another bridge.
>>>>> I agree with it, and case of sii8620 shows that there are cases where
>>>>> bridge has no direct access to the connector.
>>>> It's just a matter of plumbing it through.
>>> What do you mean exactly?
>> void bridge_foo(...
>> +   ,struct drm_connector *connector);
>>
>>>>> On the other side,  since you are passing connector to
>>>>> drm_hdmi_avi_infoframe_from_display_mode(), you could drop mode
>>>>> parameter and rename the function to
>>>>> drm_hdmi_avi_infoframe_from_connector() then, unless mode passed and
>>>>> mode set on the connector differs?
>>>> Connectors don't have a mode.
>>> As they are passing video stream they should have it, even if not
>>> directly, for example:
>>>
>>> connector->state->crtc->mode
>> That's not really how atomic works. One shouldn't go digging
>> through the obj->state pointers when we're not holding the
>> relevant locks anymore. The atomic way would be to pass either
>> both crtc state and connector state, or drm_atomic_state +
>> crtc/connector.


Usually infoframe contents is generated in modesetting/enable callbacks
so the locks should be in place.

And the locks should be hold for
drm_hdmi_avi_infoframe_from_display_mode as well - it wouldn't be correct if

generated infoframe is not relevant to actual video mode. I guess that
if connector->state->crtc->mode

differs from mode passed to drm_hdmi_avi_infoframe_from_display_mode it
is a sign of possible problem.

And if they do not differ passing mode as an extra argument is redundant.


> Or a bridge state ? With chained bridges the mode can vary along the 
> pipeline, 
> the CRTC adjusted mode will only cover the link between the CRTC and the 
> first 
> bridge. It's only a matter of time until we need to store other intermediate 
> modes in states. I'd rather prepare for that instead of passing the CRTC 
> state 
> to bridges.


Yes, optional bridge states seems reasonable, volunteers needed :)


Regards

Andrzej


>
>>> In moment of creating infoframe it should be set properly.
>>>
>>>>>> Please see below for an additional comment.
>>>>>>
>>>>>>> Cc: Alex Deucher 
>>>>>>> Cc: "Christian König" 
>>>>>>> Cc: "David (ChunMing) Zhou" 
>>>>>>> Cc: Archit Taneja 
>>>>>>> Cc: Andrzej Hajda 
>>>>>>> Cc: Laurent Pinchart 
>>>>>>> Cc: Inki Dae 
>>>>>>> Cc: Joonyoung Shim 
>>>>>> Cc: Seung-Woo Kim 
>>>>>>> Cc: Kyungmin Park 
>>>>>>> Cc: Russell King 
>>>>>>> Cc: CK Hu 
>>>>>>> Cc: Philipp Zabel 
>>>>>>> Cc: Rob Clark 
>>>>>>> Cc: Ben Skeggs 
>>>>>>> Cc: Tomi Valkeinen 
>>>>>>> Cc: Sandy Huang 
>>>>>>> Cc: "Heiko Stübner" 
>>>>>>> Cc: Benjamin Gaignard 
>>>>>>> Cc: Vincent Abriou 
>>>>>>> Cc: Thierry Reding 
>>>>>>> Cc: Eric Anhol

Re: [Intel-gfx] [PATCH v7] drm/i915/display: disable HPD workers before display driver unregister

[Andrzej Hajda]

On 10.06.2022 20:37, Ville Syrjälä wrote:

On Fri, Jun 10, 2022 at 06:00:24PM +0200, Andrzej Hajda wrote:

Handling HPD during driver removal is pointless, and can cause different
use-after-free/concurrency issues:
1. Setup of deferred fbdev after fbdev unregistration.
2. Access to DP-AUX after DP-AUX removal.

Below stacktraces of both cases observed on CI:

[272.634530] general protection fault, probably for non-canonical address 
0x6b6b6b6b6b6b6b6b:  [#1] PREEMPT SMP NOPTI
[272.634536] CPU: 0 PID: 6030 Comm: i915_selftest Tainted: G U
5.18.0-rc5-CI_DRM_11603-g12dccf4f5eef+ #1
[272.634541] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[272.634545] RIP: 0010:fb_do_apertures_overlap.part.14+0x26/0x60
...
[272.634582] Call Trace:
[272.634583]  
[272.634585]  do_remove_conflicting_framebuffers+0x59/0xa0
[272.634589]  remove_conflicting_framebuffers+0x2d/0xc0
[272.634592]  remove_conflicting_pci_framebuffers+0xc8/0x110
[272.634595]  drm_aperture_remove_conflicting_pci_framebuffers+0x52/0x70
[272.634604]  i915_driver_probe+0x63a/0xdd0 [i915]

[283.405824] cpu_latency_qos_update_request called for unknown object
[283.405866] WARNING: CPU: 2 PID: 240 at kernel/power/qos.c:296 
cpu_latency_qos_update_request+0x2d/0x100
[283.405912] CPU: 2 PID: 240 Comm: kworker/u64:9 Not tainted 
5.18.0-rc6-Patchwork_103738v3-g1672d1c43e43+ #1
[283.405915] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[283.405916] Workqueue: i915-dp i915_digport_work_func [i915]
[283.406020] RIP: 0010:cpu_latency_qos_update_request+0x2d/0x100
...
[283.406040] Call Trace:
[283.406041]  
[283.406044]  intel_dp_aux_xfer+0x60e/0x8e0 [i915]
[283.406131]  ? finish_swait+0x80/0x80
[283.406139]  intel_dp_aux_transfer+0xc5/0x2b0 [i915]
[283.406218]  drm_dp_dpcd_access+0x79/0x130 [drm_display_helper]
[283.406227]  drm_dp_dpcd_read+0xe2/0xf0 [drm_display_helper]
[283.406233]  intel_dp_hpd_pulse+0x134/0x570 [i915]
[283.406308]  ? __down_killable+0x70/0x140
[283.406313]  i915_digport_work_func+0xba/0x150 [i915]

Signed-off-by: Andrzej Hajda 
---
Hi All,

I am not sure about changes in shutdown path, any comments welcome.
I suspect suspend path have also some common bits, but I am little
bit afraid of touching it.

Changes:
v1 - v6:
 - chasing the bug appearing only on public CI.
v7:
 - shutdown path adjusted (suggested by Jani)

Regards
Andrzej
---
  drivers/gpu/drm/i915/display/intel_display.c | 11 ---
  drivers/gpu/drm/i915/i915_driver.c   |  5 ++---
  2 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 186b37925d23f2..f9952ee8289fb2 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10490,13 +10490,6 @@ void intel_modeset_driver_remove_noirq(struct 
drm_i915_private *i915)
 */
intel_hpd_poll_fini(i915);
  
-	/*

-* MST topology needs to be suspended so we don't have any calls to
-* fbdev after it's finalized. MST will be destroyed later as part of
-* drm_mode_config_cleanup()
-*/
-   intel_dp_mst_suspend(i915);
-
/* poll work can call into fbdev, hence clean that up afterwards */
intel_fbdev_fini(i915);
  
@@ -10588,6 +10581,10 @@ void intel_display_driver_unregister(struct drm_i915_private *i915)

if (!HAS_DISPLAY(i915))
return;
  
+	intel_dp_mst_suspend(i915);

+   intel_hpd_cancel_work(i915);
+   drm_kms_helper_poll_disable(&i915->drm);
+
intel_fbdev_unregister(i915);
intel_audio_deinit(i915);
  
diff --git a/drivers/gpu/drm/i915/i915_driver.c b/drivers/gpu/drm/i915/i915_driver.c

index d26dcca7e654aa..82cdccf072e2bc 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1070,15 +1070,14 @@ void i915_driver_shutdown(struct drm_i915_private *i915)
i915_gem_suspend(i915);
  
  	if (HAS_DISPLAY(i915)) {

+   intel_dp_mst_suspend(i915);
+   intel_hpd_cancel_work(i915);
drm_kms_helper_poll_disable(&i915->drm);
  
  		drm_atomic_helper_shutdown(&i915->drm);


You can't suspend MST before this since this is what actually turns the
displays off.

The real chicken and egg sitaation is due to MST sideband depending
on HPD_IRQs to work, but we want to stop the rest of hotplug processing
before we shut down the displays to make sure fbdev/etc. doesn't light
them back up.

If we didn't have MST sidband we could just turn off hotplug interrupts
ahead of time and flush the works, but with MST we need to keep the
interrupts alive. So I suspect we need some kind of flag to indicate
that at least full hotplug handling should not

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix vm use-after-free in vma destruction

[Andrzej Hajda]

On 20.06.2022 14:36, Thomas Hellström wrote:

In vma destruction, the following race may occur:

Thread 1: Thread 2:
i915_vma_destroy();

   ...
   list_del_init(vma->vm_link);
   ...
   mutex_unlock(vma->vm->mutex);
  __i915_vm_release();
release_references();

And in release_reference() we dereference vma->vm to get to the
vm gt pointer, leading to a use-after free.

However, __i915_vm_release() grabs the vm->mutex so the vm won't be
destroyed before vma->vm->mutex is released, so extract the gt pointer
under the vm->mutex to avoid the vma->vm dereference in
release_references().

v2: Fix a typo in the commit message (Andi Shyti)

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5944
Fixes: e1a7ab4fca ("drm/i915: Remove the vm open count")

Cc: Niranjana Vishwanathapura 
Cc: Matthew Auld 
Signed-off-by: Thomas Hellström 
---
  drivers/gpu/drm/i915/i915_vma.c | 12 
  1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 0bffb70b3c5f..04d12f278f57 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1637,10 +1637,10 @@ static void force_unbind(struct i915_vma *vma)
GEM_BUG_ON(drm_mm_node_allocated(&vma->node));
  }
  
-static void release_references(struct i915_vma *vma, bool vm_ddestroy)

+static void release_references(struct i915_vma *vma, struct intel_gt *gt,
+  bool vm_ddestroy)
  {
struct drm_i915_gem_object *obj = vma->obj;
-   struct intel_gt *gt = vma->vm->gt;
  
  	GEM_BUG_ON(i915_vma_is_active(vma));
  
@@ -1695,11 +1695,12 @@ void i915_vma_destroy_locked(struct i915_vma *vma)
  
  	force_unbind(vma);

list_del_init(&vma->vm_link);
-   release_references(vma, false);
+   release_references(vma, vma->vm->gt, false);
  }
  
  void i915_vma_destroy(struct i915_vma *vma)

  {
+   struct intel_gt *gt;
bool vm_ddestroy;
  
  	mutex_lock(&vma->vm->mutex);

@@ -1707,8 +1708,11 @@ void i915_vma_destroy(struct i915_vma *vma)
list_del_init(&vma->vm_link);
vm_ddestroy = vma->vm_ddestroy;
vma->vm_ddestroy = false;
+
+   /* vma->vm may be freed when releasing vma->vm->mutex. */
+   gt = vma->vm->gt;
mutex_unlock(&vma->vm->mutex);
-   release_references(vma, vm_ddestroy);
+   release_references(vma, gt, vm_ddestroy);



Reviewed-by: Andrzej Hajda 

Regards
Andrzej



  }
  
  void i915_vma_parked(struct intel_gt *gt)

[Intel-gfx] [PATCH 0/2] drm/i915/display: stop HPD workers before display driver unregister

[Andrzej Hajda]

Hi Jani, Ville,

This patchset is replacement of patch
"drm/i915/display: disable HPD workers before display driver unregister" [1].
Ive decided to split patch into two parts - fbdev and MST, there are different
issues.
Ive also dropped shutdown path, as it has slightly different requirements,
and more importantly I am not able to test properly.

[1]: https://patchwork.freedesktop.org/series/103811/

Regards
Andrzej


Andrzej Hajda (2):
  drm/i915/hpd: postpone HPD cancel work after last user suspension
  drm/i915/fbdev: suspend HPD before fbdev unregistration

 drivers/gpu/drm/i915/display/intel_display.c |  3 ++
 drivers/gpu/drm/i915/display/intel_fbdev.c   | 44 ++--
 drivers/gpu/drm/i915/i915_irq.c  |  1 -
 3 files changed, 26 insertions(+), 22 deletions(-)

-- 
2.25.1

[Intel-gfx] [PATCH 2/2] drm/i915/fbdev: suspend HPD before fbdev unregistration

[Andrzej Hajda]

HPD event after fbdev unregistration can cause registration of deferred
fbdev which will not be unregistered later, causing use-after-free.
To avoid it HPD handling should be suspended before fbdev unregistration.

It should fix following GPF:
[272.634530] general protection fault, probably for non-canonical address 
0x6b6b6b6b6b6b6b6b:  [#1] PREEMPT SMP NOPTI
[272.634536] CPU: 0 PID: 6030 Comm: i915_selftest Tainted: G U
5.18.0-rc5-CI_DRM_11603-g12dccf4f5eef+ #1
[272.634541] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[272.634545] RIP: 0010:fb_do_apertures_overlap.part.14+0x26/0x60
...
[272.634582] Call Trace:
[272.634583]  
[272.634585]  do_remove_conflicting_framebuffers+0x59/0xa0
[272.634589]  remove_conflicting_framebuffers+0x2d/0xc0
[272.634592]  remove_conflicting_pci_framebuffers+0xc8/0x110
[272.634595]  drm_aperture_remove_conflicting_pci_framebuffers+0x52/0x70
[272.634604]  i915_driver_probe+0x63a/0xdd0 [i915]

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5329
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5510
Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/display/intel_fbdev.c | 44 +++---
 1 file changed, 23 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 221336178991f0..113d6a8d65c872 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -566,6 +566,27 @@ static void intel_fbdev_sync(struct intel_fbdev *ifbdev)
ifbdev->cookie = 0;
 }
 
+/* Suspends/resumes fbdev processing of incoming HPD events. When resuming HPD
+ * processing, fbdev will perform a full connector reprobe if a hotplug event
+ * was received while HPD was suspended.
+ */
+static void intel_fbdev_hpd_set_suspend(struct drm_i915_private *i915, int 
state)
+{
+   struct intel_fbdev *ifbdev = i915->fbdev;
+   bool send_hpd = false;
+
+   mutex_lock(&ifbdev->hpd_lock);
+   ifbdev->hpd_suspended = state == FBINFO_STATE_SUSPENDED;
+   send_hpd = !ifbdev->hpd_suspended && ifbdev->hpd_waiting;
+   ifbdev->hpd_waiting = false;
+   mutex_unlock(&ifbdev->hpd_lock);
+
+   if (send_hpd) {
+   drm_dbg_kms(&i915->drm, "Handling delayed fbcon HPD event\n");
+   drm_fb_helper_hotplug_event(&ifbdev->helper);
+   }
+}
+
 void intel_fbdev_unregister(struct drm_i915_private *dev_priv)
 {
struct intel_fbdev *ifbdev = dev_priv->fbdev;
@@ -573,6 +594,8 @@ void intel_fbdev_unregister(struct drm_i915_private 
*dev_priv)
if (!ifbdev)
return;
 
+   intel_fbdev_hpd_set_suspend(dev_priv, FBINFO_STATE_SUSPENDED);
+
cancel_work_sync(&dev_priv->fbdev_suspend_work);
if (!current_is_async())
intel_fbdev_sync(ifbdev);
@@ -590,27 +613,6 @@ void intel_fbdev_fini(struct drm_i915_private *dev_priv)
intel_fbdev_destroy(ifbdev);
 }
 
-/* Suspends/resumes fbdev processing of incoming HPD events. When resuming HPD
- * processing, fbdev will perform a full connector reprobe if a hotplug event
- * was received while HPD was suspended.
- */
-static void intel_fbdev_hpd_set_suspend(struct drm_i915_private *i915, int 
state)
-{
-   struct intel_fbdev *ifbdev = i915->fbdev;
-   bool send_hpd = false;
-
-   mutex_lock(&ifbdev->hpd_lock);
-   ifbdev->hpd_suspended = state == FBINFO_STATE_SUSPENDED;
-   send_hpd = !ifbdev->hpd_suspended && ifbdev->hpd_waiting;
-   ifbdev->hpd_waiting = false;
-   mutex_unlock(&ifbdev->hpd_lock);
-
-   if (send_hpd) {
-   drm_dbg_kms(&i915->drm, "Handling delayed fbcon HPD event\n");
-   drm_fb_helper_hotplug_event(&ifbdev->helper);
-   }
-}
-
 void intel_fbdev_set_suspend(struct drm_device *dev, int state, bool 
synchronous)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
-- 
2.25.1

[Intel-gfx] [PATCH 1/2] drm/i915/hpd: postpone HPD cancel work after last user suspension

[Andrzej Hajda]

i915->hotplug.dig_port_work can be queued from intel_hpd_irq_handler
called by IRQ handler or by intel_hpd_trigger_irq called from dp_mst.
To avoid re-queuing lets cancel HPD work after intel_dp_mst_suspend.

It should fix following WARNINGS:
[283.405824] cpu_latency_qos_update_request called for unknown object
[283.405866] WARNING: CPU: 2 PID: 240 at kernel/power/qos.c:296 
cpu_latency_qos_update_request+0x2d/0x100
[283.405912] CPU: 2 PID: 240 Comm: kworker/u64:9 Not tainted 
5.18.0-rc6-Patchwork_103738v3-g1672d1c43e43+ #1
[283.405915] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[283.405916] Workqueue: i915-dp i915_digport_work_func [i915]
[283.406020] RIP: 0010:cpu_latency_qos_update_request+0x2d/0x100
...
[283.406040] Call Trace:
[283.406041]  
[283.406044]  intel_dp_aux_xfer+0x60e/0x8e0 [i915]
[283.406131]  ? finish_swait+0x80/0x80
[283.406139]  intel_dp_aux_transfer+0xc5/0x2b0 [i915]
[283.406218]  drm_dp_dpcd_access+0x79/0x130 [drm_display_helper]
[283.406227]  drm_dp_dpcd_read+0xe2/0xf0 [drm_display_helper]
[283.406233]  intel_dp_hpd_pulse+0x134/0x570 [i915]
[283.406308]  ? __down_killable+0x70/0x140
[283.406313]  i915_digport_work_func+0xba/0x150 [i915]

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4586
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5558
Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/display/intel_display.c | 3 +++
 drivers/gpu/drm/i915/i915_irq.c  | 1 -
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 186b37925d23f2..4bca6381731058 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10497,6 +10497,9 @@ void intel_modeset_driver_remove_noirq(struct 
drm_i915_private *i915)
 */
intel_dp_mst_suspend(i915);
 
+   /* MST is the last user of HPD work */
+   intel_hpd_cancel_work(i915);
+
/* poll work can call into fbdev, hence clean that up afterwards */
intel_fbdev_fini(i915);
 
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 73cebc6aa65072..db14787aef95dd 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4597,7 +4597,6 @@ void intel_irq_uninstall(struct drm_i915_private 
*dev_priv)
 
free_irq(irq, dev_priv);
 
-   intel_hpd_cancel_work(dev_priv);
dev_priv->runtime_pm.irqs_enabled = false;
 }
 
-- 
2.25.1

[Intel-gfx] [PATCH] drm/i915/selftests: fix subtraction overflow bug

[Andrzej Hajda]

On some machines hole_end can be small enough to cause subtraction
overflow. On the other side (addr + 2 * min_alignment) can overflow
in case of mock tests. This patch should handle both cases.

Fixes: e1c5f754067b59 ("drm/i915: Avoid overflow in computing pot_hole loop 
termination")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3674
Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index 8633bec18fa75e..ab9f17fc85bcf2 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -742,7 +742,7 @@ static int pot_hole(struct i915_address_space *vm,
u64 addr;
 
for (addr = round_up(hole_start + min_alignment, step) - 
min_alignment;
-addr <= round_down(hole_end - (2 * min_alignment), step) - 
min_alignment;
+hole_end > addr && hole_end - addr >= 2 * min_alignment;
 addr += step) {
err = i915_vma_pin(vma, 0, 0, addr | flags);
if (err) {
-- 
2.25.1

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix a lockdep warning at error capture

[Andrzej Hajda]

On 24.06.2022 13:08, Nirmoy Das wrote:

For some platfroms we use stop_machine version of
gen8_ggtt_insert_page/gen8_ggtt_insert_entries to avoid a
concurrent GGTT access bug but this causes a circular locking
dependency warning:

   Possible unsafe locking scenario:
 CPU0CPU1
 
lock(&ggtt->error_mutex);
 lock(dma_fence_map);
 lock(&ggtt->error_mutex);
lock(cpu_hotplug_lock);

Fix this by calling gen8_ggtt_insert_page/gen8_ggtt_insert_entries
directly at error capture which is concurrent GGTT access safe because
reset path make sure of that.

v2: Fix rebase conflict and added a comment.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5595
Reviewed-by: Gwan-gyeong Mun 
Suggested-by: Chris Wilson 
Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/i915/gt/intel_ggtt.c | 10 ++
  drivers/gpu/drm/i915/gt/intel_gtt.h  |  9 +
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c |  5 -
  drivers/gpu/drm/i915/i915_gpu_error.c|  8 ++--
  4 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 96180313..15a915bb4088 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -960,6 +960,16 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
if (intel_vm_no_concurrent_access_wa(i915)) {
ggtt->vm.insert_entries = bxt_vtd_ggtt_insert_entries__BKL;
ggtt->vm.insert_page= bxt_vtd_ggtt_insert_page__BKL;
+
+   /*
+* Calling stop_machine() version of GGTT update function
+* at error capture/reset path will raise lockdep warning.
+* Allow calling gen8_ggtt_insert_* directly at reset path
+* which is safe from parallel GGTT updates.
+*/
+   ggtt->vm.raw_insert_page = gen8_ggtt_insert_page;
+   ggtt->vm.raw_insert_entries = gen8_ggtt_insert_entries;
+
ggtt->vm.bind_async_flags =
I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h 
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 29fd3a9e8b2e..e639434e97fd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -306,6 +306,15 @@ struct i915_address_space {
   struct i915_vma_resource *vma_res,
   enum i915_cache_level cache_level,
   u32 flags);
+   void (*raw_insert_page)(struct i915_address_space *vm,
+   dma_addr_t addr,
+   u64 offset,
+   enum i915_cache_level cache_level,
+   u32 flags);
+   void (*raw_insert_entries)(struct i915_address_space *vm,
+  struct i915_vma_resource *vma_res,
+  enum i915_cache_level cache_level,
+  u32 flags);



I would expect rather extra flag to insert_(page|entries) instead of 
extra callbacks. Anyway both should work.


Reviewed-by: Andrzej Hajda 

Regards
Andrzej



void (*cleanup)(struct i915_address_space *vm);
  
  	void (*foreach)(struct i915_address_space *vm,

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index d2c5c9367cc4..c06e83872c34 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -493,7 +493,10 @@ static void uc_fw_bind_ggtt(struct intel_uc_fw *uc_fw)
if (i915_gem_object_is_lmem(obj))
pte_flags |= PTE_LM;
  
-	ggtt->vm.insert_entries(&ggtt->vm, dummy, I915_CACHE_NONE, pte_flags);

+   if (ggtt->vm.raw_insert_entries)
+   ggtt->vm.raw_insert_entries(&ggtt->vm, dummy, I915_CACHE_NONE, 
pte_flags);
+   else
+   ggtt->vm.insert_entries(&ggtt->vm, dummy, I915_CACHE_NONE, 
pte_flags);
  }
  
  static void uc_fw_unbind_ggtt(struct intel_uc_fw *uc_fw)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index bff8a111424a..f9b1969ed7ed 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1104,8 +1104,12 @@ i915_vma_coredump_create(const struct intel_gt *gt,
  
  		for_each_sgt_daddr(dma, iter, vma_res->bi.pages) {

mutex_lock(&ggtt->error_mutex);
-   ggtt->vm.insert_page(&ggtt->vm, dma, slot,
-I915_CACHE_NONE, 0);
+   if (ggtt->vm.raw_insert_page)
+   ggtt->vm.raw_insert_page(&ggtt

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: stop HPD workers before display driver unregister

[Andrzej Hajda]

On 27.06.2022 18:00, Patchwork wrote:

*Patch Details*
*Series:*	drm/i915/display: stop HPD workers before display driver 
unregister
*URL:*	https://patchwork.freedesktop.org/series/105557/ 


*State:*failure
*Details:* 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105557v1/index.html 




  CI Bug Log - changes from CI_DRM_11799_full -> Patchwork_105557v1_full


Summary

*FAILURE*

Serious unknown changes coming with Patchwork_105557v1_full absolutely 
need to be

verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_105557v1_full, please notify your bug team to 
allow them

to document this new failure mode, which will reduce false positives in CI.


Participating hosts (13 -> 13)

No changes in participating hosts


Possible new issues

Here are the unknown changes that may have been introduced in 
Patchwork_105557v1_full:



  IGT changes


Possible regressions

  *

{igt@kms_cursor_crc@cursor-rapid-movement@pipe-a-hdmi-a-3-32x10} (NEW):

  o {shard-dg1}: NOTRUN -> SKIP


+15 similar issues
  *

igt@kms_cursor_legacy@torture-move@all-pipes:

  o shard-glk: PASS


-> INCOMPLETE





These does not seem to be related, they do not touch driver remove path.

Regards
Andrzej





Suppressed

The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.

  *

{igt@kms_cursor_crc@cursor-offscreen@pipe-d-hdmi-a-1-32x10}:

  o {shard-dg1}: NOTRUN -> SKIP


+15 similar issues
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-b-edp-1-32x32:

  o {shard-rkl}: NOTRUN -> SKIP


+3 similar issues


New tests

New tests have been introduced between CI_DRM_11799_full and 
Patchwork_105557v1_full:



  New IGT tests (43)

  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-a-hdmi-a-3-128x128:

  o Statuses : 1 pass(s)
  o Exec time: [0.25] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-a-hdmi-a-3-128x42:

  o Statuses : 1 pass(s)
  o Exec time: [0.26] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-a-hdmi-a-3-256x256:

  o Statuses : 1 pass(s)
  o Exec time: [0.25] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-a-hdmi-a-3-256x85:

  o Statuses : 1 pass(s)
  o Exec time: [0.25] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-a-hdmi-a-3-32x10:

  o Statuses : 1 skip(s)
  o Exec time: [0.01] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-a-hdmi-a-3-32x32:

  o Statuses : 1 skip(s)
  o Exec time: [0.01] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-a-hdmi-a-3-512x170:

  o Statuses : 1 skip(s)
  o Exec time: [0.0] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-a-hdmi-a-3-512x512:

  o Statuses : 1 skip(s)
  o Exec time: [0.0] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-a-hdmi-a-3-64x21:

  o Statuses : 1 pass(s)
  o Exec time: [0.25] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-a-hdmi-a-3-64x64:

  o Statuses : 1 pass(s)
  o Exec time: [0.29] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-b-hdmi-a-3-128x128:

  o Statuses : 1 pass(s)
  o Exec time: [0.23] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-b-hdmi-a-3-128x42:

  o Statuses : 1 pass(s)
  o Exec time: [0.23] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-b-hdmi-a-3-256x256:

  o Statuses : 1 pass(s)
  o Exec time: [0.24] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-b-hdmi-a-3-256x85:

  o Statuses : 1 pass(s)
  o Exec time: [0.23] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-b-hdmi-a-3-32x10:

  o Statuses : 1 skip(s)
  o Exec time: [0.01] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-b-hdmi-a-3-32x32:

  o Statuses : 1 skip(s)
  o Exec time: [0.01] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-b-hdmi-a-3-512x170:

  o Statuses : 1 skip(s)
  o Exec time: [0.0] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-b-hdmi-a-3-512x512:

Re: [Intel-gfx] [PATCH 2/2] drm/i915/fbdev: suspend HPD before fbdev unregistration

[Andrzej Hajda]

Thanks for comments,


On 29.06.2022 07:38, Murthy, Arun R wrote:

  void intel_fbdev_unregister(struct drm_i915_private *dev_priv)  {
   struct intel_fbdev *ifbdev = dev_priv->fbdev; @@ -573,6 +594,8 @@
void intel_fbdev_unregister(struct drm_i915_private *dev_priv)
   if (!ifbdev)
   return;

+ intel_fbdev_hpd_set_suspend(dev_priv,
FBINFO_STATE_SUSPENDED);
+


Instead of intel_fbdev_hpd_set_suspend(), will intel_fbdev_set_suspend() make 
more sense?
If intel_fbdev_set_suspend() is called, then the below cancel_work_sync() may 
not be required.



It does more than I needed (calls drm_fb_helper_set_suspend), but it 
shouldn't hurt. I will try this approach.


Regards
Andrzej




   cancel_work_sync(&dev_priv->fbdev_suspend_work);
   if (!current_is_async())
   intel_fbdev_sync(ifbdev);


Thanks and Regards,
Arun R Murthy

[Intel-gfx] [PATCH v2 0/2] drm/i915/display: stop HPD workers before display driver unregister

[Andrzej Hajda]

Hi Jani, Ville, Arun,

This patchset is replacement of patch
"drm/i915/display: disable HPD workers before display driver unregister" [1].
Ive decided to split patch into two parts - fbdev and MST, there are different
issues.
Ive also dropped shutdown path, as it has slightly different requirements,
and more importantly I am not able to test properly.

v2 (thx Arun for review):
  - reword of commit message (Arun)
  - intel_fbdev_hpd_set_suspend replaced with intel_fbdev_set_suspend (Arun)

[1]: https://patchwork.freedesktop.org/series/103811/

Regards
Andrzej


Andrzej Hajda (2):
  drm/i915/hpd: postpone HPD cancel work after last user suspension
  drm/i915/fbdev: suspend HPD before fbdev unregistration

 drivers/gpu/drm/i915/display/intel_display.c | 3 +++
 drivers/gpu/drm/i915/display/intel_fbdev.c   | 3 ++-
 drivers/gpu/drm/i915/i915_irq.c  | 1 -
 3 files changed, 5 insertions(+), 2 deletions(-)

-- 
2.25.1

[Intel-gfx] [PATCH v2 2/2] drm/i915/fbdev: suspend HPD before fbdev unregistration

[Andrzej Hajda]

HPD event after fbdev unregistration can cause registration of deferred
fbdev which will not be unregistered later, causing use-after-free.
To avoid it HPD handling should be suspended before fbdev unregistration.

It should fix following GPF:
[272.634530] general protection fault, probably for non-canonical address 
0x6b6b6b6b6b6b6b6b:  [#1] PREEMPT SMP NOPTI
[272.634536] CPU: 0 PID: 6030 Comm: i915_selftest Tainted: G U
5.18.0-rc5-CI_DRM_11603-g12dccf4f5eef+ #1
[272.634541] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[272.634545] RIP: 0010:fb_do_apertures_overlap.part.14+0x26/0x60
...
[272.634582] Call Trace:
[272.634583]  
[272.634585]  do_remove_conflicting_framebuffers+0x59/0xa0
[272.634589]  remove_conflicting_framebuffers+0x2d/0xc0
[272.634592]  remove_conflicting_pci_framebuffers+0xc8/0x110
[272.634595]  drm_aperture_remove_conflicting_pci_framebuffers+0x52/0x70
[272.634604]  i915_driver_probe+0x63a/0xdd0 [i915]

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5329
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5510
Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/display/intel_fbdev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 221336178991f0..b682fd72d4bf25 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -573,7 +573,8 @@ void intel_fbdev_unregister(struct drm_i915_private 
*dev_priv)
if (!ifbdev)
return;
 
-   cancel_work_sync(&dev_priv->fbdev_suspend_work);
+   intel_fbdev_set_suspend(&dev_priv->drm, FBINFO_STATE_SUSPENDED, true);
+
if (!current_is_async())
intel_fbdev_sync(ifbdev);
 
-- 
2.25.1

[Intel-gfx] [PATCH v2 1/2] drm/i915/hpd: postpone HPD cancel work after last user suspension

[Andrzej Hajda]

i915->hotplug.dig_port_work can be queued from intel_hpd_irq_handler
called by IRQ handler or by intel_hpd_trigger_irq called from dp_mst.
Since dp_mst is suspended after irq handler uninstall, a cleaner approach
is to cancel hpd work after intel_dp_mst_suspend, otherwise we risk
use-after-free.

It should fix following WARNINGS:
[283.405824] cpu_latency_qos_update_request called for unknown object
[283.405866] WARNING: CPU: 2 PID: 240 at kernel/power/qos.c:296 
cpu_latency_qos_update_request+0x2d/0x100
[283.405912] CPU: 2 PID: 240 Comm: kworker/u64:9 Not tainted 
5.18.0-rc6-Patchwork_103738v3-g1672d1c43e43+ #1
[283.405915] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[283.405916] Workqueue: i915-dp i915_digport_work_func [i915]
[283.406020] RIP: 0010:cpu_latency_qos_update_request+0x2d/0x100
...
[283.406040] Call Trace:
[283.406041]  
[283.406044]  intel_dp_aux_xfer+0x60e/0x8e0 [i915]
[283.406131]  ? finish_swait+0x80/0x80
[283.406139]  intel_dp_aux_transfer+0xc5/0x2b0 [i915]
[283.406218]  drm_dp_dpcd_access+0x79/0x130 [drm_display_helper]
[283.406227]  drm_dp_dpcd_read+0xe2/0xf0 [drm_display_helper]
[283.406233]  intel_dp_hpd_pulse+0x134/0x570 [i915]
[283.406308]  ? __down_killable+0x70/0x140
[283.406313]  i915_digport_work_func+0xba/0x150 [i915]

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4586
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5558
Signed-off-by: Andrzej Hajda 
Reviewed-by: Arun R Murthy 
---
 drivers/gpu/drm/i915/display/intel_display.c | 3 +++
 drivers/gpu/drm/i915/i915_irq.c  | 1 -
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 903226e2a6260d..ec8e59b3adaea7 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -9007,6 +9007,9 @@ void intel_modeset_driver_remove_noirq(struct 
drm_i915_private *i915)
 */
intel_dp_mst_suspend(i915);
 
+   /* MST is the last user of HPD work */
+   intel_hpd_cancel_work(i915);
+
/* poll work can call into fbdev, hence clean that up afterwards */
intel_fbdev_fini(i915);
 
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 73cebc6aa65072..db14787aef95dd 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4597,7 +4597,6 @@ void intel_irq_uninstall(struct drm_i915_private 
*dev_priv)
 
free_irq(irq, dev_priv);
 
-   intel_hpd_cancel_work(dev_priv);
dev_priv->runtime_pm.irqs_enabled = false;
 }
 
-- 
2.25.1

Re: [Intel-gfx] [PATCH] drm/i915: Drain freed object after suspend display

[Andrzej Hajda]

On 29.06.2022 15:47, José Roberto de Souza wrote:

Display is turned off by i915_drm_suspend() during the suspend
procedure, removing the last reference of some gem objects that were
used by display.

The issue is that those objects are only actually freed when
mm.free_work executed and that can happen very late in the suspend
process causing issues.
So here draining all freed objects released by display fixing suspend
issues.


Describing the issues would be helpful, alternatively bug tracker 
reference if any.




Signed-off-by: José Roberto de Souza 

Anyway:
Reviewed-by: Andrzej Hajda 

Regards
Andrzej



---
  drivers/gpu/drm/i915/i915_driver.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index 6e5849c1086f6..aa2a5ea30c7bb 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1186,6 +1186,8 @@ static int i915_drm_suspend(struct drm_device *dev)
  
  	enable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
  
+	i915_gem_drain_freed_objects(dev_priv);

+
return 0;
  }
  

Re: [Intel-gfx] [PATCH] drm/i915: Remove __dma_fence_is_chain()

[Andrzej Hajda]

On 29.06.2022 01:35, Rob Clark wrote:

From: Rob Clark 

drive-by cleanup

Signed-off-by: Rob Clark 


Reviewed-by: Andrzej Hajda 

Regards
Andrzej


---
  drivers/gpu/drm/i915/gem/i915_gem_wait.c | 7 +--
  1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c 
b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
index 319936f91ac5..667841780514 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
@@ -73,11 +73,6 @@ static void fence_set_priority(struct dma_fence *fence,
rcu_read_unlock();
  }
  
-static inline bool __dma_fence_is_chain(const struct dma_fence *fence)

-{
-   return fence->ops == &dma_fence_chain_ops;
-}
-
  void i915_gem_fence_wait_priority(struct dma_fence *fence,
  const struct i915_sched_attr *attr)
  {
@@ -93,7 +88,7 @@ void i915_gem_fence_wait_priority(struct dma_fence *fence,
  
  		for (i = 0; i < array->num_fences; i++)

fence_set_priority(array->fences[i], attr);
-   } else if (__dma_fence_is_chain(fence)) {
+   } else if (dma_fence_is_chain(fence)) {
struct dma_fence *iter;
  
  		/* The chain is ordered; if we boost the last, we boost all */

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/selftests: fix subtraction overflow bug

[Andrzej Hajda]

On 27.06.2022 21:59, Patchwork wrote:

*Patch Details*
*Series:*   drm/i915/selftests: fix subtraction overflow bug
*URL:*	https://patchwork.freedesktop.org/series/105597/ 


*State:*failure
*Details:* 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105597v1/index.html 




  CI Bug Log - changes from CI_DRM_11803_full -> Patchwork_105597v1_full


Summary

*FAILURE*

Serious unknown changes coming with Patchwork_105597v1_full absolutely 
need to be

verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_105597v1_full, please notify your bug team to 
allow them

to document this new failure mode, which will reduce false positives in CI.


Participating hosts (13 -> 13)

No changes in participating hosts


Possible new issues

Here are the unknown changes that may have been introduced in 
Patchwork_105597v1_full:



  IGT changes


Possible regressions

  *

{igt@kms_cursor_crc@cursor-rapid-movement@pipe-a-hdmi-a-3-32x10} (NEW):

  o {shard-dg1}: NOTRUN -> SKIP


+15 similar issues
  *

igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-dp-1:

  o shard-kbl: NOTRUN -> FAIL





Nothing related.

Regards
Andrzej




Suppressed

The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.

  * igt@kms_cursor_crc@cursor-offscreen@pipe-c-hdmi-a-1-512x170:
  o {shard-dg1}: NOTRUN -> SKIP


+7 similar issues


New tests

New tests have been introduced between CI_DRM_11803_full and 
Patchwork_105597v1_full:



  New IGT tests (40)

  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-a-hdmi-a-3-128x128:

  o Statuses : 1 pass(s)
  o Exec time: [0.25] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-a-hdmi-a-3-128x42:

  o Statuses : 1 pass(s)
  o Exec time: [0.26] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-a-hdmi-a-3-256x256:

  o Statuses : 1 pass(s)
  o Exec time: [0.25] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-a-hdmi-a-3-256x85:

  o Statuses : 1 pass(s)
  o Exec time: [0.25] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-a-hdmi-a-3-32x10:

  o Statuses : 1 skip(s)
  o Exec time: [0.01] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-a-hdmi-a-3-32x32:

  o Statuses : 1 skip(s)
  o Exec time: [0.01] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-a-hdmi-a-3-512x170:

  o Statuses : 1 skip(s)
  o Exec time: [0.0] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-a-hdmi-a-3-512x512:

  o Statuses : 1 skip(s)
  o Exec time: [0.0] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-a-hdmi-a-3-64x21:

  o Statuses : 1 pass(s)
  o Exec time: [0.26] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-a-hdmi-a-3-64x64:

  o Statuses : 1 pass(s)
  o Exec time: [0.29] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-b-hdmi-a-3-128x128:

  o Statuses : 1 pass(s)
  o Exec time: [0.24] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-b-hdmi-a-3-128x42:

  o Statuses : 1 pass(s)
  o Exec time: [0.24] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-b-hdmi-a-3-256x256:

  o Statuses : 1 pass(s)
  o Exec time: [0.23] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-b-hdmi-a-3-256x85:

  o Statuses : 1 pass(s)
  o Exec time: [0.23] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-b-hdmi-a-3-32x10:

  o Statuses : 1 skip(s)
  o Exec time: [0.01] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-b-hdmi-a-3-32x32:

  o Statuses : 1 skip(s)
  o Exec time: [0.01] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-b-hdmi-a-3-512x170:

  o Statuses : 1 skip(s)
  o Exec time: [0.0] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-b-hdmi-a-3-512x512:

  o Statuses : 1 skip(s)
  o Exec time: [0.0] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-b-hdmi-a-3-64x21:

  o Statuses : 1 pass(s)
  o Exec time: [0.23] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-b-hdmi-a-3-64x64:

  o Statuses : 1 pass(s)
  o Exec time: [0.24] s
  *

igt@kms_cursor_crc@cursor-rapid-movement@pipe-c-hdmi-a-3-128x128:

  o Statuses : 1 pass(s)
  o Exec time: [0.24] s
  *

igt@kms_cursor_crc@c

Re: [Intel-gfx] [PATCH] drm: i915: fix a possible refcount leak in intel_dp_add_mst_connector()

[Andrzej Hajda]

On 24.06.2022 15:04, José Roberto de Souza wrote:

From: Hangyu Hua 

If drm_connector_init fails, intel_connector_free will be called to take
care of proper free. So it is necessary to drop the refcount of port
before intel_connector_free.

Fixes: 091a4f91942a ("drm/i915: Handle drm-layer errors in 
intel_dp_add_mst_connector")
Signed-off-by: Hangyu Hua 
Reviewed-by: José Roberto de Souza 



Reviewed-by: Andrzej Hajda 

Regards
Andrzej


---
  drivers/gpu/drm/i915/display/intel_dp_mst.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 061b277e5ce78..14d2a64193b2d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -839,6 +839,7 @@ static struct drm_connector 
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
ret = drm_connector_init(dev, connector, &intel_dp_mst_connector_funcs,
 DRM_MODE_CONNECTOR_DisplayPort);
if (ret) {
+   drm_dp_mst_put_port_malloc(port);
intel_connector_free(intel_connector);
return NULL;
}

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: stop HPD workers before display driver unregister (rev2)

[Andrzej Hajda]

On 01.07.2022 10:51, Patchwork wrote:

*Patch Details*
*Series:*	drm/i915/display: stop HPD workers before display driver 
unregister (rev2)
*URL:*	https://patchwork.freedesktop.org/series/105557/ 


*State:*failure
*Details:* 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105557v2/index.html 




  CI Bug Log - changes from CI_DRM_11834_full -> Patchwork_105557v2_full


Summary

*FAILURE*

Serious unknown changes coming with Patchwork_105557v2_full absolutely 
need to be

verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_105557v2_full, please notify your bug team to 
allow them

to document this new failure mode, which will reduce false positives in CI.


Participating hosts (13 -> 12)

Missing (1): pig-glk-j5005


Possible new issues

Here are the unknown changes that may have been introduced in 
Patchwork_105557v2_full:



  IGT changes


Possible regressions

  *

igt@kms_cursor_legacy@cursor-vs-flip@atomic-transitions-varying-size:

  o shard-skl: NOTRUN -> INCOMPLETE


  *

igt@kms_cursor_legacy@flip-vs-cursor@varying-size:

  o shard-iclb: PASS


-> FAIL


  *

igt@perf@non-zero-reason:

  o shard-kbl: PASS


-> INCOMPLETE





Again not related.

Regards
Andrzej




Suppressed

The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.

  * igt@gem_create@create-ext-cpu-access-sanity-check:
  o {shard-rkl}: NOTRUN -> SKIP




  Piglit changes


Possible regressions

  *

spec@arb_texture_multisample@texelfetch@16-vs-isampler2dmsarray:

  o pig-kbl-iris: NOTRUN -> CRASH


  *

spec@glsl-1.30@execution@texelfetch@fs-texelfetch-sampler2darray-swizzle:

  o pig-skl-6260u: NOTRUN -> INCOMPLETE




New tests

New tests have been introduced between CI_DRM_11834_full and 
Patchwork_105557v2_full:



  New IGT tests (13)

  *

igt@kms_async_flips@alternate-sync-async-flip@pipe-a-hdmi-a-3:

  o Statuses : 1 pass(s)
  o Exec time: [2.28] s
  *

igt@kms_async_flips@alternate-sync-async-flip@pipe-b-hdmi-a-3:

  o Statuses : 1 pass(s)
  o Exec time: [2.18] s
  *

igt@kms_async_flips@alternate-sync-async-flip@pipe-c-hdmi-a-3:

  o Statuses : 1 pass(s)
  o Exec time: [2.17] s
  *

igt@kms_async_flips@alternate-sync-async-flip@pipe-d-hdmi-a-3:

  o Statuses : 1 pass(s)
  o Exec time: [2.20] s
  *

igt@kms_cursor_edge_walk@top-bottom@pipe-b-hdmi-a-3-128x128:

  o Statuses : 1 pass(s)
  o Exec time: [3.21] s
  *

igt@kms_cursor_edge_walk@top-bottom@pipe-b-hdmi-a-3-256x256:

  o Statuses : 1 pass(s)
  o Exec time: [3.21] s
  *

igt@kms_cursor_edge_walk@top-bottom@pipe-b-hdmi-a-3-64x64:

  o Statuses : 1 pass(s)
  o Exec time: [3.19] s
  *

igt@kms_cursor_edge_walk@top-bottom@pipe-c-hdmi-a-3-128x128:

  o Statuses : 1 pass(s)
  o Exec time: [3.19] s
  *

igt@kms_cursor_edge_walk@top-bottom@pipe-c-hdmi-a-3-256x256:

  o Statuses : 1 pass(s)
  o Exec time: [3.20] s
  *

igt@kms_cursor_edge_walk@top-bottom@pipe-c-hdmi-a-3-64x64:

  o Statuses : 1 pass(s)
  o Exec time: [3.21] s
  *

igt@kms_cursor_edge_walk@top-bottom@pipe-d-hdmi-a-3-128x128:

  o Statuses : 1 pass(s)
  o Exec time: [3.21] s
  *

igt@kms_cursor_edge_walk@top-bottom@pipe-d-hdmi-a-3-256x256:

  o Statuses : 1 pass(s)
  o Exec time: [3.19] s
  *

igt@kms_cursor_edge_walk@top-bottom@pipe-d-hdmi-a-3-64x64:

  o Statuses : 1 pass(s)
  o Exec time: [3.20] s


Known issues

Here are the changes found in Patchwork_105557v2_full that come from 
known issues:



  IGT changes


I

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/gt: Serialize GRDOM access between multiple engine resets

[Andrzej Hajda]

On 04.07.2022 10:09, Mauro Carvalho Chehab wrote:

From: Chris Wilson 

Don't allow two engines to be reset in parallel, as they would both
try to select a reset bit (and send requests to common registers)
and wait on that register, at the same time. Serialize control of
the reset requests/acks using the uncore->lock, which will also ensure
that no other GT state changes at the same time as the actual reset.

Cc: sta...@vger.kernel.org # Up to 4.4
Reported-by: Mika Kuoppala 
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Reviewed-by: Andi Shyti 
Acked-by: Thomas Hellström 
Signed-off-by: Mauro Carvalho Chehab 


Reviewed-by: Andrzej Hajda 

Regards
Andrzej


---

To avoid mailbombing on a large number of people, only mailing lists were C/C 
on the cover.
See [PATCH v3 0/2] at: 
https://lore.kernel.org/all/cover.1656921701.git.mche...@kernel.org/

  drivers/gpu/drm/i915/gt/intel_reset.c | 37 ---
  1 file changed, 28 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c 
b/drivers/gpu/drm/i915/gt/intel_reset.c
index a5338c3fde7a..c68d36fb5bbd 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -300,9 +300,9 @@ static int gen6_hw_domain_reset(struct intel_gt *gt, u32 
hw_domain_mask)
return err;
  }
  
-static int gen6_reset_engines(struct intel_gt *gt,

- intel_engine_mask_t engine_mask,
- unsigned int retry)
+static int __gen6_reset_engines(struct intel_gt *gt,
+   intel_engine_mask_t engine_mask,
+   unsigned int retry)
  {
struct intel_engine_cs *engine;
u32 hw_mask;
@@ -321,6 +321,20 @@ static int gen6_reset_engines(struct intel_gt *gt,
return gen6_hw_domain_reset(gt, hw_mask);
  }
  
+static int gen6_reset_engines(struct intel_gt *gt,

+ intel_engine_mask_t engine_mask,
+ unsigned int retry)
+{
+   unsigned long flags;
+   int ret;
+
+   spin_lock_irqsave(>->uncore->lock, flags);
+   ret = __gen6_reset_engines(gt, engine_mask, retry);
+   spin_unlock_irqrestore(>->uncore->lock, flags);
+
+   return ret;
+}
+
  static struct intel_engine_cs *find_sfc_paired_vecs_engine(struct 
intel_engine_cs *engine)
  {
int vecs_id;
@@ -487,9 +501,9 @@ static void gen11_unlock_sfc(struct intel_engine_cs *engine)
rmw_clear_fw(uncore, sfc_lock.lock_reg, sfc_lock.lock_bit);
  }
  
-static int gen11_reset_engines(struct intel_gt *gt,

-  intel_engine_mask_t engine_mask,
-  unsigned int retry)
+static int __gen11_reset_engines(struct intel_gt *gt,
+intel_engine_mask_t engine_mask,
+unsigned int retry)
  {
struct intel_engine_cs *engine;
intel_engine_mask_t tmp;
@@ -583,8 +597,11 @@ static int gen8_reset_engines(struct intel_gt *gt,
struct intel_engine_cs *engine;
const bool reset_non_ready = retry >= 1;
intel_engine_mask_t tmp;
+   unsigned long flags;
int ret;
  
+	spin_lock_irqsave(>->uncore->lock, flags);

+
for_each_engine_masked(engine, gt, engine_mask, tmp) {
ret = gen8_engine_reset_prepare(engine);
if (ret && !reset_non_ready)
@@ -612,17 +629,19 @@ static int gen8_reset_engines(struct intel_gt *gt,
 * This is best effort, so ignore any error from the initial reset.
 */
if (IS_DG2(gt->i915) && engine_mask == ALL_ENGINES)
-   gen11_reset_engines(gt, gt->info.engine_mask, 0);
+   __gen11_reset_engines(gt, gt->info.engine_mask, 0);
  
  	if (GRAPHICS_VER(gt->i915) >= 11)

-   ret = gen11_reset_engines(gt, engine_mask, retry);
+   ret = __gen11_reset_engines(gt, engine_mask, retry);
else
-   ret = gen6_reset_engines(gt, engine_mask, retry);
+   ret = __gen6_reset_engines(gt, engine_mask, retry);
  
  skip_reset:

for_each_engine_masked(engine, gt, engine_mask, tmp)
gen8_engine_reset_cancel(engine);
  
+	spin_unlock_irqrestore(>->uncore->lock, flags);

+
return ret;
  }
  

Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/gt: Serialize TLB invalidates with GT resets

[Andrzej Hajda]

On 04.07.2022 10:09, Mauro Carvalho Chehab wrote:

From: Chris Wilson 

Avoid trying to invalidate the TLB in the middle of performing an
engine reset, as this may result in the reset timing out. Currently,
the TLB invalidate is only serialised by its own mutex, forgoing the
uncore lock, but we can take the uncore->lock as well to serialise
the mmio access, thereby serialising with the GDRST.

Tested on a NUC5i7RYB, BIOS RYBDWi35.86A.0380.2019.0517.1530 with
i915 selftest/hangcheck.

Cc: sta...@vger.kernel.org # Up to 4.4
Fixes: 7938d61591d3 ("drm/i915: Flush TLBs before releasing backing store")
Reported-by: Mauro Carvalho Chehab 
Tested-by: Mauro Carvalho Chehab 
Reviewed-by: Mauro Carvalho Chehab 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Thomas Hellström 
Cc: Andi Shyti 
Signed-off-by: Mauro Carvalho Chehab 


Reviewed-by: Andrzej Hajda 

Regards
Andrzej


---

To avoid mailbombing on a large number of people, only mailing lists were C/C 
on the cover.
See [PATCH v3 0/2] at: 
https://lore.kernel.org/all/cover.1656921701.git.mche...@kernel.org/

  drivers/gpu/drm/i915/gt/intel_gt.c | 15 ++-
  1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 8da3314bb6bf..68c2b0d8f187 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -952,6 +952,20 @@ void intel_gt_invalidate_tlbs(struct intel_gt *gt)
mutex_lock(>->tlb_invalidate_lock);
intel_uncore_forcewake_get(uncore, FORCEWAKE_ALL);
  
+	spin_lock_irq(&uncore->lock); /* serialise invalidate with GT reset */

+
+   for_each_engine(engine, gt, id) {
+   struct reg_and_bit rb;
+
+   rb = get_reg_and_bit(engine, regs == gen8_regs, regs, num);
+   if (!i915_mmio_reg_offset(rb.reg))
+   continue;
+
+   intel_uncore_write_fw(uncore, rb.reg, rb.bit);
+   }
+
+   spin_unlock_irq(&uncore->lock);
+
for_each_engine(engine, gt, id) {
/*
 * HW architecture suggest typical invalidation time at 40us,
@@ -966,7 +980,6 @@ void intel_gt_invalidate_tlbs(struct intel_gt *gt)
if (!i915_mmio_reg_offset(rb.reg))
continue;
  
-		intel_uncore_write_fw(uncore, rb.reg, rb.bit);

if (__intel_wait_for_register_fw(uncore,
 rb.reg, rb.bit, 0,
 timeout_us, timeout_ms,

Re: [Intel-gfx] [PATCH 1/2] i915/perf: Replace DRM_DEBUG with driver specific drm_dbg call

[Andrzej Hajda]

On 07.07.2022 21:30, Nerlige Ramappa, Umesh wrote:

DRM_DEBUG is not the right debug call to use in i915 OA, replace it with
driver specific drm_dbg() call (Matt).

Signed-off-by: Umesh Nerlige Ramappa  ---
  drivers/gpu/drm/i915/i915_perf.c | 151 ---
  1 file changed, 100 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 1577ab6754db..b3beb89884e0 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -885,8 +885,9 @@ static int gen8_oa_read(struct i915_perf_stream *stream,
if (ret)
return ret;
  
-		DRM_DEBUG("OA buffer overflow (exponent = %d): force restart\n",

- stream->period_exponent);
+   drm_dbg(&stream->perf->i915->drm,


Looking at number of uses of &stream->perf->i915->drm I wonder if some 
helper wouldn't simplify things, sth like to_drm(stream) ?


Anyway:
Reviewed-by: Andrzej Hajda 

Regards
Andrzej


+   "OA buffer overflow (exponent = %d): force restart\n",
+   stream->period_exponent);
  
  		stream->perf->ops.oa_disable(stream);

stream->perf->ops.oa_enable(stream);
@@ -1108,8 +1109,9 @@ static int gen7_oa_read(struct i915_perf_stream *stream,
if (ret)
return ret;
  
-		DRM_DEBUG("OA buffer overflow (exponent = %d): force restart\n",

- stream->period_exponent);
+   drm_dbg(&stream->perf->i915->drm,
+   "OA buffer overflow (exponent = %d): force restart\n",
+   stream->period_exponent);
  
  		stream->perf->ops.oa_disable(stream);

stream->perf->ops.oa_enable(stream);
@@ -2863,7 +2865,8 @@ static int i915_oa_stream_init(struct i915_perf_stream 
*stream,
int ret;
  
  	if (!props->engine) {

-   DRM_DEBUG("OA engine not specified\n");
+   drm_dbg(&stream->perf->i915->drm,
+   "OA engine not specified\n");
return -EINVAL;
}
  
@@ -2873,18 +2876,21 @@ static int i915_oa_stream_init(struct i915_perf_stream *stream,

 * IDs
 */
if (!perf->metrics_kobj) {
-   DRM_DEBUG("OA metrics weren't advertised via sysfs\n");
+   drm_dbg(&stream->perf->i915->drm,
+   "OA metrics weren't advertised via sysfs\n");
return -EINVAL;
}
  
  	if (!(props->sample_flags & SAMPLE_OA_REPORT) &&

(GRAPHICS_VER(perf->i915) < 12 || !stream->ctx)) {
-   DRM_DEBUG("Only OA report sampling supported\n");
+   drm_dbg(&stream->perf->i915->drm,
+   "Only OA report sampling supported\n");
return -EINVAL;
}
  
  	if (!perf->ops.enable_metric_set) {

-   DRM_DEBUG("OA unit not supported\n");
+   drm_dbg(&stream->perf->i915->drm,
+   "OA unit not supported\n");
return -ENODEV;
}
  
@@ -2894,12 +2900,14 @@ static int i915_oa_stream_init(struct i915_perf_stream *stream,

 * we currently only allow exclusive access
 */
if (perf->exclusive_stream) {
-   DRM_DEBUG("OA unit already in use\n");
+   drm_dbg(&stream->perf->i915->drm,
+   "OA unit already in use\n");
return -EBUSY;
}
  
  	if (!props->oa_format) {

-   DRM_DEBUG("OA report format not specified\n");
+   drm_dbg(&stream->perf->i915->drm,
+   "OA report format not specified\n");
return -EINVAL;
}
  
@@ -2929,20 +2937,23 @@ static int i915_oa_stream_init(struct i915_perf_stream *stream,

if (stream->ctx) {
ret = oa_get_render_ctx_id(stream);
if (ret) {
-   DRM_DEBUG("Invalid context id to filter with\n");
+   drm_dbg(&stream->perf->i915->drm,
+   "Invalid context id to filter with\n");
return ret;
}
}
  
  	ret = alloc_noa_wait(stream);

if (ret) {
-   DRM_DEBUG("Unable to allocate NOA wait batch buffer\n");
+   drm_dbg(&stream->perf->i915->drm,
+   "Unable to allocate NOA wait batch buffer\n");
goto err_noa_wait_alloc;
}
  
  	stream->oa_config = i915_per

Re: [Intel-gfx] [PATCH 2/2] i915/perf: Disable OA sseu config param for gfx12.50+

[Andrzej Hajda]

On 07.07.2022 21:30, Nerlige Ramappa, Umesh wrote:

The global sseu config is applicable only to gen11 platforms where
concurrent media, render and OA use cases may cause some subslices to be
turned off and hence lose NOA configuration. Ideally we want to return
ENODEV for non-gen11 platforms, however, this has shipped with gfx12, so
disable only for gfx12.50+.

v2: gfx12 is already shipped with this, disable for gfx12.50+ (Lionel)

v3: (Matt)
- Update commit message and replace "12.5" with "12.50"
- Replace DRM_DEBUG() with driver specific drm_dbg()

Signed-off-by: Umesh Nerlige Ramappa 


Reviewed-by: Andrzej Hajda 

Regards
Andrzej


---
  drivers/gpu/drm/i915/i915_perf.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index b3beb89884e0..f3c23fe9ad9c 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -3731,6 +3731,13 @@ static int read_properties_unlocked(struct i915_perf 
*perf,
case DRM_I915_PERF_PROP_GLOBAL_SSEU: {
struct drm_i915_gem_context_param_sseu user_sseu;
  
+			if (GRAPHICS_VER_FULL(perf->i915) >= IP_VER(12, 50)) {

+   drm_dbg(&perf->i915->drm,
+   "SSEU config not supported on gfx %x\n",
+   GRAPHICS_VER_FULL(perf->i915));
+   return -ENODEV;
+   }
+
if (copy_from_user(&user_sseu,
   u64_to_user_ptr(value),
   sizeof(user_sseu))) {

Re: [Intel-gfx] [PATCH] drm/i915/gvt: IS_ERR() vs NULL bug in intel_gvt_update_reg_whitelist()

[Andrzej Hajda]

On 08.07.2022 10:41, Dan Carpenter wrote:

The shmem_pin_map() function returns NULL, it doesn't return error
pointers.

Fixes: 97ea656521c8 ("drm/i915/gvt: Parse default state to update reg 
whitelist")
Signed-off-by: Dan Carpenter 


Reviewed-by: Andrzej Hajda 

Regards
Andrzej


---
  drivers/gpu/drm/i915/gvt/cmd_parser.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c 
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index b9eb75a2b400..1c35a41620ae 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -3117,9 +3117,9 @@ void intel_gvt_update_reg_whitelist(struct intel_vgpu 
*vgpu)
continue;
  
  		vaddr = shmem_pin_map(engine->default_state);

-   if (IS_ERR(vaddr)) {
-   gvt_err("failed to map %s->default state, err:%zd\n",
-   engine->name, PTR_ERR(vaddr));
+   if (!vaddr) {
+   gvt_err("failed to map %s->default state\n",
+   engine->name);
return;
}
  

Re: [Intel-gfx] [PATCH v5 4/7] drm/i915/gt: create per-tile sysfs interface

[Andrzej Hajda]

On 13.03.2022 20:45, Andi Shyti wrote:

Hi Andrzej,

I'm sorry, but I'm not fully understanding,


+struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev,
+   const char *name)
+{
+   struct kobject *kobj = &dev->kobj;
+
+   /*
+* We are interested at knowing from where the interface
+* has been called, whether it's called from gt/ or from
+* the parent directory.
+* From the interface position it depends also the value of
+* the private data.
+* If the interface is called from gt/ then private data is
+* of the "struct intel_gt *" type, otherwise it's * a
+* "struct drm_i915_private *" type.
+*/
+   if (!is_object_gt(kobj)) {
+   struct drm_i915_private *i915 = kdev_minor_to_i915(dev);
+
+   pr_devel_ratelimited(DEPRECATED
+   "%s (pid %d) is accessing deprecated %s "
+   "sysfs control, please use gt/gt/%s instead\n",
+   current->comm, task_pid_nr(current), name, name);
+   return to_gt(i915);
+   }
+
+   return kobj_to_gt(kobj);

It took some time for me to understand what is going on here.
We have dev argument which sometimes can point to "struct device", sometimes
to "struct kobj_gt", but it's type suggests differently, quite ugly.
I wonder if wouldn't be better to use __ATTR instead of DEVICE_ATTR* as in
case of intel_engines_add_sysfs. This way abstractions would look better,
hopefully.

How would it help?

The difference is that I'm adding twice different interfaces with
the same name and different location (i.e. different object). The
legacy intrefaces inherit the object from drm and I'm preserving
that reference.

While the new objects would derive from the previous and they are
pretty much like intel_engines_add_sysfs().

I was not clear on the issue. Here in case of 'id' attribute it is defined
as device_attribute, but in kobj_type.sysfs_ops you assign formally
incompatible &kobj_sysfs_ops.

'kobj_sysfs_ops' is of the type 'kobj_type'.


Yes, but for example kobj_sysfs_ops.show points to function 
kobj_attr_show, and kobj_attr_show expects that it's attr argument is 
embedded in kobj_attribute[1], but this is not true in case of 'id' 
attribute - it is embedded in device_attribute.
In short kobj_sysfs_ops should be used only with attrs embeded in 
kobj_attribute, unless I missed sth.


[1]: https://elixir.bootlin.com/linux/latest/source/lib/kobject.c#L836




kobj_sysfs_ops expects kobj_attribute! Fortunately kobj_attribute is 'binary
compatible' with device_attribute and kobj is at beginning of struct device
as well, so it does not blow up, but I wouldn't say it is clean solution :)
If you look at intel_engines_add_sysfs you can see that all attributes are
defined as kobj_attribute.

That's exactly the approach I use in the next patches for the
power management files, I use "struct kobj_gt" wrapped around
"struct kobject". But I'm using that only for the GT files.


But attributes are still defined using DEVICE_ATTR* macros, ie they are 
embedded in device_attribute, so the problem is the same - you are using 
kobj_sysfs_ops with device_attribute.




Are you, btw, suggesting to use this same approache also for the
legacy files that for now have a pointer to the drm kobject? This
way I would need to add more information, like the pointer to
i915 and gt_id. This way I wouldn't need the files above that
look hacky to you. Is this what you mean?


Positive feedback is more difficult :)
I am little bit lost in possible solutions, after grepping other drivers 
I have not good advice about proper handling of such situation, *beside 
splitting the interface*.
For sure attrs used in device/power must be embedded in 
device_attribute. So if you do not want to split interface, then it 
implies GTs attrs must be also in device_attribute. Then maybe creating 
custom sysfs_ops would help??? I am not sure.


Regards
Andrzej





Andi

Re: [Intel-gfx] [PATCH v6 3/7] drm/i915: Prepare for multiple GTs

[Andrzej Hajda]

On 18.03.2022 03:10, Andi Shyti wrote:

From: Tvrtko Ursulin 

On a multi-tile platform, each tile has its own registers + GGTT
space, and BAR 0 is extended to cover all of them.

Up to four GTs are supported in i915->gt[], with slot zero
shadowing the existing i915->gt0 to enable source compatibility
with legacy driver paths. A for_each_gt macro is added to iterate
over the GTs and will be used by upcoming patches that convert
various parts of the driver to be multi-gt aware.

Only the primary/root tile is initialized for now; the other
tiles will be detected and plugged in by future patches once the
necessary infrastructure is in place to handle them.

Signed-off-by: Abdiel Janulgue 
Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Matt Roper 
Signed-off-by: Andi Shyti 
Cc: Daniele Ceraolo Spurio 
Cc: Joonas Lahtinen 
Cc: Matthew Auld 
Reviewed-by: Matt Roper 
---


Reviewed-by: Andrzej Hajda 

Regards
Andrzej

Re: [Intel-gfx] [PATCH v6 7/7] drm/i915/gt: Adding new sysfs frequency attributes

[Andrzej Hajda]

On 18.03.2022 03:10, Andi Shyti wrote:

From: Sujaritha Sundaresan 

This patch adds the following new sysfs frequency attributes:

- punit_req_freq_mhz
- throttle_reason_status
- throttle_reason_pl1
- throttle_reason_pl2
- throttle_reason_pl4
- throttle_reason_thermal
- throttle_reason_prochot
- throttle_reason_ratl
- throttle_reason_vr_thermalert
- throttle_reason_vr_tdc

Signed-off-by: Sujaritha Sundaresan 
Cc: Dale B Stimson 
Signed-off-by: Andi Shyti 
---


Reviewed-by: Andrzej Hajda 

Regards
Andrzej

Re: [Intel-gfx] [PATCH v6 6/7] drm/i915/gt: Create per-tile RPS sysfs interfaces

[Andrzej Hajda]

On 18.03.2022 03:10, Andi Shyti wrote:

Now tiles have their own sysfs interfaces under the gt/
directory. Because RPS is a property that can be configured on a
tile basis, then each tile should have its own interface

The new sysfs structure will have a similar layout for the 4 tile
case:

/sys/.../card0
  ├── gt
  │   ├── gt0
  │   │   ├── id
  │   │   ├── rc6_enable
  │   │   ├── rc6_residency_ms
  │   │   ├── rps_act_freq_mhz
  │   │   ├── rps_boost_freq_mhz
  │   │   ├── rps_cur_freq_mhz
  │   │   ├── rps_max_freq_mhz
  │   │   ├── rps_min_freq_mhz
  │   │   ├── rps_RP0_freq_mhz
  │   │   ├── rps_RP1_freq_mhz
  │   │   └── rps_RPn_freq_mhz
  .   .
  .   .
  .   .
  │   └── gtN
  │   ├── id
  │   ├── rc6_enable
  │   ├── rc6_residency_ms
  │   ├── rps_act_freq_mhz
  │   ├── rps_boost_freq_mhz
  │   ├── rps_cur_freq_mhz
  │   ├── rps_max_freq_mhz
  │   ├── rps_min_freq_mhz
  │   ├── rps_RP0_freq_mhz
  │   ├── rps_RP1_freq_mhz
  │   └── rps_RPn_freq_mhz
  ├── gt_act_freq_mhz   -+
  ├── gt_boost_freq_mhz  |
  ├── gt_cur_freq_mhz|Original interface
  ├── gt_max_freq_mhz+─-> kept as existing ABI;
  ├── gt_min_freq_mhz|it points to gt0/
  ├── gt_RP0_freq_mhz|
  ├── gt_RP1_freq_mhz|
  └── gt_RPn_freq_mhz   -+

The existing interfaces have been kept in their original location
to preserve the existing ABI. They act on all the GTs: when
writing they loop through all the GTs and write the information
on each interface. When reading they provide the average value
from all the GTs.

This patch is not really adding exposing new interfaces (new
ABI) other than adapting the existing one to more tiles. In any
case this new set of interfaces will be a basic tool for system
managers and administrators when using i915.

Signed-off-by: Andi Shyti 
Signed-off-by: Lucas De Marchi 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Matt Roper 
Cc: Sujaritha Sundaresan 
Cc: Tvrtko Ursulin 
---


Reviewed-by: Andrzej Hajda 

Regards
Andrzej

Re: [Intel-gfx] [PATCH v6 4/7] drm/i915/gt: create per-tile sysfs interface

[Andrzej Hajda]

On 18.03.2022 03:10, Andi Shyti wrote:

Now that we have tiles we want each of them to have its own
interface. A directory "gt/" is created under "cardN/" that will
contain as many diroctories as the tiles.

In the coming patches tile related interfaces will be added. For
now the sysfs gt structure simply has an id interface related
to the current tile count.

The directory structure will follow this scheme:

 /sys/.../card0
  └── gt
      ├── gt0
      │   └── id
  :
 :
 └─- gtN
          └── id

This new set of interfaces will be a basic tool for system
managers and administrators when using i915.

Signed-off-by: Andi Shyti 
Cc: Matt Roper 
Cc: Sujaritha Sundaresan 
Cc: Tvrtko Ursulin 
Reviewed-by: Sujaritha Sundaresan 
---
  drivers/gpu/drm/i915/Makefile|   1 +
  drivers/gpu/drm/i915/gt/intel_gt.c   |   2 +
  drivers/gpu/drm/i915/gt/intel_gt_sysfs.c | 103 +++
  drivers/gpu/drm/i915/gt/intel_gt_sysfs.h |  34 
  drivers/gpu/drm/i915/i915_drv.h  |   2 +
  drivers/gpu/drm/i915/i915_sysfs.c|   7 +-
  drivers/gpu/drm/i915/i915_sysfs.h|   3 +
  scripts/extract-cert | Bin 0 -> 17952 bytes



With above removed.

Reviewed-by: Andrzej Hajda 

Regards
Andrzej

Re: [Intel-gfx] [PATCH 21/22] drm: Use drm_mode_init() for on-stack modes

[Andrzej Hajda]

On 18.02.2022 11:04, Ville Syrjala wrote:

From: Ville Syrjälä 

Initialize on-stack modes with drm_mode_init() to guarantee
no stack garbage in the list head, or that we aren't copying
over another mode's list head.

Based on the following cocci script, with manual fixups:
@decl@
identifier M;
expression E;
@@
- struct drm_display_mode M = E;
+ struct drm_display_mode M;

@@
identifier decl.M;
expression decl.E;
statement S, S1;
@@
struct drm_display_mode M;
... when != S
+ drm_mode_init(&M, &E);
+
S1

@@
expression decl.E;
@@
- &*E
+ E

Signed-off-by: Ville Syrjälä 
---



Reviewed-by: Andrzej Hajda 

Regards
Andrzej

Re: [Intel-gfx] [PATCH 22/22] drm: Use drm_mode_copy()

[Andrzej Hajda]

On 18.02.2022 11:04, Ville Syrjala wrote:

From: Ville Syrjälä 

struct drm_display_mode embeds a list head, so overwriting
the full struct with another one will corrupt the list
(if the destination mode is on a list). Use drm_mode_copy()
instead which explicitly preserves the list head of
the destination mode.

Even if we know the destination mode is not on any list
using drm_mode_copy() seems decent as it sets a good
example. Bad examples of not using it might eventually
get copied into code where preserving the list head
actually matters.

Obviously one case not covered here is when the mode
itself is embedded in a larger structure and the whole
structure is copied. But if we are careful when copying
into modes embedded in structures I think we can be a
little more reassured that bogus list heads haven't been
propagated in.

@is_mode_copy@
@@
drm_mode_copy(...)
{
...
}

@depends on !is_mode_copy@
struct drm_display_mode *mode;
expression E, S;
@@
(
- *mode = E
+ drm_mode_copy(mode, &E)
|
- memcpy(mode, E, S)
+ drm_mode_copy(mode, E)
)

@depends on !is_mode_copy@
struct drm_display_mode mode;
expression E;
@@
(
- mode = E
+ drm_mode_copy(&mode, &E)
|
- memcpy(&mode, E, S)
+ drm_mode_copy(&mode, E)
)

@@
struct drm_display_mode *mode;
@@
- &*mode
+ mode

Signed-off-by: Ville Syrjälä 
---


Reviewed-by: Andrzej Hajda 

Regards
Andrzej

[Intel-gfx] [PATCH] drm/i915/fbdev: unregister framebuffer after disabling hpd

[Andrzej Hajda]

Deferred framebuffer can be registered in hpd worker. So
drm_fb_helper_unregister_fbi should be called after hpd is stopped.
Otherwise we risk UAF after module removal.

The patch should fix following GPF:

[272.634530] general protection fault, probably for non-canonical address 
0x6b6b6b6b6b6b6b6b:  [#1] PREEMPT SMP NOPTI
[272.634536] CPU: 0 PID: 6030 Comm: i915_selftest Tainted: G U
5.18.0-rc5-CI_DRM_11603-g12dccf4f5eef+ #1
[272.634541] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[272.634545] RIP: 0010:fb_do_apertures_overlap.part.14+0x26/0x60
[272.634550] Code: a0 4f 4c 00 8b 0e 85 c9 74 4e 41 57 41 56 49 c7 c6 48 e2 34 
82 41 55 41 54 49 89 fc 55 48 89 f5 53 31 db 48 83 ec 10 48 63 c3 <41> 8b 14 24 
48 c1 e0 04 4c 8d 6c 05 08 85 d2 0f 85 53 9a 49 00 83
[272.634556] RSP: 0018:c900015ab988 EFLAGS: 00010286
[272.634559] RAX:  RBX:  RCX: 0002
[272.634562] RDX: 0001 RSI: 888139c14040 RDI: 6b6b6b6b6b6b6b6b
[272.634564] RBP: 888139c14040 R08: 88811a9eddf8 R09: fffe
[272.634567] R10: c900015aba18 R11: c283001c R12: 6b6b6b6b6b6b6b6b
[272.634569] R13: 82877400 R14: 8234e248 R15: 6b6b6b6b6b6b6b6b
[272.634572] FS:  7f2ea1b8c500() GS:8e80() 
knlGS:
[272.634575] CS:  0010 DS:  ES:  CR0: 80050033
[272.634578] CR2: 7ffc8db09f50 CR3: 0001406d4001 CR4: 00770ef0
[272.634580] PKRU: 5554
[272.634582] Call Trace:
[272.634583]  
[272.634585]  do_remove_conflicting_framebuffers+0x59/0xa0
[272.634589]  remove_conflicting_framebuffers+0x2d/0xc0
[272.634592]  remove_conflicting_pci_framebuffers+0xc8/0x110
[272.634595]  drm_aperture_remove_conflicting_pci_framebuffers+0x52/0x70
[272.634604]  i915_driver_probe+0x63a/0xdd0 [i915]

Signed-off-by: Andrzej Hajda 
---
Hi all,

This patch tries to solve frequent issue [1]. Currently observed only on 
bat-rpls-2
machine on public Intel CI.

[1]: https://gitlab.freedesktop.org/drm/intel/-/issues/5329

Regards
Andrzej
---
 drivers/gpu/drm/i915/display/intel_fbdev.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 557c7f15ac22a9..c04c37ba5688ce 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -581,8 +581,6 @@ void intel_fbdev_unregister(struct drm_i915_private 
*dev_priv)
cancel_work_sync(&dev_priv->fbdev_suspend_work);
if (!current_is_async())
intel_fbdev_sync(ifbdev);
-
-   drm_fb_helper_unregister_fbi(&ifbdev->helper);
 }
 
 void intel_fbdev_fini(struct drm_i915_private *dev_priv)
@@ -592,6 +590,8 @@ void intel_fbdev_fini(struct drm_i915_private *dev_priv)
if (!ifbdev)
return;
 
+   drm_fb_helper_unregister_fbi(&ifbdev->helper);
+
intel_fbdev_destroy(ifbdev);
 }
 
-- 
2.25.1

Re: [Intel-gfx] [PATCH 1/2] drm/i915/fbdev: print error in case drm_fb_helper_initial_config fails

[Andrzej Hajda]

Hi Jani,

On 05.05.2022 20:37, Jani Nikula wrote:

On Wed, 04 May 2022, Andrzej Hajda  wrote:

On some configurations drm_fb_helper_initial_config sometimes fails.
Logging error value should help debugging such issues.

Signed-off-by: Andrzej Hajda 
---
  drivers/gpu/drm/i915/display/intel_fbdev.c | 11 ---
  1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 221336178991f0..557c7f15ac22a9 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -539,11 +539,16 @@ int intel_fbdev_init(struct drm_device *dev)
  static void intel_fbdev_initial_config(void *data, async_cookie_t cookie)
  {
struct intel_fbdev *ifbdev = data;
+   int ret;
  
  	/* Due to peculiar init order wrt to hpd handling this is separate. */

-   if (drm_fb_helper_initial_config(&ifbdev->helper,
-ifbdev->preferred_bpp))
-   intel_fbdev_unregister(to_i915(ifbdev->helper.dev));
+   ret = drm_fb_helper_initial_config(&ifbdev->helper,
+  ifbdev->preferred_bpp);
+   if (!ret)
+   return;

If this patch is intended for merging, I'd prefer keeping the failure
path indented within if (ret).


+   drm_err(ifbdev->helper.dev, "failed to set initial configuration: 
%pe\n",
+   ERR_PTR(ret));

I'm leaning towards preferring "%s", errname(ret) over "%pe",
ERR_PTR(ret) because everyone knows what %s means and using ERR_PTR()
seems odd when it's really a plain int.

BR,
Jani.


Apparently this patch didn't help in catching the bug, so no big 
feelings about it.
Anyway I think I have found the issue I was looking for: hpd poll worker 
could be run during driver removal after console unregistration causing 
re-registration of console, which is not removed later leaving dangling 
pointers.

If you could take a look at the patch [1], it would be nice :)

[1]: https://patchwork.freedesktop.org/series/103621/#rev1

Regards
Andrzej




+   intel_fbdev_unregister(to_i915(ifbdev->helper.dev));
  }
  
  void intel_fbdev_initial_config_async(struct drm_device *dev)

Re: [Intel-gfx] [PATCH] fbdev: efifb: Fix a use-after-free due early fb_info cleanup

[Andrzej Hajda]

On 06.05.2022 15:22, Javier Martinez Canillas wrote:

Commit d258d00fb9c7 ("fbdev: efifb: Cleanup fb_info in .fb_destroy rather
than .remove") attempted to fix a use-after-free error due driver freeing
the fb_info in the .remove handler instead of doing it in .fb_destroy.

But ironically that change introduced yet another use-after-free since the
fb_info was still used after the free.

This should fix for good by freeing the fb_info at the end of the handler.

Fixes: d258d00fb9c7 ("fbdev: efifb: Cleanup fb_info in .fb_destroy rather than 
.remove")
Reported-by: Ville Syrjälä 
Reported-by: Andrzej Hajda 
Signed-off-by: Javier Martinez Canillas 
---


Reviewed-by: Andrzej Hajda 

Regards
Andrzej


  drivers/video/fbdev/efifb.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index cfa3dc0b4eee..b3d5f884c544 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -259,12 +259,12 @@ static void efifb_destroy(struct fb_info *info)
memunmap(info->screen_base);
}
  
-	framebuffer_release(info);

-
if (request_mem_succeeded)
release_mem_region(info->apertures->ranges[0].base,
   info->apertures->ranges[0].size);
fb_dealloc_cmap(&info->cmap);
+
+   framebuffer_release(info);
  }
  
  static const struct fb_ops efifb_ops = {

[Intel-gfx] [PATCH] drm/i915/fbdev: disable HPD before framebuffer unregistration

[Andrzej Hajda]

In case framebuffer setup is deferred it will happen in HPD worker.
Then on driver removal we should assure it will not happen after
drm_fb_helper_unregister_fbi, otherwise we risk UAF.
The patch should fix following GPF:

[272.634530] general protection fault, probably for non-canonical address 
0x6b6b6b6b6b6b6b6b:  [#1] PREEMPT SMP NOPTI
[272.634536] CPU: 0 PID: 6030 Comm: i915_selftest Tainted: G U
5.18.0-rc5-CI_DRM_11603-g12dccf4f5eef+ #1
[272.634541] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[272.634545] RIP: 0010:fb_do_apertures_overlap.part.14+0x26/0x60
[272.634550] Code: a0 4f 4c 00 8b 0e 85 c9 74 4e 41 57 41 56 49 c7 c6 48 e2 34 
82 41 55 41 54 49 89 fc 55 48 89 f5 53 31 db 48 83 ec 10 48 63 c3 <41> 8b 14 24 
48 c1 e0 04 4c 8d 6c 05 08 85 d2 0f 85 53 9a 49 00 83
[272.634556] RSP: 0018:c900015ab988 EFLAGS: 00010286
[272.634559] RAX:  RBX:  RCX: 0002
[272.634562] RDX: 0001 RSI: 888139c14040 RDI: 6b6b6b6b6b6b6b6b
[272.634564] RBP: 888139c14040 R08: 88811a9eddf8 R09: fffe
[272.634567] R10: c900015aba18 R11: c283001c R12: 6b6b6b6b6b6b6b6b
[272.634569] R13: 82877400 R14: 8234e248 R15: 6b6b6b6b6b6b6b6b
[272.634572] FS:  7f2ea1b8c500() GS:8e80() 
knlGS:
[272.634575] CS:  0010 DS:  ES:  CR0: 80050033
[272.634578] CR2: 7ffc8db09f50 CR3: 0001406d4001 CR4: 00770ef0
[272.634580] PKRU: 5554
[272.634582] Call Trace:
[272.634583]  
[272.634585]  do_remove_conflicting_framebuffers+0x59/0xa0
[272.634589]  remove_conflicting_framebuffers+0x2d/0xc0
[272.634592]  remove_conflicting_pci_framebuffers+0xc8/0x110
[272.634595]  drm_aperture_remove_conflicting_pci_framebuffers+0x52/0x70
[272.634604]  i915_driver_probe+0x63a/0xdd0 [i915]

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/display/intel_fbdev.c | 43 +++---
 1 file changed, 22 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 557c7f15ac22a9..0b0e96d3892b90 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -571,6 +571,27 @@ static void intel_fbdev_sync(struct intel_fbdev *ifbdev)
ifbdev->cookie = 0;
 }
 
+/* Suspends/resumes fbdev processing of incoming HPD events. When resuming HPD
+ * processing, fbdev will perform a full connector reprobe if a hotplug event
+ * was received while HPD was suspended.
+ */
+static void intel_fbdev_hpd_set_suspend(struct drm_i915_private *i915, int 
state)
+{
+   struct intel_fbdev *ifbdev = i915->fbdev;
+   bool send_hpd = false;
+
+   mutex_lock(&ifbdev->hpd_lock);
+   ifbdev->hpd_suspended = state == FBINFO_STATE_SUSPENDED;
+   send_hpd = !ifbdev->hpd_suspended && ifbdev->hpd_waiting;
+   ifbdev->hpd_waiting = false;
+   mutex_unlock(&ifbdev->hpd_lock);
+
+   if (send_hpd) {
+   drm_dbg_kms(&i915->drm, "Handling delayed fbcon HPD event\n");
+   drm_fb_helper_hotplug_event(&ifbdev->helper);
+   }
+}
+
 void intel_fbdev_unregister(struct drm_i915_private *dev_priv)
 {
struct intel_fbdev *ifbdev = dev_priv->fbdev;
@@ -582,6 +603,7 @@ void intel_fbdev_unregister(struct drm_i915_private 
*dev_priv)
if (!current_is_async())
intel_fbdev_sync(ifbdev);
 
+   intel_fbdev_hpd_set_suspend(dev_priv, FBINFO_STATE_SUSPENDED);
drm_fb_helper_unregister_fbi(&ifbdev->helper);
 }
 
@@ -595,27 +617,6 @@ void intel_fbdev_fini(struct drm_i915_private *dev_priv)
intel_fbdev_destroy(ifbdev);
 }
 
-/* Suspends/resumes fbdev processing of incoming HPD events. When resuming HPD
- * processing, fbdev will perform a full connector reprobe if a hotplug event
- * was received while HPD was suspended.
- */
-static void intel_fbdev_hpd_set_suspend(struct drm_i915_private *i915, int 
state)
-{
-   struct intel_fbdev *ifbdev = i915->fbdev;
-   bool send_hpd = false;
-
-   mutex_lock(&ifbdev->hpd_lock);
-   ifbdev->hpd_suspended = state == FBINFO_STATE_SUSPENDED;
-   send_hpd = !ifbdev->hpd_suspended && ifbdev->hpd_waiting;
-   ifbdev->hpd_waiting = false;
-   mutex_unlock(&ifbdev->hpd_lock);
-
-   if (send_hpd) {
-   drm_dbg_kms(&i915->drm, "Handling delayed fbcon HPD event\n");
-   drm_fb_helper_hotplug_event(&ifbdev->helper);
-   }
-}
-
 void intel_fbdev_set_suspend(struct drm_device *dev, int state, bool 
synchronous)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
-- 
2.25.1

Re: [Intel-gfx] [PATCH 6/8] drm/i915/gt: Fix memory leaks in per-gt sysfs

[Andrzej Hajda]

Hi Tvrtko,

On 10.05.2022 09:28, Tvrtko Ursulin wrote:


On 29/04/2022 20:56, Ashutosh Dixit wrote:
All kmalloc'd kobjects need a kobject_put() to free memory. For 
example in

previous code, kobj_gt_release() never gets called. The requirement of
kobject_put() now results in a slightly different code organization.

v2: s/gtn/gt/ (Andi)

Cc: Andi Shyti 
Cc: Andrzej Hajda 
Fixes: b770bcfae9ad ("drm/i915/gt: create per-tile sysfs interface")
Signed-off-by: Ashutosh Dixit 
---
  drivers/gpu/drm/i915/gt/intel_gt.c   |  1 +
  drivers/gpu/drm/i915/gt/intel_gt_sysfs.c | 29 ++--
  drivers/gpu/drm/i915/gt/intel_gt_sysfs.h |  6 +
  drivers/gpu/drm/i915/gt/intel_gt_types.h |  3 +++
  drivers/gpu/drm/i915/i915_sysfs.c    |  2 ++
  5 files changed, 19 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c

index 92394f13b42f..9aede288eb86 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -785,6 +785,7 @@ void intel_gt_driver_unregister(struct intel_gt *gt)
  {
  intel_wakeref_t wakeref;
  +    intel_gt_sysfs_unregister(gt);
  intel_rps_driver_unregister(>->rps);
  intel_gsc_fini(>->gsc);
  diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c 
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c

index 8ec8bc660c8c..9e4ebf53379b 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
@@ -24,7 +24,7 @@ bool is_object_gt(struct kobject *kobj)
    static struct intel_gt *kobj_to_gt(struct kobject *kobj)
  {
-    return container_of(kobj, struct kobj_gt, base)->gt;
+    return container_of(kobj, struct intel_gt, sysfs_gt);
  }
    struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev,
@@ -72,9 +72,9 @@ static struct attribute *id_attrs[] = {
  };
  ATTRIBUTE_GROUPS(id);
  +/* A kobject needs a release() method even if it does nothing */
  static void kobj_gt_release(struct kobject *kobj)
  {
-    kfree(kobj);
  }
    static struct kobj_type kobj_gt_type = {
@@ -85,8 +85,6 @@ static struct kobj_type kobj_gt_type = {
    void intel_gt_sysfs_register(struct intel_gt *gt)
  {
-    struct kobj_gt *kg;
-
  /*
   * We need to make things right with the
   * ABI compatibility. The files were originally
@@ -98,25 +96,22 @@ void intel_gt_sysfs_register(struct intel_gt *gt)
  if (gt_is_root(gt))
  intel_gt_sysfs_pm_init(gt, gt_get_parent_obj(gt));
  -    kg = kzalloc(sizeof(*kg), GFP_KERNEL);
-    if (!kg)
+    /* init and xfer ownership to sysfs tree */
+    if (kobject_init_and_add(>->sysfs_gt, &kobj_gt_type,
+ gt->i915->sysfs_gt, "gt%d", gt->info.id))


Was there closure/agreement on the matter of whether or not there is a 
potential race between "kfree(gt)" and sysfs access (last put from 
sysfs that is)? I've noticed Andrzej and Ashutosh were discussing it 
but did not read all the details.




Not really :)
IMO docs are against this practice, Ashutosh shows examples of this 
practice in code and according to his analysis it is safe.
I gave up looking for contradictions :) Either it is OK, kobject is not 
fully shared object, docs are obsolete and needs update, either the 
patch is wrong.
Anyway finally I tend to accept this solution, I failed to prove it is 
wrong :)

Acked-by: Andrzej Hajda 

Regards
Andrzej

Regards
Andrzej

Re: [Intel-gfx] [PATCH 6/8] drm/i915/gt: Fix memory leaks in per-gt sysfs

[Andrzej Hajda]

On 10.05.2022 10:18, Tvrtko Ursulin wrote:


On 10/05/2022 08:58, Andrzej Hajda wrote:

Hi Tvrtko,

On 10.05.2022 09:28, Tvrtko Ursulin wrote:


On 29/04/2022 20:56, Ashutosh Dixit wrote:
All kmalloc'd kobjects need a kobject_put() to free memory. For 
example in

previous code, kobj_gt_release() never gets called. The requirement of
kobject_put() now results in a slightly different code organization.

v2: s/gtn/gt/ (Andi)

Cc: Andi Shyti 
Cc: Andrzej Hajda 
Fixes: b770bcfae9ad ("drm/i915/gt: create per-tile sysfs interface")
Signed-off-by: Ashutosh Dixit 
---
  drivers/gpu/drm/i915/gt/intel_gt.c   |  1 +
  drivers/gpu/drm/i915/gt/intel_gt_sysfs.c | 29 
++--

  drivers/gpu/drm/i915/gt/intel_gt_sysfs.h |  6 +
  drivers/gpu/drm/i915/gt/intel_gt_types.h |  3 +++
  drivers/gpu/drm/i915/i915_sysfs.c    |  2 ++
  5 files changed, 19 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c

index 92394f13b42f..9aede288eb86 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -785,6 +785,7 @@ void intel_gt_driver_unregister(struct intel_gt 
*gt)

  {
  intel_wakeref_t wakeref;
  +    intel_gt_sysfs_unregister(gt);
  intel_rps_driver_unregister(>->rps);
  intel_gsc_fini(>->gsc);
  diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c 
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c

index 8ec8bc660c8c..9e4ebf53379b 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
@@ -24,7 +24,7 @@ bool is_object_gt(struct kobject *kobj)
    static struct intel_gt *kobj_to_gt(struct kobject *kobj)
  {
-    return container_of(kobj, struct kobj_gt, base)->gt;
+    return container_of(kobj, struct intel_gt, sysfs_gt);
  }
    struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev,
@@ -72,9 +72,9 @@ static struct attribute *id_attrs[] = {
  };
  ATTRIBUTE_GROUPS(id);
  +/* A kobject needs a release() method even if it does nothing */
  static void kobj_gt_release(struct kobject *kobj)
  {
-    kfree(kobj);
  }
    static struct kobj_type kobj_gt_type = {
@@ -85,8 +85,6 @@ static struct kobj_type kobj_gt_type = {
    void intel_gt_sysfs_register(struct intel_gt *gt)
  {
-    struct kobj_gt *kg;
-
  /*
   * We need to make things right with the
   * ABI compatibility. The files were originally
@@ -98,25 +96,22 @@ void intel_gt_sysfs_register(struct intel_gt *gt)
  if (gt_is_root(gt))
  intel_gt_sysfs_pm_init(gt, gt_get_parent_obj(gt));
  -    kg = kzalloc(sizeof(*kg), GFP_KERNEL);
-    if (!kg)
+    /* init and xfer ownership to sysfs tree */
+    if (kobject_init_and_add(>->sysfs_gt, &kobj_gt_type,
+ gt->i915->sysfs_gt, "gt%d", gt->info.id))


Was there closure/agreement on the matter of whether or not there is 
a potential race between "kfree(gt)" and sysfs access (last put from 
sysfs that is)? I've noticed Andrzej and Ashutosh were discussing it 
but did not read all the details.




Not really :)
IMO docs are against this practice, Ashutosh shows examples of this 
practice in code and according to his analysis it is safe.
I gave up looking for contradictions :) Either it is OK, kobject is 
not fully shared object, docs are obsolete and needs update, either 
the patch is wrong.
Anyway finally I tend to accept this solution, I failed to prove it 
is wrong :)


Like a question of whether hotunplug can be triggered while userspace 
is sitting in a sysfs hook? Final kfree then has to be delayed until 
userspace exists.


Btw where is the "kfree(gt)" for the tiles on the PCI remove path? I 
can't find it.. Do we have a leak?


intel_gt_tile_cleanup ?



Regards,

Tvrtko

Re: [Intel-gfx] [PATCH 6/8] drm/i915/gt: Fix memory leaks in per-gt sysfs

[Andrzej Hajda]

On 10.05.2022 11:48, Tvrtko Ursulin wrote:


On 10/05/2022 10:39, Andrzej Hajda wrote:

On 10.05.2022 10:18, Tvrtko Ursulin wrote:


On 10/05/2022 08:58, Andrzej Hajda wrote:

Hi Tvrtko,

On 10.05.2022 09:28, Tvrtko Ursulin wrote:


On 29/04/2022 20:56, Ashutosh Dixit wrote:
All kmalloc'd kobjects need a kobject_put() to free memory. For 
example in
previous code, kobj_gt_release() never gets called. The 
requirement of

kobject_put() now results in a slightly different code organization.

v2: s/gtn/gt/ (Andi)

Cc: Andi Shyti 
Cc: Andrzej Hajda 
Fixes: b770bcfae9ad ("drm/i915/gt: create per-tile sysfs interface")
Signed-off-by: Ashutosh Dixit 
---
  drivers/gpu/drm/i915/gt/intel_gt.c   |  1 +
  drivers/gpu/drm/i915/gt/intel_gt_sysfs.c | 29 
++--

  drivers/gpu/drm/i915/gt/intel_gt_sysfs.h |  6 +
  drivers/gpu/drm/i915/gt/intel_gt_types.h |  3 +++
  drivers/gpu/drm/i915/i915_sysfs.c    |  2 ++
  5 files changed, 19 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c

index 92394f13b42f..9aede288eb86 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -785,6 +785,7 @@ void intel_gt_driver_unregister(struct 
intel_gt *gt)

  {
  intel_wakeref_t wakeref;
  +    intel_gt_sysfs_unregister(gt);
  intel_rps_driver_unregister(>->rps);
  intel_gsc_fini(>->gsc);
  diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c 
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c

index 8ec8bc660c8c..9e4ebf53379b 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
@@ -24,7 +24,7 @@ bool is_object_gt(struct kobject *kobj)
    static struct intel_gt *kobj_to_gt(struct kobject *kobj)
  {
-    return container_of(kobj, struct kobj_gt, base)->gt;
+    return container_of(kobj, struct intel_gt, sysfs_gt);
  }
    struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev,
@@ -72,9 +72,9 @@ static struct attribute *id_attrs[] = {
  };
  ATTRIBUTE_GROUPS(id);
  +/* A kobject needs a release() method even if it does nothing */
  static void kobj_gt_release(struct kobject *kobj)
  {
-    kfree(kobj);
  }
    static struct kobj_type kobj_gt_type = {
@@ -85,8 +85,6 @@ static struct kobj_type kobj_gt_type = {
    void intel_gt_sysfs_register(struct intel_gt *gt)
  {
-    struct kobj_gt *kg;
-
  /*
   * We need to make things right with the
   * ABI compatibility. The files were originally
@@ -98,25 +96,22 @@ void intel_gt_sysfs_register(struct intel_gt 
*gt)

  if (gt_is_root(gt))
  intel_gt_sysfs_pm_init(gt, gt_get_parent_obj(gt));
  -    kg = kzalloc(sizeof(*kg), GFP_KERNEL);
-    if (!kg)
+    /* init and xfer ownership to sysfs tree */
+    if (kobject_init_and_add(>->sysfs_gt, &kobj_gt_type,
+ gt->i915->sysfs_gt, "gt%d", gt->info.id))


Was there closure/agreement on the matter of whether or not there 
is a potential race between "kfree(gt)" and sysfs access (last put 
from sysfs that is)? I've noticed Andrzej and Ashutosh were 
discussing it but did not read all the details.




Not really :)
IMO docs are against this practice, Ashutosh shows examples of this 
practice in code and according to his analysis it is safe.
I gave up looking for contradictions :) Either it is OK, kobject is 
not fully shared object, docs are obsolete and needs update, either 
the patch is wrong.
Anyway finally I tend to accept this solution, I failed to prove it 
is wrong :)


Like a question of whether hotunplug can be triggered while 
userspace is sitting in a sysfs hook? Final kfree then has to be 
delayed until userspace exists.


Btw where is the "kfree(gt)" for the tiles on the PCI remove path? I 
can't find it.. Do we have a leak?


intel_gt_tile_cleanup ?


Called from intel_gt_release_all, whose only caller is the failure 
path of i915_driver_probe. Feels like something is missing?


This is final proof this patch is safe - no kfree, no UAF :)

Apparently it is broken in internal branch as well.
Should I take care of it?

Regards
Andrzej




Regards,

Tvrtko

[Intel-gfx] [PATCH] drm/i915/display: disable HPD workers before display driver unregister

[Andrzej Hajda]

Handling HPD during driver removal is pointless, and can cause different
use-after-free/concurrency issues:
1. Setup of deffered fbdev after fbdev unregistration.
2. Access to DP-AUX after DP-AUX removal.

Below stacktraces of both cases observed on CI:

[272.634530] general protection fault, probably for non-canonical address 
0x6b6b6b6b6b6b6b6b:  [#1] PREEMPT SMP NOPTI
[272.634536] CPU: 0 PID: 6030 Comm: i915_selftest Tainted: G U
5.18.0-rc5-CI_DRM_11603-g12dccf4f5eef+ #1
[272.634541] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[272.634545] RIP: 0010:fb_do_apertures_overlap.part.14+0x26/0x60
...
[272.634582] Call Trace:
[272.634583]  
[272.634585]  do_remove_conflicting_framebuffers+0x59/0xa0
[272.634589]  remove_conflicting_framebuffers+0x2d/0xc0
[272.634592]  remove_conflicting_pci_framebuffers+0xc8/0x110
[272.634595]  drm_aperture_remove_conflicting_pci_framebuffers+0x52/0x70
[272.634604]  i915_driver_probe+0x63a/0xdd0 [i915]

[283.405824] cpu_latency_qos_update_request called for unknown object
[283.405866] WARNING: CPU: 2 PID: 240 at kernel/power/qos.c:296 
cpu_latency_qos_update_request+0x2d/0x100
[283.405912] CPU: 2 PID: 240 Comm: kworker/u64:9 Not tainted 
5.18.0-rc6-Patchwork_103738v3-g1672d1c43e43+ #1
[283.405915] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[283.405916] Workqueue: i915-dp i915_digport_work_func [i915]
[283.406020] RIP: 0010:cpu_latency_qos_update_request+0x2d/0x100
...
[283.406040] Call Trace:
[283.406041]  
[283.406044]  intel_dp_aux_xfer+0x60e/0x8e0 [i915]
[283.406131]  ? finish_swait+0x80/0x80
[283.406139]  intel_dp_aux_transfer+0xc5/0x2b0 [i915]
[283.406218]  drm_dp_dpcd_access+0x79/0x130 [drm_display_helper]
[283.406227]  drm_dp_dpcd_read+0xe2/0xf0 [drm_display_helper]
[283.406233]  intel_dp_hpd_pulse+0x134/0x570 [i915]
[283.406308]  ? __down_killable+0x70/0x140
[283.406313]  i915_digport_work_func+0xba/0x150 [i915]

Signed-off-by: Andrzej Hajda 
---
Hi all,

This is my 3rd attempt to solve some old CI bug[1].
The first one caused issues in kms code [2],
2nd one revealed that not only fbdev does not like HPD on removal [3].
I hope this one will solve things definitely.

Moreover this is quite rare bug, but due to specific configuration
of one of CI machines it appears there very frequently.

[1]: https://gitlab.freedesktop.org/drm/intel/-/issues/5329
[2]: https://patchwork.freedesktop.org/series/103621/
[3]: https://patchwork.freedesktop.org/series/103738/

Regards
Andrzej
---
 drivers/gpu/drm/i915/display/intel_display.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 806d50b302ab92..d21bbcce80b016 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10584,6 +10584,7 @@ void intel_display_driver_unregister(struct 
drm_i915_private *i915)
if (!HAS_DISPLAY(i915))
return;
 
+   intel_hpd_cancel_work(i915);
intel_fbdev_unregister(i915);
intel_audio_deinit(i915);
 
-- 
2.25.1

[Intel-gfx] [PATCH v2] drm/i915/display: disable HPD workers before display driver unregister

[Andrzej Hajda]

Handling HPD during driver removal is pointless, and can cause different
use-after-free/concurrency issues:
1. Setup of deffered fbdev after fbdev unregistration.
2. Access to DP-AUX after DP-AUX removal.

Below stacktraces of both cases observed on CI:

[272.634530] general protection fault, probably for non-canonical address 
0x6b6b6b6b6b6b6b6b:  [#1] PREEMPT SMP NOPTI
[272.634536] CPU: 0 PID: 6030 Comm: i915_selftest Tainted: G U
5.18.0-rc5-CI_DRM_11603-g12dccf4f5eef+ #1
[272.634541] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[272.634545] RIP: 0010:fb_do_apertures_overlap.part.14+0x26/0x60
...
[272.634582] Call Trace:
[272.634583]  
[272.634585]  do_remove_conflicting_framebuffers+0x59/0xa0
[272.634589]  remove_conflicting_framebuffers+0x2d/0xc0
[272.634592]  remove_conflicting_pci_framebuffers+0xc8/0x110
[272.634595]  drm_aperture_remove_conflicting_pci_framebuffers+0x52/0x70
[272.634604]  i915_driver_probe+0x63a/0xdd0 [i915]

[283.405824] cpu_latency_qos_update_request called for unknown object
[283.405866] WARNING: CPU: 2 PID: 240 at kernel/power/qos.c:296 
cpu_latency_qos_update_request+0x2d/0x100
[283.405912] CPU: 2 PID: 240 Comm: kworker/u64:9 Not tainted 
5.18.0-rc6-Patchwork_103738v3-g1672d1c43e43+ #1
[283.405915] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[283.405916] Workqueue: i915-dp i915_digport_work_func [i915]
[283.406020] RIP: 0010:cpu_latency_qos_update_request+0x2d/0x100
...
[283.406040] Call Trace:
[283.406041]  
[283.406044]  intel_dp_aux_xfer+0x60e/0x8e0 [i915]
[283.406131]  ? finish_swait+0x80/0x80
[283.406139]  intel_dp_aux_transfer+0xc5/0x2b0 [i915]
[283.406218]  drm_dp_dpcd_access+0x79/0x130 [drm_display_helper]
[283.406227]  drm_dp_dpcd_read+0xe2/0xf0 [drm_display_helper]
[283.406233]  intel_dp_hpd_pulse+0x134/0x570 [i915]
[283.406308]  ? __down_killable+0x70/0x140
[283.406313]  i915_digport_work_func+0xba/0x150 [i915]

Signed-off-by: Andrzej Hajda 
---
Hi all,

This is my Nth attempt to solve some old CI bug[1].
v1: caused issues in kms code [2],
v2: revealed that not only fbdev does not like HPD on removal [3],
v3: lacks drm_kms_helper_poll_disable[4]

Moreover this is quite rare bug, but due to specific configuration
of one of CI machines it appears there very frequently.

[1]: https://gitlab.freedesktop.org/drm/intel/-/issues/5329
[2]: https://patchwork.freedesktop.org/series/103621/
[3]: https://patchwork.freedesktop.org/series/103738/
[4]: https://patchwork.freedesktop.org/series/103811/

Regards
Andrzej
---
 drivers/gpu/drm/i915/display/intel_display.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 806d50b302ab92..9c9232da61ff37 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10584,6 +10584,8 @@ void intel_display_driver_unregister(struct 
drm_i915_private *i915)
if (!HAS_DISPLAY(i915))
return;
 
+   intel_hpd_cancel_work(i915);
+   drm_kms_helper_poll_disable(&i915->drm);
intel_fbdev_unregister(i915);
intel_audio_deinit(i915);
 
-- 
2.25.1

[Intel-gfx] [PATCH v3] drm/i915/display: disable HPD workers before display driver unregister

[Andrzej Hajda]

Handling HPD during driver removal is pointless, and can cause different
use-after-free/concurrency issues:
1. Setup of deferred fbdev after fbdev unregistration.
2. Access to DP-AUX after DP-AUX removal.

Below stacktraces of both cases observed on CI:

[272.634530] general protection fault, probably for non-canonical address 
0x6b6b6b6b6b6b6b6b:  [#1] PREEMPT SMP NOPTI
[272.634536] CPU: 0 PID: 6030 Comm: i915_selftest Tainted: G U
5.18.0-rc5-CI_DRM_11603-g12dccf4f5eef+ #1
[272.634541] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[272.634545] RIP: 0010:fb_do_apertures_overlap.part.14+0x26/0x60
...
[272.634582] Call Trace:
[272.634583]  
[272.634585]  do_remove_conflicting_framebuffers+0x59/0xa0
[272.634589]  remove_conflicting_framebuffers+0x2d/0xc0
[272.634592]  remove_conflicting_pci_framebuffers+0xc8/0x110
[272.634595]  drm_aperture_remove_conflicting_pci_framebuffers+0x52/0x70
[272.634604]  i915_driver_probe+0x63a/0xdd0 [i915]

[283.405824] cpu_latency_qos_update_request called for unknown object
[283.405866] WARNING: CPU: 2 PID: 240 at kernel/power/qos.c:296 
cpu_latency_qos_update_request+0x2d/0x100
[283.405912] CPU: 2 PID: 240 Comm: kworker/u64:9 Not tainted 
5.18.0-rc6-Patchwork_103738v3-g1672d1c43e43+ #1
[283.405915] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[283.405916] Workqueue: i915-dp i915_digport_work_func [i915]
[283.406020] RIP: 0010:cpu_latency_qos_update_request+0x2d/0x100
...
[283.406040] Call Trace:
[283.406041]  
[283.406044]  intel_dp_aux_xfer+0x60e/0x8e0 [i915]
[283.406131]  ? finish_swait+0x80/0x80
[283.406139]  intel_dp_aux_transfer+0xc5/0x2b0 [i915]
[283.406218]  drm_dp_dpcd_access+0x79/0x130 [drm_display_helper]
[283.406227]  drm_dp_dpcd_read+0xe2/0xf0 [drm_display_helper]
[283.406233]  intel_dp_hpd_pulse+0x134/0x570 [i915]
[283.406308]  ? __down_killable+0x70/0x140
[283.406313]  i915_digport_work_func+0xba/0x150 [i915]

Signed-off-by: Andrzej Hajda 
---
Hi all,

This is my Nth attempt to solve some old CI bug[1].
v1: caused issues in kms code [2],
v2: revealed that not only fbdev does not like HPD on removal [3],
v3: lacks drm_kms_helper_poll_disable[4]

Moreover this is quite rare bug, but due to specific configuration
of one of CI machines it appears there very frequently.

[1]: https://gitlab.freedesktop.org/drm/intel/-/issues/5329
[2]: https://patchwork.freedesktop.org/series/103621/
[3]: https://patchwork.freedesktop.org/series/103738/
[4]: https://patchwork.freedesktop.org/series/103811/

Regards
Andrzej
---
 drivers/gpu/drm/i915/display/intel_display.c | 2 ++
 drivers/gpu/drm/i915/display/intel_fbdev.c   | 1 +
 2 files changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 806d50b302ab92..9c9232da61ff37 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10584,6 +10584,8 @@ void intel_display_driver_unregister(struct 
drm_i915_private *i915)
if (!HAS_DISPLAY(i915))
return;
 
+   intel_hpd_cancel_work(i915);
+   drm_kms_helper_poll_disable(&i915->drm);
intel_fbdev_unregister(i915);
intel_audio_deinit(i915);
 
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 221336178991f0..908741c3161676 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -308,6 +308,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
i915_ggtt_offset(vma));
ifbdev->vma = vma;
ifbdev->vma_flags = flags;
+   dump_stack();
 
intel_runtime_pm_put(&dev_priv->runtime_pm, wakeref);
vga_switcheroo_client_fb_set(pdev, info);
-- 
2.25.1

[Intel-gfx] [PATCH v5] drm/i915/display: disable HPD workers before display driver unregister

[Andrzej Hajda]

Handling HPD during driver removal is pointless, and can cause different
use-after-free/concurrency issues:
1. Setup of deferred fbdev after fbdev unregistration.
2. Access to DP-AUX after DP-AUX removal.

Below stacktraces of both cases observed on CI:

[272.634530] general protection fault, probably for non-canonical address 
0x6b6b6b6b6b6b6b6b:  [#1] PREEMPT SMP NOPTI
[272.634536] CPU: 0 PID: 6030 Comm: i915_selftest Tainted: G U
5.18.0-rc5-CI_DRM_11603-g12dccf4f5eef+ #1
[272.634541] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[272.634545] RIP: 0010:fb_do_apertures_overlap.part.14+0x26/0x60
...
[272.634582] Call Trace:
[272.634583]  
[272.634585]  do_remove_conflicting_framebuffers+0x59/0xa0
[272.634589]  remove_conflicting_framebuffers+0x2d/0xc0
[272.634592]  remove_conflicting_pci_framebuffers+0xc8/0x110
[272.634595]  drm_aperture_remove_conflicting_pci_framebuffers+0x52/0x70
[272.634604]  i915_driver_probe+0x63a/0xdd0 [i915]

[283.405824] cpu_latency_qos_update_request called for unknown object
[283.405866] WARNING: CPU: 2 PID: 240 at kernel/power/qos.c:296 
cpu_latency_qos_update_request+0x2d/0x100
[283.405912] CPU: 2 PID: 240 Comm: kworker/u64:9 Not tainted 
5.18.0-rc6-Patchwork_103738v3-g1672d1c43e43+ #1
[283.405915] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[283.405916] Workqueue: i915-dp i915_digport_work_func [i915]
[283.406020] RIP: 0010:cpu_latency_qos_update_request+0x2d/0x100
...
[283.406040] Call Trace:
[283.406041]  
[283.406044]  intel_dp_aux_xfer+0x60e/0x8e0 [i915]
[283.406131]  ? finish_swait+0x80/0x80
[283.406139]  intel_dp_aux_transfer+0xc5/0x2b0 [i915]
[283.406218]  drm_dp_dpcd_access+0x79/0x130 [drm_display_helper]
[283.406227]  drm_dp_dpcd_read+0xe2/0xf0 [drm_display_helper]
[283.406233]  intel_dp_hpd_pulse+0x134/0x570 [i915]
[283.406308]  ? __down_killable+0x70/0x140
[283.406313]  i915_digport_work_func+0xba/0x150 [i915]

Signed-off-by: Andrzej Hajda 
---
Hi all,

This is my Nth attempt to solve some old CI bug[1].
v-2: caused issues in kms code [2],
v-1: revealed that not only fbdev does not like HPD on removal [3],
v3: lacks drm_kms_helper_poll_disable[4]
v4: added dump_stack to detect late fb registration
v5: added intel_dp_mst_suspend to stop late fb registration

Moreover this is quite rare bug, but due to specific configuration
of one of CI machines it appears there very frequently.
Forgive me spamming the list.

[1]: https://gitlab.freedesktop.org/drm/intel/-/issues/5329
[2]: https://patchwork.freedesktop.org/series/103621/
[3]: https://patchwork.freedesktop.org/series/103738/
[4]: https://patchwork.freedesktop.org/series/103811/

Regards
Andrzej
---
 drivers/gpu/drm/i915/display/intel_display.c | 11 ---
 drivers/gpu/drm/i915/display/intel_fbdev.c   |  1 +
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 806d50b302ab92..007bc6daef7d31 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10486,13 +10486,6 @@ void intel_modeset_driver_remove_noirq(struct 
drm_i915_private *i915)
 */
intel_hpd_poll_fini(i915);
 
-   /*
-* MST topology needs to be suspended so we don't have any calls to
-* fbdev after it's finalized. MST will be destroyed later as part of
-* drm_mode_config_cleanup()
-*/
-   intel_dp_mst_suspend(i915);
-
/* poll work can call into fbdev, hence clean that up afterwards */
intel_fbdev_fini(i915);
 
@@ -10584,6 +10577,10 @@ void intel_display_driver_unregister(struct 
drm_i915_private *i915)
if (!HAS_DISPLAY(i915))
return;
 
+   intel_dp_mst_suspend(i915);
+   intel_hpd_cancel_work(i915);
+   drm_kms_helper_poll_disable(&i915->drm);
+
intel_fbdev_unregister(i915);
intel_audio_deinit(i915);
 
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 221336178991f0..908741c3161676 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -308,6 +308,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
i915_ggtt_offset(vma));
ifbdev->vma = vma;
ifbdev->vma_flags = flags;
+   dump_stack();
 
intel_runtime_pm_put(&dev_priv->runtime_pm, wakeref);
vga_switcheroo_client_fb_set(pdev, info);
-- 
2.25.1

[Intel-gfx] [PATCH v6] drm/i915/display: disable HPD workers before display driver unregister

[Andrzej Hajda]

Handling HPD during driver removal is pointless, and can cause different
use-after-free/concurrency issues:
1. Setup of deferred fbdev after fbdev unregistration.
2. Access to DP-AUX after DP-AUX removal.

Below stacktraces of both cases observed on CI:

[272.634530] general protection fault, probably for non-canonical address 
0x6b6b6b6b6b6b6b6b:  [#1] PREEMPT SMP NOPTI
[272.634536] CPU: 0 PID: 6030 Comm: i915_selftest Tainted: G U
5.18.0-rc5-CI_DRM_11603-g12dccf4f5eef+ #1
[272.634541] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[272.634545] RIP: 0010:fb_do_apertures_overlap.part.14+0x26/0x60
...
[272.634582] Call Trace:
[272.634583]  
[272.634585]  do_remove_conflicting_framebuffers+0x59/0xa0
[272.634589]  remove_conflicting_framebuffers+0x2d/0xc0
[272.634592]  remove_conflicting_pci_framebuffers+0xc8/0x110
[272.634595]  drm_aperture_remove_conflicting_pci_framebuffers+0x52/0x70
[272.634604]  i915_driver_probe+0x63a/0xdd0 [i915]

[283.405824] cpu_latency_qos_update_request called for unknown object
[283.405866] WARNING: CPU: 2 PID: 240 at kernel/power/qos.c:296 
cpu_latency_qos_update_request+0x2d/0x100
[283.405912] CPU: 2 PID: 240 Comm: kworker/u64:9 Not tainted 
5.18.0-rc6-Patchwork_103738v3-g1672d1c43e43+ #1
[283.405915] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[283.405916] Workqueue: i915-dp i915_digport_work_func [i915]
[283.406020] RIP: 0010:cpu_latency_qos_update_request+0x2d/0x100
...
[283.406040] Call Trace:
[283.406041]  
[283.406044]  intel_dp_aux_xfer+0x60e/0x8e0 [i915]
[283.406131]  ? finish_swait+0x80/0x80
[283.406139]  intel_dp_aux_transfer+0xc5/0x2b0 [i915]
[283.406218]  drm_dp_dpcd_access+0x79/0x130 [drm_display_helper]
[283.406227]  drm_dp_dpcd_read+0xe2/0xf0 [drm_display_helper]
[283.406233]  intel_dp_hpd_pulse+0x134/0x570 [i915]
[283.406308]  ? __down_killable+0x70/0x140
[283.406313]  i915_digport_work_func+0xba/0x150 [i915]

Signed-off-by: Andrzej Hajda 
---
Hi all,

This is my Nth attempt to solve some old CI bug[1].
v-2: caused issues in kms code [2],
v-1: revealed that not only fbdev does not like HPD on removal [3],
v3: lacks drm_kms_helper_poll_disable[4]
v4: added dump_stack to detect late fb registration
v5: added intel_dp_mst_suspend to stop late fb registration
v6: removed dump_stack with hope everything is handled

Moreover this is quite rare bug, but due to specific configuration
of one of CI machines it appears there very frequently.
Forgive me spamming the list.

[1]: https://gitlab.freedesktop.org/drm/intel/-/issues/5329
[2]: https://patchwork.freedesktop.org/series/103621/
[3]: https://patchwork.freedesktop.org/series/103738/
[4]: https://patchwork.freedesktop.org/series/103811/

Regards
Andrzej
---
 drivers/gpu/drm/i915/display/intel_display.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 806d50b302ab92..007bc6daef7d31 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10486,13 +10486,6 @@ void intel_modeset_driver_remove_noirq(struct 
drm_i915_private *i915)
 */
intel_hpd_poll_fini(i915);
 
-   /*
-* MST topology needs to be suspended so we don't have any calls to
-* fbdev after it's finalized. MST will be destroyed later as part of
-* drm_mode_config_cleanup()
-*/
-   intel_dp_mst_suspend(i915);
-
/* poll work can call into fbdev, hence clean that up afterwards */
intel_fbdev_fini(i915);
 
@@ -10584,6 +10577,10 @@ void intel_display_driver_unregister(struct 
drm_i915_private *i915)
if (!HAS_DISPLAY(i915))
return;
 
+   intel_dp_mst_suspend(i915);
+   intel_hpd_cancel_work(i915);
+   drm_kms_helper_poll_disable(&i915->drm);
+
intel_fbdev_unregister(i915);
intel_audio_deinit(i915);
 
-- 
2.25.1

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: disable HPD workers before display driver unregister (rev7)

[Andrzej Hajda]

On 14.05.2022 19:03, Patchwork wrote:

Project List - Patchwork *Patch Details*
*Series:* 	drm/i915/display: disable HPD workers before display driver 
unregister (rev7)

*URL:*  https://patchwork.freedesktop.org/series/103811/
*State:*failure
*Details:* 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103811v7/index.html



  CI Bug Log - changes from CI_DRM_11653_full -> Patchwork_103811v7_full


Summary

*FAILURE*

Serious unknown changes coming with Patchwork_103811v7_full absolutely 
need to be

verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_103811v7_full, please notify your bug team to 
allow them
to document this new failure mode, which will reduce false positives 
in CI.



Participating hosts (13 -> 13)

No changes in participating hosts


Possible new issues

Here are the unknown changes that may have been introduced in 
Patchwork_103811v7_full:



  IGT changes


Possible regressions

  * igt@i915_pm_rpm@system-suspend-modeset:
  o shard-apl: PASS


-> INCOMPLETE






This is unrelated - the patch changes only behavior on driver removal path.

Regards
Andrzej

Re: [Intel-gfx] [PATCH v6] drm/i915/display: disable HPD workers before display driver unregister

[Andrzej Hajda]

Seems the patch correctly fixes the the issue and passes CI so added 
maintainers/reviewers to CC.



On 13.05.2022 18:06, Andrzej Hajda wrote:

Handling HPD during driver removal is pointless, and can cause different
use-after-free/concurrency issues:
1. Setup of deferred fbdev after fbdev unregistration.
2. Access to DP-AUX after DP-AUX removal.

Below stacktraces of both cases observed on CI:

[272.634530] general protection fault, probably for non-canonical address 
0x6b6b6b6b6b6b6b6b:  [#1] PREEMPT SMP NOPTI
[272.634536] CPU: 0 PID: 6030 Comm: i915_selftest Tainted: G U
5.18.0-rc5-CI_DRM_11603-g12dccf4f5eef+ #1
[272.634541] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[272.634545] RIP: 0010:fb_do_apertures_overlap.part.14+0x26/0x60
...
[272.634582] Call Trace:
[272.634583]  
[272.634585]  do_remove_conflicting_framebuffers+0x59/0xa0
[272.634589]  remove_conflicting_framebuffers+0x2d/0xc0
[272.634592]  remove_conflicting_pci_framebuffers+0xc8/0x110
[272.634595]  drm_aperture_remove_conflicting_pci_framebuffers+0x52/0x70
[272.634604]  i915_driver_probe+0x63a/0xdd0 [i915]

[283.405824] cpu_latency_qos_update_request called for unknown object
[283.405866] WARNING: CPU: 2 PID: 240 at kernel/power/qos.c:296 
cpu_latency_qos_update_request+0x2d/0x100
[283.405912] CPU: 2 PID: 240 Comm: kworker/u64:9 Not tainted 
5.18.0-rc6-Patchwork_103738v3-g1672d1c43e43+ #1
[283.405915] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[283.405916] Workqueue: i915-dp i915_digport_work_func [i915]
[283.406020] RIP: 0010:cpu_latency_qos_update_request+0x2d/0x100
...
[283.406040] Call Trace:
[283.406041]  
[283.406044]  intel_dp_aux_xfer+0x60e/0x8e0 [i915]
[283.406131]  ? finish_swait+0x80/0x80
[283.406139]  intel_dp_aux_transfer+0xc5/0x2b0 [i915]
[283.406218]  drm_dp_dpcd_access+0x79/0x130 [drm_display_helper]
[283.406227]  drm_dp_dpcd_read+0xe2/0xf0 [drm_display_helper]
[283.406233]  intel_dp_hpd_pulse+0x134/0x570 [i915]
[283.406308]  ? __down_killable+0x70/0x140
[283.406313]  i915_digport_work_func+0xba/0x150 [i915]

Signed-off-by: Andrzej Hajda 
---
Hi all,

This is my Nth attempt to solve some old CI bug[1].
v-2: caused issues in kms code [2],
v-1: revealed that not only fbdev does not like HPD on removal [3],
v3: lacks drm_kms_helper_poll_disable[4]
v4: added dump_stack to detect late fb registration
v5: added intel_dp_mst_suspend to stop late fb registration
v6: removed dump_stack with hope everything is handled

Moreover this is quite rare bug, but due to specific configuration
of one of CI machines it appears there very frequently.
Forgive me spamming the list.

[1]: https://gitlab.freedesktop.org/drm/intel/-/issues/5329
[2]: https://patchwork.freedesktop.org/series/103621/
[3]: https://patchwork.freedesktop.org/series/103738/
[4]: https://patchwork.freedesktop.org/series/103811/

Regards
Andrzej
---
  drivers/gpu/drm/i915/display/intel_display.c | 11 ---
  1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 806d50b302ab92..007bc6daef7d31 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10486,13 +10486,6 @@ void intel_modeset_driver_remove_noirq(struct 
drm_i915_private *i915)
 */
intel_hpd_poll_fini(i915);
  
-	/*

-* MST topology needs to be suspended so we don't have any calls to
-* fbdev after it's finalized. MST will be destroyed later as part of
-* drm_mode_config_cleanup()
-*/
-   intel_dp_mst_suspend(i915);
-
/* poll work can call into fbdev, hence clean that up afterwards */
intel_fbdev_fini(i915);
  
@@ -10584,6 +10577,10 @@ void intel_display_driver_unregister(struct drm_i915_private *i915)

if (!HAS_DISPLAY(i915))
return;
  
+	intel_dp_mst_suspend(i915);

+   intel_hpd_cancel_work(i915);
+   drm_kms_helper_poll_disable(&i915->drm);
+
intel_fbdev_unregister(i915);
intel_audio_deinit(i915);
  

[Intel-gfx] [PATCH RESEND v6] drm/i915/display: disable HPD workers before display driver unregister

[Andrzej Hajda]

Handling HPD during driver removal is pointless, and can cause different
use-after-free/concurrency issues:
1. Setup of deferred fbdev after fbdev unregistration.
2. Access to DP-AUX after DP-AUX removal.

Below stacktraces of both cases observed on CI:

[272.634530] general protection fault, probably for non-canonical address 
0x6b6b6b6b6b6b6b6b:  [#1] PREEMPT SMP NOPTI
[272.634536] CPU: 0 PID: 6030 Comm: i915_selftest Tainted: G U
5.18.0-rc5-CI_DRM_11603-g12dccf4f5eef+ #1
[272.634541] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[272.634545] RIP: 0010:fb_do_apertures_overlap.part.14+0x26/0x60
...
[272.634582] Call Trace:
[272.634583]  
[272.634585]  do_remove_conflicting_framebuffers+0x59/0xa0
[272.634589]  remove_conflicting_framebuffers+0x2d/0xc0
[272.634592]  remove_conflicting_pci_framebuffers+0xc8/0x110
[272.634595]  drm_aperture_remove_conflicting_pci_framebuffers+0x52/0x70
[272.634604]  i915_driver_probe+0x63a/0xdd0 [i915]

[283.405824] cpu_latency_qos_update_request called for unknown object
[283.405866] WARNING: CPU: 2 PID: 240 at kernel/power/qos.c:296 
cpu_latency_qos_update_request+0x2d/0x100
[283.405912] CPU: 2 PID: 240 Comm: kworker/u64:9 Not tainted 
5.18.0-rc6-Patchwork_103738v3-g1672d1c43e43+ #1
[283.405915] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[283.405916] Workqueue: i915-dp i915_digport_work_func [i915]
[283.406020] RIP: 0010:cpu_latency_qos_update_request+0x2d/0x100
...
[283.406040] Call Trace:
[283.406041]  
[283.406044]  intel_dp_aux_xfer+0x60e/0x8e0 [i915]
[283.406131]  ? finish_swait+0x80/0x80
[283.406139]  intel_dp_aux_transfer+0xc5/0x2b0 [i915]
[283.406218]  drm_dp_dpcd_access+0x79/0x130 [drm_display_helper]
[283.406227]  drm_dp_dpcd_read+0xe2/0xf0 [drm_display_helper]
[283.406233]  intel_dp_hpd_pulse+0x134/0x570 [i915]
[283.406308]  ? __down_killable+0x70/0x140
[283.406313]  i915_digport_work_func+0xba/0x150 [i915]

Signed-off-by: Andrzej Hajda 
---
Hi all,

This is resend of [1]. For unknown reason CC-ing ppl did not work,
so I've decided to resend. I hope this time it will work.
The patch was already succesfully tested by CI (rev6, rev7 of [1]).

[1]: https://patchwork.freedesktop.org/series/103811/

Regards
Andrzej
---
 drivers/gpu/drm/i915/display/intel_display.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 806d50b302ab92..007bc6daef7d31 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10486,13 +10486,6 @@ void intel_modeset_driver_remove_noirq(struct 
drm_i915_private *i915)
 */
intel_hpd_poll_fini(i915);
 
-   /*
-* MST topology needs to be suspended so we don't have any calls to
-* fbdev after it's finalized. MST will be destroyed later as part of
-* drm_mode_config_cleanup()
-*/
-   intel_dp_mst_suspend(i915);
-
/* poll work can call into fbdev, hence clean that up afterwards */
intel_fbdev_fini(i915);
 
@@ -10584,6 +10577,10 @@ void intel_display_driver_unregister(struct 
drm_i915_private *i915)
if (!HAS_DISPLAY(i915))
return;
 
+   intel_dp_mst_suspend(i915);
+   intel_hpd_cancel_work(i915);
+   drm_kms_helper_poll_disable(&i915->drm);
+
intel_fbdev_unregister(i915);
intel_audio_deinit(i915);
 
-- 
2.25.1

Re: [Intel-gfx] [PATCH] drm/i915/hwconfig: Report no hwconfig support on ADL-N

[Andrzej Hajda]

On 23.05.2022 09:51, Balasubramani Vivekanandan wrote:

ADL-N being a subplatform of ADL-P, it lacks support for hwconfig
table. Explicit check added to skip ADL-N.

Signed-off-by: Balasubramani Vivekanandan 


Reviewed-by: Andrzej Hajda 

Regards
Andrzej


---
  drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
index 79c66b6b51a3..5aaa3948de74 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
@@ -94,7 +94,7 @@ static int guc_hwconfig_fill_buffer(struct intel_guc *guc, 
struct intel_hwconfig
  
  static bool has_table(struct drm_i915_private *i915)

  {
-   if (IS_ALDERLAKE_P(i915))
+   if (IS_ALDERLAKE_P(i915) && !IS_ADLP_N(i915))
return true;
if (IS_DG2(i915))
return true;

Re: [Intel-gfx] [PATCH] drm/i915: Update tiled blits selftest

[Andrzej Hajda]

On 16.05.2022 10:20, Nirmoy Das wrote:

From: Bommu Krishnaiah 

Update the selftest to include Tile 4 mode and switch to Tile 4 on
platforms that supports Tile 4 but no Tile Y and vice versa.
Also switch to XY_FAST_COPY_BLT on platforms that supports it.

v4: update commit message to reflect the code changes properly.
v3: add a function to find X-tile availability for a platform.
v2: disable Tile X for iGPU in fastblit and
 fix checkpath --strict warnings.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5879
Signed-off-by: Bommu Krishnaiah 
Co-developed-by: Nirmoy Das 
Signed-off-by: Nirmoy Das 
---
  .../i915/gem/selftests/i915_gem_client_blt.c  | 250 ++
  drivers/gpu/drm/i915/gt/intel_gpu_commands.h  |  22 ++
  2 files changed, 227 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
index ddd0772fd828..3cfc621ef363 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
@@ -6,6 +6,7 @@
  #include "i915_selftest.h"
  
  #include "gt/intel_context.h"

+#include "gt/intel_engine_regs.h"
  #include "gt/intel_engine_user.h"
  #include "gt/intel_gpu_commands.h"
  #include "gt/intel_gt.h"
@@ -18,10 +19,71 @@
  #include "huge_gem_object.h"
  #include "mock_context.h"
  
+#define OW_SIZE 16  /* in bytes */

+#define F_SUBTILE_SIZE 64   /* in bytes */
+#define F_TILE_WIDTH 128/* in bytes */
+#define F_TILE_HEIGHT 32/* in pixels */
+#define F_SUBTILE_WIDTH  OW_SIZE/* in bytes */
+#define F_SUBTILE_HEIGHT 4  /* in pixels */
+
+static int linear_x_y_to_ftiled_pos(int x, int y, u32 stride, int bpp)
+{
+   int tile_base;
+   int tile_x, tile_y;
+   int swizzle, subtile;
+   int pixel_size = bpp / 8;
+   int pos;
+
+   /*
+* Subtile remapping for F tile. Note that map[a]==b implies map[b]==a
+* so we can use the same table to tile and until.
+*/
+   static const u8 f_subtile_map[] = {
+0,  1,  2,  3,  8,  9, 10, 11,
+4,  5,  6,  7, 12, 13, 14, 15,
+   16, 17, 18, 19, 24, 25, 26, 27,
+   20, 21, 22, 23, 28, 29, 30, 31,
+   32, 33, 34, 35, 40, 41, 42, 43,
+   36, 37, 38, 39, 44, 45, 46, 47,
+   48, 49, 50, 51, 56, 57, 58, 59,
+   52, 53, 54, 55, 60, 61, 62, 63
+   };


f_subtile_map[i] == (i with swapped bits 2,3)

but I do not know if there is nice C expression/core function to use here,
(i & ^12u) | (( i & 4) << 1) | ((i & 8) >> 1)
does not looks nice.



+
+   x *= pixel_size;
+   /*
+* Where does the 4k tile start (in bytes)?  This is the same for Y and
+* F so we can use the Y-tile algorithm to get to that point.
+*/
+   tile_base =
+   y / F_TILE_HEIGHT * stride * F_TILE_HEIGHT +
+   x / F_TILE_WIDTH * 4096;
+
+   /* Find pixel within tile */
+   tile_x = x % F_TILE_WIDTH;
+   tile_y = y % F_TILE_HEIGHT;
+
+   /* And figure out the subtile within the 4k tile */
+   subtile = tile_y / F_SUBTILE_HEIGHT * 8 + tile_x / F_SUBTILE_WIDTH;
+
+   /* Swizzle the subtile number according to the bspec diagram */
+   swizzle = f_subtile_map[subtile];
+
+   /* Calculate new position */
+   pos = tile_base +
+   swizzle * F_SUBTILE_SIZE +
+   tile_y % F_SUBTILE_HEIGHT * OW_SIZE +
+   tile_x % F_SUBTILE_WIDTH;
+
+   GEM_BUG_ON(!IS_ALIGNED(pos, pixel_size));
+
+   return pos / pixel_size * 4;
+}
+
  enum client_tiling {
CLIENT_TILING_LINEAR,
CLIENT_TILING_X,
CLIENT_TILING_Y,
+   CLIENT_TILING_4,
CLIENT_NUM_TILING_TYPES
  };
  
@@ -45,6 +107,36 @@ struct tiled_blits {

u32 height;
  };
  
+static bool supports_x_tiling(const struct drm_i915_private *i915)

+{
+   int gen = GRAPHICS_VER(i915);
+
+   if (gen < 12)
+   return true;


Why gen variable? you can use expression directly.

Anyway:

Reviewed-by: Andrzej Hajda 

Regards
Andrzej




+
+   if (!HAS_LMEM(i915) || IS_DG1(i915))
+   return false;
+
+   return true;
+}
+
+static bool fast_blit_ok(const struct blit_buffer *buf)
+{
+   int gen = GRAPHICS_VER(buf->vma->vm->i915);
+
+   if (gen < 9)
+   return false;
+
+   if (gen < 12)
+   return true;
+
+   /* filter out platforms with unsupported X-tile support in fastblit */
+   if (buf->tiling == CLIENT_TILING_X && 
!supports_x_tiling(buf->vma->vm->i915))
+   return false;
+
+   return true;
+}
+
  static int prepare_blit(const struct tiled_blits *t,
   

Re: [Intel-gfx] [PATCH v1 01/13] drm/edid: add block count and data helper functions for drm_edid

[Andrzej Hajda]

On 24.05.2022 12:39, Jani Nikula wrote:

Add drm_edid based block count and data access helper functions that
take the EDID allocated size into account.

At the moment, the allocated size should always match the EDID size
indicated by the extension count, but this will change in the future.

Signed-off-by: Jani Nikula 
---
  drivers/gpu/drm/drm_edid.c | 42 +++---
  1 file changed, 35 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 929fc0e46751..682d954a9e42 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1613,6 +1613,35 @@ static const void *edid_extension_block_data(const 
struct edid *edid, int index)
return edid_block_data(edid, index + 1);
  }
  
+static int drm_edid_block_count(const struct drm_edid *drm_edid)

+{
+   int num_blocks;
+
+   /* Starting point */
+   num_blocks = edid_block_count(drm_edid->edid);
+
+   /* Limit by allocated size */
+   num_blocks = min(num_blocks, (int)drm_edid->size / EDID_LENGTH);
+
+   return num_blocks;
+}
+
+static int drm_edid_extension_block_count(const struct drm_edid *drm_edid)
+{
+   return drm_edid_block_count(drm_edid) - 1;
+}
+
+static const void *drm_edid_block_data(const struct drm_edid *drm_edid, int 
index)
+{
+   return edid_block_data(drm_edid->edid, index);
+}
+
+static const void *drm_edid_extension_block_data(const struct drm_edid 
*drm_edid,
+int index)
+{
+   return edid_extension_block_data(drm_edid->edid, index);
+}
+
  /*
   * Initializer helper for legacy interfaces, where we have no choice but to
   * trust edid size. Not for general purpose use.
@@ -1665,8 +1694,8 @@ static const void *__drm_edid_iter_next(struct 
drm_edid_iter *iter)
if (!iter->drm_edid)
return NULL;
  
-	if (iter->index < edid_block_count(iter->drm_edid->edid))

-   block = edid_block_data(iter->drm_edid->edid, iter->index++);
+   if (iter->index < drm_edid_block_count(iter->drm_edid))
+   block = drm_edid_block_data(iter->drm_edid, iter->index++);
  
  	return block;

  }
@@ -3574,22 +3603,21 @@ static int add_detailed_modes(struct drm_connector 
*connector,
  const u8 *drm_find_edid_extension(const struct drm_edid *drm_edid,
  int ext_id, int *ext_index)
  {
-   const struct edid *edid = drm_edid ? drm_edid->edid : NULL;


Do we still need this var?



const u8 *edid_ext = NULL;
int i;
  
  	/* No EDID or EDID extensions */

-   if (!edid || !edid_extension_block_count(edid))
+   if (!drm_edid || !drm_edid_extension_block_count(drm_edid))
return NULL;
  
  	/* Find CEA extension */

-   for (i = *ext_index; i < edid_extension_block_count(edid); i++) {
-   edid_ext = edid_extension_block_data(edid, i);
+   for (i = *ext_index; i < drm_edid_extension_block_count(drm_edid); i++) 
{
+   edid_ext = drm_edid_extension_block_data(drm_edid, i);
if (edid_block_tag(edid_ext) == ext_id)
break;
}
  
-	if (i >= edid_extension_block_count(edid))

+   if (i >= drm_edid_extension_block_count(drm_edid))
return NULL;
  
  	*ext_index = i + 1;


It looks OK. Some suggestions to consider:
1. While at it, refactor little bit the code to return ext from 'for' 
loop and NULL later (to kill after-loop checks, and better code IMO).
2. Implement kind of iterator, for example 
drm_edid_extension_block_next(drm_edid, edid_ext), then use loop:
for (edid_ext = NULL; edid_ext = drm_edid_extension_block_next(drm_edid, 
edid_ext;)

...

Up to you.
Reviewed-by: Andrzej Hajda 

Regards
Andrzej

Re: [Intel-gfx] [PATCH v6] drm/i915: Individualize fences before adding to dma_resv obj

[Andrzej Hajda]

On 25.05.2022 11:59, Nirmoy Das wrote:

_i915_vma_move_to_active() can receive > 1 fences for
multiple batch buffers submission. Because dma_resv_add_fence()
can only accept one fence at a time, change _i915_vma_move_to_active()
to be aware of multiple fences so that it can add individual
fences to the dma resv object.

v6: fix multi-line comment.
v5: remove double fence reservation for batch VMAs.
v4: Reserve fences for composite_fence on multi-batch contexts and
 also reserve fence slots to composite_fence for each VMAs.
v3: dma_resv_reserve_fences is not cumulative so pass num_fences.
v2: make sure to reserve enough fence slots before adding.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5614
Signed-off-by: Nirmoy Das 
---
  .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  3 +-
  drivers/gpu/drm/i915/i915_vma.c   | 48 +++
  2 files changed, 30 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index b279588c0672..8880d38d36b6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1010,7 +1010,8 @@ static int eb_validate_vmas(struct i915_execbuffer *eb)
}
}
  
-		err = dma_resv_reserve_fences(vma->obj->base.resv, 1);

+   /* Reserve enough slots to accommodate composite fences */
+   err = dma_resv_reserve_fences(vma->obj->base.resv, 
eb->num_batches);
if (err)
return err;
  
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c

index 4f6db539571a..0bffb70b3c5f 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -23,6 +23,7 @@
   */
  
  #include 

+#include 
  #include 
  
  #include "display/intel_frontbuffer.h"

@@ -1823,6 +1824,21 @@ int _i915_vma_move_to_active(struct i915_vma *vma,
if (unlikely(err))
return err;
  
+	/*

+* Reserve fences slot early to prevent an allocation after preparing
+* the workload and associating fences with dma_resv.
+*/
+   if (fence && !(flags & __EXEC_OBJECT_NO_RESERVE)) {
+   struct dma_fence *curr;
+   int idx;
+
+   dma_fence_array_for_each(curr, idx, fence)
+   ;


This look little odd.
Maybe we could add helper to dma core to get fences count, different story.

Reviewed-by: Andrzej Hajda 

Regards
Andrzej




+   err = dma_resv_reserve_fences(vma->obj->base.resv, idx);
+   if (unlikely(err))
+   return err;
+   }
+
if (flags & EXEC_OBJECT_WRITE) {
struct intel_frontbuffer *front;
  
@@ -1832,31 +1848,23 @@ int _i915_vma_move_to_active(struct i915_vma *vma,

i915_active_add_request(&front->write, rq);
intel_frontbuffer_put(front);
}
+   }
  
-		if (!(flags & __EXEC_OBJECT_NO_RESERVE)) {

-   err = dma_resv_reserve_fences(vma->obj->base.resv, 1);
-   if (unlikely(err))
-   return err;
-   }
+   if (fence) {
+   struct dma_fence *curr;
+   enum dma_resv_usage usage;
+   int idx;
  
-		if (fence) {

-   dma_resv_add_fence(vma->obj->base.resv, fence,
-  DMA_RESV_USAGE_WRITE);
+   obj->read_domains = 0;
+   if (flags & EXEC_OBJECT_WRITE) {
+   usage = DMA_RESV_USAGE_WRITE;
obj->write_domain = I915_GEM_DOMAIN_RENDER;
-   obj->read_domains = 0;
-   }
-   } else {
-   if (!(flags & __EXEC_OBJECT_NO_RESERVE)) {
-   err = dma_resv_reserve_fences(vma->obj->base.resv, 1);
-   if (unlikely(err))
-   return err;
+   } else {
+   usage = DMA_RESV_USAGE_READ;
}
  
-		if (fence) {

-   dma_resv_add_fence(vma->obj->base.resv, fence,
-  DMA_RESV_USAGE_READ);
-   obj->write_domain = 0;
-   }
+   dma_fence_array_for_each(curr, idx, fence)
+   dma_resv_add_fence(vma->obj->base.resv, curr, usage);
}
  
  	if (flags & EXEC_OBJECT_NEEDS_FENCE && vma->fence)

Re: [Intel-gfx] [PATCH v2 1/1] drm/i915/tc: Don't default disconnected legacy Type-C ports to TBT mode (v2)

[Andrzej Hajda]

On 26.05.2022 02:19, Vivek Kasireddy wrote:

Commit 30e114ef4b16 ("drm/i915/tc: Check for DP-alt, legacy sinks before
taking PHY ownership") defaults any disconnected Type-C ports to TBT-alt
mode which presents a problem (which could most likely result in a system
hang) when userspace forces a modeset on a Type-C port that is wired for
legacy HDMI. The following warning is seen when Weston forces a modeset
on a disconnected legacy Type-C port (HDMI) on a TGL based Gigabyte system:
(https://www.gigabyte.com/Mini-PcBarebone/GB-BSi3-1115G4-rev-10#ov)

Missing case (clock == 173000)
WARNING: CPU: 1 PID: 438 at drivers/gpu/drm/i915/display/intel_ddi.c:245
icl_ddi_tc_enable_clock.cold+0x16a/0x1cf [i915]
CPU: 1 PID: 438 Comm: kworker/u8:3 Tainted: G U  W   E
5.18.0-rc5-drm-tip+ #20
Hardware name: GIGABYTE GB-BSi3-1115G4/GB-BSi3-1115G4, BIOS F9
10/16/2021
Workqueue: i915_modeset intel_atomic_commit_work [i915]
RIP: 0010:icl_ddi_tc_enable_clock.cold+0x16a/0x1cf [i915]
Code: 74 6c 7f 10 81 fd d0 78 02 00 74 6d 81 fd b0 1e 04 00 74 70 48 63
d5 48 c7 c6 c0 7b ab c0 48 c7 c7 20 75 ab c0 e8 b8 b5 c1 f0 <0f> 0b 45
31 ed e9 fb fe ff ff 49 63 d5
  48 c7 c6 80 7b ab c0 48 c7
RSP: 0018:8882522c78f0 EFLAGS: 00010282
RAX:  RBX: 0003 RCX: 
RDX: 0027 RSI: 0004 RDI: ed104a458f10
RBP: 00011558 R08: b078de4e R09: 888269ca748b
R10: ed104d394e91 R11:  R12: 888255a318f8
R13: 0002 R14: 888255a3 R15: 88823ef00348
FS:  () GS:888269c8()
knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7fd7afa42000 CR3: 000255c02004 CR4: 007706e0
PKRU: 5554
Call Trace:

intel_ddi_pre_enable.cold+0x96/0x5bf [i915]
intel_encoders_pre_enable+0x10e/0x140 [i915]
hsw_crtc_enable+0x207/0x99d [i915]
? ilk_crtc_enable.cold+0x2a/0x2a [i915]
? prepare_to_wait_exclusive+0x120/0x120
intel_enable_crtc+0x9a/0xf0 [i915]
skl_commit_modeset_enables+0x466/0x820 [i915]
? intel_commit_modeset_enables+0xd0/0xd0 [i915]
? intel_mbus_dbox_update+0x1ed/0x250 [i915]
intel_atomic_commit_tail+0xf2d/0x3040 [i915]
_raw_spin_lock_irqsave+0x87/0xe0
_raw_read_unlock_irqrestore+0x40/0x40
__update_load_avg_cfs_rq+0x70/0x5c0
__i915_sw_fence_complete+0x85/0x3b0 [i915]
? intel_get_crtc_new_encoder+0x190/0x190 [i915]
? sysvec_irq_work+0x13/0x90
? asm_sysvec_irq_work+0x12/0x20
? _raw_spin_lock_irq+0x82/0xd0
? read_word_at_a_time+0xe/0x20
? process_one_work+0x393/0x690
process_one_work+0x393/0x690
worker_thread+0x2b7/0x620
? process_one_work+0x690/0x690
kthread+0x15a/0x190
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x1f/0x30

Continuing with the modeset without setting the DDI clock results in
more warnings and eventually a system hang. This does not seem to
happen with disconnected legacy or DP-alt DP ports because the clock
rate defaults to 162000 (which is a valid TBT clock) during the link
training process. Therefore, to fix this issue, this patch avoids
setting disconnected Type-C legacy ports to TBT-alt mode which prevents
the selection of TBT PLL when a modeset is forced.

v2: (Imre)
- Retain the check for legacy hotplug live status to account for
incorrect VBTs.

Cc: Imre Deak 
Cc: José Roberto de Souza 
Signed-off-by: Vivek Kasireddy 


Looks sane.
Reviewed-by: Andrzej Hajda 

Regards
Andrzej



---
  drivers/gpu/drm/i915/display/intel_tc.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
b/drivers/gpu/drm/i915/display/intel_tc.c
index b8b822ea3755..6773840f6cc7 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -494,7 +494,8 @@ static void icl_tc_phy_connect(struct intel_digital_port 
*dig_port,
}
  
  	live_status_mask = tc_port_live_status_mask(dig_port);

-   if (!(live_status_mask & (BIT(TC_PORT_DP_ALT) | BIT(TC_PORT_LEGACY {
+   if (!(live_status_mask & (BIT(TC_PORT_DP_ALT) | BIT(TC_PORT_LEGACY))) &&
+   !dig_port->tc_legacy_port) {
drm_dbg_kms(&i915->drm, "Port %s: PHY ownership not required (live 
status %02x)\n",
dig_port->tc_port_name, live_status_mask);
goto out_set_tbt_alt_mode;

Re: [Intel-gfx] [PATCH] drm/i915: Improve user experience and driver robustness under SIGINT or similar

[Andrzej Hajda]

On 27.05.2022 09:24, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

We have long standing customer complaints that pressing Ctrl-C (or to the
effect of) causes engine resets with otherwise well behaving programs.

Not only is logging engine resets during normal operation not desirable
since it creates support incidents, but more fundamentally we should avoid
going the engine reset path when we can since any engine reset introduces
a chance of harming an innocent context.

Reason for this undesirable behaviour is that the driver currently does
not distinguish between banned contexts and non-persistent contexts which
have been closed.

To fix this we add the distinction between the two reasons for revoking
contexts, which then allows the strict timeout only be applied to banned,
while innocent contexts (well behaving) can preempt cleanly and exit
without triggering the engine reset path.

Note that the added context exiting category applies both to closed non-
persistent context, and any exiting context when hangcheck has been
disabled by the user.

At the same time we rename the backend operation from 'ban' to 'revoke'
which more accurately describes the actual semantics. (There is no ban at
the backend level since banning is a concept driven by the scheduling
frontend. Backends are simply able to revoke a running context so that
is the more appropriate name chosen.)

Signed-off-by: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/gem/i915_gem_context.c   | 23 +++--
  drivers/gpu/drm/i915/gt/intel_context.c   | 24 ++
  drivers/gpu/drm/i915/gt/intel_context.h   | 25 +--
  drivers/gpu/drm/i915/gt/intel_context_types.h |  4 ++-
  .../drm/i915/gt/intel_execlists_submission.c  |  6 ++---
  .../gpu/drm/i915/gt/intel_ring_submission.c   |  7 +++---
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 15 ++-
  drivers/gpu/drm/i915/i915_request.c   |  2 +-
  8 files changed, 77 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ab4c5ab28e4d..6b171c89b1b3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1367,7 +1367,8 @@ static struct intel_engine_cs *active_engine(struct 
intel_context *ce)
return engine;
  }
  
-static void kill_engines(struct i915_gem_engines *engines, bool ban)

+static void
+kill_engines(struct i915_gem_engines *engines, bool exit, bool persistent)
  {
struct i915_gem_engines_iter it;
struct intel_context *ce;
@@ -1381,9 +1382,15 @@ static void kill_engines(struct i915_gem_engines 
*engines, bool ban)
 */
for_each_gem_engine(ce, engines, it) {
struct intel_engine_cs *engine;
+   bool skip = false;
  
-		if (ban && intel_context_ban(ce, NULL))

-   continue;
+   if (exit)
+   skip = intel_context_set_exiting(ce);
+   else if (!persistent)
+   skip = intel_context_exit_nonpersistent(ce, NULL);
+
+   if (skip)
+   continue; /* Already marked. */


why not:
if (exit && intel_context_set_exiting(ce))
continue;
else if (!persistent && intel_context_exit_nonpersistent(ce, NULL)
    continue;

Anyway:
Reviewed-by: Andrzej Hajda 

Regards
Andrzej

  
  		/*

 * Check the current active state of this context; if we
@@ -1395,7 +1402,7 @@ static void kill_engines(struct i915_gem_engines 
*engines, bool ban)
engine = active_engine(ce);
  
  		/* First attempt to gracefully cancel the context */

-   if (engine && !__cancel_engine(engine) && ban)
+   if (engine && !__cancel_engine(engine) && (exit || !persistent))
/*
 * If we are unable to send a preemptive pulse to bump
 * the context from the GPU, we have to resort to a full
@@ -1407,8 +1414,6 @@ static void kill_engines(struct i915_gem_engines 
*engines, bool ban)
  
  static void kill_context(struct i915_gem_context *ctx)

  {
-   bool ban = (!i915_gem_context_is_persistent(ctx) ||
-   !ctx->i915->params.enable_hangcheck);
struct i915_gem_engines *pos, *next;
  
  	spin_lock_irq(&ctx->stale.lock);

@@ -1421,7 +1426,8 @@ static void kill_context(struct i915_gem_context *ctx)
  
  		spin_unlock_irq(&ctx->stale.lock);
  
-		kill_engines(pos, ban);

+   kill_engines(pos, !ctx->i915->params.enable_hangcheck,
+i915_gem_context_is_persistent(ctx));
  
  		spin_lock_irq(&ctx->stale.lock);

GEM_BUG_ON(i915_sw_fence_signaled(&pos->fence));
@@ -1467,7 +1473,8 @@ static void engines_idle

Re: [Intel-gfx] [PATCH] drm/edid: ignore the CEA modes not defined in CEA-861-D

[Andrzej Hajda]

On 31.05.2022 12:13, William Tseng wrote:

This is a workaround for HDMI 1.4 sink which has a CEA mode with higher vic
than what is defined in CEA-861-D.

As an example, a HDMI 1.4 sink has the video format 2560x1080p to be
displayed and the video format is indicated by both SVD (with vic 90 and
pictuure aspect ratio 64:27) and DTD.  When connecting to such sink,
source can't output the video format in SVD because an error is returned by
drm_hdmi_avi_infoframe_from_display_mode(), which can't fill the infoframe
with pictuure aspect ratio 64:27 and the vic, which is originally 90 and is
changed to 0 by drm_mode_cea_vic().

To work around it, this patch ignores such CEA modes in do_cea_modes() so
the modes won't be processed in drm_hdmi_avi_infoframe_from_display_mode().
And only the video format in DTD can be dispalyed.

Cc: Ville Syrjälä 
Cc: Wayne Lin 
Cc: Lee Shawn C 
Signed-off-by: William Tseng 
---
  drivers/gpu/drm/drm_edid.c | 39 +-
  1 file changed, 26 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index bc43e1b32092..a93f68878bfd 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3982,6 +3982,19 @@ drm_display_mode_from_cea_vic(struct drm_device *dev,
  }
  EXPORT_SYMBOL(drm_display_mode_from_cea_vic);
  
+static bool is_hdmi2_sink(const struct drm_connector *connector)

+{
+   /*
+* FIXME: sil-sii8620 doesn't have a connector around when
+* we need one, so we have to be prepared for a NULL connector.
+*/
+   if (!connector)
+   return true;
+
+   return connector->display_info.hdmi.scdc.supported ||
+   connector->display_info.color_formats & 
DRM_COLOR_FORMAT_YCBCR420;
+}
+
  static int
  do_cea_modes(struct drm_connector *connector, const u8 *db, u8 len)
  {
@@ -3993,6 +4006,19 @@ do_cea_modes(struct drm_connector *connector, const u8 
*db, u8 len)
  
  		mode = drm_display_mode_from_vic_index(connector, db, len, i);

if (mode) {
+   u8 vic = svd_to_vic(db[i]);
+
+   if (!drm_valid_cea_vic(vic))
+   continue;


It duplicates check from drm_display_mode_from_vic_index


+
+   /*
+* HDMI 1.4 VIC range: 1 <= VIC <= 64 (CEA-861-D) but
+* HDMI 2.0 VIC range: 1 <= VIC <= 107 (CEA-861-F). So 
we
+* have to make sure we dont break HDMI 1.4 sinks.
+*/
+   if (!is_hdmi2_sink(connector) && vic > 64)
+   continue;


So maybe adding this check to drm_display_mode_from_vic_index would be 
enough?


Regards
Andrzej


+
/*
 * YCBCR420 capability block contains a bitmap which
 * gives the index of CEA modes from CEA VDB, which
@@ -5846,19 +5872,6 @@ void drm_set_preferred_mode(struct drm_connector 
*connector,
  }
  EXPORT_SYMBOL(drm_set_preferred_mode);
  
-static bool is_hdmi2_sink(const struct drm_connector *connector)

-{
-   /*
-* FIXME: sil-sii8620 doesn't have a connector around when
-* we need one, so we have to be prepared for a NULL connector.
-*/
-   if (!connector)
-   return true;
-
-   return connector->display_info.hdmi.scdc.supported ||
-   connector->display_info.color_formats & 
DRM_COLOR_FORMAT_YCBCR420;
-}
-
  static u8 drm_mode_hdmi_vic(const struct drm_connector *connector,
const struct drm_display_mode *mode)
  {

Re: [Intel-gfx] [RESEND] drm/i915/display: stop using BUG()

[Andrzej Hajda]

On 31.05.2022 18:25, Jani Nikula wrote:

Avoid bringing the entire machine down even if there's a bug that
shouldn't happen, but won't corrupt the system either. Log them loudly
and limp on.

Signed-off-by: Jani Nikula 


All BUG() cases seems to be converted.

Reviewed-by: Andrzej Hajda 

Regards
Andrzej


---
  drivers/gpu/drm/i915/display/intel_ddi.c  | 11 ++-
  drivers/gpu/drm/i915/display/intel_display.c  | 19 +++
  .../drm/i915/display/intel_display_types.h| 15 +--
  3 files changed, 26 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 333871cf3a2c..915e8e3e8f38 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -455,6 +455,9 @@ intel_ddi_transcoder_func_reg_val_get(struct intel_encoder 
*encoder,
temp |= TRANS_DDI_SELECT_PORT(port);
  
  	switch (crtc_state->pipe_bpp) {

+   default:
+   MISSING_CASE(crtc_state->pipe_bpp);
+   fallthrough;
case 18:
temp |= TRANS_DDI_BPC_6;
break;
@@ -467,8 +470,6 @@ intel_ddi_transcoder_func_reg_val_get(struct intel_encoder 
*encoder,
case 36:
temp |= TRANS_DDI_BPC_12;
break;
-   default:
-   BUG();
}
  
  	if (crtc_state->hw.adjusted_mode.flags & DRM_MODE_FLAG_PVSYNC)

@@ -478,6 +479,9 @@ intel_ddi_transcoder_func_reg_val_get(struct intel_encoder 
*encoder,
  
  	if (cpu_transcoder == TRANSCODER_EDP) {

switch (pipe) {
+   default:
+   MISSING_CASE(pipe);
+   fallthrough;
case PIPE_A:
/* On Haswell, can only use the always-on power well for
 * eDP when not using the panel fitter, and when not
@@ -494,9 +498,6 @@ intel_ddi_transcoder_func_reg_val_get(struct intel_encoder 
*encoder,
case PIPE_C:
temp |= TRANS_DDI_EDP_INPUT_C_ONOFF;
break;
-   default:
-   BUG();
-   break;
}
}
  
diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c

index 806d50b302ab..e6a84d97718f 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -500,6 +500,9 @@ void vlv_wait_port_ready(struct drm_i915_private *dev_priv,
i915_reg_t dpll_reg;
  
  	switch (dig_port->base.port) {

+   default:
+   MISSING_CASE(dig_port->base.port);
+   fallthrough;
case PORT_B:
port_mask = DPLL_PORTB_READY_MASK;
dpll_reg = DPLL(0);
@@ -513,8 +516,6 @@ void vlv_wait_port_ready(struct drm_i915_private *dev_priv,
port_mask = DPLL_PORTD_READY_MASK;
dpll_reg = DPIO_PHY_STATUS;
break;
-   default:
-   BUG();
}
  
  	if (intel_de_wait_for_register(dev_priv, dpll_reg,

@@ -3157,6 +3158,10 @@ static void i9xx_set_pipeconf(const struct 
intel_crtc_state *crtc_state)
PIPECONF_DITHER_TYPE_SP;
  
  		switch (crtc_state->pipe_bpp) {

+   default:
+   /* Case prevented by intel_choose_pipe_bpp_dither. */
+   MISSING_CASE(crtc_state->pipe_bpp);
+   fallthrough;
case 18:
pipeconf |= PIPECONF_BPC_6;
break;
@@ -3166,9 +3171,6 @@ static void i9xx_set_pipeconf(const struct 
intel_crtc_state *crtc_state)
case 30:
pipeconf |= PIPECONF_BPC_10;
break;
-   default:
-   /* Case prevented by intel_choose_pipe_bpp_dither. */
-   BUG();
}
}
  
@@ -3464,6 +3466,10 @@ static void ilk_set_pipeconf(const struct intel_crtc_state *crtc_state)

val = 0;
  
  	switch (crtc_state->pipe_bpp) {

+   default:
+   /* Case prevented by intel_choose_pipe_bpp_dither. */
+   MISSING_CASE(crtc_state->pipe_bpp);
+   fallthrough;
case 18:
val |= PIPECONF_BPC_6;
break;
@@ -3476,9 +3482,6 @@ static void ilk_set_pipeconf(const struct 
intel_crtc_state *crtc_state)
case 36:
val |= PIPECONF_BPC_12;
break;
-   default:
-   /* Case prevented by intel_choose_pipe_bpp_dither. */
-   BUG();
}
  
  	if (crtc_state->dither)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index a27d66fd4383..37c25364350c 100644
--- a/drivers/gpu/drm/i915/di

[Intel-gfx] [PATCH v7] drm/i915/display: disable HPD workers before display driver unregister

[Andrzej Hajda]

Handling HPD during driver removal is pointless, and can cause different
use-after-free/concurrency issues:
1. Setup of deferred fbdev after fbdev unregistration.
2. Access to DP-AUX after DP-AUX removal.

Below stacktraces of both cases observed on CI:

[272.634530] general protection fault, probably for non-canonical address 
0x6b6b6b6b6b6b6b6b:  [#1] PREEMPT SMP NOPTI
[272.634536] CPU: 0 PID: 6030 Comm: i915_selftest Tainted: G U
5.18.0-rc5-CI_DRM_11603-g12dccf4f5eef+ #1
[272.634541] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[272.634545] RIP: 0010:fb_do_apertures_overlap.part.14+0x26/0x60
...
[272.634582] Call Trace:
[272.634583]  
[272.634585]  do_remove_conflicting_framebuffers+0x59/0xa0
[272.634589]  remove_conflicting_framebuffers+0x2d/0xc0
[272.634592]  remove_conflicting_pci_framebuffers+0xc8/0x110
[272.634595]  drm_aperture_remove_conflicting_pci_framebuffers+0x52/0x70
[272.634604]  i915_driver_probe+0x63a/0xdd0 [i915]

[283.405824] cpu_latency_qos_update_request called for unknown object
[283.405866] WARNING: CPU: 2 PID: 240 at kernel/power/qos.c:296 
cpu_latency_qos_update_request+0x2d/0x100
[283.405912] CPU: 2 PID: 240 Comm: kworker/u64:9 Not tainted 
5.18.0-rc6-Patchwork_103738v3-g1672d1c43e43+ #1
[283.405915] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[283.405916] Workqueue: i915-dp i915_digport_work_func [i915]
[283.406020] RIP: 0010:cpu_latency_qos_update_request+0x2d/0x100
...
[283.406040] Call Trace:
[283.406041]  
[283.406044]  intel_dp_aux_xfer+0x60e/0x8e0 [i915]
[283.406131]  ? finish_swait+0x80/0x80
[283.406139]  intel_dp_aux_transfer+0xc5/0x2b0 [i915]
[283.406218]  drm_dp_dpcd_access+0x79/0x130 [drm_display_helper]
[283.406227]  drm_dp_dpcd_read+0xe2/0xf0 [drm_display_helper]
[283.406233]  intel_dp_hpd_pulse+0x134/0x570 [i915]
[283.406308]  ? __down_killable+0x70/0x140
[283.406313]  i915_digport_work_func+0xba/0x150 [i915]

Signed-off-by: Andrzej Hajda 
---
Hi All,

I am not sure about changes in shutdown path, any comments welcome.
I suspect suspend path have also some common bits, but I am little
bit afraid of touching it.

Changes:
v1 - v6:
- chasing the bug appearing only on public CI.
v7:
- shutdown path adjusted (suggested by Jani)

Regards
Andrzej
---
 drivers/gpu/drm/i915/display/intel_display.c | 11 ---
 drivers/gpu/drm/i915/i915_driver.c   |  5 ++---
 2 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 186b37925d23f2..f9952ee8289fb2 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10490,13 +10490,6 @@ void intel_modeset_driver_remove_noirq(struct 
drm_i915_private *i915)
 */
intel_hpd_poll_fini(i915);
 
-   /*
-* MST topology needs to be suspended so we don't have any calls to
-* fbdev after it's finalized. MST will be destroyed later as part of
-* drm_mode_config_cleanup()
-*/
-   intel_dp_mst_suspend(i915);
-
/* poll work can call into fbdev, hence clean that up afterwards */
intel_fbdev_fini(i915);
 
@@ -10588,6 +10581,10 @@ void intel_display_driver_unregister(struct 
drm_i915_private *i915)
if (!HAS_DISPLAY(i915))
return;
 
+   intel_dp_mst_suspend(i915);
+   intel_hpd_cancel_work(i915);
+   drm_kms_helper_poll_disable(&i915->drm);
+
intel_fbdev_unregister(i915);
intel_audio_deinit(i915);
 
diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index d26dcca7e654aa..82cdccf072e2bc 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1070,15 +1070,14 @@ void i915_driver_shutdown(struct drm_i915_private *i915)
i915_gem_suspend(i915);
 
if (HAS_DISPLAY(i915)) {
+   intel_dp_mst_suspend(i915);
+   intel_hpd_cancel_work(i915);
drm_kms_helper_poll_disable(&i915->drm);
 
drm_atomic_helper_shutdown(&i915->drm);
}
 
-   intel_dp_mst_suspend(i915);
-
intel_runtime_pm_disable_interrupts(i915);
-   intel_hpd_cancel_work(i915);
 
intel_suspend_encoders(i915);
intel_shutdown_encoders(i915);
-- 
2.25.1

[Intel-gfx] [PATCH v3 0/3] drm/i915/display: stop HPD workers before display driver unregister

[Andrzej Hajda]

Hi Jani, Ville, Arun,

This patchset is replacement of patch
"drm/i915/display: disable HPD workers before display driver unregister" [1].
Ive decided to split patch into two parts - fbdev and MST, there are different
issues.
Ive also dropped shutdown path, as it has slightly different requirements,
and more importantly I am not able to test properly.

v2 (thx Arun for review):
  - reword of commit message (Arun)
  - intel_fbdev_hpd_set_suspend replaced with intel_fbdev_set_suspend (Arun)
v3:
  - new patch adding suspended flag, to handle
https://gitlab.freedesktop.org/drm/intel/-/issues/5950

[1]: https://patchwork.freedesktop.org/series/103811/

Regards
Andrzej


Andrzej Hajda (3):
  drm/i915/hpd: postpone HPD cancel work after last user suspension
  drm/i915/fbdev: suspend HPD before fbdev unregistration
  drm/i915/display: add hotplug.suspended flag

 drivers/gpu/drm/i915/display/intel_display.c |  3 +++
 drivers/gpu/drm/i915/display/intel_fbdev.c   |  3 ++-
 drivers/gpu/drm/i915/display/intel_hotplug.c | 13 -
 drivers/gpu/drm/i915/display/intel_hotplug.h |  2 +-
 drivers/gpu/drm/i915/i915_driver.c   |  4 ++--
 drivers/gpu/drm/i915/i915_drv.h  |  2 ++
 drivers/gpu/drm/i915/i915_irq.c  |  1 -
 7 files changed, 22 insertions(+), 6 deletions(-)

-- 
2.25.1

[Intel-gfx] [PATCH v3 1/3] drm/i915/hpd: postpone HPD cancel work after last user suspension

[Andrzej Hajda]

i915->hotplug.dig_port_work can be queued from intel_hpd_irq_handler
called by IRQ handler or by intel_hpd_trigger_irq called from dp_mst.
Since dp_mst is suspended after irq handler uninstall, a cleaner approach
is to cancel hpd work after intel_dp_mst_suspend, otherwise we risk
use-after-free.

It should fix following WARNINGS:
[283.405824] cpu_latency_qos_update_request called for unknown object
[283.405866] WARNING: CPU: 2 PID: 240 at kernel/power/qos.c:296 
cpu_latency_qos_update_request+0x2d/0x100
[283.405912] CPU: 2 PID: 240 Comm: kworker/u64:9 Not tainted 
5.18.0-rc6-Patchwork_103738v3-g1672d1c43e43+ #1
[283.405915] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[283.405916] Workqueue: i915-dp i915_digport_work_func [i915]
[283.406020] RIP: 0010:cpu_latency_qos_update_request+0x2d/0x100
...
[283.406040] Call Trace:
[283.406041]  
[283.406044]  intel_dp_aux_xfer+0x60e/0x8e0 [i915]
[283.406131]  ? finish_swait+0x80/0x80
[283.406139]  intel_dp_aux_transfer+0xc5/0x2b0 [i915]
[283.406218]  drm_dp_dpcd_access+0x79/0x130 [drm_display_helper]
[283.406227]  drm_dp_dpcd_read+0xe2/0xf0 [drm_display_helper]
[283.406233]  intel_dp_hpd_pulse+0x134/0x570 [i915]
[283.406308]  ? __down_killable+0x70/0x140
[283.406313]  i915_digport_work_func+0xba/0x150 [i915]

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4586
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5558
Signed-off-by: Andrzej Hajda 
Reviewed-by: Arun R Murthy 
---
 drivers/gpu/drm/i915/display/intel_display.c | 3 +++
 drivers/gpu/drm/i915/i915_irq.c  | 1 -
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 903226e2a6260d..ec8e59b3adaea7 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -9007,6 +9007,9 @@ void intel_modeset_driver_remove_noirq(struct 
drm_i915_private *i915)
 */
intel_dp_mst_suspend(i915);
 
+   /* MST is the last user of HPD work */
+   intel_hpd_cancel_work(i915);
+
/* poll work can call into fbdev, hence clean that up afterwards */
intel_fbdev_fini(i915);
 
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 73cebc6aa65072..db14787aef95dd 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4597,7 +4597,6 @@ void intel_irq_uninstall(struct drm_i915_private 
*dev_priv)
 
free_irq(irq, dev_priv);
 
-   intel_hpd_cancel_work(dev_priv);
dev_priv->runtime_pm.irqs_enabled = false;
 }
 
-- 
2.25.1

[Intel-gfx] [PATCH v3 2/3] drm/i915/fbdev: suspend HPD before fbdev unregistration

[Andrzej Hajda]

HPD event after fbdev unregistration can cause registration of deferred
fbdev which will not be unregistered later, causing use-after-free.
To avoid it HPD handling should be suspended before fbdev unregistration.

It should fix following GPF:
[272.634530] general protection fault, probably for non-canonical address 
0x6b6b6b6b6b6b6b6b:  [#1] PREEMPT SMP NOPTI
[272.634536] CPU: 0 PID: 6030 Comm: i915_selftest Tainted: G U
5.18.0-rc5-CI_DRM_11603-g12dccf4f5eef+ #1
[272.634541] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[272.634545] RIP: 0010:fb_do_apertures_overlap.part.14+0x26/0x60
...
[272.634582] Call Trace:
[272.634583]  
[272.634585]  do_remove_conflicting_framebuffers+0x59/0xa0
[272.634589]  remove_conflicting_framebuffers+0x2d/0xc0
[272.634592]  remove_conflicting_pci_framebuffers+0xc8/0x110
[272.634595]  drm_aperture_remove_conflicting_pci_framebuffers+0x52/0x70
[272.634604]  i915_driver_probe+0x63a/0xdd0 [i915]

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5329
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5510
Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/display/intel_fbdev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 221336178991f0..b682fd72d4bf25 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -573,7 +573,8 @@ void intel_fbdev_unregister(struct drm_i915_private 
*dev_priv)
if (!ifbdev)
return;
 
-   cancel_work_sync(&dev_priv->fbdev_suspend_work);
+   intel_fbdev_set_suspend(&dev_priv->drm, FBINFO_STATE_SUSPENDED, true);
+
if (!current_is_async())
intel_fbdev_sync(ifbdev);
 
-- 
2.25.1

[Intel-gfx] [PATCH v3 3/3] drm/i915/display: add hotplug.suspended flag

[Andrzej Hajda]

HPD events during driver removal can be generated by hardware and
software frameworks - drm_dp_mst, the former we can avoid by disabling
interrupts, the latter can be triggered by any drm_dp_mst transaction,
and this is too late. Introducing suspended flag allows to solve this
chicken-egg problem.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5950
Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/display/intel_display.c |  2 +-
 drivers/gpu/drm/i915/display/intel_hotplug.c | 13 -
 drivers/gpu/drm/i915/display/intel_hotplug.h |  2 +-
 drivers/gpu/drm/i915/i915_driver.c   |  4 ++--
 drivers/gpu/drm/i915/i915_drv.h  |  2 ++
 5 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index ec8e59b3adaea7..b969635b212ba9 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -9008,7 +9008,7 @@ void intel_modeset_driver_remove_noirq(struct 
drm_i915_private *i915)
intel_dp_mst_suspend(i915);
 
/* MST is the last user of HPD work */
-   intel_hpd_cancel_work(i915);
+   intel_hpd_suspend(i915);
 
/* poll work can call into fbdev, hence clean that up afterwards */
intel_fbdev_fini(i915);
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c 
b/drivers/gpu/drm/i915/display/intel_hotplug.c
index 5f8b4f481cff9a..2d505db1f6476b 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -353,6 +353,10 @@ void intel_hpd_trigger_irq(struct intel_digital_port 
*dig_port)
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
 
spin_lock_irq(&i915->irq_lock);
+   if (i915->hotplug.suspended) {
+   spin_unlock_irq(&i915->irq_lock);
+   return;
+   }
i915->hotplug.short_port_mask |= BIT(dig_port->base.port);
spin_unlock_irq(&i915->irq_lock);
 
@@ -475,6 +479,11 @@ void intel_hpd_irq_handler(struct drm_i915_private 
*dev_priv,
 
spin_lock(&dev_priv->irq_lock);
 
+   if (dev_priv->hotplug.suspended) {
+   spin_unlock(&dev_priv->irq_lock);
+   return;
+   }
+
/*
 * Determine whether ->hpd_pulse() exists for each pin, and
 * whether we have a short or a long pulse. This is needed
@@ -603,6 +612,7 @@ void intel_hpd_init(struct drm_i915_private *dev_priv)
 * just to make the assert_spin_locked checks happy.
 */
spin_lock_irq(&dev_priv->irq_lock);
+   dev_priv->hotplug.suspended = false;
intel_hpd_irq_setup(dev_priv);
spin_unlock_irq(&dev_priv->irq_lock);
 }
@@ -721,13 +731,14 @@ void intel_hpd_init_work(struct drm_i915_private 
*dev_priv)
  intel_hpd_irq_storm_reenable_work);
 }
 
-void intel_hpd_cancel_work(struct drm_i915_private *dev_priv)
+void intel_hpd_suspend(struct drm_i915_private *dev_priv)
 {
if (!HAS_DISPLAY(dev_priv))
return;
 
spin_lock_irq(&dev_priv->irq_lock);
 
+   dev_priv->hotplug.suspended = true;
dev_priv->hotplug.long_port_mask = 0;
dev_priv->hotplug.short_port_mask = 0;
dev_priv->hotplug.event_bits = 0;
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.h 
b/drivers/gpu/drm/i915/display/intel_hotplug.h
index b87e95d606e668..54bddc4dd63421 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.h
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.h
@@ -23,7 +23,7 @@ void intel_hpd_irq_handler(struct drm_i915_private *dev_priv,
 void intel_hpd_trigger_irq(struct intel_digital_port *dig_port);
 void intel_hpd_init(struct drm_i915_private *dev_priv);
 void intel_hpd_init_work(struct drm_i915_private *dev_priv);
-void intel_hpd_cancel_work(struct drm_i915_private *dev_priv);
+void intel_hpd_suspend(struct drm_i915_private *dev_priv);
 enum hpd_pin intel_hpd_pin_default(struct drm_i915_private *dev_priv,
   enum port port);
 bool intel_hpd_disable(struct drm_i915_private *dev_priv, enum hpd_pin pin);
diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index be932a6d9c7dfa..5f87719a74337c 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1079,7 +1079,7 @@ void i915_driver_shutdown(struct drm_i915_private *i915)
intel_dp_mst_suspend(i915);
 
intel_runtime_pm_disable_interrupts(i915);
-   intel_hpd_cancel_work(i915);
+   intel_hpd_suspend(i915);
 
intel_suspend_encoders(i915);
intel_shutdown_encoders(i915);
@@ -1148,7 +1148,7 @@ static int i915_drm_suspend(struct drm_device *dev)
intel_dp_mst_suspend(dev_priv);
 
intel_runtime_pm_disable_interrupts(dev_priv);
-   intel_hpd_cancel_work(dev_priv);
+ 

Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/fbdev: suspend HPD before fbdev unregistration

[Andrzej Hajda]

On 14.07.2022 05:09, Murthy, Arun R wrote:

-Original Message-
From: Hajda, Andrzej 
Sent: Wednesday, July 13, 2022 8:50 PM
To: Jani Nikula ; Ville Syrjälä
; Murthy, Arun R 
Cc: Hajda, Andrzej ; Joonas Lahtinen
; Vivi, Rodrigo ;
Tvrtko Ursulin ; Daniel Vetter
; intel-gfx@lists.freedesktop.org; dri-
de...@lists.freedesktop.org
Subject: [PATCH v3 2/3] drm/i915/fbdev: suspend HPD before fbdev
unregistration

HPD event after fbdev unregistration can cause registration of deferred fbdev
which will not be unregistered later, causing use-after-free.
To avoid it HPD handling should be suspended before fbdev unregistration.

It should fix following GPF:
[272.634530] general protection fault, probably for non-canonical address
0x6b6b6b6b6b6b6b6b:  [#1] PREEMPT SMP NOPTI
[272.634536] CPU: 0 PID: 6030 Comm: i915_selftest Tainted: G U
5.18.0-rc5-CI_DRM_11603-g12dccf4f5eef+ #1
[272.634541] Hardware name: Intel Corporation Raptor Lake Client
Platform/RPL-S ADP-S DDR5 UDIMM CRB, BIOS
RPLSFWI1.R00.2397.A01.2109300731 09/30/2021 [272.634545] RIP:
0010:fb_do_apertures_overlap.part.14+0x26/0x60
...
[272.634582] Call Trace:
[272.634583]  
[272.634585]  do_remove_conflicting_framebuffers+0x59/0xa0
[272.634589]  remove_conflicting_framebuffers+0x2d/0xc0
[272.634592]  remove_conflicting_pci_framebuffers+0xc8/0x110
[272.634595]
drm_aperture_remove_conflicting_pci_framebuffers+0x52/0x70
[272.634604]  i915_driver_probe+0x63a/0xdd0 [i915]

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5329
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5510
Signed-off-by: Andrzej Hajda 
---

Reviewed-by: Arun R Murthy 

Thanks and Regards,
Arun R Murthy



Ups, I forgot to add your r-b.
Anyway, thanks for both r-b.

Regards
Andrzej

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: stop HPD workers before display driver unregister (rev6)

[Andrzej Hajda]

On 14.07.2022 12:42, Patchwork wrote:

*Patch Details*
*Series:*	drm/i915/display: stop HPD workers before display driver 
unregister (rev6)
*URL:*	https://patchwork.freedesktop.org/series/105557/ 


*State:*failure
*Details:* 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105557v6/index.html 




  CI Bug Log - changes from CI_DRM_11877_full -> Patchwork_105557v6_full


Summary

*FAILURE*

Serious unknown changes coming with Patchwork_105557v6_full absolutely 
need to be

verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_105557v6_full, please notify your bug team to 
allow them

to document this new failure mode, which will reduce false positives in CI.


Participating hosts (13 -> 12)

Missing (1): shard-dg1


Possible new issues

Here are the unknown changes that may have been introduced in 
Patchwork_105557v6_full:



  IGT changes


Possible regressions

  * igt@gem_exec_fair@basic-deadline:
  o shard-kbl: PASS


-> FAIL





This is known issue, recently reopened, obviously unrelated:
https://gitlab.freedesktop.org/drm/intel/-/issues/2846

Regards
Andrzej





Known issues

Here are the changes found in Patchwork_105557v6_full that come from 
known issues:



  IGT changes


Issues hit

  *

igt@gem_busy@close-race:

  o shard-snb: PASS


-> INCOMPLETE


(i915#6234 )
  *

igt@gem_eio@kms:

  o shard-tglb: PASS


-> FAIL


(i915#5784 )
  *

igt@gem_exec_balancer@parallel-balancer:

  o shard-iclb: PASS


-> SKIP


(i915#4525 )
  *

igt@gem_exec_endless@dispatch@rcs0:

  o shard-apl: PASS


-> INCOMPLETE


(i915#3778 )
  *

igt@gem_exec_fair@basic-none@vcs0:

  o shard-apl: PASS


-> FAIL


(i915#2842
) +1
similar issue
  *

igt@gem_exec_fair@basic-pace@vecs0:

  o

shard-iclb: PASS


-> FAIL


(i915#2842 )

  o

shard-kbl: PASS


-> FAIL


(i915#2842
) +2
similar issues

  *

igt@gem_exec_whisper@basic-contexts-priority:

  o shard-glk: PASS


-> DMESG-WARN


(i915#118 )
  *

igt@gem_huc_copy@huc-copy:

  o shard-skl: NOTRUN -> SKIP

Re: [Intel-gfx] [PATCH RFC] drm/i915/gt: Retry RING_HEAD reset until it sticks

[Andrzej Hajda]

On 15.07.2022 10:26, Mauro Carvalho Chehab wrote:

From: Chris Wilson 

On Haswell, in particular, we see an issue where resets fails because
the engine resumes from an incorrect RING_HEAD. Since the RING_HEAD
doesn't point to the remaining requests to re-run, but may instead point
into the uninitialised portion of the ring, the GPU may be then fed
invalid instructions from a privileged context, oft pushing the GPU into
an unrecoverable hang.

If at first the write doesn't succeed, try, try again.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/5432
Testcase: igt/i915_selftest/hangcheck
Signed-off-by: Chris Wilson 
Cc: Andrzej Hajda 
Cc: Mika Kuoppala 
Signed-off-by: Mauro Carvalho Chehab 



That is pity hw does not provide reliable way of reset.

Reviewed-by: Andrzej Hajda 

Regards
Andrzej



---
  .../gpu/drm/i915/gt/intel_ring_submission.c   | 44 +--
  drivers/gpu/drm/i915/i915_utils.h | 10 +
  2 files changed, 40 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c 
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index d5d6f1fadcae..cc53feb1f8ed 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -190,6 +190,7 @@ static bool stop_ring(struct intel_engine_cs *engine)
  static int xcs_resume(struct intel_engine_cs *engine)
  {
struct intel_ring *ring = engine->legacy.ring;
+   ktime_t kt;
  
  	ENGINE_TRACE(engine, "ring:{HEAD:%04x, TAIL:%04x}\n",

 ring->head, ring->tail);
@@ -228,9 +229,20 @@ static int xcs_resume(struct intel_engine_cs *engine)
set_pp_dir(engine);
  
  	/* First wake the ring up to an empty/idle ring */

-   ENGINE_WRITE_FW(engine, RING_HEAD, ring->head);
+   until_timeout_ns(kt, 2 * NSEC_PER_MSEC) {
+   ENGINE_WRITE_FW(engine, RING_HEAD, ring->head);
+   if (ENGINE_READ_FW(engine, RING_HEAD) == ring->head)
+   break;
+   }
+
ENGINE_WRITE_FW(engine, RING_TAIL, ring->head);
-   ENGINE_POSTING_READ(engine, RING_TAIL);
+   if (ENGINE_READ_FW(engine, RING_HEAD) != ENGINE_READ_FW(engine, 
RING_TAIL)) {
+   ENGINE_TRACE(engine, "failed to reset empty ring: [%x, %x]: 
%x\n",
+ENGINE_READ_FW(engine, RING_HEAD),
+ENGINE_READ_FW(engine, RING_TAIL),
+ring->head);
+   goto err;
+   }
  
  	ENGINE_WRITE_FW(engine, RING_CTL,

RING_CTL_SIZE(ring->size) | RING_VALID);
@@ -239,12 +251,16 @@ static int xcs_resume(struct intel_engine_cs *engine)
if (__intel_wait_for_register_fw(engine->uncore,
 RING_CTL(engine->mmio_base),
 RING_VALID, RING_VALID,
-5000, 0, NULL))
+5000, 0, NULL)) {
+   ENGINE_TRACE(engine, "failed to restart\n");
goto err;
+   }
  
-	if (GRAPHICS_VER(engine->i915) > 2)

+   if (GRAPHICS_VER(engine->i915) > 2) {
ENGINE_WRITE_FW(engine,
RING_MI_MODE, _MASKED_BIT_DISABLE(STOP_RING));
+   ENGINE_POSTING_READ(engine, RING_MI_MODE);
+   }
  
  	/* Now awake, let it get started */

if (ring->tail != ring->head) {
@@ -257,16 +273,16 @@ static int xcs_resume(struct intel_engine_cs *engine)
return 0;
  
  err:

-   drm_err(&engine->i915->drm,
-   "%s initialization failed; "
-   "ctl %08x (valid? %d) head %08x [%08x] tail %08x [%08x] start %08x 
[expected %08x]\n",
-   engine->name,
-   ENGINE_READ(engine, RING_CTL),
-   ENGINE_READ(engine, RING_CTL) & RING_VALID,
-   ENGINE_READ(engine, RING_HEAD), ring->head,
-   ENGINE_READ(engine, RING_TAIL), ring->tail,
-   ENGINE_READ(engine, RING_START),
-   i915_ggtt_offset(ring->vma));
+   ENGINE_TRACE(engine,
+"initialization failed; "
+"ctl %08x (valid? %d) head %08x [%08x] tail %08x [%08x] start 
%08x [expected %08x]\n",
+ENGINE_READ(engine, RING_CTL),
+ENGINE_READ(engine, RING_CTL) & RING_VALID,
+ENGINE_READ(engine, RING_HEAD), ring->head,
+ENGINE_READ(engine, RING_TAIL), ring->tail,
+ENGINE_READ(engine, RING_START),
+i915_ggtt_offset(ring->vma));
+   GEM_TRACE_DUMP();
return -EIO;
  }
  
diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h

index c10d68cdc3ca..717fb6b9cc15 100644
--- a/driv

Re: [Intel-gfx] [PATCH] drm/i915: Pass drm_i915_private struct instead of gt for gen11_gu_misc_irq_handler()

[Andrzej Hajda]

On 18.07.2022 20:34, Anusha Srivatsa wrote:

gen11_gu_misc_irq_handler() does not do anything tile specific.

Cc: Matt Roper 
Signed-off-by: Anusha Srivatsa 


Reviewed-by: Andrzej Hajda 

Regards
Andrzej

[Intel-gfx] [PATCH v4 0/3] drm/i915/display: stop HPD workers before display driver unregister

[Andrzej Hajda]

Hi Jani, Ville, Arun,

This patchset is replacement of patch
"drm/i915/display: disable HPD workers before display driver unregister" [1].
Ive decided to split patch into two parts - fbdev and MST, there are different
issues.
Ive also dropped shutdown path, as it has slightly different requirements,
and more importantly I am not able to test properly.

v2 (thx Arun for review):
  - reword of commit message (Arun)
  - intel_fbdev_hpd_set_suspend replaced with intel_fbdev_set_suspend (Arun)
v3:
  - new patch adding suspended flag, to handle
https://gitlab.freedesktop.org/drm/intel/-/issues/5950
v4:
 - check suspend flag also in i915_digport_work_func

[1]: https://patchwork.freedesktop.org/series/103811/

Regards
Andrzej


Andrzej Hajda (3):
  drm/i915/hpd: postpone HPD cancel work after last user suspension
  drm/i915/fbdev: suspend HPD before fbdev unregistration
  drm/i915/display: add hotplug.suspended flag

 drivers/gpu/drm/i915/display/intel_display.c |  3 +++
 drivers/gpu/drm/i915/display/intel_fbdev.c   |  3 ++-
 drivers/gpu/drm/i915/display/intel_hotplug.c | 11 ++-
 drivers/gpu/drm/i915/display/intel_hotplug.h |  2 +-
 drivers/gpu/drm/i915/i915_driver.c   |  4 ++--
 drivers/gpu/drm/i915/i915_drv.h  |  2 ++
 drivers/gpu/drm/i915/i915_irq.c  |  1 -
 7 files changed, 20 insertions(+), 6 deletions(-)

-- 
2.25.1

[Intel-gfx] [PATCH v4 1/3] drm/i915/hpd: postpone HPD cancel work after last user suspension

[Andrzej Hajda]

i915->hotplug.dig_port_work can be queued from intel_hpd_irq_handler
called by IRQ handler or by intel_hpd_trigger_irq called from dp_mst.
Since dp_mst is suspended after irq handler uninstall, a cleaner approach
is to cancel hpd work after intel_dp_mst_suspend, otherwise we risk
use-after-free.

It should fix following WARNINGS:
[283.405824] cpu_latency_qos_update_request called for unknown object
[283.405866] WARNING: CPU: 2 PID: 240 at kernel/power/qos.c:296 
cpu_latency_qos_update_request+0x2d/0x100
[283.405912] CPU: 2 PID: 240 Comm: kworker/u64:9 Not tainted 
5.18.0-rc6-Patchwork_103738v3-g1672d1c43e43+ #1
[283.405915] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[283.405916] Workqueue: i915-dp i915_digport_work_func [i915]
[283.406020] RIP: 0010:cpu_latency_qos_update_request+0x2d/0x100
...
[283.406040] Call Trace:
[283.406041]  
[283.406044]  intel_dp_aux_xfer+0x60e/0x8e0 [i915]
[283.406131]  ? finish_swait+0x80/0x80
[283.406139]  intel_dp_aux_transfer+0xc5/0x2b0 [i915]
[283.406218]  drm_dp_dpcd_access+0x79/0x130 [drm_display_helper]
[283.406227]  drm_dp_dpcd_read+0xe2/0xf0 [drm_display_helper]
[283.406233]  intel_dp_hpd_pulse+0x134/0x570 [i915]
[283.406308]  ? __down_killable+0x70/0x140
[283.406313]  i915_digport_work_func+0xba/0x150 [i915]

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4586
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5558
Signed-off-by: Andrzej Hajda 
Reviewed-by: Arun R Murthy 
---
 drivers/gpu/drm/i915/display/intel_display.c | 3 +++
 drivers/gpu/drm/i915/i915_irq.c  | 1 -
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 903226e2a6260d..ec8e59b3adaea7 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -9007,6 +9007,9 @@ void intel_modeset_driver_remove_noirq(struct 
drm_i915_private *i915)
 */
intel_dp_mst_suspend(i915);
 
+   /* MST is the last user of HPD work */
+   intel_hpd_cancel_work(i915);
+
/* poll work can call into fbdev, hence clean that up afterwards */
intel_fbdev_fini(i915);
 
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 73cebc6aa65072..db14787aef95dd 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4597,7 +4597,6 @@ void intel_irq_uninstall(struct drm_i915_private 
*dev_priv)
 
free_irq(irq, dev_priv);
 
-   intel_hpd_cancel_work(dev_priv);
dev_priv->runtime_pm.irqs_enabled = false;
 }
 
-- 
2.25.1

[Intel-gfx] [PATCH v4 2/3] drm/i915/fbdev: suspend HPD before fbdev unregistration

[Andrzej Hajda]

HPD event after fbdev unregistration can cause registration of deferred
fbdev which will not be unregistered later, causing use-after-free.
To avoid it HPD handling should be suspended before fbdev unregistration.

It should fix following GPF:
[272.634530] general protection fault, probably for non-canonical address 
0x6b6b6b6b6b6b6b6b:  [#1] PREEMPT SMP NOPTI
[272.634536] CPU: 0 PID: 6030 Comm: i915_selftest Tainted: G U
5.18.0-rc5-CI_DRM_11603-g12dccf4f5eef+ #1
[272.634541] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[272.634545] RIP: 0010:fb_do_apertures_overlap.part.14+0x26/0x60
...
[272.634582] Call Trace:
[272.634583]  
[272.634585]  do_remove_conflicting_framebuffers+0x59/0xa0
[272.634589]  remove_conflicting_framebuffers+0x2d/0xc0
[272.634592]  remove_conflicting_pci_framebuffers+0xc8/0x110
[272.634595]  drm_aperture_remove_conflicting_pci_framebuffers+0x52/0x70
[272.634604]  i915_driver_probe+0x63a/0xdd0 [i915]

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5329
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5510
Signed-off-by: Andrzej Hajda 
Reviewed-by: Arun R Murthy 
---
 drivers/gpu/drm/i915/display/intel_fbdev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 221336178991f0..b682fd72d4bf25 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -573,7 +573,8 @@ void intel_fbdev_unregister(struct drm_i915_private 
*dev_priv)
if (!ifbdev)
return;
 
-   cancel_work_sync(&dev_priv->fbdev_suspend_work);
+   intel_fbdev_set_suspend(&dev_priv->drm, FBINFO_STATE_SUSPENDED, true);
+
if (!current_is_async())
intel_fbdev_sync(ifbdev);
 
-- 
2.25.1

[Intel-gfx] [PATCH v4 3/3] drm/i915/display: add hotplug.suspended flag

[Andrzej Hajda]

HPD events during driver removal can be generated by hardware and
software frameworks - drm_dp_mst, the former we can avoid by disabling
interrupts, the latter can be triggered by any drm_dp_mst transaction,
and this is too late. Introducing suspended flag allows to solve this
chicken-egg problem.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5950
Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/display/intel_display.c |  2 +-
 drivers/gpu/drm/i915/display/intel_hotplug.c | 11 ++-
 drivers/gpu/drm/i915/display/intel_hotplug.h |  2 +-
 drivers/gpu/drm/i915/i915_driver.c   |  4 ++--
 drivers/gpu/drm/i915/i915_drv.h  |  2 ++
 5 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index ec8e59b3adaea7..b969635b212ba9 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -9008,7 +9008,7 @@ void intel_modeset_driver_remove_noirq(struct 
drm_i915_private *i915)
intel_dp_mst_suspend(i915);
 
/* MST is the last user of HPD work */
-   intel_hpd_cancel_work(i915);
+   intel_hpd_suspend(i915);
 
/* poll work can call into fbdev, hence clean that up afterwards */
intel_fbdev_fini(i915);
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c 
b/drivers/gpu/drm/i915/display/intel_hotplug.c
index 5f8b4f481cff9a..e1d384cb99df6b 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -303,6 +303,8 @@ static void i915_digport_work_func(struct work_struct *work)
u32 old_bits = 0;
 
spin_lock_irq(&dev_priv->irq_lock);
+   if (dev_priv->hotplug.suspended)
+   return spin_unlock_irq(&dev_priv->irq_lock);
long_port_mask = dev_priv->hotplug.long_port_mask;
dev_priv->hotplug.long_port_mask = 0;
short_port_mask = dev_priv->hotplug.short_port_mask;
@@ -353,6 +355,8 @@ void intel_hpd_trigger_irq(struct intel_digital_port 
*dig_port)
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
 
spin_lock_irq(&i915->irq_lock);
+   if (i915->hotplug.suspended)
+   return spin_unlock_irq(&i915->irq_lock);
i915->hotplug.short_port_mask |= BIT(dig_port->base.port);
spin_unlock_irq(&i915->irq_lock);
 
@@ -475,6 +479,9 @@ void intel_hpd_irq_handler(struct drm_i915_private 
*dev_priv,
 
spin_lock(&dev_priv->irq_lock);
 
+   if (dev_priv->hotplug.suspended)
+   return spin_unlock(&dev_priv->irq_lock);
+
/*
 * Determine whether ->hpd_pulse() exists for each pin, and
 * whether we have a short or a long pulse. This is needed
@@ -603,6 +610,7 @@ void intel_hpd_init(struct drm_i915_private *dev_priv)
 * just to make the assert_spin_locked checks happy.
 */
spin_lock_irq(&dev_priv->irq_lock);
+   dev_priv->hotplug.suspended = false;
intel_hpd_irq_setup(dev_priv);
spin_unlock_irq(&dev_priv->irq_lock);
 }
@@ -721,13 +729,14 @@ void intel_hpd_init_work(struct drm_i915_private 
*dev_priv)
  intel_hpd_irq_storm_reenable_work);
 }
 
-void intel_hpd_cancel_work(struct drm_i915_private *dev_priv)
+void intel_hpd_suspend(struct drm_i915_private *dev_priv)
 {
if (!HAS_DISPLAY(dev_priv))
return;
 
spin_lock_irq(&dev_priv->irq_lock);
 
+   dev_priv->hotplug.suspended = true;
dev_priv->hotplug.long_port_mask = 0;
dev_priv->hotplug.short_port_mask = 0;
dev_priv->hotplug.event_bits = 0;
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.h 
b/drivers/gpu/drm/i915/display/intel_hotplug.h
index b87e95d606e668..54bddc4dd63421 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.h
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.h
@@ -23,7 +23,7 @@ void intel_hpd_irq_handler(struct drm_i915_private *dev_priv,
 void intel_hpd_trigger_irq(struct intel_digital_port *dig_port);
 void intel_hpd_init(struct drm_i915_private *dev_priv);
 void intel_hpd_init_work(struct drm_i915_private *dev_priv);
-void intel_hpd_cancel_work(struct drm_i915_private *dev_priv);
+void intel_hpd_suspend(struct drm_i915_private *dev_priv);
 enum hpd_pin intel_hpd_pin_default(struct drm_i915_private *dev_priv,
   enum port port);
 bool intel_hpd_disable(struct drm_i915_private *dev_priv, enum hpd_pin pin);
diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index be932a6d9c7dfa..5f87719a74337c 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1079,7 +1079,7 @@ void i915_driver_shutdown(struct drm_i915_private *i915)
intel_dp_mst_suspend(i915);
 
   

Re: [Intel-gfx] [PATCH] drm/i915: Suppress oom warning for shmemfs object allocation failure

[Andrzej Hajda]

On 20.07.2022 14:23, Nirmoy Das wrote:

From: Chris Wilson 

We report object allocation failures to userspace with ENOMEM, yet we
still show the memory warning after failing to shrink device allocated
pages. While this warning is similar to other system page allocation
failures, it is superfluous to the ENOMEM provided directly to
userspace.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4936
Signed-off-by: Chris Wilson 
Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c 
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 4eed3dd90ba8..4466173e1bcc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -137,7 +137,7 @@ int shmem_sg_alloc_table(struct drm_i915_private *i915, 
struct sg_table *st,
 * trigger the out-of-memory killer and for
 * this we want __GFP_RETRY_MAYFAIL.
 */
-   gfp |= __GFP_RETRY_MAYFAIL;
+   gfp |= __GFP_RETRY_MAYFAIL | __GFP_NOWARN;



Reviewed-by: Andrzej Hajda 

Regards
Andrzej


}
} while (1);
  

[Intel-gfx] [PATCH v5 0/4] drm/i915/display: stop HPD workers before display driver unregister

[Andrzej Hajda]

Hi Jani, Ville, Arun,

This patchset is replacement of patch
"drm/i915/display: disable HPD workers before display driver unregister" [1].
Ive decided to split patch into two parts - fbdev and MST, there are different
issues.
Ive also dropped shutdown path, as it has slightly different requirements,
and more importantly I am not able to test properly.

v2 (thx Arun for review):
  - reword of commit message (Arun)
  - intel_fbdev_hpd_set_suspend replaced with intel_fbdev_set_suspend (Arun)
v3:
  - new patch adding suspended flag, to handle
https://gitlab.freedesktop.org/drm/intel/-/issues/5950
v4:
  - check suspend flag also in i915_digport_work_func
v5:
  - added patch blocking FB creation in case HPD is supended,
  - added R-B from Arun to patch 3, thx

[1]: https://patchwork.freedesktop.org/series/103811/

Regards
Andrzej


Andrzej Hajda (4):
  drm/i915/hpd: postpone HPD cancel work after last user suspension
  drm/i915/fbdev: suspend HPD before fbdev unregistration
  drm/i915/display: add hotplug.suspended flag
  drm/i915/fbdev: do not create fbdev if HPD is suspended

 drivers/gpu/drm/i915/display/intel_display.c |  3 +++
 drivers/gpu/drm/i915/display/intel_fbdev.c   |  9 -
 drivers/gpu/drm/i915/display/intel_hotplug.c | 11 ++-
 drivers/gpu/drm/i915/display/intel_hotplug.h |  2 +-
 drivers/gpu/drm/i915/i915_driver.c   |  4 ++--
 drivers/gpu/drm/i915/i915_drv.h  |  2 ++
 drivers/gpu/drm/i915/i915_irq.c  |  1 -
 7 files changed, 26 insertions(+), 6 deletions(-)

-- 
2.25.1

[Intel-gfx] [PATCH v5 3/4] drm/i915/display: add hotplug.suspended flag

[Andrzej Hajda]

HPD events during driver removal can be generated by hardware and
software frameworks - drm_dp_mst, the former we can avoid by disabling
interrupts, the latter can be triggered by any drm_dp_mst transaction,
and this is too late. Introducing suspended flag allows to solve this
chicken-egg problem.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5950
Signed-off-by: Andrzej Hajda 
Reviewed-by: Arun R Murthy 
---
 drivers/gpu/drm/i915/display/intel_display.c |  2 +-
 drivers/gpu/drm/i915/display/intel_hotplug.c | 11 ++-
 drivers/gpu/drm/i915/display/intel_hotplug.h |  2 +-
 drivers/gpu/drm/i915/i915_driver.c   |  4 ++--
 drivers/gpu/drm/i915/i915_drv.h  |  2 ++
 5 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index ec8e59b3adaea7..b969635b212ba9 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -9008,7 +9008,7 @@ void intel_modeset_driver_remove_noirq(struct 
drm_i915_private *i915)
intel_dp_mst_suspend(i915);
 
/* MST is the last user of HPD work */
-   intel_hpd_cancel_work(i915);
+   intel_hpd_suspend(i915);
 
/* poll work can call into fbdev, hence clean that up afterwards */
intel_fbdev_fini(i915);
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c 
b/drivers/gpu/drm/i915/display/intel_hotplug.c
index 5f8b4f481cff9a..e1d384cb99df6b 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -303,6 +303,8 @@ static void i915_digport_work_func(struct work_struct *work)
u32 old_bits = 0;
 
spin_lock_irq(&dev_priv->irq_lock);
+   if (dev_priv->hotplug.suspended)
+   return spin_unlock_irq(&dev_priv->irq_lock);
long_port_mask = dev_priv->hotplug.long_port_mask;
dev_priv->hotplug.long_port_mask = 0;
short_port_mask = dev_priv->hotplug.short_port_mask;
@@ -353,6 +355,8 @@ void intel_hpd_trigger_irq(struct intel_digital_port 
*dig_port)
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
 
spin_lock_irq(&i915->irq_lock);
+   if (i915->hotplug.suspended)
+   return spin_unlock_irq(&i915->irq_lock);
i915->hotplug.short_port_mask |= BIT(dig_port->base.port);
spin_unlock_irq(&i915->irq_lock);
 
@@ -475,6 +479,9 @@ void intel_hpd_irq_handler(struct drm_i915_private 
*dev_priv,
 
spin_lock(&dev_priv->irq_lock);
 
+   if (dev_priv->hotplug.suspended)
+   return spin_unlock(&dev_priv->irq_lock);
+
/*
 * Determine whether ->hpd_pulse() exists for each pin, and
 * whether we have a short or a long pulse. This is needed
@@ -603,6 +610,7 @@ void intel_hpd_init(struct drm_i915_private *dev_priv)
 * just to make the assert_spin_locked checks happy.
 */
spin_lock_irq(&dev_priv->irq_lock);
+   dev_priv->hotplug.suspended = false;
intel_hpd_irq_setup(dev_priv);
spin_unlock_irq(&dev_priv->irq_lock);
 }
@@ -721,13 +729,14 @@ void intel_hpd_init_work(struct drm_i915_private 
*dev_priv)
  intel_hpd_irq_storm_reenable_work);
 }
 
-void intel_hpd_cancel_work(struct drm_i915_private *dev_priv)
+void intel_hpd_suspend(struct drm_i915_private *dev_priv)
 {
if (!HAS_DISPLAY(dev_priv))
return;
 
spin_lock_irq(&dev_priv->irq_lock);
 
+   dev_priv->hotplug.suspended = true;
dev_priv->hotplug.long_port_mask = 0;
dev_priv->hotplug.short_port_mask = 0;
dev_priv->hotplug.event_bits = 0;
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.h 
b/drivers/gpu/drm/i915/display/intel_hotplug.h
index b87e95d606e668..54bddc4dd63421 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.h
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.h
@@ -23,7 +23,7 @@ void intel_hpd_irq_handler(struct drm_i915_private *dev_priv,
 void intel_hpd_trigger_irq(struct intel_digital_port *dig_port);
 void intel_hpd_init(struct drm_i915_private *dev_priv);
 void intel_hpd_init_work(struct drm_i915_private *dev_priv);
-void intel_hpd_cancel_work(struct drm_i915_private *dev_priv);
+void intel_hpd_suspend(struct drm_i915_private *dev_priv);
 enum hpd_pin intel_hpd_pin_default(struct drm_i915_private *dev_priv,
   enum port port);
 bool intel_hpd_disable(struct drm_i915_private *dev_priv, enum hpd_pin pin);
diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index be932a6d9c7dfa..5f87719a74337c 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1079,7 +1079,7 @@ void i915_driver_shutdown(struct drm_i915_private *i915)
intel_dp_mst_suspend(i915);
 
   

[Intel-gfx] [PATCH v5 4/4] drm/i915/fbdev: do not create fbdev if HPD is suspended

[Andrzej Hajda]

In case of deferred FB setup core can try to create new
framebuffer. Disallow it if hpd_suspended flag is set.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/display/intel_fbdev.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index b682fd72d4bf25..7cd3eb9b7729f9 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -210,6 +210,12 @@ static int intelfb_create(struct drm_fb_helper *helper,
struct drm_i915_gem_object *obj;
int ret;
 
+   mutex_lock(&ifbdev->hpd_lock);
+   ret = ifbdev->hpd_suspended ? -EAGAIN : 0;
+   mutex_unlock(&ifbdev->hpd_lock);
+   if (ret)
+   return ret;
+
if (intel_fb &&
(sizes->fb_width > intel_fb->base.width ||
 sizes->fb_height > intel_fb->base.height)) {
-- 
2.25.1

[Intel-gfx] [PATCH v5 1/4] drm/i915/hpd: postpone HPD cancel work after last user suspension

[Andrzej Hajda]

i915->hotplug.dig_port_work can be queued from intel_hpd_irq_handler
called by IRQ handler or by intel_hpd_trigger_irq called from dp_mst.
Since dp_mst is suspended after irq handler uninstall, a cleaner approach
is to cancel hpd work after intel_dp_mst_suspend, otherwise we risk
use-after-free.

It should fix following WARNINGS:
[283.405824] cpu_latency_qos_update_request called for unknown object
[283.405866] WARNING: CPU: 2 PID: 240 at kernel/power/qos.c:296 
cpu_latency_qos_update_request+0x2d/0x100
[283.405912] CPU: 2 PID: 240 Comm: kworker/u64:9 Not tainted 
5.18.0-rc6-Patchwork_103738v3-g1672d1c43e43+ #1
[283.405915] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[283.405916] Workqueue: i915-dp i915_digport_work_func [i915]
[283.406020] RIP: 0010:cpu_latency_qos_update_request+0x2d/0x100
...
[283.406040] Call Trace:
[283.406041]  
[283.406044]  intel_dp_aux_xfer+0x60e/0x8e0 [i915]
[283.406131]  ? finish_swait+0x80/0x80
[283.406139]  intel_dp_aux_transfer+0xc5/0x2b0 [i915]
[283.406218]  drm_dp_dpcd_access+0x79/0x130 [drm_display_helper]
[283.406227]  drm_dp_dpcd_read+0xe2/0xf0 [drm_display_helper]
[283.406233]  intel_dp_hpd_pulse+0x134/0x570 [i915]
[283.406308]  ? __down_killable+0x70/0x140
[283.406313]  i915_digport_work_func+0xba/0x150 [i915]

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4586
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5558
Signed-off-by: Andrzej Hajda 
Reviewed-by: Arun R Murthy 
---
 drivers/gpu/drm/i915/display/intel_display.c | 3 +++
 drivers/gpu/drm/i915/i915_irq.c  | 1 -
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 903226e2a6260d..ec8e59b3adaea7 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -9007,6 +9007,9 @@ void intel_modeset_driver_remove_noirq(struct 
drm_i915_private *i915)
 */
intel_dp_mst_suspend(i915);
 
+   /* MST is the last user of HPD work */
+   intel_hpd_cancel_work(i915);
+
/* poll work can call into fbdev, hence clean that up afterwards */
intel_fbdev_fini(i915);
 
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 73cebc6aa65072..db14787aef95dd 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4597,7 +4597,6 @@ void intel_irq_uninstall(struct drm_i915_private 
*dev_priv)
 
free_irq(irq, dev_priv);
 
-   intel_hpd_cancel_work(dev_priv);
dev_priv->runtime_pm.irqs_enabled = false;
 }
 
-- 
2.25.1

[Intel-gfx] [PATCH v5 2/4] drm/i915/fbdev: suspend HPD before fbdev unregistration

[Andrzej Hajda]

HPD event after fbdev unregistration can cause registration of deferred
fbdev which will not be unregistered later, causing use-after-free.
To avoid it HPD handling should be suspended before fbdev unregistration.

It should fix following GPF:
[272.634530] general protection fault, probably for non-canonical address 
0x6b6b6b6b6b6b6b6b:  [#1] PREEMPT SMP NOPTI
[272.634536] CPU: 0 PID: 6030 Comm: i915_selftest Tainted: G U
5.18.0-rc5-CI_DRM_11603-g12dccf4f5eef+ #1
[272.634541] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[272.634545] RIP: 0010:fb_do_apertures_overlap.part.14+0x26/0x60
...
[272.634582] Call Trace:
[272.634583]  
[272.634585]  do_remove_conflicting_framebuffers+0x59/0xa0
[272.634589]  remove_conflicting_framebuffers+0x2d/0xc0
[272.634592]  remove_conflicting_pci_framebuffers+0xc8/0x110
[272.634595]  drm_aperture_remove_conflicting_pci_framebuffers+0x52/0x70
[272.634604]  i915_driver_probe+0x63a/0xdd0 [i915]

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5329
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5510
Signed-off-by: Andrzej Hajda 
Reviewed-by: Arun R Murthy 
---
 drivers/gpu/drm/i915/display/intel_fbdev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 221336178991f0..b682fd72d4bf25 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -573,7 +573,8 @@ void intel_fbdev_unregister(struct drm_i915_private 
*dev_priv)
if (!ifbdev)
return;
 
-   cancel_work_sync(&dev_priv->fbdev_suspend_work);
+   intel_fbdev_set_suspend(&dev_priv->drm, FBINFO_STATE_SUSPENDED, true);
+
if (!current_is_async())
intel_fbdev_sync(ifbdev);
 
-- 
2.25.1

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Fix comment typo

[Andrzej Hajda]

On 16.07.2022 06:05, Jason Wang wrote:

Fix the double `wait' typo in comment.

Signed-off-by: Jason Wang 
---
  drivers/gpu/drm/i915/selftests/i915_request.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c 
b/drivers/gpu/drm/i915/selftests/i915_request.c
index c56a0c2cd2f7..ec05f578a698 100644
--- a/drivers/gpu/drm/i915/selftests/i915_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_request.c
@@ -971,7 +971,7 @@ static struct i915_vma *empty_batch(struct drm_i915_private 
*i915)
if (err)
goto err;
  
-	/* Force the wait wait now to avoid including it in the benchmark */

+   /* Force the wait now to avoid including it in the benchmark */
err = i915_vma_sync(vma);
if (err)
goto err_pin;


Reviewed-by: Andrzej Hajda 

Regards
Andrzej

[Intel-gfx] [PATCH v6 0/4] drm/i915/display: stop HPD workers before display driver unregister

[Andrzej Hajda]

Hi Jani, Ville, Arun,

This patchset is replacement of patch
"drm/i915/display: disable HPD workers before display driver unregister" [1].
Ive decided to split patch into two parts - fbdev and MST, there are different
issues.
Ive also dropped shutdown path, as it has slightly different requirements,
and more importantly I am not able to test properly.

v2 (thx Arun for review):
  - reword of commit message (Arun)
  - intel_fbdev_hpd_set_suspend replaced with intel_fbdev_set_suspend (Arun)
v3:
  - new patch adding suspended flag, to handle
https://gitlab.freedesktop.org/drm/intel/-/issues/5950
v4:
  - check suspend flag also in i915_digport_work_func
v5:
  - added patch blocking FB creation in case HPD is supended,
  - added R-B from Arun to patch 3, thx
v6:
  - finally, after getting direct access to bat-rpls-2, I have found the source 
of last WARN,
intel_fbdev_hpd_set_suspend was not called in case of deferred setup, fixed 
in patch 2.

[1]: https://patchwork.freedesktop.org/series/103811/

Regards
Andrzej


Andrzej Hajda (4):
  drm/i915/hpd: postpone HPD cancel work after last user suspension
  drm/i915/fbdev: suspend HPD before fbdev unregistration
  drm/i915/display: add hotplug.suspended flag
  drm/i915/fbdev: do not create fbdev if HPD is suspended

 drivers/gpu/drm/i915/display/intel_display.c |  3 +++
 drivers/gpu/drm/i915/display/intel_fbdev.c   | 12 ++--
 drivers/gpu/drm/i915/display/intel_hotplug.c | 11 ++-
 drivers/gpu/drm/i915/display/intel_hotplug.h |  2 +-
 drivers/gpu/drm/i915/i915_driver.c   |  4 ++--
 drivers/gpu/drm/i915/i915_drv.h  |  2 ++
 drivers/gpu/drm/i915/i915_irq.c  |  1 -
 7 files changed, 28 insertions(+), 7 deletions(-)

-- 
2.25.1

[Intel-gfx] [PATCH v6 3/4] drm/i915/display: add hotplug.suspended flag

[Andrzej Hajda]

HPD events during driver removal can be generated by hardware and
software frameworks - drm_dp_mst, the former we can avoid by disabling
interrupts, the latter can be triggered by any drm_dp_mst transaction,
and this is too late. Introducing suspended flag allows to solve this
chicken-egg problem.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5950
Signed-off-by: Andrzej Hajda 
Reviewed-by: Arun R Murthy 
---
 drivers/gpu/drm/i915/display/intel_display.c |  2 +-
 drivers/gpu/drm/i915/display/intel_hotplug.c | 11 ++-
 drivers/gpu/drm/i915/display/intel_hotplug.h |  2 +-
 drivers/gpu/drm/i915/i915_driver.c   |  4 ++--
 drivers/gpu/drm/i915/i915_drv.h  |  2 ++
 5 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index f1c765ac7ab8aa..cd6139bb36151b 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -9022,7 +9022,7 @@ void intel_modeset_driver_remove_noirq(struct 
drm_i915_private *i915)
intel_dp_mst_suspend(i915);
 
/* MST is the last user of HPD work */
-   intel_hpd_cancel_work(i915);
+   intel_hpd_suspend(i915);
 
/* poll work can call into fbdev, hence clean that up afterwards */
intel_fbdev_fini(i915);
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c 
b/drivers/gpu/drm/i915/display/intel_hotplug.c
index 5f8b4f481cff9a..e1d384cb99df6b 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -303,6 +303,8 @@ static void i915_digport_work_func(struct work_struct *work)
u32 old_bits = 0;
 
spin_lock_irq(&dev_priv->irq_lock);
+   if (dev_priv->hotplug.suspended)
+   return spin_unlock_irq(&dev_priv->irq_lock);
long_port_mask = dev_priv->hotplug.long_port_mask;
dev_priv->hotplug.long_port_mask = 0;
short_port_mask = dev_priv->hotplug.short_port_mask;
@@ -353,6 +355,8 @@ void intel_hpd_trigger_irq(struct intel_digital_port 
*dig_port)
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
 
spin_lock_irq(&i915->irq_lock);
+   if (i915->hotplug.suspended)
+   return spin_unlock_irq(&i915->irq_lock);
i915->hotplug.short_port_mask |= BIT(dig_port->base.port);
spin_unlock_irq(&i915->irq_lock);
 
@@ -475,6 +479,9 @@ void intel_hpd_irq_handler(struct drm_i915_private 
*dev_priv,
 
spin_lock(&dev_priv->irq_lock);
 
+   if (dev_priv->hotplug.suspended)
+   return spin_unlock(&dev_priv->irq_lock);
+
/*
 * Determine whether ->hpd_pulse() exists for each pin, and
 * whether we have a short or a long pulse. This is needed
@@ -603,6 +610,7 @@ void intel_hpd_init(struct drm_i915_private *dev_priv)
 * just to make the assert_spin_locked checks happy.
 */
spin_lock_irq(&dev_priv->irq_lock);
+   dev_priv->hotplug.suspended = false;
intel_hpd_irq_setup(dev_priv);
spin_unlock_irq(&dev_priv->irq_lock);
 }
@@ -721,13 +729,14 @@ void intel_hpd_init_work(struct drm_i915_private 
*dev_priv)
  intel_hpd_irq_storm_reenable_work);
 }
 
-void intel_hpd_cancel_work(struct drm_i915_private *dev_priv)
+void intel_hpd_suspend(struct drm_i915_private *dev_priv)
 {
if (!HAS_DISPLAY(dev_priv))
return;
 
spin_lock_irq(&dev_priv->irq_lock);
 
+   dev_priv->hotplug.suspended = true;
dev_priv->hotplug.long_port_mask = 0;
dev_priv->hotplug.short_port_mask = 0;
dev_priv->hotplug.event_bits = 0;
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.h 
b/drivers/gpu/drm/i915/display/intel_hotplug.h
index b87e95d606e668..54bddc4dd63421 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.h
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.h
@@ -23,7 +23,7 @@ void intel_hpd_irq_handler(struct drm_i915_private *dev_priv,
 void intel_hpd_trigger_irq(struct intel_digital_port *dig_port);
 void intel_hpd_init(struct drm_i915_private *dev_priv);
 void intel_hpd_init_work(struct drm_i915_private *dev_priv);
-void intel_hpd_cancel_work(struct drm_i915_private *dev_priv);
+void intel_hpd_suspend(struct drm_i915_private *dev_priv);
 enum hpd_pin intel_hpd_pin_default(struct drm_i915_private *dev_priv,
   enum port port);
 bool intel_hpd_disable(struct drm_i915_private *dev_priv, enum hpd_pin pin);
diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index deb8a8b76965a1..57a063a306e3a4 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1092,7 +1092,7 @@ void i915_driver_shutdown(struct drm_i915_private *i915)
intel_dp_mst_suspend(i915);
 
   

[Intel-gfx] [PATCH v6 1/4] drm/i915/hpd: postpone HPD cancel work after last user suspension

[Andrzej Hajda]

i915->hotplug.dig_port_work can be queued from intel_hpd_irq_handler
called by IRQ handler or by intel_hpd_trigger_irq called from dp_mst.
Since dp_mst is suspended after irq handler uninstall, a cleaner approach
is to cancel hpd work after intel_dp_mst_suspend, otherwise we risk
use-after-free.

It should fix following WARNINGS:
[283.405824] cpu_latency_qos_update_request called for unknown object
[283.405866] WARNING: CPU: 2 PID: 240 at kernel/power/qos.c:296 
cpu_latency_qos_update_request+0x2d/0x100
[283.405912] CPU: 2 PID: 240 Comm: kworker/u64:9 Not tainted 
5.18.0-rc6-Patchwork_103738v3-g1672d1c43e43+ #1
[283.405915] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[283.405916] Workqueue: i915-dp i915_digport_work_func [i915]
[283.406020] RIP: 0010:cpu_latency_qos_update_request+0x2d/0x100
...
[283.406040] Call Trace:
[283.406041]  
[283.406044]  intel_dp_aux_xfer+0x60e/0x8e0 [i915]
[283.406131]  ? finish_swait+0x80/0x80
[283.406139]  intel_dp_aux_transfer+0xc5/0x2b0 [i915]
[283.406218]  drm_dp_dpcd_access+0x79/0x130 [drm_display_helper]
[283.406227]  drm_dp_dpcd_read+0xe2/0xf0 [drm_display_helper]
[283.406233]  intel_dp_hpd_pulse+0x134/0x570 [i915]
[283.406308]  ? __down_killable+0x70/0x140
[283.406313]  i915_digport_work_func+0xba/0x150 [i915]

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4586
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5558
Signed-off-by: Andrzej Hajda 
Reviewed-by: Arun R Murthy 
---
 drivers/gpu/drm/i915/display/intel_display.c | 3 +++
 drivers/gpu/drm/i915/i915_irq.c  | 1 -
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index a0f84cbe974fc3..f1c765ac7ab8aa 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -9021,6 +9021,9 @@ void intel_modeset_driver_remove_noirq(struct 
drm_i915_private *i915)
 */
intel_dp_mst_suspend(i915);
 
+   /* MST is the last user of HPD work */
+   intel_hpd_cancel_work(i915);
+
/* poll work can call into fbdev, hence clean that up afterwards */
intel_fbdev_fini(i915);
 
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 73cebc6aa65072..db14787aef95dd 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4597,7 +4597,6 @@ void intel_irq_uninstall(struct drm_i915_private 
*dev_priv)
 
free_irq(irq, dev_priv);
 
-   intel_hpd_cancel_work(dev_priv);
dev_priv->runtime_pm.irqs_enabled = false;
 }
 
-- 
2.25.1

[Intel-gfx] [PATCH v6 2/4] drm/i915/fbdev: suspend HPD before fbdev unregistration

[Andrzej Hajda]

HPD event after fbdev unregistration can cause registration of deferred
fbdev which will not be unregistered later, causing use-after-free.
To avoid it HPD handling should be suspended before fbdev unregistration.

It should fix following GPF:
[272.634530] general protection fault, probably for non-canonical address 
0x6b6b6b6b6b6b6b6b:  [#1] PREEMPT SMP NOPTI
[272.634536] CPU: 0 PID: 6030 Comm: i915_selftest Tainted: G U
5.18.0-rc5-CI_DRM_11603-g12dccf4f5eef+ #1
[272.634541] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[272.634545] RIP: 0010:fb_do_apertures_overlap.part.14+0x26/0x60
...
[272.634582] Call Trace:
[272.634583]  
[272.634585]  do_remove_conflicting_framebuffers+0x59/0xa0
[272.634589]  remove_conflicting_framebuffers+0x2d/0xc0
[272.634592]  remove_conflicting_pci_framebuffers+0xc8/0x110
[272.634595]  drm_aperture_remove_conflicting_pci_framebuffers+0x52/0x70
[272.634604]  i915_driver_probe+0x63a/0xdd0 [i915]

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5329
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5510
Signed-off-by: Andrzej Hajda 
Reviewed-by: Arun R Murthy 
---
 drivers/gpu/drm/i915/display/intel_fbdev.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 221336178991f0..94ddc0f34fde64 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -573,7 +573,8 @@ void intel_fbdev_unregister(struct drm_i915_private 
*dev_priv)
if (!ifbdev)
return;
 
-   cancel_work_sync(&dev_priv->fbdev_suspend_work);
+   intel_fbdev_set_suspend(&dev_priv->drm, FBINFO_STATE_SUSPENDED, true);
+
if (!current_is_async())
intel_fbdev_sync(ifbdev);
 
@@ -618,7 +619,7 @@ void intel_fbdev_set_suspend(struct drm_device *dev, int 
state, bool synchronous
struct fb_info *info;
 
if (!ifbdev || !ifbdev->vma)
-   return;
+   goto unlock;
 
info = ifbdev->helper.fbdev;
 
@@ -661,6 +662,7 @@ void intel_fbdev_set_suspend(struct drm_device *dev, int 
state, bool synchronous
drm_fb_helper_set_suspend(&ifbdev->helper, state);
console_unlock();
 
+unlock:
intel_fbdev_hpd_set_suspend(dev_priv, state);
 }
 
-- 
2.25.1

[Intel-gfx] [PATCH v6 4/4] drm/i915/fbdev: do not create fbdev if HPD is suspended

[Andrzej Hajda]

In case of deferred FB setup core can try to create new
framebuffer. Disallow it if hpd_suspended flag is set.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/display/intel_fbdev.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 94ddc0f34fde64..fb8dbd532b9e05 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -210,6 +210,12 @@ static int intelfb_create(struct drm_fb_helper *helper,
struct drm_i915_gem_object *obj;
int ret;
 
+   mutex_lock(&ifbdev->hpd_lock);
+   ret = ifbdev->hpd_suspended ? -EAGAIN : 0;
+   mutex_unlock(&ifbdev->hpd_lock);
+   if (ret)
+   return ret;
+
if (intel_fb &&
(sizes->fb_width > intel_fb->base.width ||
 sizes->fb_height > intel_fb->base.height)) {
-- 
2.25.1

Re: [Intel-gfx] [PATCH v5 1/7] drm: Move and add a few utility macros into drm util header

[Andrzej Hajda]

On 25.07.2022 11:25, Gwan-gyeong Mun wrote:

It moves overflows_type utility macro into drm util header from i915_utils
header. The overflows_type can be used to catch the truncation between data
types. And it adds safe_conversion() macro which performs a type conversion
(cast) of an source value into a new variable, checking that the
destination is large enough to hold the source value.
And it adds exact_type and exactly_pgoff_t macro to catch type mis-match
while compiling.

v3: Add is_type_unsigned() macro (Mauro)
 Modify overflows_type() macro to consider signed data types (Mauro)
 Fix the problem that safe_conversion() macro always returns true
v4: Fix kernel-doc markups

Signed-off-by: Gwan-gyeong Mun 
Cc: Thomas Hellström 
Cc: Matthew Auld 
Cc: Nirmoy Das 
Cc: Jani Nikula 
Reviewed-by: Mauro Carvalho Chehab 
---
  drivers/gpu/drm/i915/i915_utils.h |  5 +-
  include/drm/drm_util.h| 77 +++
  2 files changed, 78 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_utils.h 
b/drivers/gpu/drm/i915/i915_utils.h
index c10d68cdc3ca..345e5b2dc1cd 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -32,6 +32,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #ifdef CONFIG_X86

  #include 
@@ -111,10 +112,6 @@ bool i915_error_injected(void);
  #define range_overflows_end_t(type, start, size, max) \
range_overflows_end((type)(start), (type)(size), (type)(max))
  
-/* Note we don't consider signbits :| */

-#define overflows_type(x, T) \
-   (sizeof(x) > sizeof(T) && (x) >> BITS_PER_TYPE(T))
-
  #define ptr_mask_bits(ptr, n) ({  \
unsigned long __v = (unsigned long)(ptr);   \
(typeof(ptr))(__v & -BIT(n));   \
diff --git a/include/drm/drm_util.h b/include/drm/drm_util.h
index 79952d8c4bba..1de9ee5704fa 100644
--- a/include/drm/drm_util.h
+++ b/include/drm/drm_util.h
@@ -62,6 +62,83 @@
   */
  #define for_each_if(condition) if (!(condition)) {} else
  
+/**

+ * is_type_unsigned - helper for checking data type which is an unsigned data
+ * type or not
+ * @x: The data type to check
+ *
+ * Returns:
+ * True if the data type is an unsigned data type, false otherwise.
+ */
+#define is_type_unsigned(x) ((typeof(x))-1 >= (typeof(x))0)
+
+/**
+ * overflows_type - helper for checking the truncation between data types
+ * @x: Source for overflow type comparison
+ * @T: Destination for overflow type comparison
+ *
+ * It compares the values and size of each data type between the first and
+ * second argument to check whether truncation can occur when assigning the
+ * first argument to the variable of the second argument.
+ * Source and Destination can be used with or without sign bit.
+ * Composite data structures such as union and structure are not considered.
+ * Enum data types are not considered.
+ * Floating point data types are not considered.
+ *
+ * Returns:
+ * True if truncation can occur, false otherwise.
+ */
+
+#define overflows_type(x, T) \
+   (is_type_unsigned(x) ? \
+   is_type_unsigned(T) ? \
+   (sizeof(x) > sizeof(T) && (x) >> BITS_PER_TYPE(T)) ? 1 
: 0 \
+   : (sizeof(x) >= sizeof(T) && (x) >> (BITS_PER_TYPE(T) - 
1)) ? 1 : 0 \
+   : is_type_unsigned(T) ? \
+   ((x) < 0) ? 1 : (sizeof(x) > sizeof(T) && (x) >> 
BITS_PER_TYPE(T)) ? 1 : 0 \
+   : (sizeof(x) > sizeof(T)) ? \
+   ((x) < 0) ? (((x) * -1) >> BITS_PER_TYPE(T)) ? 1 : 0 \
+   : ((x) >> BITS_PER_TYPE(T)) ? 1 : 0 \
+   : 0)



It became quite big and hard to read. I wonder if we could not just 
check the effects of the conversion, sth like:

#define overflows_type(x, T) ((T)(x) != (x))

Regards
Andrzej



+
+/**
+ * exact_type - break compile if source type and destination value's type are
+ * not the same
+ * @T: Source type
+ * @n: Destination value
+ *
+ * It is a helper macro for a poor man's -Wconversion: only allow variables of
+ * an exact type. It determines whether the source type and destination value's
+ * type are the same while compiling, and it breaks compile if two types are
+ * not the same
+ */
+#define exact_type(T, n) \
+   BUILD_BUG_ON(!__builtin_constant_p(n) && 
!__builtin_types_compatible_p(T, typeof(n)))
+
+/**
+ * exactly_pgoff_t - helper to check if the type of a value is pgoff_t
+ * @n: value to compare pgoff_t type
+ *
+ * It breaks compile if the argument value's type is not pgoff_t type.
+ */
+#define exactly_pgoff_t(n) exact_type(pgoff_t, n)
+
+/**
+ * safe_conversion - perform a type conversion (cast) of an source value into
+ * a new variable, checking that the destination is large enough to hold the
+ * source value.
+ * @ptr: Destination pointer address
+ * @value: Source value
+ *
+ * Returns:
+ * If the value would overflow the de

Re: [Intel-gfx] [PATCH v5 2/7] drm/i915/gem: Typecheck page lookups

[Andrzej Hajda]

On 25.07.2022 11:25, Gwan-gyeong Mun wrote:

From: Chris Wilson 

We need to check that we avoid integer overflows when looking up a page,
and so fix all the instances where we have mistakenly used a plain
integer instead of a more suitable long. Be pedantic and add integer
typechecking to the lookup so that we can be sure that we are safe.
And it also uses pgoff_t as our page lookups must remain compatible with
the page cache, pgoff_t is currently exactly unsigned long.

v2: Move added i915_utils's macro into drm_util header (Jani N)
v3: Make not use the same macro name on a function. (Mauro)
 For kernel-doc, macros and functions are handled in the same namespace,
 the same macro name on a function prevents ever adding documentation
 for it.
v4: Add kernel-doc markups to the kAPI functions and macros (Mauoro)
v5: Fix an alignment to match open parenthesis

Signed-off-by: Chris Wilson 
Signed-off-by: Gwan-gyeong Mun 
Cc: Tvrtko Ursulin 
Cc: Matthew Auld 
Cc: Thomas Hellström 
Reviewed-by: Nirmoy Das 
Reviewed-by: Mauro Carvalho Chehab 


Reviewed-by: Andrzej Hajda 

Regards
Andrzej

Re: [Intel-gfx] [PATCH v5 3/7] drm/i915: Check for integer truncation on scatterlist creation

[Andrzej Hajda]

On 25.07.2022 11:25, Gwan-gyeong Mun wrote:

From: Chris Wilson 

There is an impedance mismatch between the scatterlist API using unsigned
int and our memory/page accounting in unsigned long. That is we may try
to create a scatterlist for a large object that overflows returning a
small table into which we try to fit very many pages. As the object size
is under control of userspace, we have to be prudent and catch the
conversion errors.

To catch the implicit truncation as we switch from unsigned long into the
scatterlist's unsigned int, we use overflows_type check and report
E2BIG prior to the operation. This is already used in our create ioctls to
indicate if the uABI request is simply too large for the backing store.
Failing that type check, we have a second check at sg_alloc_table time
to make sure the values we are passing into the scatterlist API are not
truncated.

It uses pgoff_t for locals that are dealing with page indices, in this
case, the page count is the limit of the page index.
And it uses safe_conversion() macro which performs a type conversion (cast)
of an integer value into a new variable, checking that the destination is
large enough to hold the source value.

v2: Move added i915_utils's macro into drm_util header (Jani N)
v5: Fix macros to be enclosed in parentheses for complex values
 Fix too long line warning

Signed-off-by: Chris Wilson 
Signed-off-by: Gwan-gyeong Mun 
Cc: Tvrtko Ursulin 
Cc: Brian Welty 
Cc: Matthew Auld 
Cc: Thomas Hellström 
Reviewed-by: Nirmoy Das 
Reviewed-by: Mauro Carvalho Chehab 

Reviewed-by: Andrzej Hajda 

Regards
Andrzej

Re: [Intel-gfx] [PATCH v5 4/7] drm/i915: Check for integer truncation on the configuration of ttm place

[Andrzej Hajda]

On 25.07.2022 11:25, Gwan-gyeong Mun wrote:

There is an impedance mismatch between the first/last valid page
frame number of ttm place in unsigned and our memory/page accounting in
unsigned long.
As the object size is under the control of userspace, we have to be prudent
and catch the conversion errors.
To catch the implicit truncation as we switch from unsigned long to
unsigned, we use overflows_type check and report E2BIG or overflow_type
prior to the operation.

v3: Not to change execution inside a macro. (Mauro)
 Add safe_conversion_gem_bug_on() macro and remove temporal
 SAFE_CONVERSION() macro.

v4: Fix unhandled GEM_BUG_ON() macro call from safe_conversion_gem_bug_on()

Signed-off-by: Gwan-gyeong Mun 
Cc: Chris Wilson 
Cc: Matthew Auld 
Cc: Thomas Hellström 
Reviewed-by: Nirmoy Das 
Reviewed-by: Mauro Carvalho Chehab 
Reported-by: kernel test robot 


Reviewed-by: Andrzej Hajda 

Regards
Andrzej

Re: [Intel-gfx] [PATCH v5 5/7] drm/i915: Check if the size is too big while creating shmem file

[Andrzej Hajda]

On 25.07.2022 11:25, Gwan-gyeong Mun wrote:

The __shmem_file_setup() function returns -EINVAL if size is greater than
MAX_LFS_FILESIZE. To handle the same error as other code that returns
-E2BIG when the size is too large, it add a code that returns -E2BIG when
the size is larger than the size that can be handled.

v4: If BITS_PER_LONG is 32, size > MAX_LFS_FILESIZE is always false, so it
 checks only when BITS_PER_LONG is 64.

Signed-off-by: Gwan-gyeong Mun 
Cc: Chris Wilson 
Cc: Matthew Auld 
Cc: Thomas Hellström 
Reviewed-by: Nirmoy Das 
Reviewed-by: Mauro Carvalho Chehab 
Reported-by: kernel test robot 


Reviewed-by: Andrzej Hajda 

Regards
Andrzej

Re: [Intel-gfx] [PATCH v5 6/7] drm/i915: Use error code as -E2BIG when the size of gem ttm object is too large

[Andrzej Hajda]

On 25.07.2022 11:25, Gwan-gyeong Mun wrote:

The ttm_bo_init_reserved() functions returns -ENOSPC if the size is too big
to add vma. The direct function that returns -ENOSPC is 
drm_mm_insert_node_in_range().
To handle the same error as other code returning -E2BIG when the size is
too large, it converts return value to -E2BIG.

Signed-off-by: Gwan-gyeong Mun 
Cc: Chris Wilson 
Cc: Matthew Auld 
Cc: Thomas Hellström 
Reviewed-by: Nirmoy Das 
Reviewed-by: Mauro Carvalho Chehab 


Reviewed-by: Andrzej Hajda 

Regards
Andrzej

---
  drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 88f2887627dc..4d478bf325be 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1249,6 +1249,17 @@ int __i915_gem_ttm_object_init(struct 
intel_memory_region *mem,
ret = ttm_bo_init_reserved(&i915->bdev, i915_gem_to_ttm(obj), bo_type,
   &i915_sys_placement, page_size >> PAGE_SHIFT,
   &ctx, NULL, NULL, i915_ttm_bo_destroy);
+
+   /*
+* XXX: The ttm_bo_init_reserved() functions returns -ENOSPC if the size
+* is too big to add vma. The direct function that returns -ENOSPC is
+* drm_mm_insert_node_in_range(). To handle the same error as other code
+* that returns -E2BIG when the size is too large, it converts -ENOSPC 
to
+* -E2BIG.
+*/
+   if (size >> PAGE_SHIFT > INT_MAX && ret == -ENOSPC)
+   ret = -E2BIG;
+
if (ret)
return i915_ttm_err_to_gem(ret);
  

Re: [Intel-gfx] [PATCH v5 7/7] drm/i915: Remove truncation warning for large objects

[Andrzej Hajda]

On 25.07.2022 11:25, Gwan-gyeong Mun wrote:

From: Chris Wilson 

Having addressed the issues surrounding incorrect types for local
variables and potential integer truncation in using the scatterlist API,
we have closed all the loop holes we had previously identified with
dangerously large object creation. As such, we can eliminate the warning
put in place to remind us to complete the review.

Signed-off-by: Chris Wilson 
Signed-off-by: Gwan-gyeong Mun 
Cc: Tvrtko Ursulin 
Cc: Brian Welty 
Cc: Matthew Auld 
Cc: Thomas Hellström 
Testcase: igt@gem_create@create-massive
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4991
Reviewed-by: Nirmoy Das 
Reviewed-by: Mauro Carvalho Chehab 


Reviewed-by: Andrzej Hajda 

Regards
Andrzej

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: Use of BARs names instead of numbers

[Andrzej Hajda]

ine __INTEL_PCI_CONFIG_H__
  
+/* PCI BARs */

+#define GTTMMADR_BAR   0
+#define GEN2_GTTMMADR_BAR  1
+#define GFXMEM_BAR 2
+#define GTT_APERTURE_BAR   GFXMEM_BAR
+#define GEN12_LMEM_BAR GFXMEM_BAR


In INTEL_GVT_PCI_BAR_GTTMMIO we have BAR in prefix, here in suffix.
I am not sure which onel is better, just pointing out slight incosistency.

Anyway:
Reviewed-by: Andrzej Hajda 

Regards
Andrzej



+
  /* BSM in include/drm/i915_drm.h */
  
  #define MCHBAR_I9150x44

Re: [Intel-gfx] [PATCH v6 0/4] drm/i915/display: stop HPD workers before display driver unregister

[Andrzej Hajda]

Hi Imre, Jani, Ville,

Since one of CI test machines is back (bat-rpls-2) tests are regularly 
aborted on this machine due to bugs this patchset resolves [1], 
reviewing/merging these patches would allow to cure the situation on CI.


[1]: https://intel-gfx-ci.01.org/tree/drm-tip/bat-rpls-2.html

Regards
Andrzej

On 02.08.2022 14:24, Gwan-gyeong Mun wrote:

Hi Jani, Ville and Imre,

If there are no problems after reviewing this patch series, could you 
please merge it?


Many thanks,
G.G.

On 7/22/22 3:51 PM, Andrzej Hajda wrote:

Hi Jani, Ville, Arun,

This patchset is replacement of patch
"drm/i915/display: disable HPD workers before display driver 
unregister" [1].
Ive decided to split patch into two parts - fbdev and MST, there are 
different

issues.
Ive also dropped shutdown path, as it has slightly different 
requirements,

and more importantly I am not able to test properly.

v2 (thx Arun for review):
   - reword of commit message (Arun)
   - intel_fbdev_hpd_set_suspend replaced with intel_fbdev_set_suspend 
(Arun)

v3:
   - new patch adding suspended flag, to handle
 https://gitlab.freedesktop.org/drm/intel/-/issues/5950
v4:
   - check suspend flag also in i915_digport_work_func
v5:
   - added patch blocking FB creation in case HPD is supended,
   - added R-B from Arun to patch 3, thx
v6:
   - finally, after getting direct access to bat-rpls-2, I have found 
the source of last WARN,
 intel_fbdev_hpd_set_suspend was not called in case of deferred 
setup, fixed in patch 2.


[1]: https://patchwork.freedesktop.org/series/103811/

Regards
Andrzej


Andrzej Hajda (4):
   drm/i915/hpd: postpone HPD cancel work after last user suspension
   drm/i915/fbdev: suspend HPD before fbdev unregistration
   drm/i915/display: add hotplug.suspended flag
   drm/i915/fbdev: do not create fbdev if HPD is suspended

  drivers/gpu/drm/i915/display/intel_display.c |  3 +++
  drivers/gpu/drm/i915/display/intel_fbdev.c   | 12 ++--
  drivers/gpu/drm/i915/display/intel_hotplug.c | 11 ++-
  drivers/gpu/drm/i915/display/intel_hotplug.h |  2 +-
  drivers/gpu/drm/i915/i915_driver.c   |  4 ++--
  drivers/gpu/drm/i915/i915_drv.h  |  2 ++
  drivers/gpu/drm/i915/i915_irq.c  |  1 -
  7 files changed, 28 insertions(+), 7 deletions(-)

Re: [Intel-gfx] [PATCH] Fixes KW issues for NULL pointer dereference

[Andrzej Hajda]

On 11.08.2022 13:28, Tapas Rana wrote:

I guess even for trivial patches rules should be followed - subject 
should describe what has changed, commit message should describe why.




---
  drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 9a7e50534b84..0bbf44c34cff 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -435,6 +435,9 @@ i915_ttm_memcpy_work_arm(struct i915_ttm_memcpy_work *work,
  static bool i915_ttm_memcpy_allowed(struct ttm_buffer_object *bo,
struct ttm_resource *dst_mem)
  {
+   if(!bo)
+   return NULL;



I guess it should be "return false"

Regards
Andrzej


+
if (i915_gem_object_needs_ccs_pages(i915_ttm_to_gem(bo)))
return false;
  

Re: [Intel-gfx] [PATCH v3] drm/i915/pxp: don't start pxp without mei_pxp bind

[Andrzej Hajda]

On 18.08.2022 19:42, Juston Li wrote:

pxp will not start correctly until after mei_pxp bind completes and
intel_pxp_init_hw() is called.
Wait for the bind to complete before proceeding with startup.

This fixes a race condition during bootup where we observed a small
window for pxp commands to be sent, starting pxp before mei_pxp bind
completed.

Changes since v2:
- wait for pxp_component to bind instead of returning -EAGAIN (Daniele)

Changes since v1:
- check pxp_component instead of pxp_component_added (Daniele)
- pxp_component needs tee_mutex (Daniele)
- return -EAGAIN so caller knows to retry (Daniele)

Signed-off-by: Juston Li 


In typical usage of component framework driver postpones initialization 
till component is bound. In such case checking/waiting for component as 
in this patch is not necessary and the code is more straightforward.

I wonder how it behaves on component unbind.

Anyway:
Reviewed-by: Andrzej Hajda 

Regards
Andrzej



---
  drivers/gpu/drm/i915/pxp/intel_pxp.c | 15 +++
  1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 15311eaed848..17109c513259 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -176,6 +176,18 @@ static void pxp_queue_termination(struct intel_pxp *pxp)
spin_unlock_irq(>->irq_lock);
  }
  
+static bool pxp_component_bound(struct intel_pxp *pxp)

+{
+   bool bound = false;
+
+   mutex_lock(&pxp->tee_mutex);
+   if (pxp->pxp_component)
+   bound = true;
+   mutex_unlock(&pxp->tee_mutex);
+
+   return bound;
+}
+
  /*
   * the arb session is restarted from the irq work when we receive the
   * termination completion interrupt
@@ -187,6 +199,9 @@ int intel_pxp_start(struct intel_pxp *pxp)
if (!intel_pxp_is_enabled(pxp))
return -ENODEV;
  
+	if (wait_for(pxp_component_bound(pxp), 250))

+   return -ENXIO;
+
mutex_lock(&pxp->arb_mutex);
  
  	if (pxp->arb_is_valid)

Re: [Intel-gfx] [PATCH v7 1/8] overflow: Move and add few utility macros into overflow

[Andrzej Hajda]

On 18.08.2022 02:12, Kees Cook wrote:

On Thu, Aug 18, 2022 at 01:07:29AM +0200, Andi Shyti wrote:

Hi Kees,

would you mind taking a look at this patch?


Hi! Thanks for the heads-up!



Thanks,
Andi

On Tue, Aug 16, 2022 at 06:35:18PM +0900, Gwan-gyeong Mun wrote:

It moves overflows_type utility macro into overflow header from i915_utils
header. The overflows_type can be used to catch the truncation between data
types. And it adds safe_conversion() macro which performs a type conversion
(cast) of an source value into a new variable, checking that the
destination is large enough to hold the source value. And the functionality
of overflows_type has been improved to handle the signbit.
The is_unsigned_type macro has been added to check the sign bit of the
built-in type.

v3: Add is_type_unsigned() macro (Mauro)
 Modify overflows_type() macro to consider signed data types (Mauro)
 Fix the problem that safe_conversion() macro always returns true
v4: Fix kernel-doc markups
v6: Move macro addition location so that it can be used by other than drm
 subsystem (Jani, Mauro, Andi)
 Change is_type_unsigned to is_unsigned_type to have the same name form
 as is_signed_type macro

Signed-off-by: Gwan-gyeong Mun 
Cc: Thomas Hellström 
Cc: Matthew Auld 
Cc: Nirmoy Das 
Cc: Jani Nikula 
Cc: Andi Shyti 
Reviewed-by: Mauro Carvalho Chehab  (v5)
---
  drivers/gpu/drm/i915/i915_utils.h |  5 +--
  include/linux/overflow.h  | 54 +++
  2 files changed, 55 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_utils.h 
b/drivers/gpu/drm/i915/i915_utils.h
index c10d68cdc3ca..eb0ded23fa9c 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -32,6 +32,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #ifdef CONFIG_X86

  #include 
@@ -111,10 +112,6 @@ bool i915_error_injected(void);
  #define range_overflows_end_t(type, start, size, max) \
range_overflows_end((type)(start), (type)(size), (type)(max))
  
-/* Note we don't consider signbits :| */

-#define overflows_type(x, T) \
-   (sizeof(x) > sizeof(T) && (x) >> BITS_PER_TYPE(T))
-
  #define ptr_mask_bits(ptr, n) ({  \
unsigned long __v = (unsigned long)(ptr);   \
(typeof(ptr))(__v & -BIT(n));   \
diff --git a/include/linux/overflow.h b/include/linux/overflow.h
index f1221d11f8e5..462a03454377 100644
--- a/include/linux/overflow.h
+++ b/include/linux/overflow.h
@@ -35,6 +35,60 @@
  #define type_max(T) ((T)((__type_half_max(T) - 1) + __type_half_max(T)))
  #define type_min(T) ((T)((T)-type_max(T)-(T)1))
  
+/**

+ * is_unsigned_type - helper for checking data type which is an unsigned data
+ * type or not
+ * @x: The data type to check
+ *
+ * Returns:
+ * True if the data type is an unsigned data type, false otherwise.
+ */
+#define is_unsigned_type(x) ((typeof(x))-1 >= (typeof(x))0)


I'd rather not have separate logic for this. Instead, I'd like it to be:

#define is_unsigned_type(x) (!is_signed_type(x))


+
+/**
+ * overflows_type - helper for checking the truncation between data types
+ * @x: Source for overflow type comparison
+ * @T: Destination for overflow type comparison
+ *
+ * It compares the values and size of each data type between the first and
+ * second argument to check whether truncation can occur when assigning the
+ * first argument to the variable of the second argument.
+ * Source and Destination can be used with or without sign bit.
+ * Composite data structures such as union and structure are not considered.
+ * Enum data types are not considered.
+ * Floating point data types are not considered.
+ *
+ * Returns:
+ * True if truncation can occur, false otherwise.
+ */
+#define overflows_type(x, T) \
+   (is_unsigned_type(x) ? \
+   is_unsigned_type(T) ? \
+   (sizeof(x) > sizeof(T) && (x) >> BITS_PER_TYPE(T)) ? 1 
: 0 \
+   : (sizeof(x) >= sizeof(T) && (x) >> (BITS_PER_TYPE(T) - 
1)) ? 1 : 0 \
+   : is_unsigned_type(T) ? \
+   ((x) < 0) ? 1 : (sizeof(x) > sizeof(T) && (x) >> 
BITS_PER_TYPE(T)) ? 1 : 0 \
+   : (sizeof(x) > sizeof(T)) ? \
+   ((x) < 0) ? (((x) * -1) >> BITS_PER_TYPE(T)) ? 1 : 0 \
+   : ((x) >> BITS_PER_TYPE(T)) ? 1 : 0 \
+   : 0)


Like the other, I'd much rather this was rephrased in terms of the
existing macros (e.g. type_min()/type_max().)



I am not sure how it could be rephrased with type_(min|max), but I guess 
the shortest could be sth like:


#define overflows_type(x, T) __builtin_add_overflow_p(x, (typeof(T))0, 
(typeof(T))0)


Regards
Andrzej





+
+/**
+ * safe_conversion - perform a type conversion (cast) of an source value into
+ * a new variable, checking that the destination is large enough to hold the
+ * source value.
+ * @ptr: Destination poi