Re: [RFC PATCH 00/10] Xe DRM scheduler and long running workload plans

[Asahi Lina]

On 11/04/2023 23.07, Daniel Vetter wrote:

On Sat, Apr 08, 2023 at 04:05:20PM +0900, Asahi Lina wrote:

On 04/04/2023 10.58, Matthew Brost wrote:

On Tue, Apr 04, 2023 at 10:07:48AM +0900, Asahi Lina wrote:

Hi, thanks for the Cc!



No problem.


On 04/04/2023 09.22, Matthew Brost wrote:

Hello,

As a prerequisite to merging the new Intel Xe DRM driver [1] [2], we
have been asked to merge our common DRM scheduler patches first as well
as develop a common solution for long running workloads with the DRM
scheduler. This RFC series is our first attempt at doing this. We
welcome any and all feedback.

This can we thought of as 4 parts detailed below.

- DRM scheduler changes for 1 to 1 relationship between scheduler and
entity (patches 1-3)

In Xe all of the scheduling of jobs is done by a firmware scheduler (the
GuC) which is a new paradigm WRT to the DRM scheduler and presents
severals problems as the DRM was originally designed to schedule jobs on
hardware queues. The main problem being that DRM scheduler expects the
submission order of jobs to be the completion order of jobs even across
multiple entities. This assumption falls apart with a firmware scheduler
as a firmware scheduler has no concept of jobs and jobs can complete out
of order. A novel solution for was originally thought of by Faith during
the initial prototype of Xe, create a 1 to 1 relationship between scheduler
and entity. I believe the AGX driver [3] is using this approach and
Boris may use approach as well for the Mali driver [4].

To support a 1 to 1 relationship we move the main execution function
from a kthread to a work queue and add a new scheduling mode which
bypasses code in the DRM which isn't needed in a 1 to 1 relationship.
The new scheduling mode should unify all drivers usage with a 1 to 1
relationship and can be thought of as using scheduler as a dependency /
infligt job tracker rather than a true scheduler.


Yup, we're in the exact same situation with drm/asahi, so this is very
welcome! We've been using the existing scheduler as-is, but this should help
remove some unneeded complexity in this use case.



That's the idea.


Do you want me to pull in this series into our tree and make sure this all
works out for us?



We tested this in Xe and it definitely works for us but the more testing
the better.



I haven't gotten around to testing this series yet, but after more debugging
of drm_sched issues I want to hear more about how Xe uses the scheduler.

 From what I can tell, and from what Christian says, drm_sched has the hidden
requirement that all job objects outlive the scheduler. I've run into
several UAF bugs due to this. Not only that, it also currently has the
requirement that all drm_sched fences outlive the scheduler object.

These requirements are subtle and only manifest as kernel oopses in rare
corner cases, so it wasn't at all obvious to me that this was somehow a
fundamental design assumption when I started using it.

As far as I can tell, this design is going to work in 99% of cases for
global-schedulers-per-GPU models, where those corner cases would have to be
hit on top of a GPU removal scenario (and GPU remove is... well, not the
most tested/exercised use case). When the scheduler basically lives forever,
none of this really matters.

But with a one-scheduler-per-queue model, how do you deal with this when the
queue goes away? So far, without any of the partial bugfixes I have sent so
far (which Christian objected to):

- If you try to tear down a scheduler with any jobs currently scheduled at
the hardware, drm_sched will oops when those jobs complete and the hw fences
signal.
- If you try to tear down an entity (which should cancel all its pending
jobs) and then the scheduler it was attached to without actually waiting for
all the free_job() callbacks to be called on every job that ever existed for
that entity, you can oops (entity cleanup is asynchronous in some cases like
killed processes, so it will return before all jobs are freed and then that
asynchronous process will crash and burn if the scheduler goes away out from
under its feet). Waiting for job completion fences is not enough for this,
you have to wait until free_job() has actually been called for all jobs.
- Even if you actually wait for all jobs to be truly gone and then tear down
the scheduler, if any scheduler job fences remain alive, that will then oops
if you try to call the debug functions on them (like cat
/sys/kernel/debug/dma_buf/bufinfo).

I tried to fix these things, but Christian objected implying it was the
driver's job to keep a reference from jobs and hw fences to the scheduler.
But I find that completely broken, because besides the extra memory/resource
usage keeping the scheduler alive when you're trying to free resources as
fast as possible when a process goes away, you can't even use normal
reference counting for that: if you try to drop the last drm_sched reference
from within a free_job() callback, the whole thing 

Re: Linux 6.2.1 hits a display driver bug (list_del corruption, ffff88811b4af298->next is NULL)

[Bagas Sanjaya]

On Mon, Mar 06, 2023 at 06:51:48PM +0700, Ammar Faizi wrote:
> On Mon, Mar 06, 2023 at 12:54:59PM +0200, Jani Nikula wrote:
> > Please file a bug at fdo gitlab:
> > 
> > https://gitlab.freedesktop.org/drm/intel/wikis/How-to-file-i915-bugs
> 
> OK, I posted it here https://gitlab.freedesktop.org/drm/intel/-/issues/8274
> 

Hi,

From gitlab issue above, I don't see any progress on bisection attempt.
Ammar, have you successfully boot Ubuntu 20.04 with v5.10 kernel and
test there?

Anyway, I'm adding this to regzbot (with tentative commit range):

#regzbot introduced: v5.10..v5.15.103
#regzbot title: Linux 6.2.1 hits a display driver bug (list_del corruption, 
88811b4af298->next is NULL)
#regzbot link: https://gitlab.freedesktop.org/drm/intel/-/issues/8274

(Also Cc: Thorsten)

Thanks.

-- 
An old man doll... just what I always wanted! - Clara


signature.asc
Description: PGP signature

[v9] media: mediatek: vcodec: support stateless AV1 decoder

[Xiaoyong Lu]

Add mediatek av1 decoder linux driver which use the stateless API in
MT8195.

Signed-off-by: Xiaoyong Lu
Tested-by: Nicolas Dufresne 
Reviewed-by: Nicolas Dufresne 
Tested-by: AngeloGioacchino Del Regno 
Reviewed-by: AngeloGioacchino Del Regno 

---
Changes from v8:

- remove RFC tag in subject.
- test by av1 fluster, results are 173/239(10bit/film grain are not 
support),11/13(film grain is not support),0(10bit is not support).

Changes from v7:

- change V4L2_CID_STATELESS_AV1_PROFILE to V4L2_CID_MPEG_VIDEO_AV1_PROFILE,
V4L2_CID_STATELESS_AV1_LEVEL to V4L2_CID_MPEG_VIDEO_AV1_LEVEL to match av1 uAPI 
V4.
- remove vsi and ctx null check in vdec_av1_slice_init_cdf_table, 
vdec_av1_slice_init_iq_table for the never true condition.
- add inline in function vdec_av1_slice_clear_fb, 
vdec_av1_slice_vsi_from_remote,
vdec_av1_slice_vsi_to_remote, vdec_av1_slice_setup_state, 
vdec_av1_slice_setup_operating_mode and vdec_av1_slice_get_dpb_size.
- remove fb_idx check in vdec_av1_slice_decrease_ref_count.
- add define AV1_CDF_TABLE_BUFFER_SIZE for magic number 16384.
- remove intermediate variable "size" at the end of 
vdec_av1_slice_alloc_working_buffer.
- use define V4L2_AV1_WARP_MODEL_AFFINE to replace magic number 3 in 
vdec_av1_slice_setup_gm.
- change api name vdec_av1_slice_get_relative_dist to 
vdec_av1_slice_get_sign_bias and return 0 or 1 for the caller directly use.
- add define AV1_PRIMARY_REF_NONE for magic number 7.
- remove TODO comment in vdec_av1_slice_update_core.
- change name irq to irq_enabled in struct vdec_av1_slice_instance.
- Add newline before return statememt in vdec_av1_slice_init and 
vdec_av1_slice_flush.
- remove work_buffer assignment and merge 3 loops with one in 
vdec_av1_slice_alloc_working_buffer.
- remove va null check in vdec_av1_slice_free_working_buffer.
- swap order between vdec_av1_slice_clear_fb and 
vdec_msg_queue_wait_lat_buf_full in vdec_av1_slice_flush.
- test by av1 fluster, result is 173/239

Changes from v6:

- change slot_id type from u8 to s8
- test by av1 fluster, result is 173/239

Changes from v5:

- change av1 PROFILE and LEVEL cfg
- test by av1 fluster, result is 173/239

Changes from v4:

- convert vb2_find_timestamp to vb2_find_buffer
- test by av1 fluster, result is 173/239

Changes from v3:

- modify comment for struct vdec_av1_slice_slot
- add define SEG_LVL_ALT_Q
- change use_lr/use_chroma_lr parse from av1 spec
- use ARRAY_SIZE to replace size for loop_filter_level and 
loop_filter_mode_deltas
- change array size of loop_filter_mode_deltas from 4 to 2
- add define SECONDARY_FILTER_STRENGTH_NUM_BITS
- change some hex values from upper case to lower case
- change *dpb_sz equal to V4L2_AV1_TOTAL_REFS_PER_FRAME + 1
- test by av1 fluster, result is 173/239

Changes from v2:

- Match with av1 uapi v3 modify
- test by av1 fluster, result is 173/239

---
Reference series:
[1]: v7 of this series is presend by Daniel Almeida.
 message-id: 20230306161850.492072-1-daniel.alme...@collabora.com

 .../media/platform/mediatek/vcodec/Makefile   |1 +
 .../vcodec/mtk_vcodec_dec_stateless.c |   47 +-
 .../platform/mediatek/vcodec/mtk_vcodec_drv.h |1 +
 .../vcodec/vdec/vdec_av1_req_lat_if.c | 2203 +
 .../platform/mediatek/vcodec/vdec_drv_if.c|4 +
 .../platform/mediatek/vcodec/vdec_drv_if.h|1 +
 .../platform/mediatek/vcodec/vdec_msg_queue.c |   27 +
 .../platform/mediatek/vcodec/vdec_msg_queue.h |4 +
 8 files changed, 2287 insertions(+), 1 deletion(-)
 create mode 100644 
drivers/media/platform/mediatek/vcodec/vdec/vdec_av1_req_lat_if.c

diff --git a/drivers/media/platform/mediatek/vcodec/Makefile 
b/drivers/media/platform/mediatek/vcodec/Makefile
index 93e7a343b5b0e..7537259130072 100644
--- a/drivers/media/platform/mediatek/vcodec/Makefile
+++ b/drivers/media/platform/mediatek/vcodec/Makefile
@@ -10,6 +10,7 @@ mtk-vcodec-dec-y := vdec/vdec_h264_if.o \
vdec/vdec_vp8_req_if.o \
vdec/vdec_vp9_if.o \
vdec/vdec_vp9_req_lat_if.o \
+   vdec/vdec_av1_req_lat_if.o \
vdec/vdec_h264_req_if.o \
vdec/vdec_h264_req_common.o \
vdec/vdec_h264_req_multi_if.o \
diff --git a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec_stateless.c 
b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec_stateless.c
index 04beb3f08eead..dbed52a5430de 100644
--- a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec_stateless.c
+++ b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec_stateless.c
@@ -107,11 +107,51 @@ static const struct mtk_stateless_control 
mtk_stateless_controls[] = {
},
.codec_type = V4L2_PIX_FMT_VP9_FRAME,
},
+   {
+   .cfg = {
+   .id = V4L2_CID_STATELESS_AV1_SEQUENCE,
+
+   },
+   .codec_type = V4L2_PIX_FMT_AV1_FRAME,
+   },
+   {
+   .cfg = {
+   .id = 

Re: [Freedreno] [PATCH] drm/msm/dpu: add DSC range checking during resource reservation

[Abhinav Kumar]

On 4/11/2023 6:06 PM, Dmitry Baryshkov wrote:

On 12/04/2023 01:32, Abhinav Kumar wrote:

Hi Marijn

On 4/11/2023 3:24 PM, Marijn Suijten wrote:

Again, don't forget to include previous reviewers in cc, please :)

On 2023-04-11 14:09:40, Kuogee Hsieh wrote:

Perform DSC range checking to make sure correct DSC is requested before
reserve resource for it.


nit: reserving



This isn't performing any range checking for resource reservations /
requests: this is only validating the constants written in our catalog
and seems rather useless.  It isn't fixing any real bug either, so the
Fixes: tag below seems extraneous.

Given prior comments from Abhinav that "the kernel should be trusted",
we should remove this validation for all the other blocks instead.



The purpose of this check is that today all our blocks in RM use the 
DSC_* enum as the size.


struct dpu_hw_blk *dsc_blks[DSC_MAX - DSC_0];

If the device tree ends up with more DSC blocks than the DSC_* enum, 
how can we avoid this issue today? Not because its a bug in device 
tree but how many static number of DSCs are hard-coded in RM.


We don't have these blocks in device tree. And dpu_hw_catalog shouldn't 
use indices outside of enum dpu_dsc.




ah, my bad, i should have said catalog here. Okay so the expectation is 
that dpu_hw_catalog.c will program the indices to match the RM limits.


I still stand by the fact that the hardware capabilities coming from 
catalog should be trusted but this is just the SW index.


Marijn proposed to pass struct dpu_foo_cfg directly to 
dpu_hw_foo_init(). This will allow us to drop these checks completely.




Ah okay, sure, would like to see that then uniformly get rid of these 
checks.


For the time being, I think it might be better to add these checks for 
DSC for the sake of uniformity.




Yes, i think so too.



And like you said, this is not specific to DSC. Such checks are 
present for other blocks too.



Fixes: c985d7bb64ff ("drm/msm/disp/dpu1: Add DSC support in RM")
Signed-off-by: Kuogee Hsieh 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 10 +-
  1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c

index f4dda88..95e58f1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -1,6 +1,7 @@
  // SPDX-License-Identifier: GPL-2.0-only
  /*
   * Copyright (c) 2016-2018, The Linux Foundation. All rights 
reserved.
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights 
reserved.

   */
  #define pr_fmt(fmt)    "[drm:%s] " fmt, __func__
@@ -250,6 +251,11 @@ int dpu_rm_init(struct dpu_rm *rm,
  struct dpu_hw_dsc *hw;
  const struct dpu_dsc_cfg *dsc = >dsc[i];
+    if (dsc->id < DSC_0 || dsc->id >= DSC_MAX) {
+    DPU_ERROR("skip dsc %d with invalid id\n", dsc->id);
+    continue;
+    }
+
  hw = dpu_hw_dsc_init(dsc->id, mmio, cat);
  if (IS_ERR_OR_NULL(hw)) {
  rc = PTR_ERR(hw);
@@ -557,8 +563,10 @@ static int _dpu_rm_make_reservation(
  }
  ret  = _dpu_rm_reserve_dsc(rm, global_state, enc, 
>topology);

-    if (ret)
+    if (ret) {
+    DPU_ERROR("unable to find appropriate DSC\n");


This, while a nice addition, should go in a different patch.


I'd agree here, a separate patch.



Thanks!

- Marijn


  return ret;
+    }
  return ret;
  }
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

a Linux Foundation Collaborative Project

Re: [PATCH v15 04/10] dt-bindings: display: bridge: anx7625: Add mode-switch support

[Stephen Boyd]

Quoting Pin-yen Lin (2023-03-31 02:11:39)
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml 
> b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> index b42553ac505c..604c7391d74f 100644
> --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> @@ -12,7 +12,8 @@ maintainers:
>
>  description: |
>The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
> -  designed for portable devices.
> +  designed for portable devices. Product brief is available at
> +  
> https://www.analogix.com/en/system/files/AA-002291-PB-6-ANX7625_ProductBrief.pdf
>
>  properties:
>compatible:
> @@ -112,9 +113,40 @@ properties:
>data-lanes: true
>
>port@1:
> -$ref: /schemas/graph.yaml#/properties/port
> +$ref: /schemas/graph.yaml#/$defs/port-base
>  description:
> -  Video port for panel or connector.
> +  Video port for panel or connector. Each endpoint connects to a 
> video
> +  output downstream, and the "data-lanes" property is used to 
> describe
> +  the pin connections. 0, 1, 2, 3 in "data-lanes" maps to SSRX1, 
> SSTX1,
> +  SSRX2, SSTX2, respectively.
> +
> +patternProperties:
> +  "^endpoint@[01]$":
> +$ref: /schemas/media/video-interfaces.yaml#
> +properties:
> +  reg: true
> +
> +  remote-endpoint: true
> +
> +  data-lanes:
> +oneOf:
> +  - items:
> +  - enum: [0, 1, 2, 3]
> +
> +  - items:
> +  - const: 0
> +  - const: 1
> +
> +  - items:
> +  - const: 2
> +  - const: 3
> +
> +  mode-switch:

Is it possible to not have this property? Can we have the driver for
this anx device look at the remote-endpoint and if it sees that it is
not a drm_bridge or panel on the other end, or a DP connector, that it
should register a typec mode switch (or two depending on the number of
endpoints in port@1)? Is there any case where that doesn't hold true?

I see these possible scenarios:

1. DPI to DP bridge steering DP to one of two usb-c-connectors

In this case, endpoint@0 is connected to one usb-c-connector and
endpoint@1 is connected to another usb-c-connector. The input endpoint
is only connected to DPI. The USB endpoint is not present (although I
don't see this described in the binding either, so we would need a
port@2, entirely optional to describe USB3 input). The driver will
register two mode switches.

2. DPI to DP bridge with USB3 to one usb-c-connector

In this case, endpoint@1 doesn't exist. The SSTX1/2 and SSRX1/2 pins are
all connected to a usb-c-connector node. The input ports (0 and 2) are
connected to both DPI and USB. The device acts as both a mode-switch and
an orientation-switch. It registers both switches. I wonder if there is
any benefit to describing SBU connections or CC connections? Maybe we
don't register the orientation-switch if the SBU or CC connection isn't
described?

3. DPI to DP bridge connected to eDP panel

In this case, endpoint@1 doesn't exist. The USB endpoint is not present
(port@2). Depending on how the crosspoint should be configured, we'll
need to use data-lanes in the port@1 endpoint to describe which SSTRX
pair to use (1 or 2). Or we'll have to use the endpoint's reg property
to describe which pair to drive DP on. Presumably the default
configuration is SSRX2/SSTX2 providing 2 lanes of DP to an eDP panel.
The endpoint@0 in port@1 will be connected to a drm_panel, and the
driver will be able to detect this properly by checking for the
existence of an aux-bus node or the return value of
of_dp_aux_populate_bus().

4. DPI to DP bridge connected to DP connector

This is similar to the eDP panel scenario #3. In this case, endpoint@1
doesn't exist. The USB endpoint is not present (port@2). Same story
about port@1 and lane configuration, but we don't have an aux-bus node.
In this case, the drivers/gpu/drm/bridge/display-connector.c driver will
probe for the dp-connector node and add a drm_bridge. This anx driver
will similarly add a drm_bridge, but it needs to look at the node
connected on port@1:endpoint@0 with drm_of_get_bridge() and check if it
is a drm_bridge (DP connector) or if it is some type-c thing (connector
or orientation-switch).

I think having this mode-switch property here lets us avoid calling
drm_of_get_bridge() unconditionally in anx7625_parse_dt().
drm_of_get_bridge() will always return -EPROBE_DEFER when this is the
last drm_bridge in the chain and the other side of the endpoint is a
type-c thing (scenarios #1 and #2). Maybe we should teach
drm_of_get_bridge() that a drm_bridge might be connected to a type-c
device and have it not return -EPROBE_DEFER in that case. Or make 

Re: [PATCH] drm/sun4i: uncouple DSI dotclock divider from TCON0_DCLK_REG

[Roman Beranek]

On Sat Apr 8, 2023 at 9:07 AM CEST, Jernej Škrabec wrote:
> Dne sreda, 05. april 2023 ob 14:34:11 CEST je Roman Beranek napisal(a):
> > While simply forbidding the video0-2x mux option seems
> > to me as the right way to go because there's not much use for it with
> > non-DSI interfaces either besides the opportunity to power pll-mipi
> > down, I'd like to run by you first.
>
> It's been a long time since I looked at A64 HDMI clocks, but IIRC, pll-video0 
> is the only useful source for HDMI PHY (as opposed to HDMI controller.)
> So question remains how to properly support both displays at the same time.
>

Correct.

> Have you ever tried to make HDMI and DSI work at the same time? This is one 
> of 
> issues of the PinePhone IIUC.
>

Yes, I have. Prusa3D's SL1 printer, on which I previously worked on,
uses both outputs simultaneously. I had encountered the same reparenting
problem back then but since I hadn't been able to identify it,
I resorted to fiddling with the DSI pixelclock until it worked. 

DSI & HDMI co-existence is yet another reasoni though for forbidding
the pll-video-2x parent. megi's kernel includes Mr. Zheng's commit which
does the same.



Best wishes
Roman Beranek

linux-next: manual merge of the drm tree with the powerpc tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm tree got a conflict in:

  drivers/gpu/drm/amd/display/Kconfig

between commit:

  78f0929884d4 ("powerpc/64: Always build with 128-bit long double")

from the powerpc tree and commit:

  4652ae7a51b7 ("drm/amd/display: Rename DCN config to FP")

from the drm tree.

I fixed it up (I used the powerpc version - with "(PPC64 && ALTIVEC)")
and can carry the fix as necessary. This is now fixed as far as
linux-next is concerned, but any non trivial conflicts should be
mentioned to your upstream maintainer when your tree is submitted for
merging.  You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgpNPtdh978tk.pgp
Description: OpenPGP digital signature

Re: [Freedreno] [PATCH] drm/msm/dpu: add DSC range checking during resource reservation

[Dmitry Baryshkov]

On 12/04/2023 01:32, Abhinav Kumar wrote:

Hi Marijn

On 4/11/2023 3:24 PM, Marijn Suijten wrote:

Again, don't forget to include previous reviewers in cc, please :)

On 2023-04-11 14:09:40, Kuogee Hsieh wrote:

Perform DSC range checking to make sure correct DSC is requested before
reserve resource for it.


nit: reserving



This isn't performing any range checking for resource reservations /
requests: this is only validating the constants written in our catalog
and seems rather useless.  It isn't fixing any real bug either, so the
Fixes: tag below seems extraneous.

Given prior comments from Abhinav that "the kernel should be trusted",
we should remove this validation for all the other blocks instead.



The purpose of this check is that today all our blocks in RM use the 
DSC_* enum as the size.


struct dpu_hw_blk *dsc_blks[DSC_MAX - DSC_0];

If the device tree ends up with more DSC blocks than the DSC_* enum, how 
can we avoid this issue today? Not because its a bug in device tree but 
how many static number of DSCs are hard-coded in RM.


We don't have these blocks in device tree. And dpu_hw_catalog shouldn't 
use indices outside of enum dpu_dsc.


Marijn proposed to pass struct dpu_foo_cfg directly to 
dpu_hw_foo_init(). This will allow us to drop these checks completely.


For the time being, I think it might be better to add these checks for 
DSC for the sake of uniformity.




And like you said, this is not specific to DSC. Such checks are present 
for other blocks too.



Fixes: c985d7bb64ff ("drm/msm/disp/dpu1: Add DSC support in RM")
Signed-off-by: Kuogee Hsieh 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 10 +-
  1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c

index f4dda88..95e58f1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -1,6 +1,7 @@
  // SPDX-License-Identifier: GPL-2.0-only
  /*
   * Copyright (c) 2016-2018, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights 
reserved.

   */
  #define pr_fmt(fmt)    "[drm:%s] " fmt, __func__
@@ -250,6 +251,11 @@ int dpu_rm_init(struct dpu_rm *rm,
  struct dpu_hw_dsc *hw;
  const struct dpu_dsc_cfg *dsc = >dsc[i];
+    if (dsc->id < DSC_0 || dsc->id >= DSC_MAX) {
+    DPU_ERROR("skip dsc %d with invalid id\n", dsc->id);
+    continue;
+    }
+
  hw = dpu_hw_dsc_init(dsc->id, mmio, cat);
  if (IS_ERR_OR_NULL(hw)) {
  rc = PTR_ERR(hw);
@@ -557,8 +563,10 @@ static int _dpu_rm_make_reservation(
  }
  ret  = _dpu_rm_reserve_dsc(rm, global_state, enc, 
>topology);

-    if (ret)
+    if (ret) {
+    DPU_ERROR("unable to find appropriate DSC\n");


This, while a nice addition, should go in a different patch.


I'd agree here, a separate patch.



Thanks!

- Marijn


  return ret;
+    }
  return ret;
  }
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

a Linux Foundation Collaborative Project



--
With best wishes
Dmitry

[PATCH v2] drm/display: Add missing OLED Vesa brightnesses definitions

[Rodrigo Siqueira]

This commit adds missing luminance control registers to enable a more
standard way (VESA) to deal with eDP luminance control.

Cc: Anthony Koo 
Cc: Iswara Negulendran 
Cc: Felipe Clark 
Cc: Harry Wentland 
Signed-off-by: Rodrigo Siqueira 
---
 include/drm/display/drm_dp.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index ed10e6b6f99d..7ad749423a48 100644
--- a/include/drm/display/drm_dp.h
+++ b/include/drm/display/drm_dp.h
@@ -973,6 +973,7 @@
 
 #define DP_EDP_GENERAL_CAP_2   0x703
 # define DP_EDP_OVERDRIVE_ENGINE_ENABLED   (1 << 0)
+# define DP_EDP_PANEL_LUMINANCE_CONTROL_CAPABLE(1<<4)
 
 #define DP_EDP_GENERAL_CAP_3   0x704/* eDP 1.4 */
 # define DP_EDP_X_REGION_CAP_MASK  (0xf << 0)
@@ -998,6 +999,7 @@
 # define DP_EDP_DYNAMIC_BACKLIGHT_ENABLE   (1 << 4)
 # define DP_EDP_REGIONAL_BACKLIGHT_ENABLE  (1 << 5)
 # define DP_EDP_UPDATE_REGION_BRIGHTNESS   (1 << 6) /* eDP 1.4 */
+# define DP_EDP_PANEL_LUMINANCE_CONTROL_ENABLE (1<<7)
 
 #define DP_EDP_BACKLIGHT_BRIGHTNESS_MSB 0x722
 #define DP_EDP_BACKLIGHT_BRIGHTNESS_LSB 0x723
@@ -1022,6 +1024,7 @@
 
 #define DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET   0x732
 #define DP_EDP_DBC_MAXIMUM_BRIGHTNESS_SET   0x733
+#define DP_EDP_PANEL_TARGET_LUMINANCE_VALUE 0x734
 
 #define DP_EDP_REGIONAL_BACKLIGHT_BASE  0x740/* eDP 1.4 */
 #define DP_EDP_REGIONAL_BACKLIGHT_00x741/* eDP 1.4 */
-- 
2.39.2

Re: [PATCH] drm/msm/dpu: always program dsc active bits

[Abhinav Kumar]

On 4/11/2023 3:14 PM, Marijn Suijten wrote:

Full-caps DSC in the title, as discussed previously.

On that note, don't forget to CC those who have reviewed your patches
previously, as also brought up in earlier review.

On 2023-04-11 14:04:55, Kuogee Hsieh wrote:

In current code, the dsc active bits are set only if the cfg->dsc is set.


Some typo nits:

DSC* active bits.

s/are set/are written/ (the variable is set, registers are written).

Drop `the` before `cfg->dsc` (and you could replace `s/is set/is
non-zero/).


However, for displays which are hot-pluggable, there can be a use-case
of disconnecting a DSC supported sink and connecting a non-DSC sink.

For those cases we need to clear DSC active bits during teardown.

Fixes: ede3c6bb00c ("drm/msm/disp/dpu1: Add DSC support in hw_ctl")
Signed-off-by: Kuogee Hsieh 


If you have validated that it is fine to write these registers on
_every_ platform supported by DPU1, and after fixing the above nits and
the Fixes: commit hash as pointed out by Abhinav:

Reviewed-by: Marijn Suijten 

And see one question below.


---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index bbdc95c..88e4efe 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -541,10 +541,9 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl *ctx,
if (cfg->merge_3d)
DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
  BIT(cfg->merge_3d - MERGE_3D_0));
-   if (cfg->dsc) {
-   DPU_REG_WRITE(>hw, CTL_FLUSH, DSC_IDX);
-   DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
-   }
+
+   DPU_REG_WRITE(>hw, CTL_FLUSH, DSC_IDX);


Does this flush all DSCs programmed in CTL_DSC_FLUSH as set above?  That
is currently still in `if (cfg->dsc)` and never overwritten if all DSCs
are disabled, should it be taken out of the `if` to make sure no DSCs
are inadvertently flushed, or otherwise cache the "previous mask" to
make sure we flush exactly the right DSC blocks?



Yes, DSC flush is hierarchical. This is the main DSC flush which will 
enforce the flush of the DSC's we are trying to flush in the 
CTL_DSC_FLUSH register.


So if DSC was active, the CTL_FLUSH will only enforce the flush of the 
DSC's programmed in CTL_DSC_FLUSH


If DSC is not active, we still need to flush that as well (that was the 
missing bit).


No need to cache previous mask. That programming should be accurate in 
cfg->dsc already.



Thanks!

- Marijn


+   DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
  }
  
  static void dpu_hw_ctl_intf_cfg(struct dpu_hw_ctl *ctx,

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] drm/msm/dpu: always program dsc active bits

[Dmitry Baryshkov]

On 12/04/2023 02:32, Abhinav Kumar wrote:



On 4/11/2023 3:17 PM, Dmitry Baryshkov wrote:

On 12/04/2023 00:04, Kuogee Hsieh wrote:
In current code, the dsc active bits are set only if the cfg->dsc is 
set.

However, for displays which are hot-pluggable, there can be a use-case
of disconnecting a DSC supported sink and connecting a non-DSC sink.

For those cases we need to clear DSC active bits during teardown.


Please correct me if I'm wrong here, shouldn't we start using 
reset_intf_cfg() during teardown / unplug?




This is actually a good point. Since PSR landed this cycle, we are doing 
dpu_encoder_helper_phys_cleanup() even for video mode path,


22cb02bc96ff ("drm/msm/disp/dpu: reset the datapath after timing engine 
disable")


I was doing it only for writeback path as I had not validated video mode 
enough with the dpu_encoder_helper_phys_cleanup() API.


But looking closely, I think there is an issue with the flush logic in 
that API for video mode.


The reset API, calls a ctl->ops.trigger_flush(ctl); but its getting 
called after timing engine turns off today so this wont take any effect.


We need to improve that API and add the missing pieces for it to work 
correctly with video mode and re-validate the issue for which PSR made 
that change. So needs more work there.


This change works because the timing engine is enabled right after this 
call and will trigger the flush with it.


The only drawback of this change is DSC_ACTIVE will always get written 
to either with 0 or the right value but only once during enable.


I think this change is fine till we finish the rest of the pieces. We 
can add the if (cfg->dsc) back to this when we fix the reset_intf_cfg() 
to handle DSC and dpu_encoder_helper_phys_cleanup() to handle flush 
correctly.


I'd agree here. Then a FIXME comment would be nice.



I will take up that work.



Fixes: ede3c6bb00c ("drm/msm/disp/dpu1: Add DSC support in hw_ctl")
Signed-off-by: Kuogee Hsieh 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c

index bbdc95c..88e4efe 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -541,10 +541,9 @@ static void dpu_hw_ctl_intf_cfg_v1(struct 
dpu_hw_ctl *ctx,

  if (cfg->merge_3d)
  DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
    BIT(cfg->merge_3d - MERGE_3D_0));
-    if (cfg->dsc) {
-    DPU_REG_WRITE(>hw, CTL_FLUSH, DSC_IDX);
-    DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
-    }
+
+    DPU_REG_WRITE(>hw, CTL_FLUSH, DSC_IDX);
+    DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
  }
  static void dpu_hw_ctl_intf_cfg(struct dpu_hw_ctl *ctx,




--
With best wishes
Dmitry

Re: [PATCH] drm/msm/dpu: always program dsc active bits

[Abhinav Kumar]

On 4/11/2023 3:17 PM, Dmitry Baryshkov wrote:

On 12/04/2023 00:04, Kuogee Hsieh wrote:

In current code, the dsc active bits are set only if the cfg->dsc is set.
However, for displays which are hot-pluggable, there can be a use-case
of disconnecting a DSC supported sink and connecting a non-DSC sink.

For those cases we need to clear DSC active bits during teardown.


Please correct me if I'm wrong here, shouldn't we start using 
reset_intf_cfg() during teardown / unplug?




This is actually a good point. Since PSR landed this cycle, we are doing 
dpu_encoder_helper_phys_cleanup() even for video mode path,


22cb02bc96ff ("drm/msm/disp/dpu: reset the datapath after timing engine 
disable")


I was doing it only for writeback path as I had not validated video mode 
enough with the dpu_encoder_helper_phys_cleanup() API.


But looking closely, I think there is an issue with the flush logic in 
that API for video mode.


The reset API, calls a ctl->ops.trigger_flush(ctl); but its getting 
called after timing engine turns off today so this wont take any effect.


We need to improve that API and add the missing pieces for it to work 
correctly with video mode and re-validate the issue for which PSR made 
that change. So needs more work there.


This change works because the timing engine is enabled right after this 
call and will trigger the flush with it.


The only drawback of this change is DSC_ACTIVE will always get written 
to either with 0 or the right value but only once during enable.


I think this change is fine till we finish the rest of the pieces. We 
can add the if (cfg->dsc) back to this when we fix the reset_intf_cfg() 
to handle DSC and dpu_encoder_helper_phys_cleanup() to handle flush 
correctly.


I will take up that work.



Fixes: ede3c6bb00c ("drm/msm/disp/dpu1: Add DSC support in hw_ctl")
Signed-off-by: Kuogee Hsieh 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c

index bbdc95c..88e4efe 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -541,10 +541,9 @@ static void dpu_hw_ctl_intf_cfg_v1(struct 
dpu_hw_ctl *ctx,

  if (cfg->merge_3d)
  DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
    BIT(cfg->merge_3d - MERGE_3D_0));
-    if (cfg->dsc) {
-    DPU_REG_WRITE(>hw, CTL_FLUSH, DSC_IDX);
-    DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
-    }
+
+    DPU_REG_WRITE(>hw, CTL_FLUSH, DSC_IDX);
+    DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
  }
  static void dpu_hw_ctl_intf_cfg(struct dpu_hw_ctl *ctx,

Re: [PATCH v9 04/10] drm/hdcp: Expand HDCP helper library for enable/disable/check

[kernel test robot]

Hi Mark,

kernel test robot noticed the following build warnings:

[auto build test WARNING on drm-intel/for-linux-next-fixes]
[also build test WARNING on drm/drm-next linus/master v6.3-rc6 next-20230411]
[cannot apply to drm-tip/drm-tip drm-misc/drm-misc-next 
drm-intel/for-linux-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Mark-Yacoub/drm-hdcp-Add-drm_hdcp_atomic_check/20230412-032412
base:   git://anongit.freedesktop.org/drm-intel for-linux-next-fixes
patch link:
https://lore.kernel.org/r/20230411192134.508113-5-markyacoub%40google.com
patch subject: [PATCH v9 04/10] drm/hdcp: Expand HDCP helper library for 
enable/disable/check
config: m68k-allyesconfig 
(https://download.01.org/0day-ci/archive/20230412/202304120709.of7bkzuf-...@intel.com/config)
compiler: m68k-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/intel-lab-lkp/linux/commit/972a98f65fb56b3be4370593c2b81f1283750db7
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Mark-Yacoub/drm-hdcp-Add-drm_hdcp_atomic_check/20230412-032412
git checkout 972a98f65fb56b3be4370593c2b81f1283750db7
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 
O=build_dir ARCH=m68k olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 
O=build_dir ARCH=m68k SHELL=/bin/bash drivers/gpu/drm/display/

If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot 
| Link: 
https://lore.kernel.org/oe-kbuild-all/202304120709.of7bkzuf-...@intel.com/

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/display/drm_hdcp_helper.c:675:5: warning: no previous 
>> prototype for 'drm_hdcp_helper_hdcp1_capable_dp' [-Wmissing-prototypes]
 675 | int drm_hdcp_helper_hdcp1_capable_dp(struct drm_hdcp_helper_data 
*data,
 | ^~~~
>> drivers/gpu/drm/display/drm_hdcp_helper.c:1325:5: warning: no previous 
>> prototype for 'drm_hdcp_hdcp1_check_link_registers_dp' [-Wmissing-prototypes]
1325 | int drm_hdcp_hdcp1_check_link_registers_dp(struct drm_device *dev,
 | ^~


vim +/drm_hdcp_helper_hdcp1_capable_dp +675 
drivers/gpu/drm/display/drm_hdcp_helper.c

   674  
 > 675  int drm_hdcp_helper_hdcp1_capable_dp(struct drm_hdcp_helper_data *data,
   676   bool *capable)
   677  {
   678  int ret;
   679  u8 bcaps;
   680  
   681  ret = data->display_type_funcs->remote_read(
   682  data, data->hdcp1_lut->bcaps, , 1);
   683  *capable = !ret && (bcaps & DP_BCAPS_HDCP_CAPABLE);
   684  
   685  return 0;
   686  }
   687  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests

[PATCH v3 7/7] drm/msm: Add memory stats to fdinfo

[Rob Clark]

From: Rob Clark 

Use the new helper to export stats about memory usage.

v2: Drop unintended hunk
v3: Rebase

Signed-off-by: Rob Clark 
Reviewed-by: Emil Velikov 
---
 drivers/gpu/drm/msm/msm_gem.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index db6c4e281d75..c32264234ea1 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -1096,6 +1096,20 @@ int msm_gem_new_handle(struct drm_device *dev, struct 
drm_file *file,
return ret;
 }
 
+static enum drm_gem_object_status msm_gem_status(struct drm_gem_object *obj)
+{
+   struct msm_gem_object *msm_obj = to_msm_bo(obj);
+   enum drm_gem_object_status status = 0;
+
+   if (msm_obj->pages)
+   status |= DRM_GEM_OBJECT_RESIDENT;
+
+   if (msm_obj->madv == MSM_MADV_DONTNEED)
+   status |= DRM_GEM_OBJECT_PURGEABLE;
+
+   return status;
+}
+
 static const struct vm_operations_struct vm_ops = {
.fault = msm_gem_fault,
.open = drm_gem_vm_open,
@@ -1110,6 +1124,7 @@ static const struct drm_gem_object_funcs 
msm_gem_object_funcs = {
.vmap = msm_gem_prime_vmap,
.vunmap = msm_gem_prime_vunmap,
.mmap = msm_gem_object_mmap,
+   .status = msm_gem_status,
.vm_ops = _ops,
 };
 
-- 
2.39.2

[PATCH v3 6/7] drm: Add fdinfo memory stats

[Rob Clark]

From: Rob Clark 

Add support to dump GEM stats to fdinfo.

v2: Fix typos, change size units to match docs, use div_u64
v3: Do it in core

Signed-off-by: Rob Clark 
Reviewed-by: Emil Velikov 
---
 Documentation/gpu/drm-usage-stats.rst | 21 
 drivers/gpu/drm/drm_file.c| 76 +++
 include/drm/drm_file.h|  1 +
 include/drm/drm_gem.h | 19 +++
 4 files changed, 117 insertions(+)

diff --git a/Documentation/gpu/drm-usage-stats.rst 
b/Documentation/gpu/drm-usage-stats.rst
index b46327356e80..b5e7802532ed 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -105,6 +105,27 @@ object belong to this client, in the respective memory 
region.
 Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
 indicating kibi- or mebi-bytes.
 
+- drm-shared-memory:  [KiB|MiB]
+
+The total size of buffers that are shared with another file (ie. have more
+than a single handle).
+
+- drm-private-memory:  [KiB|MiB]
+
+The total size of buffers that are not shared with another file.
+
+- drm-resident-memory:  [KiB|MiB]
+
+The total size of buffers that are resident in system memory.
+
+- drm-purgeable-memory:  [KiB|MiB]
+
+The total size of buffers that are purgeable.
+
+- drm-active-memory:  [KiB|MiB]
+
+The total size of buffers that are active on one or more rings.
+
 - drm-cycles- 
 
 Engine identifier string must be the same as the one specified in the
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 37dfaa6be560..46fdd843bb3a 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "drm_crtc_internal.h"
@@ -871,6 +872,79 @@ void drm_send_event(struct drm_device *dev, struct 
drm_pending_event *e)
 }
 EXPORT_SYMBOL(drm_send_event);
 
+static void print_size(struct drm_printer *p, const char *stat, size_t sz)
+{
+   const char *units[] = {"", " KiB", " MiB"};
+   unsigned u;
+
+   for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
+   if (sz < SZ_1K)
+   break;
+   sz = div_u64(sz, SZ_1K);
+   }
+
+   drm_printf(p, "%s:\t%zu%s\n", stat, sz, units[u]);
+}
+
+static void print_memory_stats(struct drm_printer *p, struct drm_file *file)
+{
+   struct drm_gem_object *obj;
+   struct {
+   size_t shared;
+   size_t private;
+   size_t resident;
+   size_t purgeable;
+   size_t active;
+   } size = {0};
+   bool has_status = false;
+   int id;
+
+   spin_lock(>table_lock);
+   idr_for_each_entry (>object_idr, obj, id) {
+   enum drm_gem_object_status s = 0;
+
+   if (obj->funcs && obj->funcs->status) {
+   s = obj->funcs->status(obj);
+   has_status = true;
+   }
+
+   if (obj->handle_count > 1) {
+   size.shared += obj->size;
+   } else {
+   size.private += obj->size;
+   }
+
+   if (s & DRM_GEM_OBJECT_RESIDENT) {
+   size.resident += obj->size;
+   } else {
+   /* If already purged or not yet backed by pages, don't
+* count it as purgeable:
+*/
+   s &= ~DRM_GEM_OBJECT_PURGEABLE;
+   }
+
+   if (!dma_resv_test_signaled(obj->resv, 
dma_resv_usage_rw(true))) {
+   size.active += obj->size;
+
+   /* If still active, don't count as purgeable: */
+   s &= ~DRM_GEM_OBJECT_PURGEABLE;
+   }
+
+   if (s & DRM_GEM_OBJECT_PURGEABLE)
+   size.purgeable += obj->size;
+   }
+   spin_unlock(>table_lock);
+
+   print_size(p, "drm-shared-memory", size.shared);
+   print_size(p, "drm-private-memory", size.private);
+   print_size(p, "drm-active-memory", size.active);
+
+   if (has_status) {
+   print_size(p, "drm-resident-memory", size.resident);
+   print_size(p, "drm-purgeable-memory", size.purgeable);
+   }
+}
+
 /**
  * drm_fop_show_fdinfo - helper for drm file fops
  * @seq_file: output stream
@@ -904,6 +978,8 @@ void drm_fop_show_fdinfo(struct seq_file *m, struct file *f)
 
if (dev->driver->show_fdinfo)
dev->driver->show_fdinfo(, file);
+
+   print_memory_stats(, file);
 }
 EXPORT_SYMBOL(drm_fop_show_fdinfo);
 
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index dfa995b787e1..e5b40084538f 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -41,6 +41,7 @@
 struct dma_fence;
 struct drm_file;
 struct drm_device;
+struct drm_printer;
 struct device;
 struct file;
 
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h

[PATCH v3 5/7] drm/etnaviv: Switch to fdinfo helper

[Rob Clark]

From: Rob Clark 

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 44ca803237a5..17d6af94 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -476,9 +476,8 @@ static const struct drm_ioctl_desc etnaviv_ioctls[] = {
ETNA_IOCTL(PM_QUERY_SIG, pm_query_sig, DRM_RENDER_ALLOW),
 };
 
-static void etnaviv_fop_show_fdinfo(struct seq_file *m, struct file *f)
+static void etnaviv_fop_show_fdinfo(struct drm_printer *p, struct drm_file 
*file)
 {
-   struct drm_file *file = f->private_data;
struct drm_device *dev = file->minor->dev;
struct etnaviv_drm_private *priv = dev->dev_private;
struct etnaviv_file_private *ctx = file->driver_priv;
@@ -487,8 +486,6 @@ static void etnaviv_fop_show_fdinfo(struct seq_file *m, 
struct file *f)
 * For a description of the text output format used here, see
 * Documentation/gpu/drm-usage-stats.rst.
 */
-   seq_printf(m, "drm-driver:\t%s\n", dev->driver->name);
-   seq_printf(m, "drm-client-id:\t%u\n", ctx->id);
 
for (int i = 0; i < ETNA_MAX_PIPES; i++) {
struct etnaviv_gpu *gpu = priv->gpu[i];
@@ -507,7 +504,7 @@ static void etnaviv_fop_show_fdinfo(struct seq_file *m, 
struct file *f)
cur = snprintf(engine + cur, sizeof(engine) - cur,
   "%sNN", cur ? "/" : "");
 
-   seq_printf(m, "drm-engine-%s:\t%llu ns\n", engine,
+   drm_printf(p, "drm-engine-%s:\t%llu ns\n", engine,
   ctx->sched_entity[i].elapsed_ns);
}
 }
@@ -515,7 +512,7 @@ static void etnaviv_fop_show_fdinfo(struct seq_file *m, 
struct file *f)
 static const struct file_operations fops = {
.owner = THIS_MODULE,
DRM_GEM_FOPS,
-   .show_fdinfo = etnaviv_fop_show_fdinfo,
+   .show_fdinfo = drm_fop_show_fdinfo,
 };
 
 static const struct drm_driver etnaviv_drm_driver = {
@@ -529,6 +526,7 @@ static const struct drm_driver etnaviv_drm_driver = {
 #ifdef CONFIG_DEBUG_FS
.debugfs_init   = etnaviv_debugfs_init,
 #endif
+   .show_fdinfo= etnaviv_fop_show_fdinfo,
.ioctls = etnaviv_ioctls,
.num_ioctls = DRM_ETNAVIV_NUM_IOCTLS,
.fops   = ,
-- 
2.39.2

[PATCH v3 4/7] drm/i915: Switch to fdinfo helper

[Rob Clark]

From: Rob Clark 

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/i915/i915_driver.c |  3 ++-
 drivers/gpu/drm/i915/i915_drm_client.c | 18 +-
 drivers/gpu/drm/i915/i915_drm_client.h |  2 +-
 3 files changed, 8 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index db7a86def7e2..37eacaa3064b 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1696,7 +1696,7 @@ static const struct file_operations i915_driver_fops = {
.compat_ioctl = i915_ioc32_compat_ioctl,
.llseek = noop_llseek,
 #ifdef CONFIG_PROC_FS
-   .show_fdinfo = i915_drm_client_fdinfo,
+   .show_fdinfo = drm_fop_show_fdinfo,
 #endif
 };
 
@@ -1796,6 +1796,7 @@ static const struct drm_driver i915_drm_driver = {
.open = i915_driver_open,
.lastclose = i915_driver_lastclose,
.postclose = i915_driver_postclose,
+   .show_fdinfo = i915_drm_client_fdinfo,
 
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c 
b/drivers/gpu/drm/i915/i915_drm_client.c
index b09d1d386574..4a77e5e47f79 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -101,7 +101,7 @@ static u64 busy_add(struct i915_gem_context *ctx, unsigned 
int class)
 }
 
 static void
-show_client_class(struct seq_file *m,
+show_client_class(struct drm_printer *p,
  struct i915_drm_client *client,
  unsigned int class)
 {
@@ -117,22 +117,20 @@ show_client_class(struct seq_file *m,
rcu_read_unlock();
 
if (capacity)
-   seq_printf(m, "drm-engine-%s:\t%llu ns\n",
+   drm_printf(p, "drm-engine-%s:\t%llu ns\n",
   uabi_class_names[class], total);
 
if (capacity > 1)
-   seq_printf(m, "drm-engine-capacity-%s:\t%u\n",
+   drm_printf(p, "drm-engine-capacity-%s:\t%u\n",
   uabi_class_names[class],
   capacity);
 }
 
-void i915_drm_client_fdinfo(struct seq_file *m, struct file *f)
+void i915_drm_client_fdinfo(struct drm_printer *p, struct drm_file *file)
 {
-   struct drm_file *file = f->private_data;
struct drm_i915_file_private *file_priv = file->driver_priv;
struct drm_i915_private *i915 = file_priv->dev_priv;
struct i915_drm_client *client = file_priv->client;
-   struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
unsigned int i;
 
/*
@@ -141,12 +139,6 @@ void i915_drm_client_fdinfo(struct seq_file *m, struct 
file *f)
 * **
 */
 
-   seq_printf(m, "drm-driver:\t%s\n", i915->drm.driver->name);
-   seq_printf(m, "drm-pdev:\t%04x:%02x:%02x.%d\n",
-  pci_domain_nr(pdev->bus), pdev->bus->number,
-  PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
-   seq_printf(m, "drm-client-id:\t%u\n", client->id);
-
/*
 * Temporarily skip showing client engine information with GuC 
submission till
 * fetching engine busyness is implemented in the GuC submission backend
@@ -155,6 +147,6 @@ void i915_drm_client_fdinfo(struct seq_file *m, struct file 
*f)
return;
 
for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++)
-   show_client_class(m, client, i);
+   show_client_class(p, client, i);
 }
 #endif
diff --git a/drivers/gpu/drm/i915/i915_drm_client.h 
b/drivers/gpu/drm/i915/i915_drm_client.h
index 69496af996d9..ef85fef45de5 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.h
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -60,7 +60,7 @@ static inline void i915_drm_client_put(struct i915_drm_client 
*client)
 struct i915_drm_client *i915_drm_client_add(struct i915_drm_clients *clients);
 
 #ifdef CONFIG_PROC_FS
-void i915_drm_client_fdinfo(struct seq_file *m, struct file *f);
+void i915_drm_client_fdinfo(struct drm_printer *p, struct drm_file *file);
 #endif
 
 void i915_drm_clients_fini(struct i915_drm_clients *clients);
-- 
2.39.2

[PATCH v3 3/7] drm/amdgpu: Switch to fdinfo helper

[Rob Clark]

From: Rob Clark 

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  3 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 16 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h |  2 +-
 3 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index f5ffca24def4..3611cfd5f076 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -2752,7 +2752,7 @@ static const struct file_operations 
amdgpu_driver_kms_fops = {
.compat_ioctl = amdgpu_kms_compat_ioctl,
 #endif
 #ifdef CONFIG_PROC_FS
-   .show_fdinfo = amdgpu_show_fdinfo
+   .show_fdinfo = drm_fop_show_fdinfo,
 #endif
 };
 
@@ -2807,6 +2807,7 @@ static const struct drm_driver amdgpu_kms_driver = {
.dumb_map_offset = amdgpu_mode_dumb_mmap,
.fops = _driver_kms_fops,
.release = _driver_release_kms,
+   .show_fdinfo = amdgpu_show_fdinfo,
 
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
index 99a7855ab1bc..c2fdd5e448d1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
@@ -53,9 +53,8 @@ static const char *amdgpu_ip_name[AMDGPU_HW_IP_NUM] = {
[AMDGPU_HW_IP_VCN_JPEG] =   "jpeg",
 };
 
-void amdgpu_show_fdinfo(struct seq_file *m, struct file *f)
+void amdgpu_show_fdinfo(struct drm_printer *p, struct drm_file *file)
 {
-   struct drm_file *file = f->private_data;
struct amdgpu_device *adev = drm_to_adev(file->minor->dev);
struct amdgpu_fpriv *fpriv = file->driver_priv;
struct amdgpu_vm *vm = >vm;
@@ -86,18 +85,15 @@ void amdgpu_show_fdinfo(struct seq_file *m, struct file *f)
 * **
 */
 
-   seq_printf(m, "pasid:\t%u\n", fpriv->vm.pasid);
-   seq_printf(m, "drm-driver:\t%s\n", file->minor->dev->driver->name);
-   seq_printf(m, "drm-pdev:\t%04x:%02x:%02x.%d\n", domain, bus, dev, fn);
-   seq_printf(m, "drm-client-id:\t%Lu\n", vm->immediate.fence_context);
-   seq_printf(m, "drm-memory-vram:\t%llu KiB\n", vram_mem/1024UL);
-   seq_printf(m, "drm-memory-gtt: \t%llu KiB\n", gtt_mem/1024UL);
-   seq_printf(m, "drm-memory-cpu: \t%llu KiB\n", cpu_mem/1024UL);
+   drm_printf(p, "pasid:\t%u\n", fpriv->vm.pasid);
+   drm_printf(p, "drm-memory-vram:\t%llu KiB\n", vram_mem/1024UL);
+   drm_printf(p, "drm-memory-gtt: \t%llu KiB\n", gtt_mem/1024UL);
+   drm_printf(p, "drm-memory-cpu: \t%llu KiB\n", cpu_mem/1024UL);
for (hw_ip = 0; hw_ip < AMDGPU_HW_IP_NUM; ++hw_ip) {
if (!usage[hw_ip])
continue;
 
-   seq_printf(m, "drm-engine-%s:\t%Ld ns\n", amdgpu_ip_name[hw_ip],
+   drm_printf(p, "drm-engine-%s:\t%Ld ns\n", amdgpu_ip_name[hw_ip],
   ktime_to_ns(usage[hw_ip]));
}
 }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h
index e86834bfea1d..0398f5a159ef 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h
@@ -37,6 +37,6 @@
 #include "amdgpu_ids.h"
 
 uint32_t amdgpu_get_ip_count(struct amdgpu_device *adev, int id);
-void amdgpu_show_fdinfo(struct seq_file *m, struct file *f);
+void amdgpu_show_fdinfo(struct drm_printer *p, struct drm_file *file);
 
 #endif
-- 
2.39.2

[PATCH v3 1/7] drm: Add common fdinfo helper

[Rob Clark]

From: Rob Clark 

Handle a bit of the boiler-plate in a single case, and make it easier to
add some core tracked stats.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_file.c | 39 ++
 include/drm/drm_drv.h  |  7 +++
 include/drm/drm_file.h |  4 
 3 files changed, 50 insertions(+)

diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index a51ff8cee049..37dfaa6be560 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -148,6 +148,7 @@ bool drm_dev_needs_global_mutex(struct drm_device *dev)
  */
 struct drm_file *drm_file_alloc(struct drm_minor *minor)
 {
+   static atomic_t ident = ATOMIC_INIT(0);
struct drm_device *dev = minor->dev;
struct drm_file *file;
int ret;
@@ -156,6 +157,8 @@ struct drm_file *drm_file_alloc(struct drm_minor *minor)
if (!file)
return ERR_PTR(-ENOMEM);
 
+   /* Get a unique identifier for fdinfo: */
+   file->client_id = atomic_inc_return() - 1;
file->pid = get_pid(task_pid(current));
file->minor = minor;
 
@@ -868,6 +871,42 @@ void drm_send_event(struct drm_device *dev, struct 
drm_pending_event *e)
 }
 EXPORT_SYMBOL(drm_send_event);
 
+/**
+ * drm_fop_show_fdinfo - helper for drm file fops
+ * @seq_file: output stream
+ * @f: the device file instance
+ *
+ * Helper to implement fdinfo, for userspace to query usage stats, etc, of a
+ * process using the GPU.
+ */
+void drm_fop_show_fdinfo(struct seq_file *m, struct file *f)
+{
+   struct drm_file *file = f->private_data;
+   struct drm_device *dev = file->minor->dev;
+   struct drm_printer p = drm_seq_file_printer(m);
+
+   /*
+* **
+* For text output format description please see drm-usage-stats.rst!
+* **
+*/
+
+   drm_printf(, "drm-driver:\t%s\n", dev->driver->name);
+   drm_printf(, "drm-client-id:\t%u\n", file->client_id);
+
+   if (dev_is_pci(dev->dev)) {
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
+
+   drm_printf(, "drm-pdev:\t%04x:%02x:%02x.%d\n",
+  pci_domain_nr(pdev->bus), pdev->bus->number,
+  PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
+   }
+
+   if (dev->driver->show_fdinfo)
+   dev->driver->show_fdinfo(, file);
+}
+EXPORT_SYMBOL(drm_fop_show_fdinfo);
+
 /**
  * mock_drm_getfile - Create a new struct file for the drm device
  * @minor: drm minor to wrap (e.g. #drm_device.primary)
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 5b86bb7603e7..a883c6d3bcdf 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -401,6 +401,13 @@ struct drm_driver {
   struct drm_device *dev, uint32_t handle,
   uint64_t *offset);
 
+   /**
+* @fdinfo:
+*
+* Print device specific fdinfo.  See drm-usage-stats.rst.
+*/
+   void (*show_fdinfo)(struct drm_printer *p, struct drm_file *f);
+
/** @major: driver major number */
int major;
/** @minor: driver minor number */
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 0d1f853092ab..dfa995b787e1 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -258,6 +258,9 @@ struct drm_file {
/** @pid: Process that opened this file. */
struct pid *pid;
 
+   /** @client_id: A unique id for fdinfo */
+   u32 client_id;
+
/** @magic: Authentication magic, see @authenticated. */
drm_magic_t magic;
 
@@ -437,6 +440,7 @@ void drm_send_event(struct drm_device *dev, struct 
drm_pending_event *e);
 void drm_send_event_timestamp_locked(struct drm_device *dev,
 struct drm_pending_event *e,
 ktime_t timestamp);
+void drm_fop_show_fdinfo(struct seq_file *m, struct file *f);
 
 struct file *mock_drm_getfile(struct drm_minor *minor, unsigned int flags);
 
-- 
2.39.2

[PATCH v3 2/7] drm/msm: Switch to fdinfo helper

[Rob Clark]

From: Rob Clark 

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/msm_drv.c | 11 +--
 drivers/gpu/drm/msm/msm_gpu.c |  2 --
 2 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 5a10d28de9dd..e516a3544505 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1043,23 +1043,21 @@ static const struct drm_ioctl_desc msm_ioctls[] = {
DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_QUERY, msm_ioctl_submitqueue_query, 
DRM_RENDER_ALLOW),
 };
 
-static void msm_fop_show_fdinfo(struct seq_file *m, struct file *f)
+static void msm_show_fdinfo(struct drm_printer *p, struct drm_file *file)
 {
-   struct drm_file *file = f->private_data;
struct drm_device *dev = file->minor->dev;
struct msm_drm_private *priv = dev->dev_private;
-   struct drm_printer p = drm_seq_file_printer(m);
 
if (!priv->gpu)
return;
 
-   msm_gpu_show_fdinfo(priv->gpu, file->driver_priv, );
+   msm_gpu_show_fdinfo(priv->gpu, file->driver_priv, p);
 }
 
 static const struct file_operations fops = {
.owner = THIS_MODULE,
DRM_GEM_FOPS,
-   .show_fdinfo = msm_fop_show_fdinfo,
+   .show_fdinfo = drm_fop_show_fdinfo,
 };
 
 static const struct drm_driver msm_driver = {
@@ -1070,7 +1068,7 @@ static const struct drm_driver msm_driver = {
DRIVER_SYNCOBJ_TIMELINE |
DRIVER_SYNCOBJ,
.open   = msm_open,
-   .postclose   = msm_postclose,
+   .postclose  = msm_postclose,
.lastclose  = drm_fb_helper_lastclose,
.dumb_create= msm_gem_dumb_create,
.dumb_map_offset= msm_gem_dumb_map_offset,
@@ -1081,6 +1079,7 @@ static const struct drm_driver msm_driver = {
 #ifdef CONFIG_DEBUG_FS
.debugfs_init   = msm_debugfs_init,
 #endif
+   .show_fdinfo= msm_show_fdinfo,
.ioctls = msm_ioctls,
.num_ioctls = ARRAY_SIZE(msm_ioctls),
.fops   = ,
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 26ebda40be4f..c403912d13ab 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -151,8 +151,6 @@ int msm_gpu_pm_suspend(struct msm_gpu *gpu)
 void msm_gpu_show_fdinfo(struct msm_gpu *gpu, struct msm_file_private *ctx,
 struct drm_printer *p)
 {
-   drm_printf(p, "drm-driver:\t%s\n", gpu->dev->driver->name);
-   drm_printf(p, "drm-client-id:\t%u\n", ctx->seqno);
drm_printf(p, "drm-engine-gpu:\t%llu ns\n", ctx->elapsed_ns);
drm_printf(p, "drm-cycles-gpu:\t%llu\n", ctx->cycles);
drm_printf(p, "drm-maxfreq-gpu:\t%u Hz\n", gpu->fast_rate);
-- 
2.39.2

[PATCH v3 0/7] drm: fdinfo memory stats

[Rob Clark]

From: Rob Clark 

Similar motivation to other similar recent attempt[1].  But with an
attempt to have some shared code for this.  As well as documentation.

It is probably a bit UMA-centric, I guess devices with VRAM might want
some placement stats as well.  But this seems like a reasonable start.

Basic gputop support: https://patchwork.freedesktop.org/series/116236/
And already nvtop support: https://github.com/Syllo/nvtop/pull/204

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

Rob Clark (7):
  drm: Add common fdinfo helper
  drm/msm: Switch to fdinfo helper
  drm/amdgpu: Switch to fdinfo helper
  drm/i915: Switch to fdinfo helper
  drm/etnaviv: Switch to fdinfo helper
  drm: Add fdinfo memory stats
  drm/msm: Add memory stats to fdinfo

 Documentation/gpu/drm-usage-stats.rst  |  21 
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|   3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c |  16 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h |   2 +-
 drivers/gpu/drm/drm_file.c | 115 +
 drivers/gpu/drm/etnaviv/etnaviv_drv.c  |  10 +-
 drivers/gpu/drm/i915/i915_driver.c |   3 +-
 drivers/gpu/drm/i915/i915_drm_client.c |  18 +---
 drivers/gpu/drm/i915/i915_drm_client.h |   2 +-
 drivers/gpu/drm/msm/msm_drv.c  |  11 +-
 drivers/gpu/drm/msm/msm_gem.c  |  15 +++
 drivers/gpu/drm/msm/msm_gpu.c  |   2 -
 include/drm/drm_drv.h  |   7 ++
 include/drm/drm_file.h |   5 +
 include/drm/drm_gem.h  |  19 
 15 files changed, 208 insertions(+), 41 deletions(-)

-- 
2.39.2

Re: [PATCH] MAINTAINERS: Add Marijn Suijten as drm/msm reviewer

[Dmitry Baryshkov]

On 12/04/2023 01:43, Marijn Suijten wrote:

As I get more and more active in the drm/msm space, yet sometimes miss
out on patches (where I was involved in previous discussions), add
myself as reviewer to make this involvement clear.

Signed-off-by: Marijn Suijten 
---

Note that this is only a slight commitment from my part to look at
patches arriving in this area, most notably on the DPU1 driver and only
if day-to-day workload allows for it.


I think Marijn does a good job of reviewing incoming patches in the 
mentioned area.


Acked-by: Dmitry Baryshkov 



  MAINTAINERS | 1 +
  1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 04d7c816d46a..fd1b717c57d8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6536,6 +6536,7 @@ M:Rob Clark 
  M:Abhinav Kumar 
  M:Dmitry Baryshkov 
  R:Sean Paul 
+R: Marijn Suijten 
  L:linux-arm-...@vger.kernel.org
  L:dri-devel@lists.freedesktop.org
  L:freedr...@lists.freedesktop.org


--
With best wishes
Dmitry

[PATCH] MAINTAINERS: Add Marijn Suijten as drm/msm reviewer

[Marijn Suijten]

As I get more and more active in the drm/msm space, yet sometimes miss
out on patches (where I was involved in previous discussions), add
myself as reviewer to make this involvement clear.

Signed-off-by: Marijn Suijten 
---

Note that this is only a slight commitment from my part to look at
patches arriving in this area, most notably on the DPU1 driver and only
if day-to-day workload allows for it.

 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 04d7c816d46a..fd1b717c57d8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6536,6 +6536,7 @@ M:Rob Clark 
 M: Abhinav Kumar 
 M: Dmitry Baryshkov 
 R: Sean Paul 
+R: Marijn Suijten 
 L: linux-arm-...@vger.kernel.org
 L: dri-devel@lists.freedesktop.org
 L: freedr...@lists.freedesktop.org
-- 
2.40.0

Re: [Freedreno] [PATCH v2 0/2] drm: fdinfo memory stats

[Dmitry Baryshkov]

On 11/04/2023 21:28, Rob Clark wrote:

On Tue, Apr 11, 2023 at 10:36 AM Dmitry Baryshkov
 wrote:


On Tue, 11 Apr 2023 at 20:13, Rob Clark  wrote:


On Tue, Apr 11, 2023 at 9:53 AM Daniel Vetter  wrote:


On Tue, Apr 11, 2023 at 09:47:32AM -0700, Rob Clark wrote:

On Mon, Apr 10, 2023 at 2:06 PM Rob Clark  wrote:


From: Rob Clark 

Similar motivation to other similar recent attempt[1].  But with an
attempt to have some shared code for this.  As well as documentation.

It is probably a bit UMA-centric, I guess devices with VRAM might want
some placement stats as well.  But this seems like a reasonable start.

Basic gputop support: https://patchwork.freedesktop.org/series/116236/
And already nvtop support: https://github.com/Syllo/nvtop/pull/204


On a related topic, I'm wondering if it would make sense to report
some more global things (temp, freq, etc) via fdinfo?  Some of this,
tools like nvtop could get by trawling sysfs or other driver specific
ways.  But maybe it makes sense to have these sort of things reported
in a standardized way (even though they aren't really per-drm_file)


I think that's a bit much layering violation, we'd essentially have to
reinvent the hwmon sysfs uapi in fdinfo. Not really a business I want to
be in :-)


I guess this is true for temp (where there are thermal zones with
potentially multiple temp sensors.. but I'm still digging my way thru
the thermal_cooling_device stuff)


It is slightly ugly. All thermal zones and cooling devices are virtual
devices (so, even no connection to the particular tsens device). One
can either enumerate them by checking
/sys/class/thermal/thermal_zoneN/type or enumerate them through
/sys/class/hwmon. For cooling devices again the only enumeration is
through /sys/class/thermal/cooling_deviceN/type.

Probably it should be possible to push cooling devices and thermal
zones under corresponding providers. However I do not know if there is
a good way to correlate cooling device (ideally a part of GPU) to the
thermal_zone (which in our case is provided by tsens / temp_alarm
rather than GPU itself).



But what about freq?  I think, esp for cases where some "fw thing" is
controlling the freq we end up needing to use gpu counters to measure
the freq.


For the freq it is slightly easier: /sys/class/devfreq/*, devices are
registered under proper parent (IOW, GPU). So one can read
/sys/class/devfreq/3d0.gpu/cur_freq or
/sys/bus/platform/devices/3d0.gpu/devfreq/3d0.gpu/cur_freq.

However because of the components usage, there is no link from
/sys/class/drm/card0
(/sys/devices/platform/soc@0/ae0.display-subsystem/ae01000.display-controller/drm/card0)
to /sys/devices/platform/soc@0/3d0.gpu, the GPU unit.

Getting all these items together in a platform-independent way would
be definitely an important but complex topic.


But I don't believe any of the pci gpu's use devfreq ;-)

And also, you can't expect the CPU to actually know the freq when fw
is the one controlling freq.  We can, currently, have a reasonable
approximation from devfreq but that stops if IFPC is implemented.  And
other GPUs have even less direct control.  So freq is a thing that I
don't think we should try to get from "common frameworks"


I think it might be useful to add another passive devfreq governor type 
for external frequencies. This way we can use the same interface to 
export non-CPU-controlled frequencies.




BR,
-R




What might be needed is better glue to go from the fd or fdinfo to the
right hw device and then crawl around the hwmon in sysfs automatically. I
would not be surprised at all if we really suck on this, probably more
likely on SoC than pci gpus where at least everything should be under the
main pci sysfs device.


yeah, I *think* userspace would have to look at /proc/device-tree to
find the cooling device(s) associated with the gpu.. at least I don't
see a straightforward way to figure it out just for sysfs

BR,
-R


-Daniel



BR,
-R



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

Rob Clark (2):
   drm: Add fdinfo memory stats
   drm/msm: Add memory stats to fdinfo

  Documentation/gpu/drm-usage-stats.rst | 21 +++
  drivers/gpu/drm/drm_file.c| 79 +++
  drivers/gpu/drm/msm/msm_drv.c | 25 -
  drivers/gpu/drm/msm/msm_gpu.c |  2 -
  include/drm/drm_file.h| 10 
  5 files changed, 134 insertions(+), 3 deletions(-)

--
2.39.2



--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch




--
With best wishes
Dmitry


--
With best wishes
Dmitry

Re: [Freedreno] [PATCH] drm/msm/dpu: add DSC range checking during resource reservation

[Abhinav Kumar]

Hi Marijn

On 4/11/2023 3:24 PM, Marijn Suijten wrote:

Again, don't forget to include previous reviewers in cc, please :)

On 2023-04-11 14:09:40, Kuogee Hsieh wrote:

Perform DSC range checking to make sure correct DSC is requested before
reserve resource for it.


This isn't performing any range checking for resource reservations /
requests: this is only validating the constants written in our catalog
and seems rather useless.  It isn't fixing any real bug either, so the
Fixes: tag below seems extraneous.

Given prior comments from Abhinav that "the kernel should be trusted",
we should remove this validation for all the other blocks instead.



The purpose of this check is that today all our blocks in RM use the 
DSC_* enum as the size.


struct dpu_hw_blk *dsc_blks[DSC_MAX - DSC_0];

If the device tree ends up with more DSC blocks than the DSC_* enum, how 
can we avoid this issue today? Not because its a bug in device tree but 
how many static number of DSCs are hard-coded in RM.


And like you said, this is not specific to DSC. Such checks are present 
for other blocks too.



Fixes: c985d7bb64ff ("drm/msm/disp/dpu1: Add DSC support in RM")
Signed-off-by: Kuogee Hsieh 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 10 +-
  1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index f4dda88..95e58f1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -1,6 +1,7 @@
  // SPDX-License-Identifier: GPL-2.0-only
  /*
   * Copyright (c) 2016-2018, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
   */
  
  #define pr_fmt(fmt)	"[drm:%s] " fmt, __func__

@@ -250,6 +251,11 @@ int dpu_rm_init(struct dpu_rm *rm,
struct dpu_hw_dsc *hw;
const struct dpu_dsc_cfg *dsc = >dsc[i];
  
+		if (dsc->id < DSC_0 || dsc->id >= DSC_MAX) {

+   DPU_ERROR("skip dsc %d with invalid id\n", dsc->id);
+   continue;
+   }
+
hw = dpu_hw_dsc_init(dsc->id, mmio, cat);
if (IS_ERR_OR_NULL(hw)) {
rc = PTR_ERR(hw);
@@ -557,8 +563,10 @@ static int _dpu_rm_make_reservation(
}
  
  	ret  = _dpu_rm_reserve_dsc(rm, global_state, enc, >topology);

-   if (ret)
+   if (ret) {
+   DPU_ERROR("unable to find appropriate DSC\n");


This, while a nice addition, should go in a different patch.

Thanks!

- Marijn


return ret;
+   }
  
  	return ret;

  }
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 6/6] drm/i915: Do state check for color management changes

[Ville Syrjala]

From: Ville Syrjälä 

In order to validate LUT programming more thoroughly let's
do a state check for all color management updates as well.

Not sure we really want this outside CI. It is rather heavy
and color management updates could become rather common
with all the HDR/etc. stuff happening. Maybe we should have
an extra knob for this that we could enable in CI?

v2: Skip for initial_commit to avoid FDI dotclock
sanity checks/etc. tripping up

Reviewed-by: Uma Shankar 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_modeset_verify.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_modeset_verify.c 
b/drivers/gpu/drm/i915/display/intel_modeset_verify.c
index 842d70f0dfd2..9e4767e1b900 100644
--- a/drivers/gpu/drm/i915/display/intel_modeset_verify.c
+++ b/drivers/gpu/drm/i915/display/intel_modeset_verify.c
@@ -228,6 +228,8 @@ void intel_modeset_verify_crtc(struct intel_crtc *crtc,
   struct intel_crtc_state *new_crtc_state)
 {
if (!intel_crtc_needs_modeset(new_crtc_state) &&
+   (!intel_crtc_needs_color_update(new_crtc_state) ||
+new_crtc_state->inherited) &&
!intel_crtc_needs_fastset(new_crtc_state))
return;
 
-- 
2.39.2

[PATCH 5/6] drm/i915: No 10bit gamma on desktop gen3 parts

[Ville Syrjala]

From: Ville Syrjälä 

Apparently desktop gen3 parts don't support the
10bit gamma mode at all. Stop claiming otherwise.

As is the case with pipe A on gen3 mobile parts, the
PIPECONF gamma mode bit can be set but it has no
effect on the output.

PNV seems to be the only slight exception, but generally
the desktop PNV variant looks more like a mobile part so
this is not entirely surprising.

Fixes: 67630bacae23 ("drm/i915: Add 10bit gamma mode for gen2/3")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_pci.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index cddb6e197972..305c05c3f93b 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -250,13 +250,13 @@ static const struct intel_device_info i865g_info = {
.dma_mask_size = 32, \
I9XX_PIPE_OFFSETS, \
I9XX_CURSOR_OFFSETS, \
-   I9XX_COLORS, \
GEN_DEFAULT_PAGE_SIZES, \
GEN_DEFAULT_REGIONS
 
 static const struct intel_device_info i915g_info = {
GEN3_FEATURES,
PLATFORM(INTEL_I915G),
+   I845_COLORS,
.has_coherent_ggtt = false,
.display.cursor_needs_physical = 1,
.display.has_overlay = 1,
@@ -268,6 +268,7 @@ static const struct intel_device_info i915g_info = {
 static const struct intel_device_info i915gm_info = {
GEN3_FEATURES,
PLATFORM(INTEL_I915GM),
+   I9XX_COLORS,
.is_mobile = 1,
.display.cursor_needs_physical = 1,
.display.has_overlay = 1,
@@ -281,6 +282,7 @@ static const struct intel_device_info i915gm_info = {
 static const struct intel_device_info i945g_info = {
GEN3_FEATURES,
PLATFORM(INTEL_I945G),
+   I845_COLORS,
.display.has_hotplug = 1,
.display.cursor_needs_physical = 1,
.display.has_overlay = 1,
@@ -292,6 +294,7 @@ static const struct intel_device_info i945g_info = {
 static const struct intel_device_info i945gm_info = {
GEN3_FEATURES,
PLATFORM(INTEL_I945GM),
+   I9XX_COLORS,
.is_mobile = 1,
.display.has_hotplug = 1,
.display.cursor_needs_physical = 1,
@@ -306,6 +309,7 @@ static const struct intel_device_info i945gm_info = {
 static const struct intel_device_info g33_info = {
GEN3_FEATURES,
PLATFORM(INTEL_G33),
+   I845_COLORS,
.display.has_hotplug = 1,
.display.has_overlay = 1,
.dma_mask_size = 36,
@@ -314,6 +318,7 @@ static const struct intel_device_info g33_info = {
 static const struct intel_device_info pnv_g_info = {
GEN3_FEATURES,
PLATFORM(INTEL_PINEVIEW),
+   I9XX_COLORS,
.display.has_hotplug = 1,
.display.has_overlay = 1,
.dma_mask_size = 36,
@@ -322,6 +327,7 @@ static const struct intel_device_info pnv_g_info = {
 static const struct intel_device_info pnv_m_info = {
GEN3_FEATURES,
PLATFORM(INTEL_PINEVIEW),
+   I9XX_COLORS,
.is_mobile = 1,
.display.has_hotplug = 1,
.display.has_overlay = 1,
-- 
2.39.2

[PATCH 4/6] drm/i915: Implement CTM property support for VLV

[Ville Syrjala]

From: Ville Syrjälä 

VLV has a so called "wide gamut color correction" unit (WGC).
What it is is a 3x3 matrix similar to the later CHV CGM
CSC, which less precisions/range. In fact CHV also has the WGC
but using it there doesn't reall make sense when you have the
superior CGM CSC around.

Hook up the necessary stuff to expose the WGC as the CTM
crtc property.

One additional crazy idea that came to mind would be to use
the WGC as an output CSC on CHV for YCbCr output. But it
would be incompatible with the legacy LUT usage. In fact
since the WGC lacks post-offsets we'd probably have to
use the legacy LUT to do that final part of the RGB->YCbCr
conversion. Sounds doable, but perhaps not worth the hassle.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_color.c| 170 +-
 .../drm/i915/display/intel_crtc_state_dump.c  |   6 +-
 drivers/gpu/drm/i915/display/intel_display.c  |   8 +
 .../drm/i915/display/intel_display_types.h|   3 +
 drivers/gpu/drm/i915/i915_reg.h   |  15 ++
 5 files changed, 198 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 63141f4ed372..051f86c125e5 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -587,6 +587,98 @@ static u16 ctm_to_twos_complement(u64 coeff, int int_bits, 
int frac_bits)
return c & (BIT(int_bits + frac_bits) - 1);
 }
 
+/*
+ * VLV/CHV Wide Gamut Color Correction (WGC) CSC
+ * |r|   | c0 c1 c2 |   |r|
+ * |g| = | c3 c4 c5 | x |g|
+ * |b|   | c6 c7 c8 |   |b|
+ *
+ * Coefficients are two's complement s2.10.
+ */
+static void vlv_wgc_csc_convert_ctm(const struct intel_crtc_state *crtc_state,
+   struct intel_csc_matrix *csc)
+{
+   const struct drm_color_ctm *ctm = crtc_state->hw.ctm->data;
+   int i;
+
+   for (i = 0; i < 9; i++)
+   csc->coeff[i] = ctm_to_twos_complement(ctm->matrix[i], 2, 10);
+}
+
+static void vlv_load_wgc_csc(struct intel_crtc *crtc,
+const struct intel_csc_matrix *csc)
+{
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   enum pipe pipe = crtc->pipe;
+
+   intel_de_write_fw(dev_priv, PIPE_WGC_C01_C00(pipe),
+ csc->coeff[1] << 16 | csc->coeff[0]);
+   intel_de_write_fw(dev_priv, PIPE_WGC_C02(pipe),
+ csc->coeff[2]);
+
+   intel_de_write_fw(dev_priv, PIPE_WGC_C11_C10(pipe),
+ csc->coeff[4] << 16 | csc->coeff[3]);
+   intel_de_write_fw(dev_priv, PIPE_WGC_C12(pipe),
+ csc->coeff[5]);
+
+   intel_de_write_fw(dev_priv, PIPE_WGC_C21_C20(pipe),
+ csc->coeff[7] << 16 | csc->coeff[6]);
+   intel_de_write_fw(dev_priv, PIPE_WGC_C22(pipe),
+ csc->coeff[8]);
+}
+
+static void vlv_read_wgc_csc(struct intel_crtc *crtc,
+struct intel_csc_matrix *csc)
+{
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   enum pipe pipe = crtc->pipe;
+   u32 tmp;
+
+   tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C01_C00(pipe));
+   csc->coeff[0] = tmp & 0x;
+   csc->coeff[1] = tmp >> 16;
+
+   tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C02(pipe));
+   csc->coeff[2] = tmp & 0x;
+
+   tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C11_C10(pipe));
+   csc->coeff[3] = tmp & 0x;
+   csc->coeff[4] = tmp >> 16;
+
+   tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C12(pipe));
+   csc->coeff[5] = tmp & 0x;
+
+   tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C21_C20(pipe));
+   csc->coeff[6] = tmp & 0x;
+   csc->coeff[7] = tmp >> 16;
+
+   tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C22(pipe));
+   csc->coeff[8] = tmp & 0x;
+}
+
+static void vlv_read_csc(struct intel_crtc_state *crtc_state)
+{
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+
+   if (crtc_state->wgc_enable)
+   vlv_read_wgc_csc(crtc, _state->csc);
+}
+
+static void vlv_assign_csc(struct intel_crtc_state *crtc_state)
+{
+   struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
+
+   if (crtc_state->hw.ctm) {
+   drm_WARN_ON(>drm, !crtc_state->wgc_enable);
+
+   vlv_wgc_csc_convert_ctm(crtc_state, _state->csc);
+   } else {
+   drm_WARN_ON(>drm, crtc_state->wgc_enable);
+
+   intel_csc_clear(_state->csc);
+   }
+}
+
 /*
  * CHV Color Gamut Mapping (CGM) CSC
  * |r|   | c0 c1 c2 |   |r|
@@ -662,6 +754,8 @@ static void chv_assign_csc(struct intel_crtc_state 
*crtc_state)
 {
struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
 
+   drm_WARN_ON(>drm, crtc_state->wgc_enable);
+
if (crtc_state->hw.ctm) {
drm_WARN_ON(>drm, (crtc_state->cgm_mode & 
CGM_PIPE_MODE_CSC) 

[PATCH 3/6] drm/i915: Fix CHV CGM CSC coefficient sign handling

[Ville Syrjala]

From: Ville Syrjälä 

The CHV CGM CSC coefficients are in s4.12 two's complement
format. Fix the CTM->CGM conversion to handle that correctly
instead of pretending that the hw coefficients are also
in some sign-magnitude format.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_color.c | 46 ++
 1 file changed, 29 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 4fc16cac052d..63141f4ed372 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -568,29 +568,41 @@ static void icl_load_csc_matrix(const struct 
intel_crtc_state *crtc_state)
icl_update_output_csc(crtc, _state->output_csc);
 }
 
+static u16 ctm_to_twos_complement(u64 coeff, int int_bits, int frac_bits)
+{
+   s64 c = CTM_COEFF_ABS(coeff);
+
+   /* leave an extra bit for rounding */
+   c >>= 32 - frac_bits - 1;
+
+   /* round and drop the extra bit */
+   c = (c + 1) >> 1;
+
+   if (CTM_COEFF_NEGATIVE(coeff))
+   c = -c;
+
+   c = clamp(c, -(s64)BIT(int_bits + frac_bits - 1),
+ (s64)(BIT(int_bits + frac_bits - 1) - 1));
+
+   return c & (BIT(int_bits + frac_bits) - 1);
+}
+
+/*
+ * CHV Color Gamut Mapping (CGM) CSC
+ * |r|   | c0 c1 c2 |   |r|
+ * |g| = | c3 c4 c5 | x |g|
+ * |b|   | c6 c7 c8 |   |b|
+ *
+ * Coefficients are two's complement s4.12.
+ */
 static void chv_cgm_csc_convert_ctm(const struct intel_crtc_state *crtc_state,
struct intel_csc_matrix *csc)
 {
const struct drm_color_ctm *ctm = crtc_state->hw.ctm->data;
int i;
 
-   for (i = 0; i < 9; i++) {
-   u64 abs_coeff = ((1ULL << 63) - 1) & ctm->matrix[i];
-
-   /* Round coefficient. */
-   abs_coeff += 1 << (32 - 13);
-   /* Clamp to hardware limits. */
-   abs_coeff = clamp_val(abs_coeff, 0, CTM_COEFF_8_0 - 1);
-
-   csc->coeff[i] = 0;
-
-   /* Write coefficients in S3.12 format. */
-   if (ctm->matrix[i] & (1ULL << 63))
-   csc->coeff[i] |= 1 << 15;
-
-   csc->coeff[i] |= ((abs_coeff >> 32) & 7) << 12;
-   csc->coeff[i] |= (abs_coeff >> 20) & 0xfff;
-   }
+   for (i = 0; i < 9; i++)
+   csc->coeff[i] = ctm_to_twos_complement(ctm->matrix[i], 4, 12);
 }
 
 static void chv_load_cgm_csc(struct intel_crtc *crtc,
-- 
2.39.2

[PATCH 2/6] drm/i915: Expose crtc CTM property on ilk/snb

[Ville Syrjala]

From: Ville Syrjälä 

The ilk/snb code is internally fully capable of handling the
CTM property, so expose it.

Note that we still choose not to expose DEGAMMA_LUT though.
The hardware is capable if degamma or gamma, but not both
similtanously due to lack of the split gamma mode. Exposing
both LUTs might encourage userspace to try enabling both
at the same time.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_color.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 07f1afe1d406..4fc16cac052d 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -3473,7 +3473,7 @@ void intel_color_crtc_init(struct intel_crtc *crtc)
 
gamma_lut_size = INTEL_INFO(i915)->display.color.gamma_lut_size;
degamma_lut_size = INTEL_INFO(i915)->display.color.degamma_lut_size;
-   has_ctm = degamma_lut_size != 0;
+   has_ctm = DISPLAY_VER(i915) >= 5 && !IS_VALLEYVIEW(i915);
 
/*
 * "DPALETTE_A: NOTE: The 8-bit (non-10-bit) mode is the
-- 
2.39.2

[PATCH 1/6] drm/uapi: Document CTM matrix better

[Ville Syrjala]

From: Ville Syrjälä 

Document in which order the CTM matrix elements are stored.

Signed-off-by: Ville Syrjälä 
---
 include/uapi/drm/drm_mode.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 46becedf5b2f..43691058d28f 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -834,6 +834,11 @@ struct drm_color_ctm {
/*
 * Conversion matrix in S31.32 sign-magnitude
 * (not two's complement!) format.
+*
+* out   matrixin
+* |R|   |0 1 2|   |R|
+* |G| = |3 4 5| x |G|
+* |B|   |6 7 8|   |B|
 */
__u64 matrix[9];
 };
-- 
2.39.2

[PATCH 0/6] drm/i915: CTM stuff mostly

[Ville Syrjala]

From: Ville Syrjälä 

Mostly some CTM stuff:
- document the uapi better
- fix CHV CSC negative coefficients
- expose CTM on ilk/snb/vlv
- a bonus gamma patch for gen3

Test-with: 20230411161555.10001-1-ville.syrj...@linux.intel.com

Ville Syrjälä (6):
  drm/uapi: Document CTM matrix better
  drm/i915: Expose crtc CTM property on ilk/snb
  drm/i915: Fix CHV CGM CSC coefficient sign handling
  drm/i915: Implement CTM property support for VLV
  drm/i915: No 10bit gamma on desktop gen3 parts
  drm/i915: Do state check for color management changes

 drivers/gpu/drm/i915/display/intel_color.c| 216 --
 .../drm/i915/display/intel_crtc_state_dump.c  |   6 +-
 drivers/gpu/drm/i915/display/intel_display.c  |   8 +
 .../drm/i915/display/intel_display_types.h|   3 +
 .../drm/i915/display/intel_modeset_verify.c   |   2 +
 drivers/gpu/drm/i915/i915_pci.c   |   8 +-
 drivers/gpu/drm/i915/i915_reg.h   |  15 ++
 include/uapi/drm/drm_mode.h   |   5 +
 8 files changed, 241 insertions(+), 22 deletions(-)

-- 
2.39.2

Re: [Freedreno] [PATCH v2 0/2] drm: fdinfo memory stats

[Dmitry Baryshkov]

On 11/04/2023 21:26, Daniel Vetter wrote:

On Tue, Apr 11, 2023 at 08:35:48PM +0300, Dmitry Baryshkov wrote:

On Tue, 11 Apr 2023 at 20:13, Rob Clark  wrote:


On Tue, Apr 11, 2023 at 9:53 AM Daniel Vetter  wrote:


On Tue, Apr 11, 2023 at 09:47:32AM -0700, Rob Clark wrote:

On Mon, Apr 10, 2023 at 2:06 PM Rob Clark  wrote:


From: Rob Clark 

Similar motivation to other similar recent attempt[1].  But with an
attempt to have some shared code for this.  As well as documentation.

It is probably a bit UMA-centric, I guess devices with VRAM might want
some placement stats as well.  But this seems like a reasonable start.

Basic gputop support: https://patchwork.freedesktop.org/series/116236/
And already nvtop support: https://github.com/Syllo/nvtop/pull/204


On a related topic, I'm wondering if it would make sense to report
some more global things (temp, freq, etc) via fdinfo?  Some of this,
tools like nvtop could get by trawling sysfs or other driver specific
ways.  But maybe it makes sense to have these sort of things reported
in a standardized way (even though they aren't really per-drm_file)


I think that's a bit much layering violation, we'd essentially have to
reinvent the hwmon sysfs uapi in fdinfo. Not really a business I want to
be in :-)


I guess this is true for temp (where there are thermal zones with
potentially multiple temp sensors.. but I'm still digging my way thru
the thermal_cooling_device stuff)


It is slightly ugly. All thermal zones and cooling devices are virtual
devices (so, even no connection to the particular tsens device). One
can either enumerate them by checking
/sys/class/thermal/thermal_zoneN/type or enumerate them through
/sys/class/hwmon. For cooling devices again the only enumeration is
through /sys/class/thermal/cooling_deviceN/type.

Probably it should be possible to push cooling devices and thermal
zones under corresponding providers. However I do not know if there is
a good way to correlate cooling device (ideally a part of GPU) to the
thermal_zone (which in our case is provided by tsens / temp_alarm
rather than GPU itself).


There's not even sysfs links to connect the pieces in both ways?


I missed them in the most obvious place:

/sys/class/thermal/thermal_zone1/cdev0 -> ../cooling_device0

So, there is a link from thermal zone to cooling device.




But what about freq?  I think, esp for cases where some "fw thing" is
controlling the freq we end up needing to use gpu counters to measure
the freq.


For the freq it is slightly easier: /sys/class/devfreq/*, devices are
registered under proper parent (IOW, GPU). So one can read
/sys/class/devfreq/3d0.gpu/cur_freq or
/sys/bus/platform/devices/3d0.gpu/devfreq/3d0.gpu/cur_freq.

However because of the components usage, there is no link from
/sys/class/drm/card0
(/sys/devices/platform/soc@0/ae0.display-subsystem/ae01000.display-controller/drm/card0)
to /sys/devices/platform/soc@0/3d0.gpu, the GPU unit.


Hm ... do we need to make component more visible in sysfs, with _lots_
of links? Atm it's just not even there.


Maybe. Or maybe we should use DPU (the component master and a parent of 
drm/card0) as devfreq parent too.





Getting all these items together in a platform-independent way would
be definitely an important but complex topic.


Yeah this sounds like some work. But also sounds like it's all generic
issues (thermal zones above and component here) that really should be
fixed at that level?

Cheers, Daniel



What might be needed is better glue to go from the fd or fdinfo to the
right hw device and then crawl around the hwmon in sysfs automatically. I
would not be surprised at all if we really suck on this, probably more
likely on SoC than pci gpus where at least everything should be under the
main pci sysfs device.


yeah, I *think* userspace would have to look at /proc/device-tree to
find the cooling device(s) associated with the gpu.. at least I don't
see a straightforward way to figure it out just for sysfs

BR,
-R


-Daniel



BR,
-R



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

Rob Clark (2):
   drm: Add fdinfo memory stats
   drm/msm: Add memory stats to fdinfo

  Documentation/gpu/drm-usage-stats.rst | 21 +++
  drivers/gpu/drm/drm_file.c| 79 +++
  drivers/gpu/drm/msm/msm_drv.c | 25 -
  drivers/gpu/drm/msm/msm_gpu.c |  2 -
  include/drm/drm_file.h| 10 
  5 files changed, 134 insertions(+), 3 deletions(-)

--
2.39.2



--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch




--
With best wishes
Dmitry




--
With best wishes
Dmitry

Re: [PATCH] drm/msm/dpu: add DSC range checking during resource reservation

[Marijn Suijten]

Again, don't forget to include previous reviewers in cc, please :)

On 2023-04-11 14:09:40, Kuogee Hsieh wrote:
> Perform DSC range checking to make sure correct DSC is requested before
> reserve resource for it.

This isn't performing any range checking for resource reservations /
requests: this is only validating the constants written in our catalog
and seems rather useless.  It isn't fixing any real bug either, so the
Fixes: tag below seems extraneous.

Given prior comments from Abhinav that "the kernel should be trusted",
we should remove this validation for all the other blocks instead.

> Fixes: c985d7bb64ff ("drm/msm/disp/dpu1: Add DSC support in RM")
> Signed-off-by: Kuogee Hsieh 
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> index f4dda88..95e58f1 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> @@ -1,6 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0-only
>  /*
>   * Copyright (c) 2016-2018, The Linux Foundation. All rights reserved.
> + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
>   */
>  
>  #define pr_fmt(fmt)  "[drm:%s] " fmt, __func__
> @@ -250,6 +251,11 @@ int dpu_rm_init(struct dpu_rm *rm,
>   struct dpu_hw_dsc *hw;
>   const struct dpu_dsc_cfg *dsc = >dsc[i];
>  
> + if (dsc->id < DSC_0 || dsc->id >= DSC_MAX) {
> + DPU_ERROR("skip dsc %d with invalid id\n", dsc->id);
> + continue;
> + }
> +
>   hw = dpu_hw_dsc_init(dsc->id, mmio, cat);
>   if (IS_ERR_OR_NULL(hw)) {
>   rc = PTR_ERR(hw);
> @@ -557,8 +563,10 @@ static int _dpu_rm_make_reservation(
>   }
>  
>   ret  = _dpu_rm_reserve_dsc(rm, global_state, enc, >topology);
> - if (ret)
> + if (ret) {
> + DPU_ERROR("unable to find appropriate DSC\n");

This, while a nice addition, should go in a different patch.

Thanks!

- Marijn

>   return ret;
> + }
>  
>   return ret;
>  }
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

Re: [PATCH] drm/msm/dpu: add DSC range checking during resource reservation

[Dmitry Baryshkov]

On 12/04/2023 00:09, Kuogee Hsieh wrote:

Perform DSC range checking to make sure correct DSC is requested before
reserve resource for it.

Fixes: c985d7bb64ff ("drm/msm/disp/dpu1: Add DSC support in RM")


$ git log -p -1 c985d7bb64ff
fatal: ambiguous argument 'c985d7bb64ff': unknown revision or path not 
in the working tree.


I assume this was generated against some internal tree. Please. Please. 
Don't do this again. I hoped that this was pointed out ages ago, but 
probably not. No fixes, commits, tests against internal trees, no matter 
how precious they are to you.



Signed-off-by: Kuogee Hsieh 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 10 +-
  1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index f4dda88..95e58f1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -1,6 +1,7 @@
  // SPDX-License-Identifier: GPL-2.0-only
  /*
   * Copyright (c) 2016-2018, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
   */
  
  #define pr_fmt(fmt)	"[drm:%s] " fmt, __func__

@@ -250,6 +251,11 @@ int dpu_rm_init(struct dpu_rm *rm,
struct dpu_hw_dsc *hw;
const struct dpu_dsc_cfg *dsc = >dsc[i];
  
+		if (dsc->id < DSC_0 || dsc->id >= DSC_MAX) {

+   DPU_ERROR("skip dsc %d with invalid id\n", dsc->id);
+   continue;
+   }
+
hw = dpu_hw_dsc_init(dsc->id, mmio, cat);
if (IS_ERR_OR_NULL(hw)) {
rc = PTR_ERR(hw);
@@ -557,8 +563,10 @@ static int _dpu_rm_make_reservation(
}
  
  	ret  = _dpu_rm_reserve_dsc(rm, global_state, enc, >topology);

-   if (ret)
+   if (ret) {
+   DPU_ERROR("unable to find appropriate DSC\n");
return ret;
+   }
  
  	return ret;

  }


--
With best wishes
Dmitry

Re: [PATCH] drm/msm/dpu: always program dsc active bits

[Dmitry Baryshkov]

On 12/04/2023 00:04, Kuogee Hsieh wrote:

In current code, the dsc active bits are set only if the cfg->dsc is set.
However, for displays which are hot-pluggable, there can be a use-case
of disconnecting a DSC supported sink and connecting a non-DSC sink.

For those cases we need to clear DSC active bits during teardown.


Please correct me if I'm wrong here, shouldn't we start using 
reset_intf_cfg() during teardown / unplug?




Fixes: ede3c6bb00c ("drm/msm/disp/dpu1: Add DSC support in hw_ctl")
Signed-off-by: Kuogee Hsieh 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index bbdc95c..88e4efe 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -541,10 +541,9 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl *ctx,
if (cfg->merge_3d)
DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
  BIT(cfg->merge_3d - MERGE_3D_0));
-   if (cfg->dsc) {
-   DPU_REG_WRITE(>hw, CTL_FLUSH, DSC_IDX);
-   DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
-   }
+
+   DPU_REG_WRITE(>hw, CTL_FLUSH, DSC_IDX);
+   DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
  }
  
  static void dpu_hw_ctl_intf_cfg(struct dpu_hw_ctl *ctx,


--
With best wishes
Dmitry

Re: [PATCH] drm/msm/dpu: always program dsc active bits

[Marijn Suijten]

Full-caps DSC in the title, as discussed previously.

On that note, don't forget to CC those who have reviewed your patches
previously, as also brought up in earlier review.

On 2023-04-11 14:04:55, Kuogee Hsieh wrote:
> In current code, the dsc active bits are set only if the cfg->dsc is set.

Some typo nits:

DSC* active bits.

s/are set/are written/ (the variable is set, registers are written).

Drop `the` before `cfg->dsc` (and you could replace `s/is set/is
non-zero/).

> However, for displays which are hot-pluggable, there can be a use-case
> of disconnecting a DSC supported sink and connecting a non-DSC sink.
> 
> For those cases we need to clear DSC active bits during teardown.
> 
> Fixes: ede3c6bb00c ("drm/msm/disp/dpu1: Add DSC support in hw_ctl")
> Signed-off-by: Kuogee Hsieh 

If you have validated that it is fine to write these registers on
_every_ platform supported by DPU1, and after fixing the above nits and
the Fixes: commit hash as pointed out by Abhinav:

Reviewed-by: Marijn Suijten 

And see one question below.

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> index bbdc95c..88e4efe 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> @@ -541,10 +541,9 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl 
> *ctx,
>   if (cfg->merge_3d)
>   DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
> BIT(cfg->merge_3d - MERGE_3D_0));
> - if (cfg->dsc) {
> - DPU_REG_WRITE(>hw, CTL_FLUSH, DSC_IDX);
> - DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
> - }
> +
> + DPU_REG_WRITE(>hw, CTL_FLUSH, DSC_IDX);

Does this flush all DSCs programmed in CTL_DSC_FLUSH as set above?  That
is currently still in `if (cfg->dsc)` and never overwritten if all DSCs
are disabled, should it be taken out of the `if` to make sure no DSCs
are inadvertently flushed, or otherwise cache the "previous mask" to
make sure we flush exactly the right DSC blocks?

Thanks!

- Marijn

> + DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
>  }
>  
>  static void dpu_hw_ctl_intf_cfg(struct dpu_hw_ctl *ctx,
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

RE: [Intel-gfx] [PATCH 1/8] drm/i915/mtl: Define MOCS and PAT tables for MTL

[Yang, Fei]

> Subject: Re: [Intel-gfx] [PATCH 1/8] drm/i915/mtl: Define MOCS and PAT tables 
> for MTL
>
> On Mon, Apr 10, 2023 at 08:55:16PM -0700, Yang, Fei wrote:
> ...
 diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
>>
 b/drivers/gpu/drm/i915/gt/intel_gtt.h
>>
 index 69ce55f517f5..b632167eaf2e 100644
>>
 --- a/drivers/gpu/drm/i915/gt/intel_gtt.h
>>
 +++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
>>
 @@ -88,9 +88,18 @@ typedef u64 gen8_pte_t;
>>
  #define BYT_PTE_SNOOPED_BY_CPU_CACHES REG_BIT(2)
>>
  #define BYT_PTE_WRITEABLEREG_BIT(1)
>>

>>
 +#define GEN12_PPGTT_PTE_PAT3BIT_ULL(62)
>>
  #define GEN12_PPGTT_PTE_LM  BIT_ULL(11)
>>
 +#define GEN12_PPGTT_PTE_PAT2BIT_ULL(7)
>>
 +#define GEN12_PPGTT_PTE_NC  BIT_ULL(5)
>>
 +#define GEN12_PPGTT_PTE_PAT1BIT_ULL(4)
>>
 +#define GEN12_PPGTT_PTE_PAT0BIT_ULL(3)
>>
>>> Which bspec page is this from?  The PPGTT descriptions in
>>
>>> the bspec are kind of hard to track down.
>>
>>
>>
>>[9]https://gfxspecs.intel.com/Predator/Home/Index/53521
>
> The bspec tagging is a bit bizarre in this area, but I don't believe
> this page is intended to apply to MTL. Note that this page is inside
> a section specifically listed as "57b VA Support" --- i.e., this
> general section is for platforms like PVC rather than MTL.  MTL only
> has 48b virtual address space (bspec 55416), so I think one of the
> pages in the 48b sections is what we should be referencing instead.
>
> If they screwed up and put MTL-specific details only on a PVC-specific
> page of the bspec, we should probably file a bspec issue about that to
> get it fixed.

The Bspec is a bit confusing on these. Looked at the Bsec with filter set
to TGL/ADL/MTL/ALL respectively. Here are the differences,
>>PAT_Index[2:0] = {PAT, PCD, PWT} = BIT(7, 4, 3)

These 3 PAT index bits are defined for all gen12+.
>>PAT_Index[3] = BIT(62)

PAT_Index[3] is defined for MTL/ARL, will update this one to MTL_xxx

>>PAT_Index[4] = BIT(61)

PAT_Index[4] shows up only when there is no filter set. And this bit is
marked as [NOT VALID FOR SPEC: GENERALASSETSXE], not sure how to interpret
this, but seems like it should not be used at all. Any suggestion?

>>
>>
>>> But if these only apply to MTL, why are they labelled as "GEN12?"
>>
>>These apply to GEN12plus.
>
> That's not what your patch is doing; you're using them in a function
> that only gets called on MTL.

That PTE encode will be generalized to gen12 in a patch after after the
pat_index change.

> So the question is whether these
> definitions truly applied to older platforms like TGL/RKL/ADL/etc too
> (and we need to go back and fix that code), or whether they're
> Xe_LPG-specific, in which case the "GEN12_" prefix is incorrect.

The only difference is that MTL has PAT[3] defined, so we can still apply
the same PTE encode function for all gen12+.

> Also, handling the MTL-specific PTE encoding later in the series, after
> the transition from cache_level to PAT index, might be best since then
> you can just implement it correctly at the time the code is introduced;
> no need to add the cache_level implementation first (which can't even
> use all the bits) just to come back a few patches later and replace it
> all with PAT code.

I will squash the PTE encode patches.

 -#define GEN12_GGTT_PTE_LM   BIT_ULL(1)
 +#define GEN12_GGTT_PTE_LM BIT_ULL(1)
 +#define MTL_GGTT_PTE_PAT0  BIT_ULL(52)
 +#define MTL_GGTT_PTE_PAT1  BIT_ULL(53)
 +#define GEN12_GGTT_PTE_ADDR_MASK   GENMASK_ULL(45, 12)
 +#define MTL_GGTT_PTE_PAT_MASK  GENMASK_ULL(53, 52)

  #define GEN12_PDE_64K BIT(6)
  #define GEN12_PTE_PS64 BIT(8)
 @@ -147,6 +156,15 @@ typedef u64 gen8_pte_t;  #define
>> GEN8_PDE_IPS_64K
>>
 BIT(11)
>>
  #define GEN8_PDE_PS_2M   BIT(7)
>>
 +#define MTL_PPAT_L4_CACHE_POLICY_MASK
>> REG_GENMASK(3, 2)
 +#define MTL_PAT_INDEX_COH_MODE_MASK  REG_GENMASK(1,
>> 0)
 +#define MTL_PPAT_L4_3_UC
>>REG_FIELD_PREP(MTL_PPAT_L4_CACHE_POLICY_MASK, 3)
 +#define MTL_PPAT_L4_1_WT
>>REG_FIELD_PREP(MTL_PPAT_L4_CACHE_POLICY_MASK, 1)
 +#define MTL_PPAT_L4_0_WB
>>REG_FIELD_PREP(MTL_PPAT_L4_CACHE_POLICY_MASK, 0)
 +#define MTL_3_COH_2W REG_FIELD_PREP(MTL_PAT_INDEX_COH_MODE_MASK,
>>3)
 +#define MTL_2_COH_1W REG_FIELD_PREP(MTL_PAT_INDEX_COH_MODE_MASK,
>>2)
 +#define MTL_0_COH_NON
>> REG_FIELD_PREP(MTL_PAT_INDEX_COH_MODE_MASK, 0)
>>>
>>> The values for these definitions don't seem to be aligned.
>>These are aligned with
>>[10]https://gfxspecs.intel.com/Predator/Home/Index/45101
> I mean spacing aligned.  If your tabstops are set to 8, then the values don't 
> line up visually.

Hmm... the three COH macro's are aligned, are you saying they should aligned 
with those PPAT macro's as well?

Re: [PATCH] drm/msm/dpu: always program dsc active bits

[Abhinav Kumar]

On 4/11/2023 2:04 PM, Kuogee Hsieh wrote:

In current code, the dsc active bits are set only if the cfg->dsc is set.
However, for displays which are hot-pluggable, there can be a use-case
of disconnecting a DSC supported sink and connecting a non-DSC sink.

For those cases we need to clear DSC active bits during teardown.

Fixes: ede3c6bb00c ("drm/msm/disp/dpu1: Add DSC support in hw_ctl")


Again, wrong fixes tag,

Fixes: 77f6da90487c ("drm/msm/disp/dpu1: Add DSC support in hw_ctl")


Signed-off-by: Kuogee Hsieh 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index bbdc95c..88e4efe 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -541,10 +541,9 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl *ctx,
if (cfg->merge_3d)
DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
  BIT(cfg->merge_3d - MERGE_3D_0));
-   if (cfg->dsc) {
-   DPU_REG_WRITE(>hw, CTL_FLUSH, DSC_IDX);
-   DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
-   }
+
+   DPU_REG_WRITE(>hw, CTL_FLUSH, DSC_IDX);
+   DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
  }
  
  static void dpu_hw_ctl_intf_cfg(struct dpu_hw_ctl *ctx,


But, otherwise seems fine and a valid bug fix.

Reviewed-by: Abhinav Kumar 

Re: [PATCH] drm/msm/dpu: add DSC range checking during resource reservation

[Abhinav Kumar]

On 4/11/2023 2:09 PM, Kuogee Hsieh wrote:

Perform DSC range checking to make sure correct DSC is requested before
reserve resource for it.

Fixes: c985d7bb64ff ("drm/msm/disp/dpu1: Add DSC support in RM")


I cannot find any fixes tag with this hash.

This is the right one.

Fixes: f2803ee91a41 ("drm/msm/disp/dpu1: Add DSC support in RM")


Signed-off-by: Kuogee Hsieh 
---


Otherwise, seems quite reasonable to me,

Reviewed-by: Abhinav Kumar 

RE: [PATCH] radeon: avoid double free in ci_dpm_init()

[Deucher, Alexander]

[Public]

> -Original Message-
> From: Nikita Zhandarovich 
> Sent: Monday, April 3, 2023 2:28 PM
> To: Deucher, Alexander 
> Cc: Nikita Zhandarovich ; Koenig, Christian
> ; Pan, Xinhui ; David
> Airlie ; Daniel Vetter ; amd-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-
> ker...@vger.kernel.org; lvc-proj...@linuxtesting.org
> Subject: [PATCH] radeon: avoid double free in ci_dpm_init()
> 
> There are several calls to ci_dpm_fini() in ci_dpm_init() when there occur
> errors in functions like r600_parse_extended_power_table().
> This is harmful as it can lead to double free situations: for instance,
> r600_parse_extended_power_table() will call for
> r600_free_extended_power_table() as will ci_dpm_fini(), both of which will
> try to free resources.
> Other drivers do not call *_dpm_fini functions from their respective
> *_dpm_init calls - neither should cpm_dpm_init().
> 
> Fix this by removing extra calls to ci_dpm_fini().

You can't just drop the calls to fini().  You'll need to properly unwind to 
avoid leaking memory.

Alex

> 
> Found by Linux Verification Center (linuxtesting.org) with static analysis 
> tool
> SVACE.
> 
> Fixes: cc8dbbb4f62a ("drm/radeon: add dpm support for CI dGPUs (v2)")
> Cc: sta...@vger.kernel.org
> Co-developed-by: Natalia Petrova 
> Signed-off-by: Nikita Zhandarovich 
> 
> ---
>  drivers/gpu/drm/radeon/ci_dpm.c | 20 +---
>  1 file changed, 5 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/ci_dpm.c
> b/drivers/gpu/drm/radeon/ci_dpm.c index 8ef25ab305ae..7b77d4c93f1d
> 100644
> --- a/drivers/gpu/drm/radeon/ci_dpm.c
> +++ b/drivers/gpu/drm/radeon/ci_dpm.c
> @@ -5677,28 +5677,20 @@ int ci_dpm_init(struct radeon_device *rdev)
>   pi->pcie_lane_powersaving.min = 16;
> 
>   ret = ci_get_vbios_boot_values(rdev, >vbios_boot_state);
> - if (ret) {
> - ci_dpm_fini(rdev);
> + if (ret)
>   return ret;
> - }
> 
>   ret = r600_get_platform_caps(rdev);
> - if (ret) {
> - ci_dpm_fini(rdev);
> + if (ret)
>   return ret;
> - }
> 
>   ret = r600_parse_extended_power_table(rdev);
> - if (ret) {
> - ci_dpm_fini(rdev);
> + if (ret)
>   return ret;
> - }
> 
>   ret = ci_parse_power_table(rdev);
> - if (ret) {
> - ci_dpm_fini(rdev);
> + if (ret)
>   return ret;
> - }
> 
>   pi->dll_default_on = false;
>   pi->sram_end = SMC_RAM_END;
> @@ -5749,10 +5741,8 @@ int ci_dpm_init(struct radeon_device *rdev)
>   kcalloc(4,
>   sizeof(struct
> radeon_clock_voltage_dependency_entry),
>   GFP_KERNEL);
> - if (!rdev-
> >pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries) {
> - ci_dpm_fini(rdev);
> + if (!rdev-
> >pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries)
>   return -ENOMEM;
> - }
>   rdev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.count = 4;
>   rdev-
> >pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries[0].clk = 0;
>   rdev-
> >pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries[0].v = 0;

[PATCH] drm/msm/dpu: add DSC range checking during resource reservation

[Kuogee Hsieh]

Perform DSC range checking to make sure correct DSC is requested before
reserve resource for it.

Fixes: c985d7bb64ff ("drm/msm/disp/dpu1: Add DSC support in RM")
Signed-off-by: Kuogee Hsieh 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index f4dda88..95e58f1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0-only
 /*
  * Copyright (c) 2016-2018, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
  */
 
 #define pr_fmt(fmt)"[drm:%s] " fmt, __func__
@@ -250,6 +251,11 @@ int dpu_rm_init(struct dpu_rm *rm,
struct dpu_hw_dsc *hw;
const struct dpu_dsc_cfg *dsc = >dsc[i];
 
+   if (dsc->id < DSC_0 || dsc->id >= DSC_MAX) {
+   DPU_ERROR("skip dsc %d with invalid id\n", dsc->id);
+   continue;
+   }
+
hw = dpu_hw_dsc_init(dsc->id, mmio, cat);
if (IS_ERR_OR_NULL(hw)) {
rc = PTR_ERR(hw);
@@ -557,8 +563,10 @@ static int _dpu_rm_make_reservation(
}
 
ret  = _dpu_rm_reserve_dsc(rm, global_state, enc, >topology);
-   if (ret)
+   if (ret) {
+   DPU_ERROR("unable to find appropriate DSC\n");
return ret;
+   }
 
return ret;
 }
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] drm/msm/dpu: always program dsc active bits

[Kuogee Hsieh]

In current code, the dsc active bits are set only if the cfg->dsc is set.
However, for displays which are hot-pluggable, there can be a use-case
of disconnecting a DSC supported sink and connecting a non-DSC sink.

For those cases we need to clear DSC active bits during teardown.

Fixes: ede3c6bb00c ("drm/msm/disp/dpu1: Add DSC support in hw_ctl")
Signed-off-by: Kuogee Hsieh 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index bbdc95c..88e4efe 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -541,10 +541,9 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl *ctx,
if (cfg->merge_3d)
DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
  BIT(cfg->merge_3d - MERGE_3D_0));
-   if (cfg->dsc) {
-   DPU_REG_WRITE(>hw, CTL_FLUSH, DSC_IDX);
-   DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
-   }
+
+   DPU_REG_WRITE(>hw, CTL_FLUSH, DSC_IDX);
+   DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
 }
 
 static void dpu_hw_ctl_intf_cfg(struct dpu_hw_ctl *ctx,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] drm/scheduler: set entity to NULL in drm_sched_entity_pop_job()

[Luben Tuikov]

On 2023-04-11 14:13, Danilo Krummrich wrote:
> On 4/5/23 19:39, Luben Tuikov wrote:
>> On 2023-03-31 01:59, Christian König wrote:
>>> Am 31.03.23 um 02:06 schrieb Danilo Krummrich:
 It already happend a few times that patches slipped through which
 implemented access to an entity through a job that was already removed
 from the entities queue. Since jobs and entities might have different
 lifecycles, this can potentially cause UAF bugs.

 In order to make it obvious that a jobs entity pointer shouldn't be
 accessed after drm_sched_entity_pop_job() was called successfully, set
 the jobs entity pointer to NULL once the job is removed from the entity
 queue.

 Moreover, debugging a potential NULL pointer dereference is way easier
 than potentially corrupted memory through a UAF.

 Signed-off-by: Danilo Krummrich 
>>>
>>> In general "YES PLEASE!", but I fear that this will break amdgpus reset
>>> sequence.
>>>
>>> On the other hand when amdgpu still relies on that pointer it's clearly
>>> a bug (which I pointed out tons of times before).
>>>
>>> Luben any opinion on that? Could you drive cleaning that up as well?
>>
>> I didn't find any references to scheduling entity after the job
>> is submitted to the hardware. (I commented the same in the other
>> thread, we just need to decide which way to go.)
> 
> AFAICS from the other mail thread it seems to be consensus to not 
> ref-count entities and handle job statistics differently.
> 
> Should we go ahead and take this patch then? Maybe it also makes sense 
> to send a V2 additionally adding a comment to the drm_sched_job 
> structure mentioning that .entity must not be used after the job was 
> taken from the entities queue.

Yes, please send a v2, but instead of mentioning (or in addition to)
that the job was taken from the "entities queue", mention that
once the job is pushed to the hardware, i.e. the pending queue,
from then on, the "entity" should not be referenced anymore. IOW, we
want to mention that it is going from X to Y, as opposed to just
that it's taken from X, because the latter begs the question "Where
is it going to then?".

For the record, I think that using kref would give us the most
stability, even if we skipped "entity" and let the scheduler, or
even the controller keep a kref on submitted commands down to
the GPU. On reset, we block command submission to the GPU from
the outermost boundary, and then start peeling the layers from
the innermost boundary.

Using kref also forces us to think objectively and set explicit
(clear) dependencies from the outset--i.e. who gets freed and when
and under what circumstances.

And using kref might even expose the wrong dependencies, thus
prompting a redesign and thus a fix.
-- 
Regards,
Luben

Re: [PATCH v3 01/13] firmware/sysfb: Fix EFI/VESA format selection

[Pierre Asselin]

> Can you please share you grub config file? It seems that is set to
> GRUB_GFXMODE=1024x768x32 but the actual mode is set to 1024x768x24 ?

Okay, but you'll be sorry...  The gfxmode is set to "keep" in all the
entries.  https://www.panix.com/~pa/linux-6.3-simplefb/grub.cfg .

The "TEST" entry was used to bisect.  The "PRE-TEST" was to set things
up, to receive the bzImages compiled on a faster machine. Now I boot
the "Linux 6.3.0-rc5-x86".


> That is, it fails when the picked format is DRM_FORMAT_RGB but
> works when is DRM_FORMAT_XRGB888. I can't spot any error in Thomas'
> patch so I wonder if the problem is with what grub is passing to the
> kernel.
>
> The mentioned vga=0x318 workaround that you mentioned makes the mode
> passed to match the selected DRM_FORMAT_RGB888 which I guess is why
> that worked for you.

All right, I did a series of reboots, editing the grub command line
to change the "gfxpayload=" grub option or the "vga=" kernel option.
In each case I captured the output of
  "dmesg | egrep -i 'fbcon|console|fb0|frameb|simple|vga|vesa'

https://www.panix.com/~pa/linux-6.3-simplefb/selected-modes

(D'oh.  My script printed "vga=vga=" twice when that option was set.
Good enough as is.)

Note the difference in linelength= between the bad and good r8g8b8.
Does it mean anything ?
 (bad)> format=r8g8b8, mode=1024x768x24, linelength=4096
(good)> format=r8g8b8, mode=1024x768x24, linelength=3072

Re: [Intel-gfx] [PATCH 1/8] drm/i915/mtl: Define MOCS and PAT tables for MTL

[Matt Roper]

On Mon, Apr 10, 2023 at 08:55:16PM -0700, Yang, Fei wrote:
...
>>> diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
> 
>>> b/drivers/gpu/drm/i915/gt/intel_gtt.h
> 
>>> index 69ce55f517f5..b632167eaf2e 100644
> 
>>> --- a/drivers/gpu/drm/i915/gt/intel_gtt.h
> 
>>> +++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
> 
>>> @@ -88,9 +88,18 @@ typedef u64 gen8_pte_t;
> 
>>>  #define BYT_PTE_SNOOPED_BY_CPU_CACHES REG_BIT(2)
> 
>>>  #define BYT_PTE_WRITEABLE    REG_BIT(1)
> 
>>> 
> 
>>> +#define GEN12_PPGTT_PTE_PAT3    BIT_ULL(62)
> 
>>>  #define GEN12_PPGTT_PTE_LM  BIT_ULL(11)
> 
>>> +#define GEN12_PPGTT_PTE_PAT2    BIT_ULL(7)
> 
>>> +#define GEN12_PPGTT_PTE_NC  BIT_ULL(5)
> 
>>> +#define GEN12_PPGTT_PTE_PAT1    BIT_ULL(4)
> 
>>> +#define GEN12_PPGTT_PTE_PAT0    BIT_ULL(3)
> 
>> 
> 
>> Which bspec page is this from?  The PPGTT descriptions in
> 
>> the bspec are kind of hard to track down.
> 
> 
> 
>[9]https://gfxspecs.intel.com/Predator/Home/Index/53521

The bspec tagging is a bit bizarre in this area, but I don't believe
this page is intended to apply to MTL.  Note that this page is inside a
section specifically listed as "57b VA Support" --- i.e., this general
section is for platforms like PVC rather than MTL.  MTL only has 48b
virtual address space (bspec 55416), so I think one of the pages in the
48b sections is what we should be referencing instead.

If they screwed up and put MTL-specific details only on a PVC-specific
page of the bspec, we should probably file a bspec issue about that to
get it fixed.

> 
>PAT_Index[2:0] = {PAT, PCD, PWT} = BIT(7, 4, 3)
> 
>PAT_Index[3] = BIT(62)
> 
>PAT_Index[4] = BIT(61)
> 
> 
> 
>> But if these only apply to MTL, why are they labelled as "GEN12?"
> 
> 
> 
>These apply to GEN12plus.

That's not what your patch is doing; you're using them in a function
that only gets called on MTL.  So the question is whether these
definitions truly applied to older platforms like TGL/RKL/ADL/etc too
(and we need to go back and fix that code), or whether they're
Xe_LPG-specific, in which case the "GEN12_" prefix is incorrect.

Also, handling the MTL-specific PTE encoding later in the series, after
the transition from cache_level to PAT index, might be best since then
you can just implement it correctly at the time the code is introduced;
no need to add the cache_level implementation first (which can't even
use all the bits) just to come back a few patches later and replace it
all with PAT code.

> 
> 
> 
>>> 
> 
>>> -#define GEN12_GGTT_PTE_LM   BIT_ULL(1)
> 
>>> +#define GEN12_GGTT_PTE_LM BIT_ULL(1)
> 
>>> +#define MTL_GGTT_PTE_PAT0  BIT_ULL(52)
> 
>>> +#define MTL_GGTT_PTE_PAT1  BIT_ULL(53)
> 
>>> +#define GEN12_GGTT_PTE_ADDR_MASK   GENMASK_ULL(45, 12)
> 
>>> +#define MTL_GGTT_PTE_PAT_MASK  
>GENMASK_ULL(53, 52)
> 
>>> 
> 
>>>  #define GEN12_PDE_64K BIT(6)
> 
>>>  #define GEN12_PTE_PS64 BIT(8)
> 
>>> @@ -147,6 +156,15 @@ typedef u64 gen8_pte_t;  #define GEN8_PDE_IPS_64K
> 
>>> BIT(11)
> 
>>>  #define GEN8_PDE_PS_2M   BIT(7)
> 
>>> 
> 
>>> +#define MTL_PPAT_L4_CACHE_POLICY_MASK REG_GENMASK(3, 2)
> 
>>> +#define MTL_PAT_INDEX_COH_MODE_MASK  REG_GENMASK(1, 0)
> 
>>> +#define MTL_PPAT_L4_3_UC  
>REG_FIELD_PREP(MTL_PPAT_L4_CACHE_POLICY_MASK, 3)
> 
>>> +#define MTL_PPAT_L4_1_WT  
>REG_FIELD_PREP(MTL_PPAT_L4_CACHE_POLICY_MASK, 1)
> 
>>> +#define MTL_PPAT_L4_0_WB  
>REG_FIELD_PREP(MTL_PPAT_L4_CACHE_POLICY_MASK, 0)
> 
>>> +#define MTL_3_COH_2W REG_FIELD_PREP(MTL_PAT_INDEX_COH_MODE_MASK,
>3)
> 
>>> +#define MTL_2_COH_1W REG_FIELD_PREP(MTL_PAT_INDEX_COH_MODE_MASK,
>2)
> 
>>> +#define MTL_0_COH_NON   REG_FIELD_PREP(MTL_PAT_INDEX_COH_MODE_MASK, 0)
> 
>> 
> 
>>The values for these definitions don't seem to be aligned.
> 
> 
> 
>These are aligned with
>[10]https://gfxspecs.intel.com/Predator/Home/Index/45101

I mean spacing aligned.  If your tabstops are set to 8, then the values
don't line up visually.


Matt

-- 
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation

[PATCH v9 10/10] drm/msm: Implement HDCP 1.x using the new drm HDCP helpers

[Mark Yacoub]

From: Sean Paul 

Add HDCP 1.x support to msm DP bridges using the new HDCP
helpers.

Cc: Stephen Boyd 
Reviewed-by: Stephen Boyd 
Signed-off-by: Sean Paul 
Signed-off-by: Mark Yacoub 

---

Changes in v2:
-Squash [1] into this patch with the following changes (Stephen)
  -Update the sc7180 dtsi file
  -Remove resource names and just use index (Stephen)
Changes in v3:
-Split out the dtsi change from v2 (Stephen)
-Fix set-but-unused warning identified by 0-day
-Fix up a couple of style nits (Stephen)
-Store HDCP key directly in dp_hdcp struct (Stephen)
-Remove wmb in HDCP key initialization, move an_seed (Stephen)
-Use FIELD_PREP for bstatus/bcaps (Stephen)
-#define read_poll_timeout values (Stephen)
-Remove unnecessary parentheses in dp_hdcp_store_ksv_fifo (Stephen)
-Add compatible string for hdcp (Stephen)
-Rename dp_hdcp_write_* functions (Abhinav)
-Add 1us delay between An reads (Abhinav)
-Delete unused dp_hdcp_read_* functions
Changes in v4:
-Rebase on Bjorn's multi-dp patchset
Changes in v5:
-Change return check of drm_hdcp_helper_initialize_dp() (Stephen)
Changes in v6:
-Change the tracking of the state from connector state to bridge as
state as drm_connector_state is no longer tracked and the functionality
has moved to msm_dp_bridge
Changes in v7:
-Use dp bridge to maintain the state with no use for connector
Changes in v8:
-Move the hdcp read/write to dp_catalog
Changes in v9:
-Remove display type specific helper funcs init from driver

 drivers/gpu/drm/msm/Kconfig |   1 +
 drivers/gpu/drm/msm/Makefile|   1 +
 drivers/gpu/drm/msm/dp/dp_catalog.c | 156 +++
 drivers/gpu/drm/msm/dp/dp_catalog.h |  18 ++
 drivers/gpu/drm/msm/dp/dp_debug.c   |  46 +++-
 drivers/gpu/drm/msm/dp/dp_debug.h   |  11 +-
 drivers/gpu/drm/msm/dp/dp_display.c |  39 ++-
 drivers/gpu/drm/msm/dp/dp_display.h |   5 +
 drivers/gpu/drm/msm/dp/dp_drm.c |  39 ++-
 drivers/gpu/drm/msm/dp/dp_drm.h |   7 +
 drivers/gpu/drm/msm/dp/dp_hdcp.c| 389 
 drivers/gpu/drm/msm/dp/dp_hdcp.h|  33 +++
 drivers/gpu/drm/msm/dp/dp_parser.c  |  14 +
 drivers/gpu/drm/msm/dp/dp_parser.h  |   4 +
 drivers/gpu/drm/msm/dp/dp_reg.h |  30 ++-
 drivers/gpu/drm/msm/msm_atomic.c|  19 ++
 16 files changed, 800 insertions(+), 12 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/dp/dp_hdcp.c
 create mode 100644 drivers/gpu/drm/msm/dp/dp_hdcp.h

diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 4d8fddbdcd9e0..1c369ca2ea6e3 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -15,6 +15,7 @@ config DRM_MSM
select REGULATOR
select DRM_DP_AUX_BUS
select DRM_DISPLAY_DP_HELPER
+   select DRM_DISPLAY_HDCP_HELPER
select DRM_DISPLAY_HELPER
select DRM_KMS_HELPER
select DRM_PANEL
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 7274c41228ed9..a73e7b858af27 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -122,6 +122,7 @@ msm-$(CONFIG_DRM_MSM_DP)+= dp/dp_aux.o \
dp/dp_ctrl.o \
dp/dp_display.o \
dp/dp_drm.o \
+   dp/dp_hdcp.o \
dp/dp_hpd.o \
dp/dp_link.o \
dp/dp_panel.o \
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c 
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index 676279d0ca8d9..a1395e0c67d56 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -16,6 +16,8 @@
 #include "dp_catalog.h"
 #include "dp_reg.h"
 
+#include 
+
 #define POLLING_SLEEP_US   1000
 #define POLLING_TIMEOUT_US 1
 
@@ -47,6 +49,14 @@
 #define DP_INTERRUPT_STATUS2_MASK \
(DP_INTERRUPT_STATUS2 << DP_INTERRUPT_STATUS_MASK_SHIFT)
 
+#define DP_AN_READ_DELAY_US 1
+/* Key offsets based on hdcp_key mmio */
+#define DP_HDCP_KEY_BASE 0x30
+#define DP_HDCP_KEY_MSB(x) (DP_HDCP_KEY_BASE + (x * 8))
+#define DP_HDCP_KEY_LSB(x) (DP_HDCP_KEY_MSB(x) + 4)
+#define DP_HDCP_KEY_VALID 0x170
+#define DP_HDCP_SW_KEY_VALID BIT(0)
+
 struct dp_catalog_private {
struct device *dev;
struct drm_device *drm_dev;
@@ -133,6 +143,18 @@ static inline void dp_write_link(struct dp_catalog_private 
*catalog,
writel(data, catalog->io->dp_controller.link.base + offset);
 }
 
+static inline void dp_write_hdcp_key(struct dp_catalog_private *catalog,
+u32 offset, u32 val)
+{
+   writel(val, catalog->io->dp_controller.hdcp_key.base + offset);
+}
+
+static inline void dp_write_hdcp_tz(struct dp_catalog_private *catalog,
+   u32 offset, u32 val)
+{
+   writel(val, catalog->io->dp_controller.hdcp_tz.base + offset);
+}
+
 /* aux related catalog functions */
 u32 dp_catalog_aux_read_data(struct dp_catalog *dp_catalog)
 {
@@ -1094,3 +1116,137 @@ void dp_catalog_audio_sfe_level(struct dp_catalog 
*dp_catalog)
 
dp_write_link(catalog, REG_DP_MAINLINK_LEVELS, mainlink_levels);
 

[PATCH v9 09/10] arm64: dts: qcom: sc7180: Add support for HDCP in dp-controller

[Mark Yacoub]

From: Sean Paul 

Add the register ranges required for HDCP key injection and
HDCP TrustZone interaction as described in the dt-bindings for the
sc7180 dp controller.

Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Douglas Anderson 
Signed-off-by: Sean Paul 
Signed-off-by: Mark Yacoub 

---
Changes in v3:
-Split off into a new patch containing just the dts change (Stephen)
-Add hdcp compatible string (Stephen)
Changes in v4:
-Rebase on Bjorn's multi-dp patchset
Changes in v5:
-Put the tz register offsets in trogdor dtsi (Rob C)
Changes in v6:
-Rebased: Removed modifications in sc7180.dtsi as it's already upstream
Changes in v7:
-Change registers offset

 arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi 
b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
index 423630c4d02c7..89d913fa6e3eb 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
@@ -822,6 +822,14 @@ _dp {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_hot_plug_det>;
+
+   reg = <0 0x0ae9 0 0x200>,
+ <0 0x0ae90200 0 0x200>,
+ <0 0x0ae90400 0 0xc00>,
+ <0 0x0ae91000 0 0x400>,
+ <0 0x0ae91400 0 0x400>,
+ <0 0x0aed1000 0 0x174>,
+ <0 0x0aee1000 0 0x2c>;
 };
 
 _dp_out {
-- 
2.40.0.577.gac1e443424-goog

[PATCH v9 08/10] dt-bindings: msm/dp: Add bindings for HDCP registers

[Mark Yacoub]

From: Sean Paul 

Add the bindings for the MSM DisplayPort HDCP registers
which are required to write the HDCP key into the display controller as
well as the registers to enable HDCP authentication/key
exchange/encryption.

Cc: Rob Herring 
Cc: Stephen Boyd 
Reviewed-by: Rob Herring 
Reviewed-by: Douglas Anderson 
Signed-off-by: Sean Paul 
Signed-off-by: Mark Yacoub 

---
Changes in v2:
-Drop register range names (Stephen)
-Fix yaml errors (Rob)
Changes in v3:
-Add new compatible string for dp-hdcp
-Add descriptions to reg
-Add minItems/maxItems to reg
-Make reg depend on the new hdcp compatible string
Changes in v4:
-Rebase on Bjorn's multi-dp patchset
Changes in v4.5:
-Remove maxItems from reg (Rob)
-Remove leading zeros in example (Rob)
Changes in v5:
-None
Changes in v6:
-Rebased: modify minItems instead of adding it as new line.
Changes in v7:
-Revert the change to minItems
-Added the maxItems to Reg

 .../devicetree/bindings/display/msm/dp-controller.yaml | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml 
b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
index 0e8d8df686dc9..4763a2ff12fb7 100644
--- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
@@ -34,6 +34,8 @@ properties:
   - description: link register block
   - description: p0 register block
   - description: p1 register block
+  - description: (Optional) Registers for HDCP device key injection
+  - description: (Optional) Registers for HDCP TrustZone interaction
 
   interrupts:
 maxItems: 1
@@ -159,6 +161,7 @@ allOf:
 aux-bus: false
 reg:
   minItems: 5
+  maxItems: 7
   required:
 - "#sound-dai-cells"
 
@@ -176,7 +179,9 @@ examples:
   <0xae90200 0x200>,
   <0xae90400 0xc00>,
   <0xae91000 0x400>,
-  <0xae91400 0x400>;
+  <0xae91400 0x400>,
+  <0xaed1000 0x174>,
+  <0xaee1000 0x2c>;
 interrupt-parent = <>;
 interrupts = <12>;
 clocks = < DISP_CC_MDSS_AHB_CLK>,
-- 
2.40.0.577.gac1e443424-goog

[PATCH v9 07/10] drm/i915/hdcp: Use HDCP helpers for i915

[Mark Yacoub]

From: Sean Paul 

Now that all of the HDCP 1.x logic has been migrated to the central HDCP
helpers, use it in the i915 driver.

The majority of the driver code for HDCP 1.x will live in intel_hdcp.c,
however there are a few helper hooks which are connector-specific and
need to be partially or fully implemented in the intel_dp_hdcp.c or
intel_hdmi.c.

We'll leave most of the HDCP 2.x code alone since we don't have another
implementation of HDCP 2.x to use as reference for what should and
should not live in the drm helpers. The helper will call the overly
general enable/disable/is_capable HDCP 2.x callbacks and leave the
interesting stuff for the driver. Once we have another HDCP 2.x
implementation, we should do a similar migration.

Acked-by: Jani Nikula 
Acked-by: Rodrigo Vivi 
Signed-off-by: Sean Paul 
Signed-off-by: Mark Yacoub 

---
Changes in v2:
-Fix mst helper function pointer reported by 0-day
Changes in v3:
-Add forward declaration for drm_atomic_state in intel_hdcp.h identified
 by 0-day
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-Rebased.
Changes in v7:
-Added to drm_hdcp_helper_funcs new functions that are unique between DP
and HDMI
-Adjusted the function signatures to take "driver data"
Changes in v8:
-None
Changes in v9:
-rename dev_priv to i915
-remove display type specific hdcp calls init from driver

 drivers/gpu/drm/i915/display/intel_ddi.c  |  32 +-
 .../drm/i915/display/intel_display_debugfs.c  |   7 +-
 .../drm/i915/display/intel_display_types.h|  51 +-
 drivers/gpu/drm/i915/display/intel_dp_hdcp.c  | 352 +++
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  16 +-
 drivers/gpu/drm/i915/display/intel_hdcp.c | 984 --
 drivers/gpu/drm/i915/display/intel_hdcp.h |  43 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c | 267 ++---
 8 files changed, 475 insertions(+), 1277 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 254559abedfba..8a2f20c929e9c 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -28,6 +28,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 #include "i915_drv.h"
@@ -2956,6 +2957,10 @@ static void intel_enable_ddi(struct intel_atomic_state 
*state,
 const struct intel_crtc_state *crtc_state,
 const struct drm_connector_state *conn_state)
 {
+   struct intel_connector *connector =
+   to_intel_connector(conn_state->connector);
+   struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
+
drm_WARN_ON(state->base.dev, crtc_state->has_pch_encoder);
 
if (!intel_crtc_is_bigjoiner_slave(crtc_state))
@@ -2975,12 +2980,10 @@ static void intel_enable_ddi(struct intel_atomic_state 
*state,
else
intel_enable_ddi_dp(state, encoder, crtc_state, conn_state);
 
-   /* Enable hdcp if it's desired */
-   if (conn_state->content_protection ==
-   DRM_MODE_CONTENT_PROTECTION_DESIRED)
-   intel_hdcp_enable(to_intel_connector(conn_state->connector),
- crtc_state,
- (u8)conn_state->hdcp_content_type);
+   if (connector->hdcp_helper_data)
+   drm_hdcp_helper_atomic_commit(connector->hdcp_helper_data,
+ >base,
+ _port->hdcp_mutex);
 }
 
 static void intel_disable_ddi_dp(struct intel_atomic_state *state,
@@ -3026,7 +3029,14 @@ static void intel_disable_ddi(struct intel_atomic_state 
*state,
  const struct intel_crtc_state *old_crtc_state,
  const struct drm_connector_state *old_conn_state)
 {
-   intel_hdcp_disable(to_intel_connector(old_conn_state->connector));
+   struct intel_connector *connector =
+   to_intel_connector(old_conn_state->connector);
+   struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
+
+   if (connector->hdcp_helper_data)
+   drm_hdcp_helper_atomic_commit(connector->hdcp_helper_data,
+ >base,
+ _port->hdcp_mutex);
 
if (intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_HDMI))
intel_disable_ddi_hdmi(state, encoder, old_crtc_state,
@@ -3054,13 +3064,19 @@ void intel_ddi_update_pipe(struct intel_atomic_state 
*state,
   const struct intel_crtc_state *crtc_state,
   const struct drm_connector_state *conn_state)
 {
+   struct intel_connector *connector =
+   to_intel_connector(conn_state->connector);
+   struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
 
if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI) &&
!intel_encoder_is_mst(encoder))

[PATCH v9 06/10] drm/i915/hdcp: Retain hdcp_capable return codes

[Mark Yacoub]

From: Sean Paul 

The shim functions return error codes, but they are discarded in
intel_hdcp.c. This patch plumbs the return codes through so they are
properly handled.

Acked-by: Jani Nikula 
Reviewed-by: Rodrigo Vivi 
Reviewed-by: Suraj Kandpal 
Signed-off-by: Sean Paul 
Signed-off-by: Mark Yacoub 

---
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-Rebased
Changes in v7:
-None

 .../drm/i915/display/intel_display_debugfs.c  |  9 +++-
 drivers/gpu/drm/i915/display/intel_hdcp.c | 51 ++-
 drivers/gpu/drm/i915/display/intel_hdcp.h |  4 +-
 3 files changed, 37 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 7bcd90384a46d..a14b86a07e545 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -494,6 +494,7 @@ static void intel_panel_info(struct seq_file *m,
 static void intel_hdcp_info(struct seq_file *m,
struct intel_connector *intel_connector)
 {
+   int ret;
bool hdcp_cap, hdcp2_cap;
 
if (!intel_connector->hdcp.shim) {
@@ -501,8 +502,12 @@ static void intel_hdcp_info(struct seq_file *m,
goto out;
}
 
-   hdcp_cap = intel_hdcp_capable(intel_connector);
-   hdcp2_cap = intel_hdcp2_capable(intel_connector);
+   ret = intel_hdcp_capable(intel_connector, _cap);
+   if (ret)
+   hdcp_cap = false;
+   ret = intel_hdcp2_capable(intel_connector, _cap);
+   if (ret)
+   hdcp2_cap = false;
 
if (hdcp_cap)
seq_puts(m, "HDCP1.4 ");
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 0a20bc41be55d..61a862ae1f286 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -177,50 +177,49 @@ int intel_hdcp_read_valid_bksv(struct intel_digital_port 
*dig_port,
 }
 
 /* Is HDCP1.4 capable on Platform and Sink */
-bool intel_hdcp_capable(struct intel_connector *connector)
+int intel_hdcp_capable(struct intel_connector *connector, bool *capable)
 {
struct intel_digital_port *dig_port = 
intel_attached_dig_port(connector);
const struct intel_hdcp_shim *shim = connector->hdcp.shim;
-   bool capable = false;
u8 bksv[5];
 
+   *capable = false;
+
if (!shim)
-   return capable;
+   return 0;
 
-   if (shim->hdcp_capable) {
-   shim->hdcp_capable(dig_port, );
-   } else {
-   if (!intel_hdcp_read_valid_bksv(dig_port, shim, bksv))
-   capable = true;
-   }
+   if (shim->hdcp_capable)
+   return shim->hdcp_capable(dig_port, capable);
+
+   if (!intel_hdcp_read_valid_bksv(dig_port, shim, bksv))
+   *capable = true;
 
-   return capable;
+   return 0;
 }
 
 /* Is HDCP2.2 capable on Platform and Sink */
-bool intel_hdcp2_capable(struct intel_connector *connector)
+int intel_hdcp2_capable(struct intel_connector *connector, bool *capable)
 {
struct intel_digital_port *dig_port = 
intel_attached_dig_port(connector);
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = >hdcp;
-   bool capable = false;
+
+   *capable = false;
 
/* I915 support for HDCP2.2 */
if (!hdcp->hdcp2_supported)
-   return false;
+   return 0;
 
/* MEI interface is solid */
mutex_lock(_priv->display.hdcp.comp_mutex);
if (!dev_priv->display.hdcp.comp_added ||  
!dev_priv->display.hdcp.master) {
mutex_unlock(_priv->display.hdcp.comp_mutex);
-   return false;
+   return 0;
}
mutex_unlock(_priv->display.hdcp.comp_mutex);
 
/* Sink's capability for HDCP2.2 */
-   hdcp->shim->hdcp_2_2_capable(dig_port, );
-
-   return capable;
+   return hdcp->shim->hdcp_2_2_capable(dig_port, capable);
 }
 
 static bool intel_hdcp_in_use(struct drm_i915_private *dev_priv,
@@ -2355,6 +2354,7 @@ int intel_hdcp_enable(struct intel_connector *connector,
struct intel_digital_port *dig_port = 
intel_attached_dig_port(connector);
struct intel_hdcp *hdcp = >hdcp;
unsigned long check_link_interval = DRM_HDCP_CHECK_PERIOD_MS;
+   bool capable;
int ret = -EINVAL;
 
if (!hdcp->shim)
@@ -2373,21 +2373,27 @@ int intel_hdcp_enable(struct intel_connector *connector,
 * Considering that HDCP2.2 is more secure than HDCP1.4, If the setup
 * is capable of HDCP2.2, it is preferred to use HDCP2.2.
 */
-   if (intel_hdcp2_capable(connector)) {
+   ret = intel_hdcp2_capable(connector, );
+   if (capable) {
ret = _intel_hdcp2_enable(connector);
-   

[PATCH v9 05/10] drm/i915/hdcp: Consolidate HDCP setup/state cache

[Mark Yacoub]

From: Sean Paul 

Stick all of the setup for HDCP into a dedicated function. No functional
change, but this will facilitate moving HDCP logic into helpers.

Acked-by: Jani Nikula 
Reviewed-by: Rodrigo Vivi 
Signed-off-by: Sean Paul 

---
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
- None

 drivers/gpu/drm/i915/display/intel_hdcp.c | 52 +++
 1 file changed, 35 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 396d2cef000aa..0a20bc41be55d 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2190,6 +2190,37 @@ static enum mei_fw_tc intel_get_mei_fw_tc(enum 
transcoder cpu_transcoder)
}
 }
 
+static int
+_intel_hdcp_setup(struct intel_connector *connector,
+ const struct intel_crtc_state *pipe_config, u8 content_type)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_digital_port *dig_port = 
intel_attached_dig_port(connector);
+   struct intel_hdcp *hdcp = >hdcp;
+   int ret = 0;
+
+   if (!connector->encoder) {
+   drm_err(_priv->drm, "[%s:%d] encoder is not initialized\n",
+   connector->base.name, connector->base.base.id);
+   return -ENODEV;
+   }
+
+   hdcp->content_type = content_type;
+
+   if (intel_crtc_has_type(pipe_config, INTEL_OUTPUT_DP_MST)) {
+   hdcp->cpu_transcoder = pipe_config->mst_master_transcoder;
+   hdcp->stream_transcoder = pipe_config->cpu_transcoder;
+   } else {
+   hdcp->cpu_transcoder = pipe_config->cpu_transcoder;
+   hdcp->stream_transcoder = INVALID_TRANSCODER;
+   }
+
+   if (DISPLAY_VER(dev_priv) >= 12)
+   dig_port->hdcp_port_data.fw_tc = 
intel_get_mei_fw_tc(hdcp->cpu_transcoder);
+
+   return ret;
+}
+
 static int initialize_hdcp_port_data(struct intel_connector *connector,
 struct intel_digital_port *dig_port,
 const struct intel_hdcp_shim *shim)
@@ -2329,28 +2360,14 @@ int intel_hdcp_enable(struct intel_connector *connector,
if (!hdcp->shim)
return -ENOENT;
 
-   if (!connector->encoder) {
-   drm_err(_priv->drm, "[%s:%d] encoder is not initialized\n",
-   connector->base.name, connector->base.base.id);
-   return -ENODEV;
-   }
-
mutex_lock(>mutex);
mutex_lock(_port->hdcp_mutex);
drm_WARN_ON(_priv->drm,
hdcp->value == DRM_MODE_CONTENT_PROTECTION_ENABLED);
-   hdcp->content_type = content_type;
-
-   if (intel_crtc_has_type(pipe_config, INTEL_OUTPUT_DP_MST)) {
-   hdcp->cpu_transcoder = pipe_config->mst_master_transcoder;
-   hdcp->stream_transcoder = pipe_config->cpu_transcoder;
-   } else {
-   hdcp->cpu_transcoder = pipe_config->cpu_transcoder;
-   hdcp->stream_transcoder = INVALID_TRANSCODER;
-   }
 
-   if (DISPLAY_VER(dev_priv) >= 12)
-   dig_port->hdcp_port_data.fw_tc = 
intel_get_mei_fw_tc(hdcp->cpu_transcoder);
+   ret = _intel_hdcp_setup(connector, pipe_config, content_type);
+   if (ret)
+   goto out;
 
/*
 * Considering that HDCP2.2 is more secure than HDCP1.4, If the setup
@@ -2378,6 +2395,7 @@ int intel_hdcp_enable(struct intel_connector *connector,
true);
}
 
+out:
mutex_unlock(_port->hdcp_mutex);
mutex_unlock(>mutex);
return ret;
-- 
2.40.0.577.gac1e443424-goog

[PATCH v9 04/10] drm/hdcp: Expand HDCP helper library for enable/disable/check

[Mark Yacoub]

From: Sean Paul 

Expand upon the HDCP helper library to manage HDCP enable, disable, and check.

Previous to this patch, the majority of the state management and sink
interaction is tucked inside the Intel driver with the understanding
that once a new platform supported HDCP we could make good decisions
about what should be centralized. With the addition of HDCP support
for Qualcomm, it's time to migrate the protocol-specific bits of HDCP
authentication, key exchange, and link checks to the HDCP helper.

In terms of functionality, this migration is 1:1 with the Intel driver,
however things are laid out a bit differently than with intel_hdcp.c,
which is why this is a separate patch from the i915 transition to the
helper. On i915, the shim vtable is used to account for HDMI vs. DP
vs. DP-MST differences whereas the helper library uses a LUT to
account for the register offsets and a remote read function to route
the messages. On i915, storing the sink information in the source is
done inline whereas now we use the new drm_hdcp_helper_funcs vtable
to store and fetch information to/from source hw. Finally, instead of
calling enable/disable directly from the driver, we'll leave that
decision to the helper and by calling drm_hdcp_helper_atomic_commit()
from the driver. All told, this will centralize the protocol and state
handling in the helper, ensuring we collect all of our bugs^Wlogic
in one place.

Acked-by: Jani Nikula 
Signed-off-by: Sean Paul 
Signed-off-by: Mark Yacoub 

---
Changes in v2:
-Fixed set-but-unused variable identified by 0-day
Changes in v3:
-Fixed uninitialized variable warning identified by 0-day
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-Fixed typo in function descriptions
-Rebased: Moved the new code between drm_hdcp.h and drm_hdcp_helper.c/h
-Add missing headers. Reported-by: kernel test robot 
Changes in v7:
- Add a |driver_data| field to some functions in drm_hdcp_helper_funcs
  that are called by the driver so drivers can pass anything they such
  as bridges
- Isolate all non-common code between HDMI and DP into separate
  functions instead of manually checking for datra->aux
Changes in v8 (suraj):
-Try hdcp 1.x if hdcp2_capable returns an error instead of goto out.
-set the enabled type to either 1 or 0 depending on the prop as hdcp2
can support either.
Changes in v9:
-Replace the drm_err by drm_dbg_kms
-Assign data->enabled_type without if-statement
-Moved display type specific func init into the drm helper

 drivers/gpu/drm/display/drm_hdcp_helper.c | 1136 +
 include/drm/display/drm_hdcp.h|  296 ++
 include/drm/display/drm_hdcp_helper.h |   22 +-
 3 files changed, 1453 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/display/drm_hdcp_helper.c 
b/drivers/gpu/drm/display/drm_hdcp_helper.c
index 3ee1a6ae26c53..9b62e476d21b4 100644
--- a/drivers/gpu/drm/display/drm_hdcp_helper.c
+++ b/drivers/gpu/drm/display/drm_hdcp_helper.c
@@ -6,13 +6,18 @@
  * Ramalingam C 
  */
 
+#include 
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
+#include 
 
+#include 
 #include 
 #include 
 #include 
@@ -507,3 +512,1134 @@ bool drm_hdcp_has_changed(struct drm_connector 
*connector,
return old_hdcp != new_hdcp;
 }
 EXPORT_SYMBOL(drm_hdcp_has_changed);
+
+struct drm_hdcp_hdcp1_receiver_reg_lut {
+   unsigned int bksv;
+   unsigned int ri;
+   unsigned int aksv;
+   unsigned int an;
+   unsigned int ainfo;
+   unsigned int v[5];
+   unsigned int bcaps;
+   unsigned int bcaps_mask_repeater_present;
+   unsigned int bstatus;
+};
+
+static const struct drm_hdcp_hdcp1_receiver_reg_lut drm_hdcp_hdcp1_ddc_lut = {
+   .bksv = DRM_HDCP_DDC_BKSV,
+   .ri = DRM_HDCP_DDC_RI_PRIME,
+   .aksv = DRM_HDCP_DDC_AKSV,
+   .an = DRM_HDCP_DDC_AN,
+   .ainfo = DRM_HDCP_DDC_AINFO,
+   .v = { DRM_HDCP_DDC_V_PRIME(0), DRM_HDCP_DDC_V_PRIME(1),
+  DRM_HDCP_DDC_V_PRIME(2), DRM_HDCP_DDC_V_PRIME(3),
+  DRM_HDCP_DDC_V_PRIME(4) },
+   .bcaps = DRM_HDCP_DDC_BCAPS,
+   .bcaps_mask_repeater_present = DRM_HDCP_DDC_BCAPS_REPEATER_PRESENT,
+   .bstatus = DRM_HDCP_DDC_BSTATUS,
+};
+
+static const struct drm_hdcp_hdcp1_receiver_reg_lut drm_hdcp_hdcp1_dpcd_lut = {
+   .bksv = DP_AUX_HDCP_BKSV,
+   .ri = DP_AUX_HDCP_RI_PRIME,
+   .aksv = DP_AUX_HDCP_AKSV,
+   .an = DP_AUX_HDCP_AN,
+   .ainfo = DP_AUX_HDCP_AINFO,
+   .v = { DP_AUX_HDCP_V_PRIME(0), DP_AUX_HDCP_V_PRIME(1),
+  DP_AUX_HDCP_V_PRIME(2), DP_AUX_HDCP_V_PRIME(3),
+  DP_AUX_HDCP_V_PRIME(4) },
+   .bcaps = DP_AUX_HDCP_BCAPS,
+   .bcaps_mask_repeater_present = DP_BCAPS_REPEATER_PRESENT,
+
+   /*
+* For some reason the HDMI and DP HDCP specs call this register
+* definition by different names. In the HDMI spec, it's called BSTATUS,
+* but in DP it's called BINFO.
+*/
+   .bstatus = 

[PATCH v9 03/10] drm/hdcp: Update property value on content type and user changes

[Mark Yacoub]

From: Sean Paul 

Update the connector's property value in 2 cases which were
previously missed:

1- Content type changes. The value should revert back to DESIRED from
   ENABLED in case the driver must re-authenticate the link due to the
   new content type.

2- Userspace sets value to DESIRED while ENABLED. In this case, the
   value should be reset immediately to ENABLED since the link is
   actively being encrypted.

To accommodate these changes, I've split up the conditionals to make
things a bit more clear (as much as one can with this mess of state).

Acked-by: Jani Nikula 
Reviewed-by: Rodrigo Vivi 
Signed-off-by: Sean Paul 
Signed-off-by: Mark Yacoub 

---
Changes in v2:
-None
Changes in v3:
-Fixed indentation issue identified by 0-day
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-Rebased: modifications in drm_hdcp_helper.c instead of drm_hdcp.c
Changes in v7:
-Rebased as function name has changed.

 drivers/gpu/drm/display/drm_hdcp_helper.c | 29 +++
 1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_hdcp_helper.c 
b/drivers/gpu/drm/display/drm_hdcp_helper.c
index 34baf2b97cd87..3ee1a6ae26c53 100644
--- a/drivers/gpu/drm/display/drm_hdcp_helper.c
+++ b/drivers/gpu/drm/display/drm_hdcp_helper.c
@@ -480,21 +480,30 @@ bool drm_hdcp_has_changed(struct drm_connector *connector,
return true;
 
/*
-* Nothing to do if content type is unchanged and one of:
-*  - state didn't change
-*  - HDCP was activated since the last commit
-*  - attempting to set to desired while already enabled
+* Content type changes require an HDCP disable/enable cycle.
 */
-   if (old_hdcp == new_hdcp ||
-   (old_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
+   if (new_conn_state->hdcp_content_type !=
+   old_conn_state->hdcp_content_type) {
+   new_conn_state->content_protection =
+   DRM_MODE_CONTENT_PROTECTION_DESIRED;
+   return true;
+   }
+
+   /*
+* Ignore meaningless state changes:
+*  - HDCP was activated since the last commit
+*  - Attempting to set to desired while already enabled
+*/
+   if ((old_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
 new_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED) ||
(old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
 new_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED)) {
-   if (old_conn_state->hdcp_content_type ==
-   new_conn_state->hdcp_content_type)
-   return false;
+   new_conn_state->content_protection =
+   DRM_MODE_CONTENT_PROTECTION_ENABLED;
+   return false;
}
 
-   return true;
+   /* Finally, if state changes, we need action */
+   return old_hdcp != new_hdcp;
 }
 EXPORT_SYMBOL(drm_hdcp_has_changed);
-- 
2.40.0.577.gac1e443424-goog

[PATCH v9 02/10] drm/hdcp: Avoid changing crtc state in hdcp atomic check

[Mark Yacoub]

From: Sean Paul 

Instead of forcing a modeset in the hdcp atomic check, rename to
drm_hdcp_has_changed and return true if the content protection value
is changing and let the driver decide whether a modeset is required or not.

Acked-by: Jani Nikula 
Reviewed-by: Rodrigo Vivi 
Signed-off-by: Sean Paul 
Signed-off-by: Mark Yacoub 

---
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-Rebase: modifications in drm_hdcp_helper.c instead of drm_hdcp.c
Changes in v7:
-Renamed the function from drm_hdcp_atomic_check to drm_hdcp_has_changed
(Dmitry Baryshkov)

 drivers/gpu/drm/display/drm_hdcp_helper.c   | 39 ++---
 drivers/gpu/drm/i915/display/intel_atomic.c |  6 ++--
 include/drm/display/drm_hdcp_helper.h   |  2 +-
 3 files changed, 30 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_hdcp_helper.c 
b/drivers/gpu/drm/display/drm_hdcp_helper.c
index 7ca390b3ea106..34baf2b97cd87 100644
--- a/drivers/gpu/drm/display/drm_hdcp_helper.c
+++ b/drivers/gpu/drm/display/drm_hdcp_helper.c
@@ -422,18 +422,21 @@ void drm_hdcp_update_content_protection(struct 
drm_connector *connector,
 EXPORT_SYMBOL(drm_hdcp_update_content_protection);
 
 /**
- * drm_hdcp_atomic_check - Helper for drivers to call during 
connector->atomic_check
+ * drm_hdcp_has_changed - Helper for drivers to call during 
connector->atomic_check
  *
  * @state: pointer to the atomic state being checked
  * @connector: drm_connector on which content protection state needs an update
  *
  * This function can be used by display drivers to perform an atomic check on 
the
- * hdcp state elements. If hdcp state has changed, this function will set
- * mode_changed on the crtc driving the connector so it can update its hardware
- * to match the hdcp state.
+ * hdcp state elements. If hdcp state has changed in a manner which requires 
the
+ * driver to enable or disable content protection, this function will return
+ * true.
+ *
+ * Returns:
+ * true if the driver must enable/disable hdcp, false otherwise
  */
-void drm_hdcp_atomic_check(struct drm_connector *connector,
-  struct drm_atomic_state *state)
+bool drm_hdcp_has_changed(struct drm_connector *connector,
+ struct drm_atomic_state *state)
 {
struct drm_connector_state *new_conn_state, *old_conn_state;
struct drm_crtc_state *new_crtc_state;
@@ -450,19 +453,31 @@ void drm_hdcp_atomic_check(struct drm_connector 
*connector,
 * If the connector is being disabled with CP enabled, mark it
 * desired so it's re-enabled when the connector is brought back
 */
-   if (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED)
+   if (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
new_conn_state->content_protection =
DRM_MODE_CONTENT_PROTECTION_DESIRED;
-   return;
+   return true;
+   }
+   return false;
}
 
new_crtc_state =
drm_atomic_get_new_crtc_state(state, new_conn_state->crtc);
if (drm_atomic_crtc_needs_modeset(new_crtc_state) &&
(old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
-new_hdcp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED))
+new_hdcp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED)) {
new_conn_state->content_protection =
DRM_MODE_CONTENT_PROTECTION_DESIRED;
+   return true;
+   }
+
+   /*
+* Coming back from UNDESIRED state, CRTC change or re-enablement 
requires
+* the driver to try CP enable.
+*/
+   if (new_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
+   new_conn_state->crtc != old_conn_state->crtc)
+   return true;
 
/*
 * Nothing to do if content type is unchanged and one of:
@@ -477,9 +492,9 @@ void drm_hdcp_atomic_check(struct drm_connector *connector,
 new_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED)) {
if (old_conn_state->hdcp_content_type ==
new_conn_state->hdcp_content_type)
-   return;
+   return false;
}
 
-   new_crtc_state->mode_changed = true;
+   return true;
 }
-EXPORT_SYMBOL(drm_hdcp_atomic_check);
+EXPORT_SYMBOL(drm_hdcp_has_changed);
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
b/drivers/gpu/drm/i915/display/intel_atomic.c
index e9d00b6a63d39..23a6ba315a22e 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -124,8 +124,6 @@ int intel_digital_connector_atomic_check(struct 
drm_connector *conn,
to_intel_digital_connector_state(old_state);
struct drm_crtc_state *crtc_state;
 
-   drm_hdcp_atomic_check(conn, state);
-
if (!new_state->crtc)

[PATCH v9 01/10] drm/hdcp: Add drm_hdcp_atomic_check()

[Mark Yacoub]

From: Sean Paul 

Move the hdcp atomic check from i915 to drm_hdcp so other
drivers can use it. No functional changes, just cleaned up some of the
code when moving it over.

Acked-by: Jani Nikula 
Reviewed-by: Rodrigo Vivi 
Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Sean Paul 
Signed-off-by: Mark Yacoub 

---
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-Rebase: move helper from drm_hdcp.c to drm_hdcp_helper.c
Changes in v7:
-Removed links to patch from commit msg (Dmitry Baryshkov)

 drivers/gpu/drm/display/drm_hdcp_helper.c   | 64 +
 drivers/gpu/drm/i915/display/intel_atomic.c |  4 +-
 drivers/gpu/drm/i915/display/intel_hdcp.c   | 47 ---
 drivers/gpu/drm/i915/display/intel_hdcp.h   |  3 -
 include/drm/display/drm_hdcp_helper.h   |  3 +
 5 files changed, 69 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_hdcp_helper.c 
b/drivers/gpu/drm/display/drm_hdcp_helper.c
index e78999c72bd77..7ca390b3ea106 100644
--- a/drivers/gpu/drm/display/drm_hdcp_helper.c
+++ b/drivers/gpu/drm/display/drm_hdcp_helper.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static inline void drm_hdcp_print_ksv(const u8 *ksv)
 {
@@ -419,3 +420,66 @@ void drm_hdcp_update_content_protection(struct 
drm_connector *connector,
 dev->mode_config.content_protection_property);
 }
 EXPORT_SYMBOL(drm_hdcp_update_content_protection);
+
+/**
+ * drm_hdcp_atomic_check - Helper for drivers to call during 
connector->atomic_check
+ *
+ * @state: pointer to the atomic state being checked
+ * @connector: drm_connector on which content protection state needs an update
+ *
+ * This function can be used by display drivers to perform an atomic check on 
the
+ * hdcp state elements. If hdcp state has changed, this function will set
+ * mode_changed on the crtc driving the connector so it can update its hardware
+ * to match the hdcp state.
+ */
+void drm_hdcp_atomic_check(struct drm_connector *connector,
+  struct drm_atomic_state *state)
+{
+   struct drm_connector_state *new_conn_state, *old_conn_state;
+   struct drm_crtc_state *new_crtc_state;
+   u64 old_hdcp, new_hdcp;
+
+   old_conn_state = drm_atomic_get_old_connector_state(state, connector);
+   old_hdcp = old_conn_state->content_protection;
+
+   new_conn_state = drm_atomic_get_new_connector_state(state, connector);
+   new_hdcp = new_conn_state->content_protection;
+
+   if (!new_conn_state->crtc) {
+   /*
+* If the connector is being disabled with CP enabled, mark it
+* desired so it's re-enabled when the connector is brought back
+*/
+   if (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED)
+   new_conn_state->content_protection =
+   DRM_MODE_CONTENT_PROTECTION_DESIRED;
+   return;
+   }
+
+   new_crtc_state =
+   drm_atomic_get_new_crtc_state(state, new_conn_state->crtc);
+   if (drm_atomic_crtc_needs_modeset(new_crtc_state) &&
+   (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
+new_hdcp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED))
+   new_conn_state->content_protection =
+   DRM_MODE_CONTENT_PROTECTION_DESIRED;
+
+   /*
+* Nothing to do if content type is unchanged and one of:
+*  - state didn't change
+*  - HDCP was activated since the last commit
+*  - attempting to set to desired while already enabled
+*/
+   if (old_hdcp == new_hdcp ||
+   (old_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
+new_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED) ||
+   (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
+new_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED)) {
+   if (old_conn_state->hdcp_content_type ==
+   new_conn_state->hdcp_content_type)
+   return;
+   }
+
+   new_crtc_state->mode_changed = true;
+}
+EXPORT_SYMBOL(drm_hdcp_atomic_check);
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
b/drivers/gpu/drm/i915/display/intel_atomic.c
index a9a3f3715279d..e9d00b6a63d39 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "i915_drv.h"
 #include "i915_reg.h"
@@ -39,7 +40,6 @@
 #include "intel_cdclk.h"
 #include "intel_display_types.h"
 #include "intel_global_state.h"
-#include "intel_hdcp.h"
 #include "intel_psr.h"
 #include "intel_fb.h"
 #include "skl_universal_plane.h"
@@ -124,7 +124,7 @@ int intel_digital_connector_atomic_check(struct 
drm_connector *conn,
to_intel_digital_connector_state(old_state);
struct drm_crtc_state *crtc_state;
 
-   

[PATCH v9 00/10] drm/hdcp: Pull HDCP auth/exchange/check into helpers

[Mark Yacoub]

Hi all,
This is v7 of the HDCP patches. The patches are authored by Sean Paul. 
I rebased and addressed the review comments in v6-v9.

Main change in v9 is renaming i915 priv data and moving the display type 
specific init to the drm helper instead of the driver.

Patches 1-4 focus on moving the common HDCP helpers to common DRM. 
This introduces a slight change in the original intel flow
as it splits the unique driver protocol from the generic implementation.

Patches 5-7 split the HDCP flow on the i915 driver to make use of the common 
DRM helpers.

Patches 8-10 implement HDCP on MSM driver.

Thanks,
-Mark Yacoub

Sean Paul (10):
  drm/hdcp: Add drm_hdcp_atomic_check()
  drm/hdcp: Avoid changing crtc state in hdcp atomic check
  drm/hdcp: Update property value on content type and user changes
  drm/hdcp: Expand HDCP helper library for enable/disable/check
  drm/i915/hdcp: Consolidate HDCP setup/state cache
  drm/i915/hdcp: Retain hdcp_capable return codes
  drm/i915/hdcp: Use HDCP helpers for i915
  dt-bindings: msm/dp: Add bindings for HDCP registers
  arm64: dts: qcom: sc7180: Add support for HDCP in dp-controller
  drm/msm: Implement HDCP 1.x using the new drm HDCP helpers

 .../bindings/display/msm/dp-controller.yaml   |7 +-
 arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi  |8 +
 drivers/gpu/drm/display/drm_hdcp_helper.c | 1224 +
 drivers/gpu/drm/i915/display/intel_atomic.c   |8 +-
 drivers/gpu/drm/i915/display/intel_ddi.c  |   32 +-
 .../drm/i915/display/intel_display_debugfs.c  |   12 +-
 .../drm/i915/display/intel_display_types.h|   51 +-
 drivers/gpu/drm/i915/display/intel_dp_hdcp.c  |  352 ++---
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |   16 +-
 drivers/gpu/drm/i915/display/intel_hdcp.c | 1060 +++---
 drivers/gpu/drm/i915/display/intel_hdcp.h |   48 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c |  267 ++--
 drivers/gpu/drm/msm/Kconfig   |1 +
 drivers/gpu/drm/msm/Makefile  |1 +
 drivers/gpu/drm/msm/dp/dp_catalog.c   |  156 +++
 drivers/gpu/drm/msm/dp/dp_catalog.h   |   18 +
 drivers/gpu/drm/msm/dp/dp_debug.c |   46 +-
 drivers/gpu/drm/msm/dp/dp_debug.h |   11 +-
 drivers/gpu/drm/msm/dp/dp_display.c   |   39 +-
 drivers/gpu/drm/msm/dp/dp_display.h   |5 +
 drivers/gpu/drm/msm/dp/dp_drm.c   |   39 +-
 drivers/gpu/drm/msm/dp/dp_drm.h   |7 +
 drivers/gpu/drm/msm/dp/dp_hdcp.c  |  389 ++
 drivers/gpu/drm/msm/dp/dp_hdcp.h  |   33 +
 drivers/gpu/drm/msm/dp/dp_parser.c|   14 +
 drivers/gpu/drm/msm/dp/dp_parser.h|4 +
 drivers/gpu/drm/msm/dp/dp_reg.h   |   30 +-
 drivers/gpu/drm/msm/msm_atomic.c  |   19 +
 include/drm/display/drm_hdcp.h|  296 
 include/drm/display/drm_hdcp_helper.h |   23 +
 30 files changed, 2867 insertions(+), 1349 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/dp/dp_hdcp.c
 create mode 100644 drivers/gpu/drm/msm/dp/dp_hdcp.h

-- 
2.40.0.577.gac1e443424-goog

Re: [PATCH] drm/bridge_connector: enable HPD by default if supported

[Yongqin Liu]

HI, All

Just an updated here.
As the commits listed the the following link merged into the
android-mainline kernel:

https://lore.kernel.org/linux-arm-kernel/20221102180705.459294-1-dmitry.barysh...@linaro.org/T/
The problem caused by this commit with x15 build is gone now.

Thanks,
Yongqin Liu
On Mon, 5 Sept 2022 at 13:26, Tomi Valkeinen
 wrote:
>
> On 31/08/2022 16:02, Tomi Valkeinen wrote:
> > Hi,
> >
> > On 23/02/2022 19:02, Kieran Bingham wrote:
> >> Quoting Laurent Pinchart (2022-02-23 16:25:28)
> >>> Hello,
> >>>
> >>> On Wed, Feb 23, 2022 at 04:17:22PM +, Kieran Bingham wrote:
>  Quoting Laurent Pinchart (2021-12-29 23:44:29)
> > On Sat, Dec 25, 2021 at 09:31:51AM +0300, Nikita Yushchenko wrote:
> >> Hotplug events reported by bridge drivers over
> >> drm_bridge_hpd_notify()
> >> get ignored unless somebody calls drm_bridge_hpd_enable(). When the
> >> connector for the bridge is bridge_connector, such a call is done
> >> from
> >> drm_bridge_connector_enable_hpd().
> >>
> >> However drm_bridge_connector_enable_hpd() is never called on init
> >> paths,
> >> documentation suggests that it is intended for suspend/resume paths.
> >
> > H... I'm in two minds about this. The problem description is
> > correct, but I wonder if HPD should be enabled unconditionally
> > here, or
> > if this should be left to display drivers to control.
> > drivers/gpu/drm/imx/dcss/dcss-kms.c enables HPD manually at init time,
> > other drivers don't.
> >
> > It feels like this should be under control of the display controller
> > driver, but I can't think of a use case for not enabling HPD at init
> > time. Any second opinion from anyone ?
> 
>  This patch solves an issue I have where I have recently enabled HPD on
>  the SN65DSI86, but without this, I do not get calls to my
>  .hpd_enable or
>  .hpd_disable hooks that I have added to the ti_sn_bridge_funcs.
> 
>  So it needs to be enabled somewhere, and this seems reasonable to me?
>  It's not directly related to the display controller - as it's a factor
>  of the bridge?
> 
>  On Falcon-V3U with HPD additions to SN65DSI86:
>  Tested-by: Kieran Bingham 
> >>>
> >>> If you think this is right, then
> >>>
> >>> Reviewed-by: Laurent Pinchart 
> >>
> >> I do, and at the very least it works for me, and fixes Nikita's issue so
> >> to me that's enough for:
> >
> > So who disables the HPD now?
> >
> > Is the drm_bridge_connector_enable_hpd &
> > drm_bridge_connector_disable_hpd documentation now wrong as they talk
> > about suspend/resume handlers?
>
> To give more context, currently omapdrm enables the HPDs at init time
> and disables them at remove time. With this patch, the HPDs are enabled
> twice, leading to a WARN.
>
> imx and msm drivers also seem to call drm_bridge_connector_enable_hpd(),
> so I would guess those also WARN with this patch.
>
> Afaics, this patch alone is broken, as it just disregards the drivers
> that already enable the HPD, and also as it doesn't handle the disabling
> of the HPD, or give any guidelines on how the drivers should now manage
> the HPD.
>
> My suggestion is to revert this one.
>
>   Tomi



-- 
Best Regards,
Yongqin Liu
---
#mailing list
linaro-andr...@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-android

Re: linux-next: build failure after merge of the driver-core tree

[Daniel Vetter]

On Tue, Apr 11, 2023 at 12:37:23PM -0600, Jeffrey Hugo wrote:
> On 4/11/2023 12:21 PM, Daniel Vetter wrote:
> > On Tue, Apr 11, 2023 at 11:18:29AM -0600, Jeffrey Hugo wrote:
> > > On 4/11/2023 10:31 AM, Daniel Vetter wrote:
> > > > On Tue, Apr 11, 2023 at 09:29:27AM -0600, Jeffrey Hugo wrote:
> > > > > On 4/11/2023 9:26 AM, Jeffrey Hugo wrote:
> > > > > > On 4/11/2023 9:13 AM, Greg KH wrote:
> > > > > > > On Tue, Apr 11, 2023 at 09:08:39AM -0600, Jeffrey Hugo wrote:
> > > > > > > > On 4/11/2023 9:01 AM, Daniel Vetter wrote:
> > > > > > > > > On Tue, Apr 11, 2023 at 12:40:28PM +0200, Greg KH wrote:
> > > > > > > > > > On Tue, Apr 11, 2023 at 11:55:20AM +0200, Daniel Vetter 
> > > > > > > > > > wrote:
> > > > > > > > > > > On Tue, Apr 11, 2023 at 02:38:12PM +1000, Stephen 
> > > > > > > > > > > Rothwell wrote:
> > > > > > > > > > > > Hi all,
> > > > > > > > > > > > 
> > > > > > > > > > > > After merging the driver-core tree, today's linux-next 
> > > > > > > > > > > > build (x86_64
> > > > > > > > > > > > allmodconfig) failed like this:
> > > > > > > > > > > > 
> > > > > > > > > > > > In file included from include/linux/linkage.h:7,
> > > > > > > > > > > >      from include/linux/kernel.h:17,
> > > > > > > > > > > >      from 
> > > > > > > > > > > > drivers/accel/qaic/mhi_qaic_ctrl.c:4:
> > > > > > > > > > > > drivers/accel/qaic/mhi_qaic_ctrl.c: In function
> > > > > > > > > > > > 'mhi_qaic_ctrl_init':
> > > > > > > > > > > > include/linux/export.h:27:22: error: passing
> > > > > > > > > > > > argument 1 of 'class_create' from incompatible
> > > > > > > > > > > > pointer type
> > > > > > > > > > > > [-Werror=incompatible-pointer-types]
> > > > > > > > > > > >    27 | #define THIS_MODULE (&__this_module)
> > > > > > > > > > > >       | ~^~~
> > > > > > > > > > > >       |  |
> > > > > > > > > > > >       |  struct module *
> > > > > > > > > > > > drivers/accel/qaic/mhi_qaic_ctrl.c:544:38: note:
> > > > > > > > > > > > in expansion of macro 'THIS_MODULE'
> > > > > > > > > > > >       544 | mqc_dev_class =
> > > > > > > > > > > > class_create(THIS_MODULE,
> > > > > > > > > > > > MHI_QAIC_CTRL_DRIVER_NAME);
> > > > > > > > > > > >       |  
> > > > > > > > > > > > ^~~
> > > > > > > > > > > > In file included from include/linux/device.h:31,
> > > > > > > > > > > >      from include/linux/mhi.h:9,
> > > > > > > > > > > >      from 
> > > > > > > > > > > > drivers/accel/qaic/mhi_qaic_ctrl.c:5:
> > > > > > > > > > > > include/linux/device/class.h:229:54: note:
> > > > > > > > > > > > expected 'const char *' but argument is of type
> > > > > > > > > > > > 'struct module *'
> > > > > > > > > > > >       229 | struct class * __must_check
> > > > > > > > > > > > class_create(const char *name);
> > > > > > > > > > > >       |  
> > > > > > > > > > > > ^~~~
> > > > > > > > > > > > drivers/accel/qaic/mhi_qaic_ctrl.c:544:25:
> > > > > > > > > > > > error: too many arguments to function
> > > > > > > > > > > > 'class_create'
> > > > > > > > > > > >       544 | mqc_dev_class =
> > > > > > > > > > > > class_create(THIS_MODULE,
> > > > > > > > > > > > MHI_QAIC_CTRL_DRIVER_NAME);
> > > > > > > > > > > >       | ^~~~
> > > > > > > > > > > > include/linux/device/class.h:229:29: note: declared here
> > > > > > > > > > > >       229 | struct class * __must_check
> > > > > > > > > > > > class_create(const char *name);
> > > > > > > > > > > >       | ^~~~
> > > > > > > > > > > > 
> > > > > > > > > > > > Caused by commit
> > > > > > > > > > > > 
> > > > > > > > > > > >       1aaba11da9aa ("driver core: class: remove
> > > > > > > > > > > > module * from class_create()")
> > > > > > > > > > > > 
> > > > > > > > > > > > interacting with commit
> > > > > > > > > > > > 
> > > > > > > > > > > >       566fc96198b4 ("accel/qaic: Add mhi_qaic_cntl")
> > > > > > > > > > > > 
> > > > > > > > > > > > from the drm tree.
> > > > > > > > > > > > 
> > > > > > > > > > > > I have applied the following merge fix patch for today.
> > > > > > > > > > > > 
> > > > > > > > > > > > From: Stephen Rothwell 
> > > > > > > > > > > > Date: Tue, 11 Apr 2023 14:16:57 +1000
> > > > > > > > > > > > Subject: [PATCH] fixup for "driver core: class:
> > > > > > > > > > > > remove module * from class_create()"
> > > > > > > > > > > > 
> > > > > > > > > > > > interacting with "accel/qaic: Add mhi_qaic_cntl"
> > > > > > > > > > > > 
> > > > > > > > > > > > Signed-off-by: Stephen Rothwell 
> > > > > > > > > > > 
> > > > > > > > > > > Thanks for the fixup. Since Dave is out I've made a
> > > > > > > > > > > note about this in my
> > > > > > > > > > > handover mail so it won't get lost in the drm-next
> > > > > > > > > > > merge 

Re: [PATCH v2 2/2] drm/msm/adreno: change adreno_is_* functions to accept const argument

[Stephen Boyd]

Quoting Dmitry Baryshkov (2023-04-11 09:19:03)
> All adreno_is_*() functions do not modify their argument in any way, so
> they can be changed to accept const struct adreno_gpu pointer.
>
> Suggested-by: Stephen Boyd 
> Signed-off-by: Dmitry Baryshkov 
> ---

Reviewed-by: Stephen Boyd 

Re: [PATCH v2 1/2] drm/msm/adreno: warn if chip revn is verified before being set

[Stephen Boyd]

Quoting Dmitry Baryshkov (2023-04-11 09:19:02)
> The commit 010c8bbad2cb ("drm: msm: adreno: Disable preemption on Adreno
> 510") tried to check GPU's revn before revn being set. Add WARN_ON_ONCE
> to prevent such bugs from happening again. A separate helper is
> necessary so that the warning is displayed really just once instead of
> being displayed for each of comparisons.
>
> Suggested-by: Stephen Boyd 
> Signed-off-by: Dmitry Baryshkov 
> ---

Reviewed-by: Stephen Boyd 

Re: linux-next: build failure after merge of the driver-core tree

[Jeffrey Hugo]

On 4/11/2023 12:21 PM, Daniel Vetter wrote:

On Tue, Apr 11, 2023 at 11:18:29AM -0600, Jeffrey Hugo wrote:

On 4/11/2023 10:31 AM, Daniel Vetter wrote:

On Tue, Apr 11, 2023 at 09:29:27AM -0600, Jeffrey Hugo wrote:

On 4/11/2023 9:26 AM, Jeffrey Hugo wrote:

On 4/11/2023 9:13 AM, Greg KH wrote:

On Tue, Apr 11, 2023 at 09:08:39AM -0600, Jeffrey Hugo wrote:

On 4/11/2023 9:01 AM, Daniel Vetter wrote:

On Tue, Apr 11, 2023 at 12:40:28PM +0200, Greg KH wrote:

On Tue, Apr 11, 2023 at 11:55:20AM +0200, Daniel Vetter wrote:

On Tue, Apr 11, 2023 at 02:38:12PM +1000, Stephen Rothwell wrote:

Hi all,

After merging the driver-core tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from include/linux/linkage.h:7,
     from include/linux/kernel.h:17,
     from drivers/accel/qaic/mhi_qaic_ctrl.c:4:
drivers/accel/qaic/mhi_qaic_ctrl.c: In function
'mhi_qaic_ctrl_init':
include/linux/export.h:27:22: error: passing
argument 1 of 'class_create' from incompatible
pointer type
[-Werror=incompatible-pointer-types]
   27 | #define THIS_MODULE (&__this_module)
      | ~^~~
      |  |
      |  struct module *
drivers/accel/qaic/mhi_qaic_ctrl.c:544:38: note:
in expansion of macro 'THIS_MODULE'
      544 | mqc_dev_class =
class_create(THIS_MODULE,
MHI_QAIC_CTRL_DRIVER_NAME);
      |  ^~~
In file included from include/linux/device.h:31,
     from include/linux/mhi.h:9,
     from drivers/accel/qaic/mhi_qaic_ctrl.c:5:
include/linux/device/class.h:229:54: note:
expected 'const char *' but argument is of type
'struct module *'
      229 | struct class * __must_check
class_create(const char *name);
      |  ^~~~
drivers/accel/qaic/mhi_qaic_ctrl.c:544:25:
error: too many arguments to function
'class_create'
      544 | mqc_dev_class =
class_create(THIS_MODULE,
MHI_QAIC_CTRL_DRIVER_NAME);
      | ^~~~
include/linux/device/class.h:229:29: note: declared here
      229 | struct class * __must_check
class_create(const char *name);
      | ^~~~

Caused by commit

      1aaba11da9aa ("driver core: class: remove
module * from class_create()")

interacting with commit

      566fc96198b4 ("accel/qaic: Add mhi_qaic_cntl")

from the drm tree.

I have applied the following merge fix patch for today.

From: Stephen Rothwell 
Date: Tue, 11 Apr 2023 14:16:57 +1000
Subject: [PATCH] fixup for "driver core: class:
remove module * from class_create()"

interacting with "accel/qaic: Add mhi_qaic_cntl"

Signed-off-by: Stephen Rothwell 


Thanks for the fixup. Since Dave is out I've made a
note about this in my
handover mail so it won't get lost in the drm-next
merge window pull. I
don't think we need any other coordination than
mention it in each pull to
Linus, topic tree seems overkill for this. Plus there's no way I can
untangle the drm tree anyway :-).


Want me to submit a patch for the drm tree that moves this to use
class_register() instead, which will make the
merge/build issue go away
for you?  That's my long-term goal here anyway, so converting this new
code to this api today would be something I have to do eventually :)


We kinda closed drm-next for feature work mostly already (just pulling
stuff in from subtrees), so won't really help for this merge window.

For everything else I think this is up to Oded, I had no
idea qaic needed
it's entire own dev class and I don't want to dig into this
for the risk I
might freak out :-)

Adding Oded.

Cheers, Daniel


Sorry for the mess.

I made a note to update to class_register() once my drm-misc access is
sorted out.  Looks like we'll address the conflict in the merge
window, and
catch the update to the new API in the following release.


Wait, I think the large question is, "why does this need a separate
class"?  Why are you not using the accel char device and class?  That is
what everything under accel/ should be using, otherwise why put it in
there?

And what exactly are you using that class for?  Just device nodes?  If
so, how many?

thanks,

greg k-h



Remember MHI_UCI that then evolved into the WWAN subsystem?  I pointed
out at the time that AIC100/QAIC would need the same functionality.
You/Jakub told myself/Mani/Loic that a combined implementation is not
acceptable, and every area needs to implement their own version of
MHI_UCI.

We took the WWAN subsystem and simplified it to meet our needs.

The functionality is QAIC specific, so wedging it into the Accel node
seems to be a poor fit as it would subject Habana and iVPU to the same.


Also, I forgot to mention.  QAIC is sharing userspace components with WWAN,
so we really cannot diverge from what WWAN has done and define a new API
through the Accel node.


So 

Re: [Freedreno] [PATCH v2 0/2] drm: fdinfo memory stats

[Rob Clark]

On Tue, Apr 11, 2023 at 10:36 AM Dmitry Baryshkov
 wrote:
>
> On Tue, 11 Apr 2023 at 20:13, Rob Clark  wrote:
> >
> > On Tue, Apr 11, 2023 at 9:53 AM Daniel Vetter  wrote:
> > >
> > > On Tue, Apr 11, 2023 at 09:47:32AM -0700, Rob Clark wrote:
> > > > On Mon, Apr 10, 2023 at 2:06 PM Rob Clark  wrote:
> > > > >
> > > > > From: Rob Clark 
> > > > >
> > > > > Similar motivation to other similar recent attempt[1].  But with an
> > > > > attempt to have some shared code for this.  As well as documentation.
> > > > >
> > > > > It is probably a bit UMA-centric, I guess devices with VRAM might want
> > > > > some placement stats as well.  But this seems like a reasonable start.
> > > > >
> > > > > Basic gputop support: https://patchwork.freedesktop.org/series/116236/
> > > > > And already nvtop support: https://github.com/Syllo/nvtop/pull/204
> > > >
> > > > On a related topic, I'm wondering if it would make sense to report
> > > > some more global things (temp, freq, etc) via fdinfo?  Some of this,
> > > > tools like nvtop could get by trawling sysfs or other driver specific
> > > > ways.  But maybe it makes sense to have these sort of things reported
> > > > in a standardized way (even though they aren't really per-drm_file)
> > >
> > > I think that's a bit much layering violation, we'd essentially have to
> > > reinvent the hwmon sysfs uapi in fdinfo. Not really a business I want to
> > > be in :-)
> >
> > I guess this is true for temp (where there are thermal zones with
> > potentially multiple temp sensors.. but I'm still digging my way thru
> > the thermal_cooling_device stuff)
>
> It is slightly ugly. All thermal zones and cooling devices are virtual
> devices (so, even no connection to the particular tsens device). One
> can either enumerate them by checking
> /sys/class/thermal/thermal_zoneN/type or enumerate them through
> /sys/class/hwmon. For cooling devices again the only enumeration is
> through /sys/class/thermal/cooling_deviceN/type.
>
> Probably it should be possible to push cooling devices and thermal
> zones under corresponding providers. However I do not know if there is
> a good way to correlate cooling device (ideally a part of GPU) to the
> thermal_zone (which in our case is provided by tsens / temp_alarm
> rather than GPU itself).
>
> >
> > But what about freq?  I think, esp for cases where some "fw thing" is
> > controlling the freq we end up needing to use gpu counters to measure
> > the freq.
>
> For the freq it is slightly easier: /sys/class/devfreq/*, devices are
> registered under proper parent (IOW, GPU). So one can read
> /sys/class/devfreq/3d0.gpu/cur_freq or
> /sys/bus/platform/devices/3d0.gpu/devfreq/3d0.gpu/cur_freq.
>
> However because of the components usage, there is no link from
> /sys/class/drm/card0
> (/sys/devices/platform/soc@0/ae0.display-subsystem/ae01000.display-controller/drm/card0)
> to /sys/devices/platform/soc@0/3d0.gpu, the GPU unit.
>
> Getting all these items together in a platform-independent way would
> be definitely an important but complex topic.

But I don't believe any of the pci gpu's use devfreq ;-)

And also, you can't expect the CPU to actually know the freq when fw
is the one controlling freq.  We can, currently, have a reasonable
approximation from devfreq but that stops if IFPC is implemented.  And
other GPUs have even less direct control.  So freq is a thing that I
don't think we should try to get from "common frameworks"

BR,
-R

> >
> > > What might be needed is better glue to go from the fd or fdinfo to the
> > > right hw device and then crawl around the hwmon in sysfs automatically. I
> > > would not be surprised at all if we really suck on this, probably more
> > > likely on SoC than pci gpus where at least everything should be under the
> > > main pci sysfs device.
> >
> > yeah, I *think* userspace would have to look at /proc/device-tree to
> > find the cooling device(s) associated with the gpu.. at least I don't
> > see a straightforward way to figure it out just for sysfs
> >
> > BR,
> > -R
> >
> > > -Daniel
> > >
> > > >
> > > > BR,
> > > > -R
> > > >
> > > >
> > > > > [1] https://patchwork.freedesktop.org/series/112397/
> > > > >
> > > > > Rob Clark (2):
> > > > >   drm: Add fdinfo memory stats
> > > > >   drm/msm: Add memory stats to fdinfo
> > > > >
> > > > >  Documentation/gpu/drm-usage-stats.rst | 21 +++
> > > > >  drivers/gpu/drm/drm_file.c| 79 
> > > > > +++
> > > > >  drivers/gpu/drm/msm/msm_drv.c | 25 -
> > > > >  drivers/gpu/drm/msm/msm_gpu.c |  2 -
> > > > >  include/drm/drm_file.h| 10 
> > > > >  5 files changed, 134 insertions(+), 3 deletions(-)
> > > > >
> > > > > --
> > > > > 2.39.2
> > > > >
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
>
>
>
> --
> With best wishes
> Dmitry

Re: [Freedreno] [PATCH v2 0/2] drm: fdinfo memory stats

[Daniel Vetter]

On Tue, Apr 11, 2023 at 08:35:48PM +0300, Dmitry Baryshkov wrote:
> On Tue, 11 Apr 2023 at 20:13, Rob Clark  wrote:
> >
> > On Tue, Apr 11, 2023 at 9:53 AM Daniel Vetter  wrote:
> > >
> > > On Tue, Apr 11, 2023 at 09:47:32AM -0700, Rob Clark wrote:
> > > > On Mon, Apr 10, 2023 at 2:06 PM Rob Clark  wrote:
> > > > >
> > > > > From: Rob Clark 
> > > > >
> > > > > Similar motivation to other similar recent attempt[1].  But with an
> > > > > attempt to have some shared code for this.  As well as documentation.
> > > > >
> > > > > It is probably a bit UMA-centric, I guess devices with VRAM might want
> > > > > some placement stats as well.  But this seems like a reasonable start.
> > > > >
> > > > > Basic gputop support: https://patchwork.freedesktop.org/series/116236/
> > > > > And already nvtop support: https://github.com/Syllo/nvtop/pull/204
> > > >
> > > > On a related topic, I'm wondering if it would make sense to report
> > > > some more global things (temp, freq, etc) via fdinfo?  Some of this,
> > > > tools like nvtop could get by trawling sysfs or other driver specific
> > > > ways.  But maybe it makes sense to have these sort of things reported
> > > > in a standardized way (even though they aren't really per-drm_file)
> > >
> > > I think that's a bit much layering violation, we'd essentially have to
> > > reinvent the hwmon sysfs uapi in fdinfo. Not really a business I want to
> > > be in :-)
> >
> > I guess this is true for temp (where there are thermal zones with
> > potentially multiple temp sensors.. but I'm still digging my way thru
> > the thermal_cooling_device stuff)
> 
> It is slightly ugly. All thermal zones and cooling devices are virtual
> devices (so, even no connection to the particular tsens device). One
> can either enumerate them by checking
> /sys/class/thermal/thermal_zoneN/type or enumerate them through
> /sys/class/hwmon. For cooling devices again the only enumeration is
> through /sys/class/thermal/cooling_deviceN/type.
> 
> Probably it should be possible to push cooling devices and thermal
> zones under corresponding providers. However I do not know if there is
> a good way to correlate cooling device (ideally a part of GPU) to the
> thermal_zone (which in our case is provided by tsens / temp_alarm
> rather than GPU itself).

There's not even sysfs links to connect the pieces in both ways?

> > But what about freq?  I think, esp for cases where some "fw thing" is
> > controlling the freq we end up needing to use gpu counters to measure
> > the freq.
> 
> For the freq it is slightly easier: /sys/class/devfreq/*, devices are
> registered under proper parent (IOW, GPU). So one can read
> /sys/class/devfreq/3d0.gpu/cur_freq or
> /sys/bus/platform/devices/3d0.gpu/devfreq/3d0.gpu/cur_freq.
> 
> However because of the components usage, there is no link from
> /sys/class/drm/card0
> (/sys/devices/platform/soc@0/ae0.display-subsystem/ae01000.display-controller/drm/card0)
> to /sys/devices/platform/soc@0/3d0.gpu, the GPU unit.

Hm ... do we need to make component more visible in sysfs, with _lots_
of links? Atm it's just not even there.

> Getting all these items together in a platform-independent way would
> be definitely an important but complex topic.

Yeah this sounds like some work. But also sounds like it's all generic
issues (thermal zones above and component here) that really should be
fixed at that level?

Cheers, Daniel


> > > What might be needed is better glue to go from the fd or fdinfo to the
> > > right hw device and then crawl around the hwmon in sysfs automatically. I
> > > would not be surprised at all if we really suck on this, probably more
> > > likely on SoC than pci gpus where at least everything should be under the
> > > main pci sysfs device.
> >
> > yeah, I *think* userspace would have to look at /proc/device-tree to
> > find the cooling device(s) associated with the gpu.. at least I don't
> > see a straightforward way to figure it out just for sysfs
> >
> > BR,
> > -R
> >
> > > -Daniel
> > >
> > > >
> > > > BR,
> > > > -R
> > > >
> > > >
> > > > > [1] https://patchwork.freedesktop.org/series/112397/
> > > > >
> > > > > Rob Clark (2):
> > > > >   drm: Add fdinfo memory stats
> > > > >   drm/msm: Add memory stats to fdinfo
> > > > >
> > > > >  Documentation/gpu/drm-usage-stats.rst | 21 +++
> > > > >  drivers/gpu/drm/drm_file.c| 79 
> > > > > +++
> > > > >  drivers/gpu/drm/msm/msm_drv.c | 25 -
> > > > >  drivers/gpu/drm/msm/msm_gpu.c |  2 -
> > > > >  include/drm/drm_file.h| 10 
> > > > >  5 files changed, 134 insertions(+), 3 deletions(-)
> > > > >
> > > > > --
> > > > > 2.39.2
> > > > >
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
> 
> 
> 
> -- 
> With best wishes
> Dmitry

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: linux-next: build failure after merge of the driver-core tree

[Daniel Vetter]

On Tue, Apr 11, 2023 at 11:18:29AM -0600, Jeffrey Hugo wrote:
> On 4/11/2023 10:31 AM, Daniel Vetter wrote:
> > On Tue, Apr 11, 2023 at 09:29:27AM -0600, Jeffrey Hugo wrote:
> > > On 4/11/2023 9:26 AM, Jeffrey Hugo wrote:
> > > > On 4/11/2023 9:13 AM, Greg KH wrote:
> > > > > On Tue, Apr 11, 2023 at 09:08:39AM -0600, Jeffrey Hugo wrote:
> > > > > > On 4/11/2023 9:01 AM, Daniel Vetter wrote:
> > > > > > > On Tue, Apr 11, 2023 at 12:40:28PM +0200, Greg KH wrote:
> > > > > > > > On Tue, Apr 11, 2023 at 11:55:20AM +0200, Daniel Vetter wrote:
> > > > > > > > > On Tue, Apr 11, 2023 at 02:38:12PM +1000, Stephen Rothwell 
> > > > > > > > > wrote:
> > > > > > > > > > Hi all,
> > > > > > > > > > 
> > > > > > > > > > After merging the driver-core tree, today's linux-next 
> > > > > > > > > > build (x86_64
> > > > > > > > > > allmodconfig) failed like this:
> > > > > > > > > > 
> > > > > > > > > > In file included from include/linux/linkage.h:7,
> > > > > > > > > >     from include/linux/kernel.h:17,
> > > > > > > > > >     from 
> > > > > > > > > > drivers/accel/qaic/mhi_qaic_ctrl.c:4:
> > > > > > > > > > drivers/accel/qaic/mhi_qaic_ctrl.c: In function
> > > > > > > > > > 'mhi_qaic_ctrl_init':
> > > > > > > > > > include/linux/export.h:27:22: error: passing
> > > > > > > > > > argument 1 of 'class_create' from incompatible
> > > > > > > > > > pointer type
> > > > > > > > > > [-Werror=incompatible-pointer-types]
> > > > > > > > > >   27 | #define THIS_MODULE (&__this_module)
> > > > > > > > > >      | ~^~~
> > > > > > > > > >      |  |
> > > > > > > > > >      |  struct module *
> > > > > > > > > > drivers/accel/qaic/mhi_qaic_ctrl.c:544:38: note:
> > > > > > > > > > in expansion of macro 'THIS_MODULE'
> > > > > > > > > >      544 | mqc_dev_class =
> > > > > > > > > > class_create(THIS_MODULE,
> > > > > > > > > > MHI_QAIC_CTRL_DRIVER_NAME);
> > > > > > > > > >      |  ^~~
> > > > > > > > > > In file included from include/linux/device.h:31,
> > > > > > > > > >     from include/linux/mhi.h:9,
> > > > > > > > > >     from 
> > > > > > > > > > drivers/accel/qaic/mhi_qaic_ctrl.c:5:
> > > > > > > > > > include/linux/device/class.h:229:54: note:
> > > > > > > > > > expected 'const char *' but argument is of type
> > > > > > > > > > 'struct module *'
> > > > > > > > > >      229 | struct class * __must_check
> > > > > > > > > > class_create(const char *name);
> > > > > > > > > >      |  
> > > > > > > > > > ^~~~
> > > > > > > > > > drivers/accel/qaic/mhi_qaic_ctrl.c:544:25:
> > > > > > > > > > error: too many arguments to function
> > > > > > > > > > 'class_create'
> > > > > > > > > >      544 | mqc_dev_class =
> > > > > > > > > > class_create(THIS_MODULE,
> > > > > > > > > > MHI_QAIC_CTRL_DRIVER_NAME);
> > > > > > > > > >      | ^~~~
> > > > > > > > > > include/linux/device/class.h:229:29: note: declared here
> > > > > > > > > >      229 | struct class * __must_check
> > > > > > > > > > class_create(const char *name);
> > > > > > > > > >      | ^~~~
> > > > > > > > > > 
> > > > > > > > > > Caused by commit
> > > > > > > > > > 
> > > > > > > > > >      1aaba11da9aa ("driver core: class: remove
> > > > > > > > > > module * from class_create()")
> > > > > > > > > > 
> > > > > > > > > > interacting with commit
> > > > > > > > > > 
> > > > > > > > > >      566fc96198b4 ("accel/qaic: Add mhi_qaic_cntl")
> > > > > > > > > > 
> > > > > > > > > > from the drm tree.
> > > > > > > > > > 
> > > > > > > > > > I have applied the following merge fix patch for today.
> > > > > > > > > > 
> > > > > > > > > > From: Stephen Rothwell 
> > > > > > > > > > Date: Tue, 11 Apr 2023 14:16:57 +1000
> > > > > > > > > > Subject: [PATCH] fixup for "driver core: class:
> > > > > > > > > > remove module * from class_create()"
> > > > > > > > > > 
> > > > > > > > > > interacting with "accel/qaic: Add mhi_qaic_cntl"
> > > > > > > > > > 
> > > > > > > > > > Signed-off-by: Stephen Rothwell 
> > > > > > > > > 
> > > > > > > > > Thanks for the fixup. Since Dave is out I've made a
> > > > > > > > > note about this in my
> > > > > > > > > handover mail so it won't get lost in the drm-next
> > > > > > > > > merge window pull. I
> > > > > > > > > don't think we need any other coordination than
> > > > > > > > > mention it in each pull to
> > > > > > > > > Linus, topic tree seems overkill for this. Plus there's no 
> > > > > > > > > way I can
> > > > > > > > > untangle the drm tree anyway :-).
> > > > > > > > 
> > > > > > > > Want me to submit a patch for the drm tree that moves this to 
> > > > > > > > use
> > > > > > > > class_register() instead, which will make the
> > > > > > > > merge/build issue go away
> > > > > > > > 

Re: [PATCH] drm/scheduler: set entity to NULL in drm_sched_entity_pop_job()

[Danilo Krummrich]

On 4/5/23 19:39, Luben Tuikov wrote:

On 2023-03-31 01:59, Christian König wrote:

Am 31.03.23 um 02:06 schrieb Danilo Krummrich:

It already happend a few times that patches slipped through which
implemented access to an entity through a job that was already removed
from the entities queue. Since jobs and entities might have different
lifecycles, this can potentially cause UAF bugs.

In order to make it obvious that a jobs entity pointer shouldn't be
accessed after drm_sched_entity_pop_job() was called successfully, set
the jobs entity pointer to NULL once the job is removed from the entity
queue.

Moreover, debugging a potential NULL pointer dereference is way easier
than potentially corrupted memory through a UAF.

Signed-off-by: Danilo Krummrich 


In general "YES PLEASE!", but I fear that this will break amdgpus reset
sequence.

On the other hand when amdgpu still relies on that pointer it's clearly
a bug (which I pointed out tons of times before).

Luben any opinion on that? Could you drive cleaning that up as well?


I didn't find any references to scheduling entity after the job
is submitted to the hardware. (I commented the same in the other
thread, we just need to decide which way to go.)


AFAICS from the other mail thread it seems to be consensus to not 
ref-count entities and handle job statistics differently.


Should we go ahead and take this patch then? Maybe it also makes sense 
to send a V2 additionally adding a comment to the drm_sched_job 
structure mentioning that .entity must not be used after the job was 
taken from the entities queue.


- Danilo



Regards,
Luben



Thanks,
Christian.


---
I'm aware that drivers could already use job->entity in arbitrary places, since
they in control of when the entity is actually freed. A quick grep didn't give
me any results where this would actually be the case, however maybe I also just
didn't catch it.

If, therefore, we don't want to set job->entity to NULL I think we should at
least add a comment somewhere.
---

   drivers/gpu/drm/scheduler/sched_entity.c | 6 ++
   1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/scheduler/sched_entity.c 
b/drivers/gpu/drm/scheduler/sched_entity.c
index 15d04a0ec623..a9c6118e534b 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -448,6 +448,12 @@ struct drm_sched_job *drm_sched_entity_pop_job(struct 
drm_sched_entity *entity)
drm_sched_rq_update_fifo(entity, next->submit_ts);
}
   
+	/* Jobs and entities might have different lifecycles. Since we're

+* removing the job from the entities queue, set the jobs entity pointer
+* to NULL to prevent any future access of the entity through this job.
+*/
+   sched_job->entity = NULL;
+
return sched_job;
   }
   

Re: [PATCH] drm/armada: Fix a potential double free in an error handling path

[Christophe JAILLET]

Le 26/12/2021 à 17:34, Christophe JAILLET a écrit :

'priv' is a managed resource, so there is no need to free it explicitly or
there will be a double free().

Fixes: 90ad200b4cbc ("drm/armada: Use devm_drm_dev_alloc")
Signed-off-by: Christophe JAILLET 
---
  drivers/gpu/drm/armada/armada_drv.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/armada/armada_drv.c 
b/drivers/gpu/drm/armada/armada_drv.c
index 8e3e98f13db4..54168134d9b9 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -99,7 +99,6 @@ static int armada_drm_bind(struct device *dev)
if (ret) {
dev_err(dev, "[" DRM_NAME ":%s] can't kick out simple-fb: %d\n",
__func__, ret);
-   kfree(priv);
return ret;
}
  


Hi,

polite reminder. (I've updated the mails according to the output of 
get_maintainer.pl)


The patch still LGTM and should apply cleanly.

CJ

Re: [PATCH] drm/vmwgfx: remove unused mksstat_init_record function

[Zack Rusin]

On Fri, 2023-03-24 at 15:54 -0400, Tom Rix wrote:
> clang with W=1 reports
> drivers/gpu/drm/vmwgfx/vmwgfx_msg.c:716:21: error: unused function
>   'mksstat_init_record' [-Werror,-Wunused-function]
> static inline char *mksstat_init_record(mksstat_kern_stats_t stat_idx,
>     ^
> This function is not used so remove it.
> 
> Signed-off-by: Tom Rix 

Thanks, Martin Krastev already sent the same patch to the dri-devel two weeks
before. It's in the drm-misc-next branch in the drm-misc tree and should 
migrate to
kernel for 6.4.

z

Re: [PATCH] drm/doc/rfc: Introduce the merge plan for the Xe driver.

[Daniel Vetter]

On Wed, 5 Apr 2023 at 21:52, Rodrigo Vivi  wrote:
>
> Let’s establish a merge plan for Xe, by writing down clear pre-merge goals, in
> order to avoid unnecessary delays.
>
> This initial document starts with a TODO list containing items with clear and
> measurable key results. Xe’s initial pull request should only be sent to
> dri-devel after all the items are clearly resolved.
>
> Since many of them involve some level of a community consensus, in many cases,
> the consensus will be reached in follow-up patches to this document with more
> details of the API or helpers that will be developed or modified.
>
> Cc: Dave Airlie 
> Cc: Daniel Vetter 
> Cc: Oded Gabbay 
> Signed-off-by: Rodrigo Vivi 
> Signed-off-by: Francois Dugast 
> Signed-off-by: Luis Strano 
> Signed-off-by: Matthew Brost 
> Signed-off-by: Thomas Hellström 
> ---
>  Documentation/gpu/rfc/index.rst |   4 +
>  Documentation/gpu/rfc/xe.rst| 216 
>  2 files changed, 220 insertions(+)
>  create mode 100644 Documentation/gpu/rfc/xe.rst
>
> diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst
> index 476719771eef..e4f7b005138d 100644
> --- a/Documentation/gpu/rfc/index.rst
> +++ b/Documentation/gpu/rfc/index.rst
> @@ -31,3 +31,7 @@ host such documentation:
>  .. toctree::
>
>  i915_vm_bind.rst
> +
> +.. toctree::
> +
> +   xe.rst
> diff --git a/Documentation/gpu/rfc/xe.rst b/Documentation/gpu/rfc/xe.rst
> new file mode 100644
> index ..1e3e7e9c67c3
> --- /dev/null
> +++ b/Documentation/gpu/rfc/xe.rst
> @@ -0,0 +1,216 @@
> +==
> +Xe – Merge Acceptance Plan
> +==
> +Xe is a new driver for Intel GPUs that supports both integrated and
> +discrete platforms starting with Tiger Lake (first Intel Xe Architecture).
> +
> +This document aims to establish a merge plan for the Xe, by writing down 
> clear
> +pre-merge goals, in order to avoid unnecessary delays.
> +
> +Xe – Overview
> +=
> +The main motivation of Xe is to have a fresh base to work from that is
> +unencumbered by older platforms, whilst also taking the opportunity to
> +rearchitect our driver to increase sharing across the drm subsystem, both
> +leveraging and allowing us to contribute more towards other shared components
> +like TTM and drm/scheduler.
> +
> +This is also an opportunity to start from the beginning with a clean uAPI 
> that is
> +extensible by design and already aligned with the modern userspace needs. For
> +this reason, the memory model is solely based on GPU Virtual Address space
> +bind/unbind (‘VM_BIND’) of GEM buffer objects (BOs) and execution only 
> supporting
> +explicit synchronization. With persistent mapping across the execution, the
> +userspace does not need to provide a list of all required mappings during 
> each
> +submission.
> +
> +The new driver leverages a lot from i915. As for display, the intent is to 
> share
> +the display code with the i915 driver so that there is maximum reuse there.
> +
> +As for the power management area, the goal is to have a much-simplified 
> support
> +for the system suspend states (S-states), PCI device suspend states 
> (D-states),
> +GPU/Render suspend states (R-states) and frequency management. It should 
> leverage
> +as much as possible all the existent PCI-subsystem infrastructure (pm and
> +runtime_pm) and underlying firmware components such PCODE and GuC for the 
> power
> +states and frequency decisions.
> +
> +Repository:
> +
> +https://gitlab.freedesktop.org/drm/xe/kernel (branch drm-xe-next)
> +
> +Xe – Platforms
> +==
> +Currently, Xe is already functional and has experimental support for multiple
> +platforms starting from Tiger Lake, with initial support in userspace 
> implemented
> +in Mesa (for Iris and Anv, our OpenGL and Vulkan drivers), as well as in NEO
> +(for OpenCL and Level0).
> +
> +During a transition period, platforms will be supported by both Xe and i915.
> +However, the force_probe mechanism existent in both drivers will allow only 
> one
> +official and by-default probe at a given time.
> +
> +For instance, in order to probe a DG2 which PCI ID is 0x5690 by Xe instead of
> +i915, the following set of parameters need to be used:
> +
> +```
> +i915.force_probe=!5690 xe.force_probe=5690
> +```
> +
> +In both drivers, the ‘.require_force_probe’ protection forces the user to 
> use the
> +force_probe parameter while the driver is under development. This protection 
> is
> +only removed when the support for the platform and the uAPI are stable. 
> Stability
> +which needs to be demonstrated by CI results.
> +
> +In order to avoid user space regressions, i915 will continue to support all 
> the
> +current platforms that are already out of this protection. Xe support will be
> +forever experimental and dependent on the usage of force_probe for these
> +platforms.
> +
> +When the time comes for Xe, the protection will be lifted on Xe and kept in 
> i915.
> 

Re: [PATCH] drm/vmwgfx: remove unused vmw_overlay function

[Zack Rusin]

On Tue, 2023-03-21 at 14:24 -0400, Tom Rix wrote:
> clang with W=1 reports
> drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:56:35: error:
>   unused function 'vmw_overlay' [-Werror,-Wunused-function]
> static inline struct vmw_overlay *vmw_overlay(struct drm_device *dev)
>   ^
> This function is not used, so remove it.
> 
> Signed-off-by: Tom Rix 

Thank you for the patch. I went ahead and pushed it to the drm-misc-next branch 
in
drm-misc tree.

z

Re: [PATCH] fbdev: Don't spam dmesg on bad userspace ioctl input

[Michel Dänzer]

On 4/11/23 11:10, Geert Uytterhoeven wrote:
> Hi Michel,
> 
> On Wed, Apr 5, 2023 at 10:50 AM Michel Dänzer
>  wrote:
>> On 4/4/23 14:36, Daniel Vetter wrote:
>>> There's a few reasons the kernel should not spam dmesg on bad
>>> userspace ioctl input:
>>> - at warning level it results in CI false positives
>>> - it allows userspace to drown dmesg output, potentially hiding real
>>>   issues.
>>>
>>> None of the other generic EINVAL checks report in the
>>> FBIOPUT_VSCREENINFO ioctl do this, so it's also inconsistent.
>>>
>>> I guess the intent of the patch which introduced this warning was that
>>> the drivers ->fb_check_var routine should fail in that case. Reality
>>> is that there's too many fbdev drivers and not enough people
>>> maintaining them by far, and so over the past few years we've simply
>>> handled all these validation gaps by tighning the checks in the core,
>>> because that's realistically really all that will ever happen.
>>>
>>> Reported-by: syzbot+20dcf81733d43ddff...@syzkaller.appspotmail.com
>>> Link: 
>>> https://syzkaller.appspot.com/bug?id=c5faf983bfa4a607de530cd3bb00bf06cefc
>>> Fixes: 6c11df58fd1a ("fbmem: Check virtual screen sizes in fb_set_var()")
>>> Cc: Helge Deller 
>>> Cc: Geert Uytterhoeven 
>>> Cc: sta...@vger.kernel.org # v5.4+
>>> Cc: Daniel Vetter 
>>> Cc: Javier Martinez Canillas 
>>> Cc: Thomas Zimmermann 
>>> Signed-off-by: Daniel Vetter 
>>> ---
>>>  drivers/video/fbdev/core/fbmem.c | 4 
>>>  1 file changed, 4 deletions(-)
>>>
>>> diff --git a/drivers/video/fbdev/core/fbmem.c 
>>> b/drivers/video/fbdev/core/fbmem.c
>>> index 875541ff185b..9757f4bcdf57 100644
>>> --- a/drivers/video/fbdev/core/fbmem.c
>>> +++ b/drivers/video/fbdev/core/fbmem.c
>>> @@ -1021,10 +1021,6 @@ fb_set_var(struct fb_info *info, struct 
>>> fb_var_screeninfo *var)
>>>   /* verify that virtual resolution >= physical resolution */
>>>   if (var->xres_virtual < var->xres ||
>>>   var->yres_virtual < var->yres) {
>>> - pr_warn("WARNING: fbcon: Driver '%s' missed to adjust virtual 
>>> screen size (%ux%u vs. %ux%u)\n",
>>> - info->fix.id,
>>> - var->xres_virtual, var->yres_virtual,
>>> - var->xres, var->yres);
>>>   return -EINVAL;
>>>   }
>>>
>>
>> Make it pr_warn_once? 99.9...% of the benefit, without spam.
> 
> Except that it should be pr_warn_once_per_fb_info, [...]

Not really, that's what I mean by 99.9...% of the benefit. Even if a broken 
driver is masked on some systems, eventually the other driver masking it should 
get fixed, at which point the previously masked driver will be reported again.


-- 
Earthling Michel Dänzer|  https://redhat.com
Libre software enthusiast  | Mesa and Xwayland developer

Re: [Freedreno] [PATCH v2 0/2] drm: fdinfo memory stats

[Dmitry Baryshkov]

On Tue, 11 Apr 2023 at 20:13, Rob Clark  wrote:
>
> On Tue, Apr 11, 2023 at 9:53 AM Daniel Vetter  wrote:
> >
> > On Tue, Apr 11, 2023 at 09:47:32AM -0700, Rob Clark wrote:
> > > On Mon, Apr 10, 2023 at 2:06 PM Rob Clark  wrote:
> > > >
> > > > From: Rob Clark 
> > > >
> > > > Similar motivation to other similar recent attempt[1].  But with an
> > > > attempt to have some shared code for this.  As well as documentation.
> > > >
> > > > It is probably a bit UMA-centric, I guess devices with VRAM might want
> > > > some placement stats as well.  But this seems like a reasonable start.
> > > >
> > > > Basic gputop support: https://patchwork.freedesktop.org/series/116236/
> > > > And already nvtop support: https://github.com/Syllo/nvtop/pull/204
> > >
> > > On a related topic, I'm wondering if it would make sense to report
> > > some more global things (temp, freq, etc) via fdinfo?  Some of this,
> > > tools like nvtop could get by trawling sysfs or other driver specific
> > > ways.  But maybe it makes sense to have these sort of things reported
> > > in a standardized way (even though they aren't really per-drm_file)
> >
> > I think that's a bit much layering violation, we'd essentially have to
> > reinvent the hwmon sysfs uapi in fdinfo. Not really a business I want to
> > be in :-)
>
> I guess this is true for temp (where there are thermal zones with
> potentially multiple temp sensors.. but I'm still digging my way thru
> the thermal_cooling_device stuff)

It is slightly ugly. All thermal zones and cooling devices are virtual
devices (so, even no connection to the particular tsens device). One
can either enumerate them by checking
/sys/class/thermal/thermal_zoneN/type or enumerate them through
/sys/class/hwmon. For cooling devices again the only enumeration is
through /sys/class/thermal/cooling_deviceN/type.

Probably it should be possible to push cooling devices and thermal
zones under corresponding providers. However I do not know if there is
a good way to correlate cooling device (ideally a part of GPU) to the
thermal_zone (which in our case is provided by tsens / temp_alarm
rather than GPU itself).

>
> But what about freq?  I think, esp for cases where some "fw thing" is
> controlling the freq we end up needing to use gpu counters to measure
> the freq.

For the freq it is slightly easier: /sys/class/devfreq/*, devices are
registered under proper parent (IOW, GPU). So one can read
/sys/class/devfreq/3d0.gpu/cur_freq or
/sys/bus/platform/devices/3d0.gpu/devfreq/3d0.gpu/cur_freq.

However because of the components usage, there is no link from
/sys/class/drm/card0
(/sys/devices/platform/soc@0/ae0.display-subsystem/ae01000.display-controller/drm/card0)
to /sys/devices/platform/soc@0/3d0.gpu, the GPU unit.

Getting all these items together in a platform-independent way would
be definitely an important but complex topic.

>
> > What might be needed is better glue to go from the fd or fdinfo to the
> > right hw device and then crawl around the hwmon in sysfs automatically. I
> > would not be surprised at all if we really suck on this, probably more
> > likely on SoC than pci gpus where at least everything should be under the
> > main pci sysfs device.
>
> yeah, I *think* userspace would have to look at /proc/device-tree to
> find the cooling device(s) associated with the gpu.. at least I don't
> see a straightforward way to figure it out just for sysfs
>
> BR,
> -R
>
> > -Daniel
> >
> > >
> > > BR,
> > > -R
> > >
> > >
> > > > [1] https://patchwork.freedesktop.org/series/112397/
> > > >
> > > > Rob Clark (2):
> > > >   drm: Add fdinfo memory stats
> > > >   drm/msm: Add memory stats to fdinfo
> > > >
> > > >  Documentation/gpu/drm-usage-stats.rst | 21 +++
> > > >  drivers/gpu/drm/drm_file.c| 79 +++
> > > >  drivers/gpu/drm/msm/msm_drv.c | 25 -
> > > >  drivers/gpu/drm/msm/msm_gpu.c |  2 -
> > > >  include/drm/drm_file.h| 10 
> > > >  5 files changed, 134 insertions(+), 3 deletions(-)
> > > >
> > > > --
> > > > 2.39.2
> > > >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch



-- 
With best wishes
Dmitry

Re: linux-next: build failure after merge of the driver-core tree

[Jeffrey Hugo]

On 4/11/2023 10:31 AM, Daniel Vetter wrote:

On Tue, Apr 11, 2023 at 09:29:27AM -0600, Jeffrey Hugo wrote:

On 4/11/2023 9:26 AM, Jeffrey Hugo wrote:

On 4/11/2023 9:13 AM, Greg KH wrote:

On Tue, Apr 11, 2023 at 09:08:39AM -0600, Jeffrey Hugo wrote:

On 4/11/2023 9:01 AM, Daniel Vetter wrote:

On Tue, Apr 11, 2023 at 12:40:28PM +0200, Greg KH wrote:

On Tue, Apr 11, 2023 at 11:55:20AM +0200, Daniel Vetter wrote:

On Tue, Apr 11, 2023 at 02:38:12PM +1000, Stephen Rothwell wrote:

Hi all,

After merging the driver-core tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from include/linux/linkage.h:7,
    from include/linux/kernel.h:17,
    from drivers/accel/qaic/mhi_qaic_ctrl.c:4:
drivers/accel/qaic/mhi_qaic_ctrl.c: In function
'mhi_qaic_ctrl_init':
include/linux/export.h:27:22: error: passing
argument 1 of 'class_create' from incompatible
pointer type
[-Werror=incompatible-pointer-types]
  27 | #define THIS_MODULE (&__this_module)
     | ~^~~
     |  |
     |  struct module *
drivers/accel/qaic/mhi_qaic_ctrl.c:544:38: note:
in expansion of macro 'THIS_MODULE'
     544 | mqc_dev_class =
class_create(THIS_MODULE,
MHI_QAIC_CTRL_DRIVER_NAME);
     |  ^~~
In file included from include/linux/device.h:31,
    from include/linux/mhi.h:9,
    from drivers/accel/qaic/mhi_qaic_ctrl.c:5:
include/linux/device/class.h:229:54: note:
expected 'const char *' but argument is of type
'struct module *'
     229 | struct class * __must_check
class_create(const char *name);
     |  ^~~~
drivers/accel/qaic/mhi_qaic_ctrl.c:544:25:
error: too many arguments to function
'class_create'
     544 | mqc_dev_class =
class_create(THIS_MODULE,
MHI_QAIC_CTRL_DRIVER_NAME);
     | ^~~~
include/linux/device/class.h:229:29: note: declared here
     229 | struct class * __must_check
class_create(const char *name);
     | ^~~~

Caused by commit

     1aaba11da9aa ("driver core: class: remove
module * from class_create()")

interacting with commit

     566fc96198b4 ("accel/qaic: Add mhi_qaic_cntl")

from the drm tree.

I have applied the following merge fix patch for today.

From: Stephen Rothwell 
Date: Tue, 11 Apr 2023 14:16:57 +1000
Subject: [PATCH] fixup for "driver core: class:
remove module * from class_create()"

interacting with "accel/qaic: Add mhi_qaic_cntl"

Signed-off-by: Stephen Rothwell 


Thanks for the fixup. Since Dave is out I've made a
note about this in my
handover mail so it won't get lost in the drm-next
merge window pull. I
don't think we need any other coordination than
mention it in each pull to
Linus, topic tree seems overkill for this. Plus there's no way I can
untangle the drm tree anyway :-).


Want me to submit a patch for the drm tree that moves this to use
class_register() instead, which will make the
merge/build issue go away
for you?  That's my long-term goal here anyway, so converting this new
code to this api today would be something I have to do eventually :)


We kinda closed drm-next for feature work mostly already (just pulling
stuff in from subtrees), so won't really help for this merge window.

For everything else I think this is up to Oded, I had no
idea qaic needed
it's entire own dev class and I don't want to dig into this
for the risk I
might freak out :-)

Adding Oded.

Cheers, Daniel


Sorry for the mess.

I made a note to update to class_register() once my drm-misc access is
sorted out.  Looks like we'll address the conflict in the merge
window, and
catch the update to the new API in the following release.


Wait, I think the large question is, "why does this need a separate
class"?  Why are you not using the accel char device and class?  That is
what everything under accel/ should be using, otherwise why put it in
there?

And what exactly are you using that class for?  Just device nodes?  If
so, how many?

thanks,

greg k-h



Remember MHI_UCI that then evolved into the WWAN subsystem?  I pointed
out at the time that AIC100/QAIC would need the same functionality.
You/Jakub told myself/Mani/Loic that a combined implementation is not
acceptable, and every area needs to implement their own version of
MHI_UCI.

We took the WWAN subsystem and simplified it to meet our needs.

The functionality is QAIC specific, so wedging it into the Accel node
seems to be a poor fit as it would subject Habana and iVPU to the same.


Also, I forgot to mention.  QAIC is sharing userspace components with WWAN,
so we really cannot diverge from what WWAN has done and define a new API
through the Accel node.


So there is an accel/drm_device in the qaic driver, but there's also this
different class thing, which I don't get.

And yeah if 

Re: [PATCH v2 0/2] drm: fdinfo memory stats

[Rob Clark]

On Tue, Apr 11, 2023 at 9:53 AM Daniel Vetter  wrote:
>
> On Tue, Apr 11, 2023 at 09:47:32AM -0700, Rob Clark wrote:
> > On Mon, Apr 10, 2023 at 2:06 PM Rob Clark  wrote:
> > >
> > > From: Rob Clark 
> > >
> > > Similar motivation to other similar recent attempt[1].  But with an
> > > attempt to have some shared code for this.  As well as documentation.
> > >
> > > It is probably a bit UMA-centric, I guess devices with VRAM might want
> > > some placement stats as well.  But this seems like a reasonable start.
> > >
> > > Basic gputop support: https://patchwork.freedesktop.org/series/116236/
> > > And already nvtop support: https://github.com/Syllo/nvtop/pull/204
> >
> > On a related topic, I'm wondering if it would make sense to report
> > some more global things (temp, freq, etc) via fdinfo?  Some of this,
> > tools like nvtop could get by trawling sysfs or other driver specific
> > ways.  But maybe it makes sense to have these sort of things reported
> > in a standardized way (even though they aren't really per-drm_file)
>
> I think that's a bit much layering violation, we'd essentially have to
> reinvent the hwmon sysfs uapi in fdinfo. Not really a business I want to
> be in :-)

I guess this is true for temp (where there are thermal zones with
potentially multiple temp sensors.. but I'm still digging my way thru
the thermal_cooling_device stuff)

But what about freq?  I think, esp for cases where some "fw thing" is
controlling the freq we end up needing to use gpu counters to measure
the freq.

> What might be needed is better glue to go from the fd or fdinfo to the
> right hw device and then crawl around the hwmon in sysfs automatically. I
> would not be surprised at all if we really suck on this, probably more
> likely on SoC than pci gpus where at least everything should be under the
> main pci sysfs device.

yeah, I *think* userspace would have to look at /proc/device-tree to
find the cooling device(s) associated with the gpu.. at least I don't
see a straightforward way to figure it out just for sysfs

BR,
-R

> -Daniel
>
> >
> > BR,
> > -R
> >
> >
> > > [1] https://patchwork.freedesktop.org/series/112397/
> > >
> > > Rob Clark (2):
> > >   drm: Add fdinfo memory stats
> > >   drm/msm: Add memory stats to fdinfo
> > >
> > >  Documentation/gpu/drm-usage-stats.rst | 21 +++
> > >  drivers/gpu/drm/drm_file.c| 79 +++
> > >  drivers/gpu/drm/msm/msm_drv.c | 25 -
> > >  drivers/gpu/drm/msm/msm_gpu.c |  2 -
> > >  include/drm/drm_file.h| 10 
> > >  5 files changed, 134 insertions(+), 3 deletions(-)
> > >
> > > --
> > > 2.39.2
> > >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

Re: [PATCH v2 0/2] drm: fdinfo memory stats

[Daniel Vetter]

On Tue, Apr 11, 2023 at 09:47:32AM -0700, Rob Clark wrote:
> On Mon, Apr 10, 2023 at 2:06 PM Rob Clark  wrote:
> >
> > From: Rob Clark 
> >
> > Similar motivation to other similar recent attempt[1].  But with an
> > attempt to have some shared code for this.  As well as documentation.
> >
> > It is probably a bit UMA-centric, I guess devices with VRAM might want
> > some placement stats as well.  But this seems like a reasonable start.
> >
> > Basic gputop support: https://patchwork.freedesktop.org/series/116236/
> > And already nvtop support: https://github.com/Syllo/nvtop/pull/204
> 
> On a related topic, I'm wondering if it would make sense to report
> some more global things (temp, freq, etc) via fdinfo?  Some of this,
> tools like nvtop could get by trawling sysfs or other driver specific
> ways.  But maybe it makes sense to have these sort of things reported
> in a standardized way (even though they aren't really per-drm_file)

I think that's a bit much layering violation, we'd essentially have to
reinvent the hwmon sysfs uapi in fdinfo. Not really a business I want to
be in :-)

What might be needed is better glue to go from the fd or fdinfo to the
right hw device and then crawl around the hwmon in sysfs automatically. I
would not be surprised at all if we really suck on this, probably more
likely on SoC than pci gpus where at least everything should be under the
main pci sysfs device.
-Daniel

> 
> BR,
> -R
> 
> 
> > [1] https://patchwork.freedesktop.org/series/112397/
> >
> > Rob Clark (2):
> >   drm: Add fdinfo memory stats
> >   drm/msm: Add memory stats to fdinfo
> >
> >  Documentation/gpu/drm-usage-stats.rst | 21 +++
> >  drivers/gpu/drm/drm_file.c| 79 +++
> >  drivers/gpu/drm/msm/msm_drv.c | 25 -
> >  drivers/gpu/drm/msm/msm_gpu.c |  2 -
> >  include/drm/drm_file.h| 10 
> >  5 files changed, 134 insertions(+), 3 deletions(-)
> >
> > --
> > 2.39.2
> >

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 0/2] Add support for dumping error captures via kernel logging

[Daniel Vetter]

On Tue, Apr 11, 2023 at 09:41:04AM -0700, John Harrison wrote:
> On 4/11/2023 07:41, Rodrigo Vivi wrote:
> > On Mon, Apr 10, 2023 at 12:25:21PM -0700, john.c.harri...@intel.com wrote:
> > > From: John Harrison 
> > > 
> > > Sometimes, the only effective way to debug an issue is to dump all the
> > > interesting information at the point of failure. So add support for
> > > doing that.
> > No! Please no!
> > We have some of this on Xe and I'm hating it. I'm going to try to remove
> > from there soon. It is horrible when you lost the hability to use dmesg
> > directly because it goes over the number of lines it saves... or even
> > with dmesg -w it goes over the number of lines of your terminal...
> > or the ssh and serial slowness when printing a bunch of information.
> > 
> > We probably want to be able to capture multiple error states and be
> > able to cross them with a kernel timeline, but definitely not overflood
> > our log terminals.
> I think you are missing the point.
> 
> This is the emergency backup plan for when nothing else works. It is not on
> by default. It should never happen on an end user system unless we
> specifically request them to run with a patched kernel to enable a dump at a
> specific point.
> 
> But there are (many) times when nothing else works. In those instances, it
> is extremely useful to be able to dump the system state in this manner.
> 
> It is code we have been using internally for some time and it has helped
> resolve a number of different difficult to debug bugs. As our Xe generation
> platforms are now out in the wild and no longer just internal, it is also
> proving important to have this facility available in upstream trees as well.
> And having it merged rather than floating around as random patches passed
> from person to person is far easier to manage and would also help reduce the
> internal tree burden.

Note that Xe needs to move over to devcoredump infrastructure, so if you
need dumping straight to dmesg that would be a patch for that subsystem in
the future.

Not sure how much you want to add fun here in the i915-gem deadend, I'll
leave that up to i915 maintainers.

Just figured this is a good place to drop this aside :-)
-Daniel

> 
> John.
> 
> > > Signed-off-by: John Harrison 
> > > 
> > > 
> > > John Harrison (2):
> > >drm/i915: Dump error capture to kernel log
> > >drm/i915/guc: Dump error capture to dmesg on CTB error
> > > 
> > >   drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c |  53 +
> > >   drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |   6 +
> > >   drivers/gpu/drm/i915/i915_gpu_error.c | 130 ++
> > >   drivers/gpu/drm/i915/i915_gpu_error.h |   8 ++
> > >   4 files changed, 197 insertions(+)
> > > 
> > > -- 
> > > 2.39.1
> > > 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2 0/2] drm: fdinfo memory stats

[Rob Clark]

On Mon, Apr 10, 2023 at 2:06 PM Rob Clark  wrote:
>
> From: Rob Clark 
>
> Similar motivation to other similar recent attempt[1].  But with an
> attempt to have some shared code for this.  As well as documentation.
>
> It is probably a bit UMA-centric, I guess devices with VRAM might want
> some placement stats as well.  But this seems like a reasonable start.
>
> Basic gputop support: https://patchwork.freedesktop.org/series/116236/
> And already nvtop support: https://github.com/Syllo/nvtop/pull/204

On a related topic, I'm wondering if it would make sense to report
some more global things (temp, freq, etc) via fdinfo?  Some of this,
tools like nvtop could get by trawling sysfs or other driver specific
ways.  But maybe it makes sense to have these sort of things reported
in a standardized way (even though they aren't really per-drm_file)

BR,
-R


> [1] https://patchwork.freedesktop.org/series/112397/
>
> Rob Clark (2):
>   drm: Add fdinfo memory stats
>   drm/msm: Add memory stats to fdinfo
>
>  Documentation/gpu/drm-usage-stats.rst | 21 +++
>  drivers/gpu/drm/drm_file.c| 79 +++
>  drivers/gpu/drm/msm/msm_drv.c | 25 -
>  drivers/gpu/drm/msm/msm_gpu.c |  2 -
>  include/drm/drm_file.h| 10 
>  5 files changed, 134 insertions(+), 3 deletions(-)
>
> --
> 2.39.2
>

Re: [PATCH] drm/msm/dpu: Delete a variable initialisation before a null pointer check in two functions

[Abhinav Kumar]

On 4/11/2023 9:38 AM, Markus Elfring wrote:

Date: Tue, 11 Apr 2023 18:24:24 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the functions “dpu_hw_pp_enable_te” and “dpu_hw_pp_get_vsync_info”.

Thus avoid the risk for undefined behaviour by removing extra
initialisations for the variable “c” (also because it was already
reassigned with the same value behind this pointer check).

This issue was detected by using the Coccinelle software.

Fixes: 25fdd5933e4c0f5fe2ea5cd59994f8ac5fbe90ef ("drm/msm: Add SDM845 DPU 
support")


Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")

We usually have 12 chars of the hash. Other than that,

Reviewed-by: Abhinav Kumar 


Signed-off-by: Markus Elfring 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
index 0fcad9760b6f..870ab3ebbc94 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
@@ -176,7 +176,7 @@ static int dpu_hw_pp_enable_te(struct dpu_hw_pingpong *pp, 
bool enable)
  static int dpu_hw_pp_connect_external_te(struct dpu_hw_pingpong *pp,
bool enable_external_te)
  {
-   struct dpu_hw_blk_reg_map *c = >hw;
+   struct dpu_hw_blk_reg_map *c;
u32 cfg;
int orig;

@@ -221,7 +221,7 @@ static int dpu_hw_pp_get_vsync_info(struct dpu_hw_pingpong 
*pp,

  static u32 dpu_hw_pp_get_line_count(struct dpu_hw_pingpong *pp)
  {
-   struct dpu_hw_blk_reg_map *c = >hw;
+   struct dpu_hw_blk_reg_map *c;
u32 height, init;
u32 line = 0x;

--
2.40.0

Re: [PATCH] drm/msm/dpu: Delete a variable initialisation before a null pointer check in two functions

[Dmitry Baryshkov]

On 11/04/2023 19:38, Markus Elfring wrote:

Date: Tue, 11 Apr 2023 18:24:24 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the functions “dpu_hw_pp_enable_te” and “dpu_hw_pp_get_vsync_info”.

Thus avoid the risk for undefined behaviour by removing extra
initialisations for the variable “c” (also because it was already
reassigned with the same value behind this pointer check).

This issue was detected by using the Coccinelle software.

Fixes: 25fdd5933e4c0f5fe2ea5cd59994f8ac5fbe90ef ("drm/msm: Add SDM845 DPU 
support")


Plese follow the format for the Fixes tags and limit the hash to 12 
chars. Proper tag:


Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")

Other than that LGTM.


Signed-off-by: Markus Elfring 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
index 0fcad9760b6f..870ab3ebbc94 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
@@ -176,7 +176,7 @@ static int dpu_hw_pp_enable_te(struct dpu_hw_pingpong *pp, 
bool enable)
  static int dpu_hw_pp_connect_external_te(struct dpu_hw_pingpong *pp,
bool enable_external_te)
  {
-   struct dpu_hw_blk_reg_map *c = >hw;
+   struct dpu_hw_blk_reg_map *c;
u32 cfg;
int orig;

@@ -221,7 +221,7 @@ static int dpu_hw_pp_get_vsync_info(struct dpu_hw_pingpong 
*pp,

  static u32 dpu_hw_pp_get_line_count(struct dpu_hw_pingpong *pp)
  {
-   struct dpu_hw_blk_reg_map *c = >hw;
+   struct dpu_hw_blk_reg_map *c;
u32 height, init;
u32 line = 0x;

--
2.40.0



--
With best wishes
Dmitry

Re: [PATCH 0/2] Add support for dumping error captures via kernel logging

[John Harrison]

On 4/11/2023 07:41, Rodrigo Vivi wrote:

On Mon, Apr 10, 2023 at 12:25:21PM -0700, john.c.harri...@intel.com wrote:

From: John Harrison 

Sometimes, the only effective way to debug an issue is to dump all the
interesting information at the point of failure. So add support for
doing that.

No! Please no!
We have some of this on Xe and I'm hating it. I'm going to try to remove
from there soon. It is horrible when you lost the hability to use dmesg
directly because it goes over the number of lines it saves... or even
with dmesg -w it goes over the number of lines of your terminal...
or the ssh and serial slowness when printing a bunch of information.

We probably want to be able to capture multiple error states and be
able to cross them with a kernel timeline, but definitely not overflood
our log terminals.

I think you are missing the point.

This is the emergency backup plan for when nothing else works. It is not 
on by default. It should never happen on an end user system unless we 
specifically request them to run with a patched kernel to enable a dump 
at a specific point.


But there are (many) times when nothing else works. In those instances, 
it is extremely useful to be able to dump the system state in this manner.


It is code we have been using internally for some time and it has helped 
resolve a number of different difficult to debug bugs. As our Xe 
generation platforms are now out in the wild and no longer just 
internal, it is also proving important to have this facility available 
in upstream trees as well. And having it merged rather than floating 
around as random patches passed from person to person is far easier to 
manage and would also help reduce the internal tree burden.


John.


Signed-off-by: John Harrison 


John Harrison (2):
   drm/i915: Dump error capture to kernel log
   drm/i915/guc: Dump error capture to dmesg on CTB error

  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c |  53 +
  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |   6 +
  drivers/gpu/drm/i915/i915_gpu_error.c | 130 ++
  drivers/gpu/drm/i915/i915_gpu_error.h |   8 ++
  4 files changed, 197 insertions(+)

--
2.39.1

[PATCH] drm/msm/dpu: Delete a variable initialisation before a null pointer check in two functions

[Markus Elfring]

Date: Tue, 11 Apr 2023 18:24:24 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the functions “dpu_hw_pp_enable_te” and “dpu_hw_pp_get_vsync_info”.

Thus avoid the risk for undefined behaviour by removing extra
initialisations for the variable “c” (also because it was already
reassigned with the same value behind this pointer check).

This issue was detected by using the Coccinelle software.

Fixes: 25fdd5933e4c0f5fe2ea5cd59994f8ac5fbe90ef ("drm/msm: Add SDM845 DPU 
support")
Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
index 0fcad9760b6f..870ab3ebbc94 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
@@ -176,7 +176,7 @@ static int dpu_hw_pp_enable_te(struct dpu_hw_pingpong *pp, 
bool enable)
 static int dpu_hw_pp_connect_external_te(struct dpu_hw_pingpong *pp,
bool enable_external_te)
 {
-   struct dpu_hw_blk_reg_map *c = >hw;
+   struct dpu_hw_blk_reg_map *c;
u32 cfg;
int orig;

@@ -221,7 +221,7 @@ static int dpu_hw_pp_get_vsync_info(struct dpu_hw_pingpong 
*pp,

 static u32 dpu_hw_pp_get_line_count(struct dpu_hw_pingpong *pp)
 {
-   struct dpu_hw_blk_reg_map *c = >hw;
+   struct dpu_hw_blk_reg_map *c;
u32 height, init;
u32 line = 0x;

--
2.40.0

Re: linux-next: build failure after merge of the driver-core tree

[Daniel Vetter]

On Tue, Apr 11, 2023 at 09:29:27AM -0600, Jeffrey Hugo wrote:
> On 4/11/2023 9:26 AM, Jeffrey Hugo wrote:
> > On 4/11/2023 9:13 AM, Greg KH wrote:
> > > On Tue, Apr 11, 2023 at 09:08:39AM -0600, Jeffrey Hugo wrote:
> > > > On 4/11/2023 9:01 AM, Daniel Vetter wrote:
> > > > > On Tue, Apr 11, 2023 at 12:40:28PM +0200, Greg KH wrote:
> > > > > > On Tue, Apr 11, 2023 at 11:55:20AM +0200, Daniel Vetter wrote:
> > > > > > > On Tue, Apr 11, 2023 at 02:38:12PM +1000, Stephen Rothwell wrote:
> > > > > > > > Hi all,
> > > > > > > > 
> > > > > > > > After merging the driver-core tree, today's linux-next build 
> > > > > > > > (x86_64
> > > > > > > > allmodconfig) failed like this:
> > > > > > > > 
> > > > > > > > In file included from include/linux/linkage.h:7,
> > > > > > > >    from include/linux/kernel.h:17,
> > > > > > > >    from drivers/accel/qaic/mhi_qaic_ctrl.c:4:
> > > > > > > > drivers/accel/qaic/mhi_qaic_ctrl.c: In function
> > > > > > > > 'mhi_qaic_ctrl_init':
> > > > > > > > include/linux/export.h:27:22: error: passing
> > > > > > > > argument 1 of 'class_create' from incompatible
> > > > > > > > pointer type
> > > > > > > > [-Werror=incompatible-pointer-types]
> > > > > > > >  27 | #define THIS_MODULE (&__this_module)
> > > > > > > >     | ~^~~
> > > > > > > >     |  |
> > > > > > > >     |  struct module *
> > > > > > > > drivers/accel/qaic/mhi_qaic_ctrl.c:544:38: note:
> > > > > > > > in expansion of macro 'THIS_MODULE'
> > > > > > > >     544 | mqc_dev_class =
> > > > > > > > class_create(THIS_MODULE,
> > > > > > > > MHI_QAIC_CTRL_DRIVER_NAME);
> > > > > > > >     |  ^~~
> > > > > > > > In file included from include/linux/device.h:31,
> > > > > > > >    from include/linux/mhi.h:9,
> > > > > > > >    from drivers/accel/qaic/mhi_qaic_ctrl.c:5:
> > > > > > > > include/linux/device/class.h:229:54: note:
> > > > > > > > expected 'const char *' but argument is of type
> > > > > > > > 'struct module *'
> > > > > > > >     229 | struct class * __must_check
> > > > > > > > class_create(const char *name);
> > > > > > > >     |  
> > > > > > > > ^~~~
> > > > > > > > drivers/accel/qaic/mhi_qaic_ctrl.c:544:25:
> > > > > > > > error: too many arguments to function
> > > > > > > > 'class_create'
> > > > > > > >     544 | mqc_dev_class =
> > > > > > > > class_create(THIS_MODULE,
> > > > > > > > MHI_QAIC_CTRL_DRIVER_NAME);
> > > > > > > >     | ^~~~
> > > > > > > > include/linux/device/class.h:229:29: note: declared here
> > > > > > > >     229 | struct class * __must_check
> > > > > > > > class_create(const char *name);
> > > > > > > >     | ^~~~
> > > > > > > > 
> > > > > > > > Caused by commit
> > > > > > > > 
> > > > > > > >     1aaba11da9aa ("driver core: class: remove
> > > > > > > > module * from class_create()")
> > > > > > > > 
> > > > > > > > interacting with commit
> > > > > > > > 
> > > > > > > >     566fc96198b4 ("accel/qaic: Add mhi_qaic_cntl")
> > > > > > > > 
> > > > > > > > from the drm tree.
> > > > > > > > 
> > > > > > > > I have applied the following merge fix patch for today.
> > > > > > > > 
> > > > > > > > From: Stephen Rothwell 
> > > > > > > > Date: Tue, 11 Apr 2023 14:16:57 +1000
> > > > > > > > Subject: [PATCH] fixup for "driver core: class:
> > > > > > > > remove module * from class_create()"
> > > > > > > > 
> > > > > > > > interacting with "accel/qaic: Add mhi_qaic_cntl"
> > > > > > > > 
> > > > > > > > Signed-off-by: Stephen Rothwell 
> > > > > > > 
> > > > > > > Thanks for the fixup. Since Dave is out I've made a
> > > > > > > note about this in my
> > > > > > > handover mail so it won't get lost in the drm-next
> > > > > > > merge window pull. I
> > > > > > > don't think we need any other coordination than
> > > > > > > mention it in each pull to
> > > > > > > Linus, topic tree seems overkill for this. Plus there's no way I 
> > > > > > > can
> > > > > > > untangle the drm tree anyway :-).
> > > > > > 
> > > > > > Want me to submit a patch for the drm tree that moves this to use
> > > > > > class_register() instead, which will make the
> > > > > > merge/build issue go away
> > > > > > for you?  That's my long-term goal here anyway, so converting this 
> > > > > > new
> > > > > > code to this api today would be something I have to do eventually :)
> > > > > 
> > > > > We kinda closed drm-next for feature work mostly already (just pulling
> > > > > stuff in from subtrees), so won't really help for this merge window.
> > > > > 
> > > > > For everything else I think this is up to Oded, I had no
> > > > > idea qaic needed
> > > > > it's entire own dev class and I don't want to dig into this
> > > > > for the risk I
> > > > > might freak out :-)
> 

[PATCH v2 2/2] drm/msm/adreno: change adreno_is_* functions to accept const argument

[Dmitry Baryshkov]

All adreno_is_*() functions do not modify their argument in any way, so
they can be changed to accept const struct adreno_gpu pointer.

Suggested-by: Stephen Boyd 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/adreno/adreno_gpu.h | 56 -
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index cf3b7abf201a..9857314295f9 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -152,140 +152,140 @@ static inline bool adreno_is_revn(const struct 
adreno_gpu *gpu, uint32_t revn)
return gpu->revn == revn;
 }
 
-static inline bool adreno_is_a2xx(struct adreno_gpu *gpu)
+static inline bool adreno_is_a2xx(const struct adreno_gpu *gpu)
 {
WARN_ON_ONCE(!gpu->revn);
 
return (gpu->revn < 300);
 }
 
-static inline bool adreno_is_a20x(struct adreno_gpu *gpu)
+static inline bool adreno_is_a20x(const struct adreno_gpu *gpu)
 {
WARN_ON_ONCE(!gpu->revn);
 
return (gpu->revn < 210);
 }
 
-static inline bool adreno_is_a225(struct adreno_gpu *gpu)
+static inline bool adreno_is_a225(const struct adreno_gpu *gpu)
 {
return adreno_is_revn(gpu, 225);
 }
 
-static inline bool adreno_is_a305(struct adreno_gpu *gpu)
+static inline bool adreno_is_a305(const struct adreno_gpu *gpu)
 {
return adreno_is_revn(gpu, 305);
 }
 
-static inline bool adreno_is_a306(struct adreno_gpu *gpu)
+static inline bool adreno_is_a306(const struct adreno_gpu *gpu)
 {
/* yes, 307, because a305c is 306 */
return adreno_is_revn(gpu, 307);
 }
 
-static inline bool adreno_is_a320(struct adreno_gpu *gpu)
+static inline bool adreno_is_a320(const struct adreno_gpu *gpu)
 {
return adreno_is_revn(gpu, 320);
 }
 
-static inline bool adreno_is_a330(struct adreno_gpu *gpu)
+static inline bool adreno_is_a330(const struct adreno_gpu *gpu)
 {
return adreno_is_revn(gpu, 330);
 }
 
-static inline bool adreno_is_a330v2(struct adreno_gpu *gpu)
+static inline bool adreno_is_a330v2(const struct adreno_gpu *gpu)
 {
return adreno_is_a330(gpu) && (gpu->rev.patchid > 0);
 }
 
-static inline int adreno_is_a405(struct adreno_gpu *gpu)
+static inline int adreno_is_a405(const struct adreno_gpu *gpu)
 {
return adreno_is_revn(gpu, 405);
 }
 
-static inline int adreno_is_a420(struct adreno_gpu *gpu)
+static inline int adreno_is_a420(const struct adreno_gpu *gpu)
 {
return adreno_is_revn(gpu, 420);
 }
 
-static inline int adreno_is_a430(struct adreno_gpu *gpu)
+static inline int adreno_is_a430(const struct adreno_gpu *gpu)
 {
return adreno_is_revn(gpu, 430);
 }
 
-static inline int adreno_is_a506(struct adreno_gpu *gpu)
+static inline int adreno_is_a506(const struct adreno_gpu *gpu)
 {
return adreno_is_revn(gpu, 506);
 }
 
-static inline int adreno_is_a508(struct adreno_gpu *gpu)
+static inline int adreno_is_a508(const struct adreno_gpu *gpu)
 {
return adreno_is_revn(gpu, 508);
 }
 
-static inline int adreno_is_a509(struct adreno_gpu *gpu)
+static inline int adreno_is_a509(const struct adreno_gpu *gpu)
 {
return adreno_is_revn(gpu, 509);
 }
 
-static inline int adreno_is_a510(struct adreno_gpu *gpu)
+static inline int adreno_is_a510(const struct adreno_gpu *gpu)
 {
return adreno_is_revn(gpu, 510);
 }
 
-static inline int adreno_is_a512(struct adreno_gpu *gpu)
+static inline int adreno_is_a512(const struct adreno_gpu *gpu)
 {
return adreno_is_revn(gpu, 512);
 }
 
-static inline int adreno_is_a530(struct adreno_gpu *gpu)
+static inline int adreno_is_a530(const struct adreno_gpu *gpu)
 {
return adreno_is_revn(gpu, 530);
 }
 
-static inline int adreno_is_a540(struct adreno_gpu *gpu)
+static inline int adreno_is_a540(const struct adreno_gpu *gpu)
 {
return adreno_is_revn(gpu, 540);
 }
 
-static inline int adreno_is_a618(struct adreno_gpu *gpu)
+static inline int adreno_is_a618(const struct adreno_gpu *gpu)
 {
return adreno_is_revn(gpu, 618);
 }
 
-static inline int adreno_is_a619(struct adreno_gpu *gpu)
+static inline int adreno_is_a619(const struct adreno_gpu *gpu)
 {
return adreno_is_revn(gpu, 619);
 }
 
-static inline int adreno_is_a630(struct adreno_gpu *gpu)
+static inline int adreno_is_a630(const struct adreno_gpu *gpu)
 {
return adreno_is_revn(gpu, 630);
 }
 
-static inline int adreno_is_a640_family(struct adreno_gpu *gpu)
+static inline int adreno_is_a640_family(const struct adreno_gpu *gpu)
 {
return adreno_is_revn(gpu, 640) ||
adreno_is_revn(gpu, 680);
 }
 
-static inline int adreno_is_a650(struct adreno_gpu *gpu)
+static inline int adreno_is_a650(const struct adreno_gpu *gpu)
 {
return adreno_is_revn(gpu, 650);
 }
 
-static inline int adreno_is_7c3(struct adreno_gpu *gpu)
+static inline int adreno_is_7c3(const struct adreno_gpu *gpu)
 {
/* The order of args is important 

[PATCH v2 1/2] drm/msm/adreno: warn if chip revn is verified before being set

[Dmitry Baryshkov]

The commit 010c8bbad2cb ("drm: msm: adreno: Disable preemption on Adreno
510") tried to check GPU's revn before revn being set. Add WARN_ON_ONCE
to prevent such bugs from happening again. A separate helper is
necessary so that the warning is displayed really just once instead of
being displayed for each of comparisons.

Suggested-by: Stephen Boyd 
Signed-off-by: Dmitry Baryshkov 
---

Changes since v1:
 - Renamed to adreno_is_revn() (Stephen)
 - Changed it to accept const gpu pointer (Stephen)

---
 drivers/gpu/drm/msm/adreno/adreno_gpu.h | 63 -
 1 file changed, 40 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index f62612a5c70f..cf3b7abf201a 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -145,40 +145,51 @@ struct adreno_platform_config {
 
 bool adreno_cmp_rev(struct adreno_rev rev1, struct adreno_rev rev2);
 
+static inline bool adreno_is_revn(const struct adreno_gpu *gpu, uint32_t revn)
+{
+   WARN_ON_ONCE(!gpu->revn);
+
+   return gpu->revn == revn;
+}
+
 static inline bool adreno_is_a2xx(struct adreno_gpu *gpu)
 {
+   WARN_ON_ONCE(!gpu->revn);
+
return (gpu->revn < 300);
 }
 
 static inline bool adreno_is_a20x(struct adreno_gpu *gpu)
 {
+   WARN_ON_ONCE(!gpu->revn);
+
return (gpu->revn < 210);
 }
 
 static inline bool adreno_is_a225(struct adreno_gpu *gpu)
 {
-   return gpu->revn == 225;
+   return adreno_is_revn(gpu, 225);
 }
 
 static inline bool adreno_is_a305(struct adreno_gpu *gpu)
 {
-   return gpu->revn == 305;
+   return adreno_is_revn(gpu, 305);
 }
 
 static inline bool adreno_is_a306(struct adreno_gpu *gpu)
 {
/* yes, 307, because a305c is 306 */
-   return gpu->revn == 307;
+   return adreno_is_revn(gpu, 307);
 }
 
 static inline bool adreno_is_a320(struct adreno_gpu *gpu)
 {
-   return gpu->revn == 320;
+   return adreno_is_revn(gpu, 320);
 }
 
 static inline bool adreno_is_a330(struct adreno_gpu *gpu)
 {
-   return gpu->revn == 330;
+   return adreno_is_revn(gpu, 330);
 }
 
 static inline bool adreno_is_a330v2(struct adreno_gpu *gpu)
@@ -188,77 +199,78 @@ static inline bool adreno_is_a330v2(struct adreno_gpu 
*gpu)
 
 static inline int adreno_is_a405(struct adreno_gpu *gpu)
 {
-   return gpu->revn == 405;
+   return adreno_is_revn(gpu, 405);
 }
 
 static inline int adreno_is_a420(struct adreno_gpu *gpu)
 {
-   return gpu->revn == 420;
+   return adreno_is_revn(gpu, 420);
 }
 
 static inline int adreno_is_a430(struct adreno_gpu *gpu)
 {
-   return gpu->revn == 430;
+   return adreno_is_revn(gpu, 430);
 }
 
 static inline int adreno_is_a506(struct adreno_gpu *gpu)
 {
-   return gpu->revn == 506;
+   return adreno_is_revn(gpu, 506);
 }
 
 static inline int adreno_is_a508(struct adreno_gpu *gpu)
 {
-   return gpu->revn == 508;
+   return adreno_is_revn(gpu, 508);
 }
 
 static inline int adreno_is_a509(struct adreno_gpu *gpu)
 {
-   return gpu->revn == 509;
+   return adreno_is_revn(gpu, 509);
 }
 
 static inline int adreno_is_a510(struct adreno_gpu *gpu)
 {
-   return gpu->revn == 510;
+   return adreno_is_revn(gpu, 510);
 }
 
 static inline int adreno_is_a512(struct adreno_gpu *gpu)
 {
-   return gpu->revn == 512;
+   return adreno_is_revn(gpu, 512);
 }
 
 static inline int adreno_is_a530(struct adreno_gpu *gpu)
 {
-   return gpu->revn == 530;
+   return adreno_is_revn(gpu, 530);
 }
 
 static inline int adreno_is_a540(struct adreno_gpu *gpu)
 {
-   return gpu->revn == 540;
+   return adreno_is_revn(gpu, 540);
 }
 
 static inline int adreno_is_a618(struct adreno_gpu *gpu)
 {
-   return gpu->revn == 618;
+   return adreno_is_revn(gpu, 618);
 }
 
 static inline int adreno_is_a619(struct adreno_gpu *gpu)
 {
-   return gpu->revn == 619;
+   return adreno_is_revn(gpu, 619);
 }
 
 static inline int adreno_is_a630(struct adreno_gpu *gpu)
 {
-   return gpu->revn == 630;
+   return adreno_is_revn(gpu, 630);
 }
 
 static inline int adreno_is_a640_family(struct adreno_gpu *gpu)
 {
-   return (gpu->revn == 640) || (gpu->revn == 680);
+   return adreno_is_revn(gpu, 640) ||
+   adreno_is_revn(gpu, 680);
 }
 
 static inline int adreno_is_a650(struct adreno_gpu *gpu)
 {
-   return gpu->revn == 650;
+   return adreno_is_revn(gpu, 650);
 }
 
 static inline int adreno_is_7c3(struct adreno_gpu *gpu)
@@ -269,13 +281,16 @@ static inline int adreno_is_7c3(struct adreno_gpu *gpu)
 
 static inline int adreno_is_a660(struct adreno_gpu *gpu)
 {
-   return gpu->revn == 660;
+   return adreno_is_revn(gpu, 660);
 }
 
 /* check for a615, a616, a618, a619 or any derivatives */
 static inline int adreno_is_a615_family(struct adreno_gpu *gpu)
 {
-   return gpu->revn == 615 || gpu->revn == 616 || gpu->revn == 618 || 
gpu->revn == 619;
+   

Re: [PATCH] fbmem: Reject FB_ACTIVATE_KD_TEXT from userspace

[Geert Uytterhoeven]

Hi Daniel,

On Tue, Apr 11, 2023 at 3:44 PM Daniel Vetter  wrote:
> On Tue, Apr 04, 2023 at 09:39:34PM +0200, Daniel Vetter wrote:
> > This is an oversight from dc5bdb68b5b3 ("drm/fb-helper: Fix vt
> > restore") - I failed to realize that nasty userspace could set this.
> >
> > It's not pretty to mix up kernel-internal and userspace uapi flags
> > like this, but since the entire fb_var_screeninfo structure is uapi
> > we'd need to either add a new parameter to the ->fb_set_par callback
> > and fb_set_par() function, which has a _lot_ of users. Or some other
> > fairly ugly side-channel int fb_info. Neither is a pretty prospect.
> >
> > Instead just correct the issue at hand by filtering out this
> > kernel-internal flag in the ioctl handling code.
> >
> > Signed-off-by: Daniel Vetter 
> > Fixes: dc5bdb68b5b3 ("drm/fb-helper: Fix vt restore")

> An Ack on this (or a better idea) would be great, so I can stuff it into
> -fixes.

I don't understand what the original commit this fixes is doing anyway...

> > --- a/drivers/video/fbdev/core/fbmem.c
> > +++ b/drivers/video/fbdev/core/fbmem.c
> > @@ -1116,6 +1116,8 @@ static long do_fb_ioctl(struct fb_info *info, 
> > unsigned int cmd,
> >   case FBIOPUT_VSCREENINFO:
> >   if (copy_from_user(, argp, sizeof(var)))
> >   return -EFAULT;
> > + /* only for kernel-internal use */
> > + var.activate &= ~FB_ACTIVATE_KD_TEXT;
> >   console_lock();
> >   lock_fb_info(info);
> >   ret = fbcon_modechange_possible(info, );

Perhaps FB_ACTIVATE_KD_TEXT should be removed (marked as
reserved) from include/uapi/linux/fb.h, too?

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [pull] drm/msm: drm-msm-next-2023-04-10 for v6.4

[Rob Clark]

On Tue, Apr 11, 2023 at 8:00 AM Daniel Vetter  wrote:
>
> On Tue, Apr 11, 2023 at 07:55:33AM -0700, Rob Clark wrote:
> > On Tue, Apr 11, 2023 at 3:27 AM Daniel Vetter  wrote:
> > > > Konrad Dybcio (18):
> > > >   drm/msm/adreno: Use OPP for every GPU generation
> > >
> > > This had a minor conflict with refactoring from drm-misc-next, I went
> > > what's in your pr. Please double check I didn't screw up, but at least it
> > > compiles :-)
> >
> > Hmm, am I looking at the wrong thing.. the conflict I'm seeing is with
> > drm_gem_lru (and looks to be correctly resolved)
>
> Yeah that one was trivial. Unfortunately git does not report anything if
> you only keep one or the other branch entirely in your resolution, so the
> only way for you to see the conflict is to re-create the merge :-) Or at
> least my git foo isn't good enough for a better way ...

Ahh, right.. yes, this looks like the correct resolution (change
coming from drm-misc side was something that was removed from msm-next
side)

BR,
-R

> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

Re: [PATCH v3 01/13] firmware/sysfb: Fix EFI/VESA format selection

[Javier Martinez Canillas]

"Pierre Asselin"  writes:

Hello Pierre,

> Oh oh, I just reproduced the problem on a desktop tower, a Dell Precision
> T3610, probably 2019 vintage.  The only thing in common with the old
> laptop, that I can think of, is that both use the legacy BIOS.  The Dell
> has EFI but the graphics card may not support that; there is no integrated
> graphics, if I switch to EFI and lose the video I may not be able to switch
> back.
>

Can you please share you grub config file? It seems that is set to
GRUB_GFXMODE=1024x768x32 but the actual mode is set to 1024x768x24 ?

That is, it fails when the picked format is DRM_FORMAT_RGB but
works when is DRM_FORMAT_XRGB888. I can't spot any error in Thomas'
patch so I wonder if the problem is with what grub is passing to the
kernel.

The mentioned vga=0x318 workaround that you mentioned makes the mode
passed to match the selected DRM_FORMAT_RGB888 which I guess is why
that worked for you.

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: linux-next: build failure after merge of the driver-core tree

[Jeffrey Hugo]

On 4/11/2023 9:26 AM, Jeffrey Hugo wrote:

On 4/11/2023 9:13 AM, Greg KH wrote:

On Tue, Apr 11, 2023 at 09:08:39AM -0600, Jeffrey Hugo wrote:

On 4/11/2023 9:01 AM, Daniel Vetter wrote:

On Tue, Apr 11, 2023 at 12:40:28PM +0200, Greg KH wrote:

On Tue, Apr 11, 2023 at 11:55:20AM +0200, Daniel Vetter wrote:

On Tue, Apr 11, 2023 at 02:38:12PM +1000, Stephen Rothwell wrote:

Hi all,

After merging the driver-core tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from include/linux/linkage.h:7,
   from include/linux/kernel.h:17,
   from drivers/accel/qaic/mhi_qaic_ctrl.c:4:
drivers/accel/qaic/mhi_qaic_ctrl.c: In function 
'mhi_qaic_ctrl_init':
include/linux/export.h:27:22: error: passing argument 1 of 
'class_create' from incompatible pointer type 
[-Werror=incompatible-pointer-types]

 27 | #define THIS_MODULE (&__this_module)
    | ~^~~
    |  |
    |  struct module *
drivers/accel/qaic/mhi_qaic_ctrl.c:544:38: note: in expansion of 
macro 'THIS_MODULE'
    544 | mqc_dev_class = class_create(THIS_MODULE, 
MHI_QAIC_CTRL_DRIVER_NAME);

    |  ^~~
In file included from include/linux/device.h:31,
   from include/linux/mhi.h:9,
   from drivers/accel/qaic/mhi_qaic_ctrl.c:5:
include/linux/device/class.h:229:54: note: expected 'const char 
*' but argument is of type 'struct module *'
    229 | struct class * __must_check class_create(const char 
*name);

    |  ^~~~
drivers/accel/qaic/mhi_qaic_ctrl.c:544:25: error: too many 
arguments to function 'class_create'
    544 | mqc_dev_class = class_create(THIS_MODULE, 
MHI_QAIC_CTRL_DRIVER_NAME);

    | ^~~~
include/linux/device/class.h:229:29: note: declared here
    229 | struct class * __must_check class_create(const char 
*name);

    | ^~~~

Caused by commit

    1aaba11da9aa ("driver core: class: remove module * from 
class_create()")


interacting with commit

    566fc96198b4 ("accel/qaic: Add mhi_qaic_cntl")

from the drm tree.

I have applied the following merge fix patch for today.

From: Stephen Rothwell 
Date: Tue, 11 Apr 2023 14:16:57 +1000
Subject: [PATCH] fixup for "driver core: class: remove module * 
from class_create()"


interacting with "accel/qaic: Add mhi_qaic_cntl"

Signed-off-by: Stephen Rothwell 


Thanks for the fixup. Since Dave is out I've made a note about 
this in my
handover mail so it won't get lost in the drm-next merge window 
pull. I
don't think we need any other coordination than mention it in each 
pull to

Linus, topic tree seems overkill for this. Plus there's no way I can
untangle the drm tree anyway :-).


Want me to submit a patch for the drm tree that moves this to use
class_register() instead, which will make the merge/build issue go 
away

for you?  That's my long-term goal here anyway, so converting this new
code to this api today would be something I have to do eventually :)


We kinda closed drm-next for feature work mostly already (just pulling
stuff in from subtrees), so won't really help for this merge window.

For everything else I think this is up to Oded, I had no idea qaic 
needed
it's entire own dev class and I don't want to dig into this for the 
risk I

might freak out :-)

Adding Oded.

Cheers, Daniel


Sorry for the mess.

I made a note to update to class_register() once my drm-misc access is
sorted out.  Looks like we'll address the conflict in the merge 
window, and

catch the update to the new API in the following release.


Wait, I think the large question is, "why does this need a separate
class"?  Why are you not using the accel char device and class?  That is
what everything under accel/ should be using, otherwise why put it in
there?

And what exactly are you using that class for?  Just device nodes?  If
so, how many?

thanks,

greg k-h



Remember MHI_UCI that then evolved into the WWAN subsystem?  I pointed 
out at the time that AIC100/QAIC would need the same functionality. 
You/Jakub told myself/Mani/Loic that a combined implementation is not 
acceptable, and every area needs to implement their own version of MHI_UCI.


We took the WWAN subsystem and simplified it to meet our needs.

The functionality is QAIC specific, so wedging it into the Accel node 
seems to be a poor fit as it would subject Habana and iVPU to the same.


Also, I forgot to mention.  QAIC is sharing userspace components with 
WWAN, so we really cannot diverge from what WWAN has done and define a 
new API through the Accel node.




We need (eventually) 128 device nodes.  We have systems with 32 QAIC 
devices, and each QAIC device uses 4 device nodes (32 * 4 = 128).  WWAN 
subsystem would be similar.  Looks like each 5G modem is 6 nodes per 
device, 

Re: linux-next: build failure after merge of the driver-core tree

[Jeffrey Hugo]

On 4/11/2023 9:13 AM, Greg KH wrote:

On Tue, Apr 11, 2023 at 09:08:39AM -0600, Jeffrey Hugo wrote:

On 4/11/2023 9:01 AM, Daniel Vetter wrote:

On Tue, Apr 11, 2023 at 12:40:28PM +0200, Greg KH wrote:

On Tue, Apr 11, 2023 at 11:55:20AM +0200, Daniel Vetter wrote:

On Tue, Apr 11, 2023 at 02:38:12PM +1000, Stephen Rothwell wrote:

Hi all,

After merging the driver-core tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from include/linux/linkage.h:7,
   from include/linux/kernel.h:17,
   from drivers/accel/qaic/mhi_qaic_ctrl.c:4:
drivers/accel/qaic/mhi_qaic_ctrl.c: In function 'mhi_qaic_ctrl_init':
include/linux/export.h:27:22: error: passing argument 1 of 'class_create' from 
incompatible pointer type [-Werror=incompatible-pointer-types]
 27 | #define THIS_MODULE (&__this_module)
| ~^~~
|  |
|  struct module *
drivers/accel/qaic/mhi_qaic_ctrl.c:544:38: note: in expansion of macro 
'THIS_MODULE'
544 | mqc_dev_class = class_create(THIS_MODULE, 
MHI_QAIC_CTRL_DRIVER_NAME);
|  ^~~
In file included from include/linux/device.h:31,
   from include/linux/mhi.h:9,
   from drivers/accel/qaic/mhi_qaic_ctrl.c:5:
include/linux/device/class.h:229:54: note: expected 'const char *' but argument 
is of type 'struct module *'
229 | struct class * __must_check class_create(const char *name);
|  ^~~~
drivers/accel/qaic/mhi_qaic_ctrl.c:544:25: error: too many arguments to 
function 'class_create'
544 | mqc_dev_class = class_create(THIS_MODULE, 
MHI_QAIC_CTRL_DRIVER_NAME);
| ^~~~
include/linux/device/class.h:229:29: note: declared here
229 | struct class * __must_check class_create(const char *name);
| ^~~~

Caused by commit

1aaba11da9aa ("driver core: class: remove module * from class_create()")

interacting with commit

566fc96198b4 ("accel/qaic: Add mhi_qaic_cntl")

from the drm tree.

I have applied the following merge fix patch for today.

From: Stephen Rothwell 
Date: Tue, 11 Apr 2023 14:16:57 +1000
Subject: [PATCH] fixup for "driver core: class: remove module * from 
class_create()"

interacting with "accel/qaic: Add mhi_qaic_cntl"

Signed-off-by: Stephen Rothwell 


Thanks for the fixup. Since Dave is out I've made a note about this in my
handover mail so it won't get lost in the drm-next merge window pull. I
don't think we need any other coordination than mention it in each pull to
Linus, topic tree seems overkill for this. Plus there's no way I can
untangle the drm tree anyway :-).


Want me to submit a patch for the drm tree that moves this to use
class_register() instead, which will make the merge/build issue go away
for you?  That's my long-term goal here anyway, so converting this new
code to this api today would be something I have to do eventually :)


We kinda closed drm-next for feature work mostly already (just pulling
stuff in from subtrees), so won't really help for this merge window.

For everything else I think this is up to Oded, I had no idea qaic needed
it's entire own dev class and I don't want to dig into this for the risk I
might freak out :-)

Adding Oded.

Cheers, Daniel


Sorry for the mess.

I made a note to update to class_register() once my drm-misc access is
sorted out.  Looks like we'll address the conflict in the merge window, and
catch the update to the new API in the following release.


Wait, I think the large question is, "why does this need a separate
class"?  Why are you not using the accel char device and class?  That is
what everything under accel/ should be using, otherwise why put it in
there?

And what exactly are you using that class for?  Just device nodes?  If
so, how many?

thanks,

greg k-h



Remember MHI_UCI that then evolved into the WWAN subsystem?  I pointed 
out at the time that AIC100/QAIC would need the same functionality. 
You/Jakub told myself/Mani/Loic that a combined implementation is not 
acceptable, and every area needs to implement their own version of MHI_UCI.


We took the WWAN subsystem and simplified it to meet our needs.

The functionality is QAIC specific, so wedging it into the Accel node 
seems to be a poor fit as it would subject Habana and iVPU to the same.


We need (eventually) 128 device nodes.  We have systems with 32 QAIC 
devices, and each QAIC device uses 4 device nodes (32 * 4 = 128).  WWAN 
subsystem would be similar.  Looks like each 5G modem is 6 nodes per 
device, so if you had 22 5G modems on a system, you'd have 132 device 
nodes.  I'm not aware of any such system, but it could exist.


-Jeff

Re: [PATCH v5 2/9] video/aperture: use generic code to figure out the vga default device

[Helge Deller]

On 4/11/23 16:36, Daniel Vetter wrote:

On Fri, Apr 07, 2023 at 10:54:00PM +0200, Helge Deller wrote:

On 4/6/23 15:21, Thomas Zimmermann wrote:

From: Daniel Vetter 

Since vgaarb has been promoted to be a core piece of the pci subsystem
we don't have to open code random guesses anymore, we actually know
this in a platform agnostic way, and there's no need for an x86
specific hack. See also commit 1d38fe6ee6a8 ("PCI/VGA: Move vgaarb to
drivers/pci")

This should not result in any functional change, and the non-x86
multi-gpu pci systems are probably rare enough to not matter (I don't
know of any tbh). But it's a nice cleanup, so let's do it.

There's been a few questions on previous iterations on dri-devel and
irc:

- fb_is_primary_device() seems to be yet another implementation of
this theme, and at least on x86 it checks for both
vga_default_device OR rom shadowing. There shouldn't ever be a case
where rom shadowing gives any additional hints about the boot vga
device, but if there is then the default vga selection in vgaarb
should probably be fixed. And not special-case checks replicated all
over.

- Thomas also brought up that on most !x86 systems
fb_is_primary_device() returns 0, except on sparc/parisc. But these
2 special cases are about platform specific devices and not pci, so
shouldn't have any interactions.


Nearly all graphics cards on parisc machines are actually PCI cards,
but the way we handle the handover to graphics mode with STIcore doesn't
conflicts with your planned aperture changes.
So no problem as far as I can see for parisc...


Ah I thought sticore was some very special bus, if those can be pci cards


STI stands for "Standard Text Interface" [1], which is a API of ROM functions
to output text chars on a console. It's comparable to the text output functions
in a PC-BIOS on x86 and dependend on the ROM it drives any supported card which 
has
a parisc ROM. So, STI supports cards on PCI & AGP busses, as well on older GSC 
busses.
[1] https://parisc.wiki.kernel.org/images-parisc/e/e3/Sti.pdf


underneath then I guess some cleanup eventually might be a good idea? For
anything with a pci bus it's rather strange when vgaarb and
fb_is_primary_device() aren't a match ...


There is no VGA on parisc, so there is no conflict. Cards come either with
a parisc STI ROM to support text mode, or they will only be used as secondary
cards only.  The graphics mode is only done in userspace by specific drivers, 
e.g.
by the X11 server in HP-UX.
Even on x86 the BIOS will only show text output if the graphics card comes
with a VGA-compatible BIOS.

Helge

Re: [PATCH 0/2] drm: sun4i/dsi: allow modeset helpers to manage display

[Maxime Ripard]

Hi,

On Mon, Apr 10, 2023 at 09:47:48AM +0100, Brandon Cheo Fusi wrote:
> This change moves DSI PHY poweron/off from the encoder to the TCON. 
> 
> As a consequence enabling or disabling the DSI sink can be left to the
> modeset helpers, and bridge support easily introduced without touching
> the drm_encoder.bridge_chain or converting the encoder to a
> drm_bridge.

I guess this is related to the discussion we had a couple of weeks ago
about being able to send DCS commands while in HS mode.

This just seems to workaround the issue entirely, breaking KMS
abstractions in the process. We had some leads on how to fix it
properly, so please follow them instead.

Maxime


signature.asc
Description: PGP signature

Re: linux-next: build failure after merge of the driver-core tree

[Greg KH]

On Tue, Apr 11, 2023 at 09:08:39AM -0600, Jeffrey Hugo wrote:
> On 4/11/2023 9:01 AM, Daniel Vetter wrote:
> > On Tue, Apr 11, 2023 at 12:40:28PM +0200, Greg KH wrote:
> > > On Tue, Apr 11, 2023 at 11:55:20AM +0200, Daniel Vetter wrote:
> > > > On Tue, Apr 11, 2023 at 02:38:12PM +1000, Stephen Rothwell wrote:
> > > > > Hi all,
> > > > > 
> > > > > After merging the driver-core tree, today's linux-next build (x86_64
> > > > > allmodconfig) failed like this:
> > > > > 
> > > > > In file included from include/linux/linkage.h:7,
> > > > >   from include/linux/kernel.h:17,
> > > > >   from drivers/accel/qaic/mhi_qaic_ctrl.c:4:
> > > > > drivers/accel/qaic/mhi_qaic_ctrl.c: In function 'mhi_qaic_ctrl_init':
> > > > > include/linux/export.h:27:22: error: passing argument 1 of 
> > > > > 'class_create' from incompatible pointer type 
> > > > > [-Werror=incompatible-pointer-types]
> > > > > 27 | #define THIS_MODULE (&__this_module)
> > > > >| ~^~~
> > > > >|  |
> > > > >|  struct module *
> > > > > drivers/accel/qaic/mhi_qaic_ctrl.c:544:38: note: in expansion of 
> > > > > macro 'THIS_MODULE'
> > > > >544 | mqc_dev_class = class_create(THIS_MODULE, 
> > > > > MHI_QAIC_CTRL_DRIVER_NAME);
> > > > >|  ^~~
> > > > > In file included from include/linux/device.h:31,
> > > > >   from include/linux/mhi.h:9,
> > > > >   from drivers/accel/qaic/mhi_qaic_ctrl.c:5:
> > > > > include/linux/device/class.h:229:54: note: expected 'const char *' 
> > > > > but argument is of type 'struct module *'
> > > > >229 | struct class * __must_check class_create(const char *name);
> > > > >|  ^~~~
> > > > > drivers/accel/qaic/mhi_qaic_ctrl.c:544:25: error: too many arguments 
> > > > > to function 'class_create'
> > > > >544 | mqc_dev_class = class_create(THIS_MODULE, 
> > > > > MHI_QAIC_CTRL_DRIVER_NAME);
> > > > >| ^~~~
> > > > > include/linux/device/class.h:229:29: note: declared here
> > > > >229 | struct class * __must_check class_create(const char *name);
> > > > >| ^~~~
> > > > > 
> > > > > Caused by commit
> > > > > 
> > > > >1aaba11da9aa ("driver core: class: remove module * from 
> > > > > class_create()")
> > > > > 
> > > > > interacting with commit
> > > > > 
> > > > >566fc96198b4 ("accel/qaic: Add mhi_qaic_cntl")
> > > > > 
> > > > > from the drm tree.
> > > > > 
> > > > > I have applied the following merge fix patch for today.
> > > > > 
> > > > > From: Stephen Rothwell 
> > > > > Date: Tue, 11 Apr 2023 14:16:57 +1000
> > > > > Subject: [PATCH] fixup for "driver core: class: remove module * from 
> > > > > class_create()"
> > > > > 
> > > > > interacting with "accel/qaic: Add mhi_qaic_cntl"
> > > > > 
> > > > > Signed-off-by: Stephen Rothwell 
> > > > 
> > > > Thanks for the fixup. Since Dave is out I've made a note about this in 
> > > > my
> > > > handover mail so it won't get lost in the drm-next merge window pull. I
> > > > don't think we need any other coordination than mention it in each pull 
> > > > to
> > > > Linus, topic tree seems overkill for this. Plus there's no way I can
> > > > untangle the drm tree anyway :-).
> > > 
> > > Want me to submit a patch for the drm tree that moves this to use
> > > class_register() instead, which will make the merge/build issue go away
> > > for you?  That's my long-term goal here anyway, so converting this new
> > > code to this api today would be something I have to do eventually :)
> > 
> > We kinda closed drm-next for feature work mostly already (just pulling
> > stuff in from subtrees), so won't really help for this merge window.
> > 
> > For everything else I think this is up to Oded, I had no idea qaic needed
> > it's entire own dev class and I don't want to dig into this for the risk I
> > might freak out :-)
> > 
> > Adding Oded.
> > 
> > Cheers, Daniel
> 
> Sorry for the mess.
> 
> I made a note to update to class_register() once my drm-misc access is
> sorted out.  Looks like we'll address the conflict in the merge window, and
> catch the update to the new API in the following release.

Wait, I think the large question is, "why does this need a separate
class"?  Why are you not using the accel char device and class?  That is
what everything under accel/ should be using, otherwise why put it in
there?

And what exactly are you using that class for?  Just device nodes?  If
so, how many?

thanks,

greg k-h

Re: [PATCH v2 1/2] drm: Add fdinfo memory stats

[Daniel Vetter]

On Tue, Apr 11, 2023 at 08:02:09AM -0700, Rob Clark wrote:
> On Tue, Apr 11, 2023 at 3:43 AM Daniel Vetter  wrote:
> >
> > On Mon, Apr 10, 2023 at 02:06:06PM -0700, Rob Clark wrote:
> > > From: Rob Clark 
> > >
> > > Add a helper to dump memory stats to fdinfo.  For the things the drm
> > > core isn't aware of, use a callback.
> > >
> > > v2: Fix typos, change size units to match docs, use div_u64
> > >
> > > Signed-off-by: Rob Clark 
> > > Reviewed-by: Emil Velikov 
> >
> > Uh can't we wire this up by default? Having this as a per-driver opt-in
> > sounds like we'll get maximally fragmented drm fd_info, and since that's
> > uapi I don't think that's any good at all.
> 
> That is the reason for the centralized documentation of the props (and
> why for this one I added a helper, rather than continuing the current
> pattern of everyone rolling their own)..

Yeah, but we all know how consistent specs are without either a common
implementation or a test suite (or better, both) :-)

It's imo good to kick of new things, but anything that multiple drivers
could/should implement or once we have multiple drivers implementing
something should be common code.

I'm doing the same pushing for the fd_info around ctx, at least all
drivers using drm/sched should mostly just get this stuff instead of tons
of driver glue that then blows up in interesting ways because people
discover new ways to get lifetime rules wrong ...

> We _could_ (and I had contemplated) doing this all in core if (a) we
> move madv to drm_gem_object, and (b) track
> drm_gem_get_pages()/drm_gem_put_pages().  I guess neither is totally
> unreasonable, pretty much all the non-ttm/non-cma GEM drivers have
> some form of madvise ioctl and use
> drm_gem_get_pages()/drm_gem_put_pages()..

The active part shouldn't need anything new, you should be able to compute
that by looking at dma_resv (which is still ok under the spinlock, we
still have the lockless stuff to check status afaik).

The other bits are a bit more work, and I guess you could sort that out
for now by making the status callback optional. Long term pushing
purgeable as a concept one level up might make sense, but that's maybe a
bit too much refactoring for this.

I think just the minimal to get at least infra in place and the fully
driver-agnostic stuff computed for every gem driver would be great
already. And it makes it much easier for the next fd_info thing to become
fully generic, which hopefully motivates people to do that.
-Daniel

> 
> BR,
> -R
> 
> > I think it's time we have
> > - drm_fd_info
> > - rolled out to all drivers in their fops
> > - with feature checks as appropriate
> > - push the driver-specific things into a drm_driver callback
> >
> > And I guess start peopling giving a hard time for making things needless
> > driver-specifict ... there's really no reason at all this is not
> > consistent across drivers.
> > -Daniel
> >
> > > ---
> > >  Documentation/gpu/drm-usage-stats.rst | 21 +++
> > >  drivers/gpu/drm/drm_file.c| 79 +++
> > >  include/drm/drm_file.h| 10 
> > >  3 files changed, 110 insertions(+)
> > >
> > > diff --git a/Documentation/gpu/drm-usage-stats.rst 
> > > b/Documentation/gpu/drm-usage-stats.rst
> > > index b46327356e80..b5e7802532ed 100644
> > > --- a/Documentation/gpu/drm-usage-stats.rst
> > > +++ b/Documentation/gpu/drm-usage-stats.rst
> > > @@ -105,6 +105,27 @@ object belong to this client, in the respective 
> > > memory region.
> > >  Default unit shall be bytes with optional unit specifiers of 'KiB' or 
> > > 'MiB'
> > >  indicating kibi- or mebi-bytes.
> > >
> > > +- drm-shared-memory:  [KiB|MiB]
> > > +
> > > +The total size of buffers that are shared with another file (ie. have 
> > > more
> > > +than a single handle).
> > > +
> > > +- drm-private-memory:  [KiB|MiB]
> > > +
> > > +The total size of buffers that are not shared with another file.
> > > +
> > > +- drm-resident-memory:  [KiB|MiB]
> > > +
> > > +The total size of buffers that are resident in system memory.
> > > +
> > > +- drm-purgeable-memory:  [KiB|MiB]
> > > +
> > > +The total size of buffers that are purgeable.
> > > +
> > > +- drm-active-memory:  [KiB|MiB]
> > > +
> > > +The total size of buffers that are active on one or more rings.
> > > +
> > >  - drm-cycles- 
> > >
> > >  Engine identifier string must be the same as the one specified in the
> > > diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> > > index a51ff8cee049..085b01842a87 100644
> > > --- a/drivers/gpu/drm/drm_file.c
> > > +++ b/drivers/gpu/drm/drm_file.c
> > > @@ -42,6 +42,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >
> > >  #include "drm_crtc_internal.h"
> > > @@ -868,6 +869,84 @@ void drm_send_event(struct drm_device *dev, struct 
> > > drm_pending_event *e)
> > >  }
> > >  EXPORT_SYMBOL(drm_send_event);
> > >
> > > +static void print_size(struct drm_printer *p, const char *stat, 

Re: linux-next: build failure after merge of the driver-core tree

[Jeffrey Hugo]

On 4/11/2023 9:01 AM, Daniel Vetter wrote:

On Tue, Apr 11, 2023 at 12:40:28PM +0200, Greg KH wrote:

On Tue, Apr 11, 2023 at 11:55:20AM +0200, Daniel Vetter wrote:

On Tue, Apr 11, 2023 at 02:38:12PM +1000, Stephen Rothwell wrote:

Hi all,

After merging the driver-core tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from include/linux/linkage.h:7,
  from include/linux/kernel.h:17,
  from drivers/accel/qaic/mhi_qaic_ctrl.c:4:
drivers/accel/qaic/mhi_qaic_ctrl.c: In function 'mhi_qaic_ctrl_init':
include/linux/export.h:27:22: error: passing argument 1 of 'class_create' from 
incompatible pointer type [-Werror=incompatible-pointer-types]
27 | #define THIS_MODULE (&__this_module)
   | ~^~~
   |  |
   |  struct module *
drivers/accel/qaic/mhi_qaic_ctrl.c:544:38: note: in expansion of macro 
'THIS_MODULE'
   544 | mqc_dev_class = class_create(THIS_MODULE, 
MHI_QAIC_CTRL_DRIVER_NAME);
   |  ^~~
In file included from include/linux/device.h:31,
  from include/linux/mhi.h:9,
  from drivers/accel/qaic/mhi_qaic_ctrl.c:5:
include/linux/device/class.h:229:54: note: expected 'const char *' but argument 
is of type 'struct module *'
   229 | struct class * __must_check class_create(const char *name);
   |  ^~~~
drivers/accel/qaic/mhi_qaic_ctrl.c:544:25: error: too many arguments to 
function 'class_create'
   544 | mqc_dev_class = class_create(THIS_MODULE, 
MHI_QAIC_CTRL_DRIVER_NAME);
   | ^~~~
include/linux/device/class.h:229:29: note: declared here
   229 | struct class * __must_check class_create(const char *name);
   | ^~~~

Caused by commit

   1aaba11da9aa ("driver core: class: remove module * from class_create()")

interacting with commit

   566fc96198b4 ("accel/qaic: Add mhi_qaic_cntl")

from the drm tree.

I have applied the following merge fix patch for today.

From: Stephen Rothwell 
Date: Tue, 11 Apr 2023 14:16:57 +1000
Subject: [PATCH] fixup for "driver core: class: remove module * from 
class_create()"

interacting with "accel/qaic: Add mhi_qaic_cntl"

Signed-off-by: Stephen Rothwell 


Thanks for the fixup. Since Dave is out I've made a note about this in my
handover mail so it won't get lost in the drm-next merge window pull. I
don't think we need any other coordination than mention it in each pull to
Linus, topic tree seems overkill for this. Plus there's no way I can
untangle the drm tree anyway :-).


Want me to submit a patch for the drm tree that moves this to use
class_register() instead, which will make the merge/build issue go away
for you?  That's my long-term goal here anyway, so converting this new
code to this api today would be something I have to do eventually :)


We kinda closed drm-next for feature work mostly already (just pulling
stuff in from subtrees), so won't really help for this merge window.

For everything else I think this is up to Oded, I had no idea qaic needed
it's entire own dev class and I don't want to dig into this for the risk I
might freak out :-)

Adding Oded.

Cheers, Daniel


Sorry for the mess.

I made a note to update to class_register() once my drm-misc access is 
sorted out.  Looks like we'll address the conflict in the merge window, 
and catch the update to the new API in the following release.


-Jeff

Re: [PATCH 2/5] drm/amd/display: Move three variable assignments behind condition checks in trigger_hotplug()

[Christian König]

Am 11.04.23 um 15:43 schrieb Markus Elfring:

Date: Tue, 11 Apr 2023 11:39:02 +0200

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “trigger_hotplug”.

Thus avoid the risk for undefined behaviour by moving the assignment
for three local variables behind some condition checks.


It might be that the NULL check doesn't make sense in the first place, 
but since I'm not an expert for this code I can't fully judge.


On the other hand the patches clearly look like nice cleanups to me, so 
feel free to add an Acked-by: Christian König  
to the series.


Thanks,
Christian.



This issue was detected by using the Coccinelle software.

Fixes: 6f77b2ac628073f647041a92b36c824ae3aef16e ("drm/amd/display: Add connector HPD 
trigger debugfs entry")
Signed-off-by: Markus Elfring 
---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c  | 10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 827fcb4fb3b3..b3cfd7dfbb28 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -1205,10 +1205,10 @@ static ssize_t trigger_hotplug(struct file *f, const 
char __user *buf,
size_t size, loff_t 
*pos)
  {
struct amdgpu_dm_connector *aconnector = file_inode(f)->i_private;
-   struct drm_connector *connector = >base;
+   struct drm_connector *connector;
struct dc_link *link = NULL;
-   struct drm_device *dev = connector->dev;
-   struct amdgpu_device *adev = drm_to_adev(dev);
+   struct drm_device *dev;
+   struct amdgpu_device *adev;
enum dc_connection_type new_connection_type = dc_connection_none;
char *wr_buf = NULL;
uint32_t wr_buf_size = 42;
@@ -1253,12 +1253,16 @@ static ssize_t trigger_hotplug(struct file *f, const 
char __user *buf,
return -EINVAL;
}

+   connector = >base;
+   dev = connector->dev;
+
if (param[0] == 1) {

if (!dc_link_detect_connection_type(aconnector->dc_link, 
_connection_type) &&
new_connection_type != dc_connection_none)
goto unlock;

+   adev = drm_to_adev(dev);
mutex_lock(>dm.dc_lock);
ret = dc_link_detect(aconnector->dc_link, DETECT_REASON_HPD);
mutex_unlock(>dm.dc_lock);
--
2.40.0

Re: [PATCH v2 1/2] drm: Add fdinfo memory stats

[Rob Clark]

On Tue, Apr 11, 2023 at 3:43 AM Daniel Vetter  wrote:
>
> On Mon, Apr 10, 2023 at 02:06:06PM -0700, Rob Clark wrote:
> > From: Rob Clark 
> >
> > Add a helper to dump memory stats to fdinfo.  For the things the drm
> > core isn't aware of, use a callback.
> >
> > v2: Fix typos, change size units to match docs, use div_u64
> >
> > Signed-off-by: Rob Clark 
> > Reviewed-by: Emil Velikov 
>
> Uh can't we wire this up by default? Having this as a per-driver opt-in
> sounds like we'll get maximally fragmented drm fd_info, and since that's
> uapi I don't think that's any good at all.

That is the reason for the centralized documentation of the props (and
why for this one I added a helper, rather than continuing the current
pattern of everyone rolling their own)..

We _could_ (and I had contemplated) doing this all in core if (a) we
move madv to drm_gem_object, and (b) track
drm_gem_get_pages()/drm_gem_put_pages().  I guess neither is totally
unreasonable, pretty much all the non-ttm/non-cma GEM drivers have
some form of madvise ioctl and use
drm_gem_get_pages()/drm_gem_put_pages()..

BR,
-R

> I think it's time we have
> - drm_fd_info
> - rolled out to all drivers in their fops
> - with feature checks as appropriate
> - push the driver-specific things into a drm_driver callback
>
> And I guess start peopling giving a hard time for making things needless
> driver-specifict ... there's really no reason at all this is not
> consistent across drivers.
> -Daniel
>
> > ---
> >  Documentation/gpu/drm-usage-stats.rst | 21 +++
> >  drivers/gpu/drm/drm_file.c| 79 +++
> >  include/drm/drm_file.h| 10 
> >  3 files changed, 110 insertions(+)
> >
> > diff --git a/Documentation/gpu/drm-usage-stats.rst 
> > b/Documentation/gpu/drm-usage-stats.rst
> > index b46327356e80..b5e7802532ed 100644
> > --- a/Documentation/gpu/drm-usage-stats.rst
> > +++ b/Documentation/gpu/drm-usage-stats.rst
> > @@ -105,6 +105,27 @@ object belong to this client, in the respective memory 
> > region.
> >  Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
> >  indicating kibi- or mebi-bytes.
> >
> > +- drm-shared-memory:  [KiB|MiB]
> > +
> > +The total size of buffers that are shared with another file (ie. have more
> > +than a single handle).
> > +
> > +- drm-private-memory:  [KiB|MiB]
> > +
> > +The total size of buffers that are not shared with another file.
> > +
> > +- drm-resident-memory:  [KiB|MiB]
> > +
> > +The total size of buffers that are resident in system memory.
> > +
> > +- drm-purgeable-memory:  [KiB|MiB]
> > +
> > +The total size of buffers that are purgeable.
> > +
> > +- drm-active-memory:  [KiB|MiB]
> > +
> > +The total size of buffers that are active on one or more rings.
> > +
> >  - drm-cycles- 
> >
> >  Engine identifier string must be the same as the one specified in the
> > diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> > index a51ff8cee049..085b01842a87 100644
> > --- a/drivers/gpu/drm/drm_file.c
> > +++ b/drivers/gpu/drm/drm_file.c
> > @@ -42,6 +42,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >
> >  #include "drm_crtc_internal.h"
> > @@ -868,6 +869,84 @@ void drm_send_event(struct drm_device *dev, struct 
> > drm_pending_event *e)
> >  }
> >  EXPORT_SYMBOL(drm_send_event);
> >
> > +static void print_size(struct drm_printer *p, const char *stat, size_t sz)
> > +{
> > + const char *units[] = {"", " KiB", " MiB"};
> > + unsigned u;
> > +
> > + for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
> > + if (sz < SZ_1K)
> > + break;
> > + sz = div_u64(sz, SZ_1K);
> > + }
> > +
> > + drm_printf(p, "%s:\t%zu%s\n", stat, sz, units[u]);
> > +}
> > +
> > +/**
> > + * drm_print_memory_stats - Helper to print standard fdinfo memory stats
> > + * @file: the DRM file
> > + * @p: the printer to print output to
> > + * @status: callback to get driver tracked object status
> > + *
> > + * Helper to iterate over GEM objects with a handle allocated in the 
> > specified
> > + * file.  The optional status callback can return additional object state 
> > which
> > + * determines which stats the object is counted against.  The callback is 
> > called
> > + * under table_lock.  Racing against object status change is "harmless", 
> > and the
> > + * callback can expect to not race against object destruction.
> > + */
> > +void drm_print_memory_stats(struct drm_file *file, struct drm_printer *p,
> > + enum drm_gem_object_status (*status)(struct 
> > drm_gem_object *))
> > +{
> > + struct drm_gem_object *obj;
> > + struct {
> > + size_t shared;
> > + size_t private;
> > + size_t resident;
> > + size_t purgeable;
> > + size_t active;
> > + } size = {0};
> > + int id;
> > +
> > + spin_lock(>table_lock);
> > + idr_for_each_entry (>object_idr, obj, 

Re: linux-next: build failure after merge of the driver-core tree

[Daniel Vetter]

On Tue, Apr 11, 2023 at 12:40:28PM +0200, Greg KH wrote:
> On Tue, Apr 11, 2023 at 11:55:20AM +0200, Daniel Vetter wrote:
> > On Tue, Apr 11, 2023 at 02:38:12PM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > After merging the driver-core tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > > 
> > > In file included from include/linux/linkage.h:7,
> > >  from include/linux/kernel.h:17,
> > >  from drivers/accel/qaic/mhi_qaic_ctrl.c:4:
> > > drivers/accel/qaic/mhi_qaic_ctrl.c: In function 'mhi_qaic_ctrl_init':
> > > include/linux/export.h:27:22: error: passing argument 1 of 'class_create' 
> > > from incompatible pointer type [-Werror=incompatible-pointer-types]
> > >27 | #define THIS_MODULE (&__this_module)
> > >   | ~^~~
> > >   |  |
> > >   |  struct module *
> > > drivers/accel/qaic/mhi_qaic_ctrl.c:544:38: note: in expansion of macro 
> > > 'THIS_MODULE'
> > >   544 | mqc_dev_class = class_create(THIS_MODULE, 
> > > MHI_QAIC_CTRL_DRIVER_NAME);
> > >   |  ^~~
> > > In file included from include/linux/device.h:31,
> > >  from include/linux/mhi.h:9,
> > >  from drivers/accel/qaic/mhi_qaic_ctrl.c:5:
> > > include/linux/device/class.h:229:54: note: expected 'const char *' but 
> > > argument is of type 'struct module *'
> > >   229 | struct class * __must_check class_create(const char *name);
> > >   |  ^~~~
> > > drivers/accel/qaic/mhi_qaic_ctrl.c:544:25: error: too many arguments to 
> > > function 'class_create'
> > >   544 | mqc_dev_class = class_create(THIS_MODULE, 
> > > MHI_QAIC_CTRL_DRIVER_NAME);
> > >   | ^~~~
> > > include/linux/device/class.h:229:29: note: declared here
> > >   229 | struct class * __must_check class_create(const char *name);
> > >   | ^~~~
> > > 
> > > Caused by commit
> > > 
> > >   1aaba11da9aa ("driver core: class: remove module * from class_create()")
> > > 
> > > interacting with commit
> > > 
> > >   566fc96198b4 ("accel/qaic: Add mhi_qaic_cntl")
> > > 
> > > from the drm tree.
> > > 
> > > I have applied the following merge fix patch for today.
> > > 
> > > From: Stephen Rothwell 
> > > Date: Tue, 11 Apr 2023 14:16:57 +1000
> > > Subject: [PATCH] fixup for "driver core: class: remove module * from 
> > > class_create()"
> > > 
> > > interacting with "accel/qaic: Add mhi_qaic_cntl"
> > > 
> > > Signed-off-by: Stephen Rothwell 
> > 
> > Thanks for the fixup. Since Dave is out I've made a note about this in my
> > handover mail so it won't get lost in the drm-next merge window pull. I
> > don't think we need any other coordination than mention it in each pull to
> > Linus, topic tree seems overkill for this. Plus there's no way I can
> > untangle the drm tree anyway :-).
> 
> Want me to submit a patch for the drm tree that moves this to use
> class_register() instead, which will make the merge/build issue go away
> for you?  That's my long-term goal here anyway, so converting this new
> code to this api today would be something I have to do eventually :)

We kinda closed drm-next for feature work mostly already (just pulling
stuff in from subtrees), so won't really help for this merge window.

For everything else I think this is up to Oded, I had no idea qaic needed
it's entire own dev class and I don't want to dig into this for the risk I
might freak out :-)

Adding Oded.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [pull] drm/msm: drm-msm-next-2023-04-10 for v6.4

[Daniel Vetter]

On Tue, Apr 11, 2023 at 07:55:33AM -0700, Rob Clark wrote:
> On Tue, Apr 11, 2023 at 3:27 AM Daniel Vetter  wrote:
> > > Konrad Dybcio (18):
> > >   drm/msm/adreno: Use OPP for every GPU generation
> >
> > This had a minor conflict with refactoring from drm-misc-next, I went
> > what's in your pr. Please double check I didn't screw up, but at least it
> > compiles :-)
> 
> Hmm, am I looking at the wrong thing.. the conflict I'm seeing is with
> drm_gem_lru (and looks to be correctly resolved)

Yeah that one was trivial. Unfortunately git does not report anything if
you only keep one or the other branch entirely in your resolution, so the
only way for you to see the conflict is to re-create the merge :-) Or at
least my git foo isn't good enough for a better way ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [pull] drm/msm: drm-msm-next-2023-04-10 for v6.4

[Rob Clark]

On Tue, Apr 11, 2023 at 3:27 AM Daniel Vetter  wrote:
>
> On Mon, Apr 10, 2023 at 07:50:50AM -0700, Rob Clark wrote:
> > Hi Dave,
> >
> > This is the main pull for v6.4, see below for description.  A bit big
> > this time because of (1) generated header updates and (2) dpu hw
> > catelog rework which split the increasingly unwieldy
> > big-giant-file-of-tables into per-SoC files.  But those are mainly
> > mechanical churn.
> >
> > The following changes since commit e752ab11dcb48353727ea26eefd740155e028865:
> >
> >   Merge remote-tracking branch 'drm/drm-next' into msm-next
> > (2023-03-20 10:31:25 -0700)
> >
> > are available in the Git repository at:
> >
> >   https://gitlab.freedesktop.org/drm/msm.git tags/drm-msm-next-2023-04-10
> >
> > for you to fetch changes up to ac7e7c9c65ecfb1fcc99de91cfd6b17a8d4cb9c1:
> >
> >   drm/msm/dpu: drop unused macros from hw catalog (2023-04-07 03:54:50 
> > +0300)
>
> Pulled, thanks.
>
> Two comments below.
>
> >
> > 
> > main pull request for v6.4
> >
> > Core Display:
> > 
> > * Bugfixes for error handling during probe
> > * rework UBWC decoder programming
> > * prepare_commit cleanup
> > * bindings for SM8550 (MDSS, DPU), SM8450 (DP)
> > * timeout calculation fixup
> > * atomic: use drm_crtc_next_vblank_start() instead of our own
> >   custom thing to calculate the start of next vblank
> >
> > DP:
> > ==
> > * interrupts cleanup
> >
> > DPU:
> > ===
> > * DSPP sub-block flush on sc7280
> > * support AR30 in addition to XR30 format
> > * Allow using REC_0 and REC_1 to handle wide (4k) RGB planes
> > * Split the HW catalog into individual per-SoC files
> >
> > DSI:
> > ===
> > * rework DSI instance ID detection on obscure platforms
> >
> > GPU:
> > ===
> > * uapi C++ compatibility fix
> > * a6xx: More robust gdsc reset
> > * a3xx and a4xx devfreq support
> > * update generated headers
> > * various cleanups and fixes
> > * GPU and GEM updates to avoid allocations which could trigger
> >   reclaim (shrinker) in fence signaling path
>
> dim complained about a pile of commits without 2nd eyes, and it was mostly
> this. I think especially for these tricky locking/reclaim issues having a
> bus factor > 1 would be really good. I'll try and brush of my anotations,
> hopefully we can have a bit more cross-driver discussions and reviews
> going here, iirc when Boris did the timed_out annotations for panfrost he
> didn't fix all the splats, so that's perfect candidate to help push the
> remaining work.

Fwiw, that was at least all tested with sched fence signaling
annotations, so tested-by: lockdep ;-)

Unfortunately we can't enable the annotations yet because of various
fixes needed in pm and icc.  But I'll resend that series with the
remaining outstanding patches after the merge window.

> > * dma-fence deadline hint support and wait-boost
> > * a640 speedbin support
> > * a650 speedbin support
> >
> > 
> > Abhinav Kumar (3):
> >   MAINTAINERS: Update the URI for MSM DRM bugs
> >   drm/msm/dpu: log the multirect_index in _dpu_crtc_blend_setup_pipe
> >   drm/msm/dpu: remove unused dpu_plane_validate_multirect_v2 function
> >
> > Adam Skladowski (1):
> >   drm: msm: adreno: Disable preemption on Adreno 510
> >
> > Akhil P Oommen (3):
> >   drm/msm/a6xx: Vote for cx gdsc from gpu driver
> >   drm/msm/a6xx: Remove cx gdsc polling using 'reset'
> >   drm/msm/a6xx: Use genpd notifier to ensure cx-gdsc collapse
> >
> > Arnd Bergmann (1):
> >   drm/msm/a6xx: add CONFIG_PM dependency
> >
> > Colin Ian King (2):
> >   drm/msm/mdss: Fix spelling mistake "Unuspported" -> "Unsupported"
> >   drm/msm/dp: Fix spelling mistake "Capabiity" -> "Capability"
> >
> > Danylo Piliaiev (1):
> >   drm/msm: Rename drm_msm_gem_submit_reloc::or in C++ code
> >
> > Dmitry Baryshkov (67):
> >   drm/msm/adreno: stall translation on fault for all GPU families
> >   drm/msm/adreno: split a6xx fault handler into generic and a6xx parts
> >   drm/msm/a5xx: add devcoredump support to the fault handler
> >   drm/msm/mdss: convert UBWC setup to use match data
> >   drm/msm/mdss: add data for sc8180xp
> >   drm/msm/mdss: add the sdm845 data for completeness
> >   drm/msm/dpu: rename struct dpu_hw_pipe(_cfg) to dpu_hw_sspp(_cfg)
> >   drm/msm/dpu: move SSPP allocation to the RM
> >   drm/msm/dpu: move SSPP debugfs creation to dpu_kms.c
> >   drm/msm/dpu: drop EAGAIN check from dpu_format_populate_layout
> >   drm/msm/dpu: move pipe_hw to dpu_plane_state
> >   drm/msm/dpu: drop dpu_plane_pipe function
> >   drm/msm/dpu: introduce struct dpu_sw_pipe
> >   drm/msm/dpu: use dpu_sw_pipe for dpu_hw_sspp callbacks
> >   drm/msm/dpu: pass dpu_format to _dpu_hw_sspp_setup_scaler3()
> >   drm/msm/dpu: clean up SRC addresses when setting up SSPP for solid 
> > fill
> >   

Re: [PATCH] drm/fbdev-generic: fix potential out-of-bounds access

[Daniel Vetter]

On Sun, Apr 09, 2023 at 09:21:10PM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng 
> 
> We should setting the screen buffer size according to the screen's actual
> size, rather than the size of the GEM object backing the front framebuffer.
> The size of GEM buffer is page size aligned, while the size of active area
> of a specific screen is *NOT* necessarily page size aliged. For example,
> 1680x1050, 1600x900, 1440x900, 800x6000 etc. In those case, the damage rect
> computed by drm_fb_helper_memory_range_to_clip() goes out of bottom bounds
> of the display.
> 
> Run fbdev test of IGT on a x86+ast2400 platform with 1680x1050 resolution
> will cause the system hang with the following call trace:
> 
>   Oops:  [#1] PREEMPT SMP PTI
>   [IGT] fbdev: starting subtest eof
>   Workqueue: events drm_fb_helper_damage_work [drm_kms_helper]
>   [IGT] fbdev: starting subtest nullptr
> 
>   RIP: 0010:memcpy_erms+0xa/0x20
>   RSP: 0018:a17d40167d98 EFLAGS: 00010246
>   RAX: a17d4eb7fa80 RBX: a17d40e0aa80 RCX: 14c0
>   RDX: 1a40 RSI: a17d40e0b000 RDI: a17d4eb8
>   RBP: a17d40167e20 R08:  R09: 89522ecff8c0
>   R10: a17d4e4c5000 R11:  R12: a17d4eb7fa80
>   R13: 1a40 R14: 041a R15: a17d40167e30
>   FS:  () GS:89525738() knlGS:
>   CS:  0010 DS:  ES:  CR0: 80050033
>   CR2: a17d40e0b000 CR3: 0001eaeca006 CR4: 001706e0
>   Call Trace:
>
>? drm_fbdev_generic_helper_fb_dirty+0x207/0x330 [drm_kms_helper]
>drm_fb_helper_damage_work+0x8f/0x170 [drm_kms_helper]
>process_one_work+0x21f/0x430
>worker_thread+0x4e/0x3c0
>? __pfx_worker_thread+0x10/0x10
>kthread+0xf4/0x120
>? __pfx_kthread+0x10/0x10
>ret_from_fork+0x2c/0x50
>
>   CR2: a17d40e0b000
>   ---[ end trace  ]---
> 
> We also add trival code in this patch to restrict the damage rect beyond
> the last line of the framebuffer.

Nice catch!

> 
> Signed-off-by: Sui Jingfeng 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 2 +-
>  drivers/gpu/drm/drm_fbdev_generic.c | 2 ++
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 64458982be40..a2b749372759 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -645,7 +645,7 @@ static void drm_fb_helper_memory_range_to_clip(struct 
> fb_info *info, off_t off,
>   u32 x1 = 0;
>   u32 y1 = off / info->fix.line_length;
>   u32 x2 = info->var.xres;
> - u32 y2 = DIV_ROUND_UP(end, info->fix.line_length);
> + u32 y2 = min_t(u32, DIV_ROUND_UP(end, info->fix.line_length), 
> info->var.yres);

So for additional robustness I think it'd be good if we change the entire
computation here to use drm_framebuffer data and not fb_info data, because
fundamentally that's what the drm kms code consumes. It should all match
anyway, but I think it makes the code more obviously correct.

So in the entire function instead of looking at fb_info->fix we should
probably look at

struct drm_fb_helper *helper = info->par;

And then helper->fb->pitches[0] and helper->fb->height.

If you agree would be great if you can please respin with that (and the
commit message augmented to explain why we do the change)?
>  
>   if ((y2 - y1) == 1) {
>   /*
> diff --git a/drivers/gpu/drm/drm_fbdev_generic.c 
> b/drivers/gpu/drm/drm_fbdev_generic.c
> index 8e5148bf40bb..a6daecb5f640 100644
> --- a/drivers/gpu/drm/drm_fbdev_generic.c
> +++ b/drivers/gpu/drm/drm_fbdev_generic.c
> @@ -95,6 +95,8 @@ static int drm_fbdev_generic_helper_fb_probe(struct 
> drm_fb_helper *fb_helper,
>   fb_helper->fb = buffer->fb;
>  
>   screen_size = buffer->gem->size;

I guess you forgot to remove this line here? Also I'm not understanding
why this matters, I think you're fix only needs the above chunk, not this
one? If I got this right then please drop this part, there's drivers which
only use drm_fb_helper.c but not drm_fbdev_generic.c, and from what I can
tell they all still set the gem buffer size here.

If otoh we need this too, then there's a few more places that need to be
fixed.

> + screen_size = sizes->surface_height * buffer->fb->pitches[0];
> +
>   screen_buffer = vzalloc(screen_size);
>   if (!screen_buffer) {
>   ret = -ENOMEM;

Cheers, Daniel

> -- 
> 2.25.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch