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

[Frank Oltmanns]

Hi Roman,

On 2023-03-29 at 21:58:02 +0200, Maxime Ripard  wrote:
> On Tue, Mar 28, 2023 at 01:48:33AM +0200, Roman Beranek wrote:
>> On Mon Mar 27, 2023 at 10:20 PM CEST, Maxime Ripard wrote:
>> >
>> > On Sat, Mar 25, 2023 at 12:40:04PM +0100, Frank Oltmanns wrote:
>> > > Claiming to set the divider to a different value (bpp / lanes) than what 
>> > > we’re actually using in
>> > > the end (SUN6I_DSIO_TCON_DIV) is somehow bugging me. I feel like the 
>> > > proposal that I submitted is
>> > > more direct: 
>> > > 
>> >
>> > Yeah, this patch looks better to me too: it's simpler, more 
>> > straightforward. If Roman can confirm it
>> > works with his testing, I'll be happy to merge it.
>> >
>>
>> So I've just found out that my understanding of what sun4i_dotclock is
>> was wrong the whole time. I treated it as a virtual clock representing
>> the true CRTC pixel clock and only coincidentally also matching what
>> A64 Reference Manual labels as TCON0 data clock (a coincidence to which
>> DSI is an exception).
>>
>> Now that I finally see dotclock as 'what could dclk be an abbreviation
>> to', I to agree that it's not only straightforward but also correct to
>> keep the divider at 4 and adjust the rate as is done it the patch Frank
>> submitted.
>>
>> In order to preserve semantic correctness however, I propose to preface
>> the change with a patch that renames sun4i_dotclock and tcon-pixel-clock
>> such that dot/pixel is replaced with d/data. What do you think?
>
> I don't think it's exposed to the userspace in any way so it makes sense to me

Roman, will you please submit a V2 of the patch I submitted then? Or do
you want me to do it?

Thanks,
  Frank

>
> Maxime
>


--

Re: [PATCH v7 27/32] drm/msm/dpu: add support for wide planes

[Abhinav Kumar]

On 3/29/2023 8:30 PM, Dmitry Baryshkov wrote:

On 30/03/2023 05:53, Abhinav Kumar wrote:



On 3/16/2023 9:16 AM, Dmitry Baryshkov wrote:

It is possible to use multirect feature and split source to use the SSPP
to output two consecutive rectangles. This commit brings in this
capability to support wider screen resolutions.

Tested-by: Abhinav Kumar  # sc7280
Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |  19 ++-
  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 136 +++---
  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h |   4 +
  3 files changed, 142 insertions(+), 17 deletions(-)

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

index 217a8112f1a2..90b406e409d3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -481,6 +481,15 @@ static void _dpu_crtc_blend_setup_mixer(struct 
drm_crtc *crtc,

 format, fb ? fb->modifier : 0,
 >pipe, 0, stage_cfg);
+    if (pstate->r_pipe.sspp) {
+    set_bit(pstate->r_pipe.sspp->idx, fetch_active);
+    _dpu_crtc_blend_setup_pipe(crtc, plane,
+   mixer, cstate->num_mixers,
+   pstate->stage,
+   format, fb ? fb->modifier : 0,
+   >r_pipe, 1, stage_cfg);
+    }
+
  /* blend config update */
  for (lm_idx = 0; lm_idx < cstate->num_mixers; lm_idx++) {
  _dpu_crtc_setup_blend_cfg(mixer + lm_idx, pstate, format);
@@ -1341,10 +1350,16 @@ static int _dpu_debugfs_status_show(struct 
seq_file *s, void *data)

  seq_printf(s, "\tdst x:%4d dst_y:%4d dst_w:%4d dst_h:%4d\n",
  state->crtc_x, state->crtc_y, state->crtc_w,
  state->crtc_h);
-    seq_printf(s, "\tsspp:%s\n",
+    seq_printf(s, "\tsspp[0]:%s\n",
 pstate->pipe.sspp->cap->name);
-    seq_printf(s, "\tmultirect: mode: %d index: %d\n",
+    seq_printf(s, "\tmultirect[0]: mode: %d index: %d\n",
  pstate->pipe.multirect_mode, 
pstate->pipe.multirect_index);

+    if (pstate->r_pipe.sspp) {
+    seq_printf(s, "\tsspp[1]:%s\n",
+   pstate->r_pipe.sspp->cap->name);
+    seq_printf(s, "\tmultirect[1]: mode: %d index: %d\n",
+   pstate->r_pipe.multirect_mode, 
pstate->r_pipe.multirect_index);

+    }
  seq_puts(s, "\n");
  }
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c

index f52120b05b6e..73db15d76059 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -701,6 +701,10 @@ static void _dpu_plane_color_fill(struct 
dpu_plane *pdpu,

  /* update sspp */
  _dpu_plane_color_fill_pipe(pstate, >pipe, 
>pipe_cfg.dst_rect,

 fill_color, fmt);
+
+    if (pstate->r_pipe.sspp)
+    _dpu_plane_color_fill_pipe(pstate, >r_pipe, 
>r_pipe_cfg.dst_rect,

+   fill_color, fmt);
  }
  int dpu_plane_validate_multirect_v2(struct 
dpu_multirect_plane_states *plane)
@@ -959,9 +963,12 @@ static int dpu_plane_atomic_check(struct 
drm_plane *plane,

  int ret = 0, min_scale;
  struct dpu_plane *pdpu = to_dpu_plane(plane);
  struct dpu_plane_state *pstate = 
to_dpu_plane_state(new_plane_state);

+    struct dpu_sw_pipe *pipe = >pipe;
+    struct dpu_sw_pipe *r_pipe = >r_pipe;
  const struct drm_crtc_state *crtc_state = NULL;
  const struct dpu_format *fmt;
  struct dpu_sw_pipe_cfg *pipe_cfg = >pipe_cfg;
+    struct dpu_sw_pipe_cfg *r_pipe_cfg = >r_pipe_cfg;
  struct drm_rect fb_rect = { 0 };
  uint32_t max_linewidth;
  unsigned int rotation;
@@ -985,8 +992,11 @@ static int dpu_plane_atomic_check(struct 
drm_plane *plane,

  if (!new_plane_state->visible)
  return 0;
-    pstate->pipe.multirect_index = DPU_SSPP_RECT_SOLO;
-    pstate->pipe.multirect_mode = DPU_SSPP_MULTIRECT_NONE;
+    pipe->multirect_index = DPU_SSPP_RECT_SOLO;
+    pipe->multirect_mode = DPU_SSPP_MULTIRECT_NONE;
+    r_pipe->multirect_index = DPU_SSPP_RECT_SOLO;
+    r_pipe->multirect_mode = DPU_SSPP_MULTIRECT_NONE;
+    r_pipe->sspp = NULL;
  pstate->stage = DPU_STAGE_0 + pstate->base.normalized_zpos;
  if (pstate->stage >= pdpu->catalog->caps->max_mixer_blendstages) {
@@ -1016,21 +1026,67 @@ static int dpu_plane_atomic_check(struct 
drm_plane *plane,

  return -E2BIG;
  }
+    fmt = to_dpu_format(msm_framebuffer_format(new_plane_state->fb));
+
  max_linewidth = pdpu->catalog->caps->max_linewidth;
-    /* check decimated source width */
  if (drm_rect_width(_cfg->src_rect) > max_linewidth) {
-    DPU_DEBUG_PLANE(pdpu, "invalid src " DRM_RECT_FMT " line:%u\n",
-    DRM_RECT_ARG(_cfg->src_rect), max_linewidth);
-    return -E2BIG;
-    }
+    /*
+ * 

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

[Frank Oltmanns]

Hi,

On 2023-03-29 at 21:56:39 +0200, Maxime Ripard  wrote:
> Hi,
>
> On Tue, Mar 28, 2023 at 09:28:19PM +0200, Frank Oltmanns wrote:
>> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
>> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
>> @@ -819,6 +819,34 @@ static void sun6i_dsi_encoder_disable(struct 
>> drm_encoder *encoder)
>>  regulator_disable(dsi->regulator);
>>  }
>>
>> +static bool sun6i_dsi_encoder_mode_fixup(
>> +   struct drm_encoder *encoder,
>> +   const struct drm_display_mode *mode,
>> +   struct drm_display_mode *adjusted_mode)
>
> So, mode_fixup is kind of deprecated in favour of atomic_check

I see. Thanks for pointing that out.

>> +{
>> +if (encoder->encoder_type == DRM_MODE_ENCODER_DSI) {
>> +/*
>> + * For DSI the PLL rate has to respect the bits per pixel and
>> + * number of lanes.
>> + *
>> + * According to the BSP code:
>> + * PLL rate = DOTCLOCK * bpp / lanes
>> + *
>> + * Therefore, the clock has to be adjusted in order to set the
>> + * correct PLL rate when actually setting the clock.
>> + */
>> +struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
>> +struct mipi_dsi_device *device = dsi->device;
>> +u8 bpp = mipi_dsi_pixel_format_to_bpp(device->format);
>> +u8 lanes = device->lanes;
>> +
>> +adjusted_mode->crtc_clock = mode->crtc_clock
>> + * bpp / (lanes * SUN6I_DSI_TCON_DIV);
>
> And that's visible to the userspace, so it's not where we should store
> that value. I guess the best way to do something similar would be to
> store it into crtc_state, and then reuse it there. But it starts to make
> a lot of rather complicated code compared to your previous patch.

Ah, interesting. But I agree, let's stick to the simpler aproach.

Thanks,
  Frank

>
> Maxime
>
> [[End of PGP Signed Part]]

--

Re: [PATCH 1/2] drm/amdgpu: Reset GPU on S0ix when device supports BOCO

[Mario Limonciello]

On 3/29/23 22:36, Kai-Heng Feng wrote:

On Wed, Mar 29, 2023 at 9:23 PM Mario Limonciello
 wrote:


On 3/29/23 04:59, Kai-Heng Feng wrote:

When the power is lost due to ACPI power resources being turned off, the
driver should reset the GPU so it can work anew.

First, _PR3 support of the hierarchy needs to be found correctly. Since
the GPU on some discrete GFX cards is behind a PCIe switch, checking the
_PR3 on downstream port alone is not enough, as the _PR3 can associate
to the root port above the PCIe switch.

I think this should be split into two commits:

* One of them to look at _PR3 further up in hierarchy to fix indication
for BOCO support.

Yes, this part can be split up.


* One to adjust policy for whether to reset

IIUC, the GPU only needs to be reset when the power status isn't certain?
Yeah; think of reset as a particular case that all hardware isn't 
initialized.

Assuming power resources in _PR3 are really disabled, GPU is already
reset by itself. That means reset shouldn't be necessary for D3cold,
am I understanding it correctly?

Can we see the acpidump for this system?

However, this is a desktop plugged with GFX card that has external
power, does that assumption still stand? Perform resetting on D3cold
can cover this scenario.


Are you sure it's going to D3cold?  Or is it D3hot?  What does _S0W have 
in this design?





Once the _PR3 is found and BOCO support is correctly marked, use that
information to inform the GPU should be reset. This solves an issue that
system freeze on a Intel ADL desktop that uses S0ix for sleep and D3cold
is supported for the GFX slot.

I'm worried this is still papering over an underlying issue with L0s
handling on ALD + Navi1x/Navi2x.

Is it possible to get the ASIC's ASPM parameter under Windows? Knowing
the difference can be useful.

Evan is in discussion with Windows guys about this issue too.



Also, what about runtime suspend?  If you unplug the monitor from this
dGPU and interact with it over SSH it should go into runtime suspend.

Is it working properly for that case now?

Thanks for the tip. Runtime resume doesn't work at all:
[ 1087.601631] pcieport :00:01.0: power state changed by ACPI to D0
[ 1087.613820] pcieport :00:01.0: restoring config space at offset
0x2c (was 0x43, writing 0x43)
[ 1087.613835] pcieport :00:01.0: restoring config space at offset
0x28 (was 0x41, writing 0x41)
[ 1087.613841] pcieport :00:01.0: restoring config space at offset
0x24 (was 0xfff10001, writing 0xfff10001)
[ 1087.613978] pcieport :00:01.0: PME# disabled
[ 1087.613984] pcieport :00:01.0: waiting 100 ms for downstream
link, after activation
[ 1089.330956] pcieport :01:00.0: not ready 1023ms after resume; giving up
[ 1089.373036] pcieport :01:00.0: Unable to change power state
from D3cold to D0, device inaccessible

After a short while the whole system froze.

So the upstream port of GFX's PCIe switch cannot be powered on again.


What is the state of the kernel patches while doing this test?
Specifically does this happen without amdgpu.aspm set?  Or this happens
no matter what?



Kai-Heng


Fixes: 0064b0ce85bb ("drm/amd/pm: enable ASPM by default")
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1885
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2458
Signed-off-by: Kai-Heng Feng 
---
   drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c   |  3 +++
   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  7 ++-
   drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 12 +---
   3 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
index 60b1857f469e..407456ac0e84 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -987,6 +987,9 @@ bool amdgpu_acpi_should_gpu_reset(struct amdgpu_device 
*adev)
   if (amdgpu_sriov_vf(adev))
   return false;

+ if (amdgpu_device_supports_boco(adev_to_drm(adev)))
+ return true;
+
   #if IS_ENABLED(CONFIG_SUSPEND)
   return pm_suspend_target_state != PM_SUSPEND_TO_IDLE;
   #else
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index f5658359ff5c..d56b7a2bafa6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2181,7 +2181,12 @@ static int amdgpu_device_ip_early_init(struct 
amdgpu_device *adev)

   if (!(adev->flags & AMD_IS_APU)) {
   parent = pci_upstream_bridge(adev->pdev);
- adev->has_pr3 = parent ? pci_pr3_present(parent) : false;
+ do {
+ if (pci_pr3_present(parent)) {
+ adev->has_pr3 = true;
+ break;
+ }
+ } while ((parent = pci_upstream_bridge(parent)));
   }

   amdgpu_amdkfd_device_probe(adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 

Re: [PATCH] drm/fbdev-generic: optimize out a redundant assignment clause

[Lucas De Marchi]

On Wed, Mar 29, 2023 at 11:04:17AM +0200, Thomas Zimmermann wrote:

(cc'ing Lucas)

Hi

Am 25.03.23 um 08:46 schrieb Sui Jingfeng:

 The assignment already done in drm_client_buffer_vmap(),
 just trival clean, no functional change.

Signed-off-by: Sui Jingfeng <15330273...@189.cn>
---
 drivers/gpu/drm/drm_fbdev_generic.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_fbdev_generic.c 
b/drivers/gpu/drm/drm_fbdev_generic.c
index 4d6325e91565..1da48e71c7f1 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -282,7 +282,7 @@ static int drm_fbdev_damage_blit(struct drm_fb_helper 
*fb_helper,
 struct drm_clip_rect *clip)
 {
struct drm_client_buffer *buffer = fb_helper->buffer;
-   struct iosys_map map, dst;
+   struct iosys_map map;
int ret;
/*
@@ -302,8 +302,7 @@ static int drm_fbdev_damage_blit(struct drm_fb_helper 
*fb_helper,
if (ret)
goto out;
-   dst = map;
-   drm_fbdev_damage_blit_real(fb_helper, clip, );
+   drm_fbdev_damage_blit_real(fb_helper, clip, );


I see what you're doing and it's probably correct in this case.

But there's a larger issue with this iosys interfaces. Sometimes the 
address has to be modified (see calls of iosys_map_incr()). That can 
prevent incorrect uses of the mapping in other places, especially in 
unmap code.


using a initializer for the cases it's needed IMO would make these kind
of problems go away, because then the intent is explicit



I think it would make sense to consider a separate structure for the 
I/O location. The buffer as a whole would still be represented by 
struct iosys_map.  And that new structure, let's call it struct 
iosys_ptr, would point to an actual location within the buffer's


sounds fine to me, but I'd have to take a deeper look later (or when
someone writes the patch).  It seems we'd replicate almost the entire
API to just accomodate the 2 structs.  And the different types will lead
to confusion when one or the other should be used

thanks
Lucas De Marchi

memory range. A few locations and helpers would need changes, but 
there are not so many callers that it's an issue.  This would also 
allow for a few debugging tests that ensure that iosys_ptr always 
operates within the bounds of an iosys_map.


I've long considered this idea, but there was no pressure to work on 
it. Maybe now.


Best regards
Thomas


drm_client_buffer_vunmap(buffer);


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

Re: [PATCH v3 0/5] Add generic-display-mux driver and bindings

[Chen-Yu Tsai]

On Thu, Mar 30, 2023 at 2:10 AM Jagan Teki  wrote:
>
> On Sat, Feb 18, 2023 at 4:47 PM Pin-yen Lin  wrote:
> >
> > This series is developed for and tested on MT8173 board, and the layout is:
> >
> >   /-- anx7688
> > -- MT8173 HDMI bridge -- GPIO mux
> >   \-- native HDMI
>
> What is the part number of this GPIO mux? Does mux gpio interrupt
> based and able to switch output HDMI and DP. If so, how this gpio
> interrupt is different than the HPD in native HDMI? I mean does HPD
> have any detection bottlenecks with mux gpio interrupt?

It's a full blown HDMI 1:2 demultiplexer, so DDC and HPD signals are muxed
as well. The anx7688 handles all the Type-C stuff, and our EC talks to it.
If HDMI output from the SoC needs to be muxed over for DP alt-mode, the EC
will signal the SoC.

> I do have GPIO Mux that input DSI and two outputs DMD/HDMI Input and
> HDMI Out. 2x1 with 1x2 mux.
>
> I'm thinking having a generic mux to select the specific out number of
> outputs with associated interface outputs can be a viable solution to
> address all use cases here.

AFAIK DRM doesn't allow dynamically changing the constitution of a display
pipeline, so it doesn't really work out for us.

If you're just muxing between different outputs with passive/dumb bridges,
it may still work for you.

ChenYu

Re: [PATCH 3/3] drm/xe: Update GuC/HuC firmware autoselect logic

[Lucas De Marchi]

On Tue, Mar 28, 2023 at 04:31:13PM -0700, Anusha Srivatsa wrote:




-Original Message-
From: De Marchi, Lucas 
Sent: Thursday, March 23, 2023 10:18 PM
To: intel...@lists.freedesktop.org
Cc: Srivatsa, Anusha ; Harrison, John C
; Ceraolo Spurio, Daniele
; dri-devel@lists.freedesktop.org; Daniel
Vetter ; Dave Airlie ; De Marchi,
Lucas 
Subject: [PATCH 3/3] drm/xe: Update GuC/HuC firmware autoselect logic

Update the logic to autoselect GuC/HuC for the platforms with the following
improvements:

- Document what is the firmware file that is expected to be
  loaded and what is checked from blob headers
- When the platform is under force-probe it's desired to enforce
  the full-version requirement so the correct firmware is used
  before widespread adoption and backward-compatibility


Extra line ^


  commitments
- Directory from which we expect firmware blobs to be available in
  upstream linux-firmware repository depends on the platform: for
  the ones supported by i915 it uses the i915/ directory, but the ones
  expected to be supported by xe, it's on the xe/ directory. This
  means that for platforms in the intersection, the firmware is
  loaded from a different directory, but that is not much important
  in the firmware repo and it avoids firmware duplication.

- Make the table with the firmware definitions clearly state the
  versions being expected. Now with macros to select the version it's
  possible to choose between full-version/major-version for GuC and
  full-version/no-version for HuC. These are similar to the macros used
  in i915, but implemented in a slightly different way to avoid
  duplicating the macros for each firmware/type and functionality,
  besides adding the support for different directories.

- There is no check added regarding force-probe since xe should
  reuse the same firmware files published for i915 for past
  platforms. This can be improved later with additional
  kunit checking against a hardcoded list of platforms that

Extra line here.


  falls in this category.
- As mentioned in the TODO, the major version fallback was not
  implemented before as currently each platform only supports one
  major. That can be easily added later.

- GuC version for MTL and PVC were updated to 70.6.4, using the exact
  full version, while the

After this the GuC firmware used by PVC changes to pvc_guc_70.5.2.bin since it's
using a file not published yet.

Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/xe/xe_uc_fw.c   | 315 +---
 drivers/gpu/drm/xe/xe_uc_fw.h   |   2 +-
 drivers/gpu/drm/xe/xe_uc_fw_types.h |   7 +
 3 files changed, 204 insertions(+), 120 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_uc_fw.c b/drivers/gpu/drm/xe/xe_uc_fw.c
index 174c42873ebb..653bc3584cc5 100644
--- a/drivers/gpu/drm/xe/xe_uc_fw.c
+++ b/drivers/gpu/drm/xe/xe_uc_fw.c
@@ -17,6 +17,137 @@
 #include "xe_mmio.h"
 #include "xe_uc_fw.h"

+/*
+ * List of required GuC and HuC binaries per-platform. They must be
+ordered
+ * based on platform, from newer to older.
+ *
+ * Versioning follows the guidelines from
+ * Documentation/driver-api/firmware/firmware-usage-guidelines.rst.
+There is a
+ * distinction for platforms being officially supported by the driver or not.
+ * Platforms not available publicly or not yet officially supported by
+the
+ * driver (under force-probe), use the mmp_ver(): the firmware
+autoselect logic
+ * will select the firmware from disk with filename that matches the
+full
+ * "mpp version", i.e. major.minor.patch. mmp_ver() should only be used
+for
+ * this case.
+ *
+ * For platforms officially supported by the driver, the filename
+always only
+ * ever contains the major version (GuC) or no version at all (HuC).
+ *
+ * After loading the file, the driver parses the versions embedded in the blob.
+ * The major version needs to match a major version supported by the
+driver (if
+ * any). The minor version is also checked and a notice emitted to the
+log if
+ * the version found is smaller than the version wanted. This is done
+only for
+ * informational purposes so users may have a chance to upgrade, but
+the driver
+ * still loads and use the older firmware.
+ *
+ * Examples:
+ *
+ * 1) Platform officially supported by i915 - using Tigerlake as example.
+ *Driver loads the following firmware blobs from disk:
+ *
+ * - i915/tgl_guc_.bin
+ * - i915/tgl_huc.bin
+ *
+ * number for GuC is checked that it matches the version inside
+ *the blob.  version is checked and if smaller than the expected
+ *an info message is emitted about that.
+ *
+ * 1) XE_, still under require_force_probe.
Using
+ *"wipplat" as a short-name. Driver loads the following firmware blobs
+ *from disk:
+ *
+ * - xe/wipplat_guc_...bin
+ * - xe/wipplat_huc_...bin
+ *
+ * and  are checked that they match the version inside
+ *the blob. Both of them need to 

Re: [PATCH 1/2] drm/amdgpu: Reset GPU on S0ix when device supports BOCO

[Kai-Heng Feng]

On Wed, Mar 29, 2023 at 9:23 PM Mario Limonciello
 wrote:
>
>
> On 3/29/23 04:59, Kai-Heng Feng wrote:
> > When the power is lost due to ACPI power resources being turned off, the
> > driver should reset the GPU so it can work anew.
> >
> > First, _PR3 support of the hierarchy needs to be found correctly. Since
> > the GPU on some discrete GFX cards is behind a PCIe switch, checking the
> > _PR3 on downstream port alone is not enough, as the _PR3 can associate
> > to the root port above the PCIe switch.
>
> I think this should be split into two commits:
>
> * One of them to look at _PR3 further up in hierarchy to fix indication
> for BOCO support.

Yes, this part can be split up.

>
> * One to adjust policy for whether to reset

IIUC, the GPU only needs to be reset when the power status isn't certain?

Assuming power resources in _PR3 are really disabled, GPU is already
reset by itself. That means reset shouldn't be necessary for D3cold,
am I understanding it correctly?

However, this is a desktop plugged with GFX card that has external
power, does that assumption still stand? Perform resetting on D3cold
can cover this scenario.

>
>
> > Once the _PR3 is found and BOCO support is correctly marked, use that
> > information to inform the GPU should be reset. This solves an issue that
> > system freeze on a Intel ADL desktop that uses S0ix for sleep and D3cold
> > is supported for the GFX slot.
>
> I'm worried this is still papering over an underlying issue with L0s
> handling on ALD + Navi1x/Navi2x.

Is it possible to get the ASIC's ASPM parameter under Windows? Knowing
the difference can be useful.

>
> Also, what about runtime suspend?  If you unplug the monitor from this
> dGPU and interact with it over SSH it should go into runtime suspend.
>
> Is it working properly for that case now?

Thanks for the tip. Runtime resume doesn't work at all:
[ 1087.601631] pcieport :00:01.0: power state changed by ACPI to D0
[ 1087.613820] pcieport :00:01.0: restoring config space at offset
0x2c (was 0x43, writing 0x43)
[ 1087.613835] pcieport :00:01.0: restoring config space at offset
0x28 (was 0x41, writing 0x41)
[ 1087.613841] pcieport :00:01.0: restoring config space at offset
0x24 (was 0xfff10001, writing 0xfff10001)
[ 1087.613978] pcieport :00:01.0: PME# disabled
[ 1087.613984] pcieport :00:01.0: waiting 100 ms for downstream
link, after activation
[ 1089.330956] pcieport :01:00.0: not ready 1023ms after resume; giving up
[ 1089.373036] pcieport :01:00.0: Unable to change power state
from D3cold to D0, device inaccessible

After a short while the whole system froze.

So the upstream port of GFX's PCIe switch cannot be powered on again.

Kai-Heng

>
> >
> > Fixes: 0064b0ce85bb ("drm/amd/pm: enable ASPM by default")
> > Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1885
> > Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2458
> > Signed-off-by: Kai-Heng Feng 
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c   |  3 +++
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  7 ++-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 12 +---
> >   3 files changed, 14 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > index 60b1857f469e..407456ac0e84 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > @@ -987,6 +987,9 @@ bool amdgpu_acpi_should_gpu_reset(struct amdgpu_device 
> > *adev)
> >   if (amdgpu_sriov_vf(adev))
> >   return false;
> >
> > + if (amdgpu_device_supports_boco(adev_to_drm(adev)))
> > + return true;
> > +
> >   #if IS_ENABLED(CONFIG_SUSPEND)
> >   return pm_suspend_target_state != PM_SUSPEND_TO_IDLE;
> >   #else
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > index f5658359ff5c..d56b7a2bafa6 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > @@ -2181,7 +2181,12 @@ static int amdgpu_device_ip_early_init(struct 
> > amdgpu_device *adev)
> >
> >   if (!(adev->flags & AMD_IS_APU)) {
> >   parent = pci_upstream_bridge(adev->pdev);
> > - adev->has_pr3 = parent ? pci_pr3_present(parent) : false;
> > + do {
> > + if (pci_pr3_present(parent)) {
> > + adev->has_pr3 = true;
> > + break;
> > + }
> > + } while ((parent = pci_upstream_bridge(parent)));
> >   }
> >
> >   amdgpu_amdkfd_device_probe(adev);
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > index ba5def374368..5d81fcac4b0a 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > @@ -2415,10 +2415,11 @@ static int 

Re: [PATCH v7 27/32] drm/msm/dpu: add support for wide planes

[Dmitry Baryshkov]

On 30/03/2023 05:53, Abhinav Kumar wrote:



On 3/16/2023 9:16 AM, Dmitry Baryshkov wrote:

It is possible to use multirect feature and split source to use the SSPP
to output two consecutive rectangles. This commit brings in this
capability to support wider screen resolutions.

Tested-by: Abhinav Kumar  # sc7280
Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |  19 ++-
  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 136 +++---
  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h |   4 +
  3 files changed, 142 insertions(+), 17 deletions(-)

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

index 217a8112f1a2..90b406e409d3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -481,6 +481,15 @@ static void _dpu_crtc_blend_setup_mixer(struct 
drm_crtc *crtc,

 format, fb ? fb->modifier : 0,
 >pipe, 0, stage_cfg);
+    if (pstate->r_pipe.sspp) {
+    set_bit(pstate->r_pipe.sspp->idx, fetch_active);
+    _dpu_crtc_blend_setup_pipe(crtc, plane,
+   mixer, cstate->num_mixers,
+   pstate->stage,
+   format, fb ? fb->modifier : 0,
+   >r_pipe, 1, stage_cfg);
+    }
+
  /* blend config update */
  for (lm_idx = 0; lm_idx < cstate->num_mixers; lm_idx++) {
  _dpu_crtc_setup_blend_cfg(mixer + lm_idx, pstate, format);
@@ -1341,10 +1350,16 @@ static int _dpu_debugfs_status_show(struct 
seq_file *s, void *data)

  seq_printf(s, "\tdst x:%4d dst_y:%4d dst_w:%4d dst_h:%4d\n",
  state->crtc_x, state->crtc_y, state->crtc_w,
  state->crtc_h);
-    seq_printf(s, "\tsspp:%s\n",
+    seq_printf(s, "\tsspp[0]:%s\n",
 pstate->pipe.sspp->cap->name);
-    seq_printf(s, "\tmultirect: mode: %d index: %d\n",
+    seq_printf(s, "\tmultirect[0]: mode: %d index: %d\n",
  pstate->pipe.multirect_mode, pstate->pipe.multirect_index);
+    if (pstate->r_pipe.sspp) {
+    seq_printf(s, "\tsspp[1]:%s\n",
+   pstate->r_pipe.sspp->cap->name);
+    seq_printf(s, "\tmultirect[1]: mode: %d index: %d\n",
+   pstate->r_pipe.multirect_mode, 
pstate->r_pipe.multirect_index);

+    }
  seq_puts(s, "\n");
  }
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c

index f52120b05b6e..73db15d76059 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -701,6 +701,10 @@ static void _dpu_plane_color_fill(struct 
dpu_plane *pdpu,

  /* update sspp */
  _dpu_plane_color_fill_pipe(pstate, >pipe, 
>pipe_cfg.dst_rect,

 fill_color, fmt);
+
+    if (pstate->r_pipe.sspp)
+    _dpu_plane_color_fill_pipe(pstate, >r_pipe, 
>r_pipe_cfg.dst_rect,

+   fill_color, fmt);
  }
  int dpu_plane_validate_multirect_v2(struct 
dpu_multirect_plane_states *plane)
@@ -959,9 +963,12 @@ static int dpu_plane_atomic_check(struct 
drm_plane *plane,

  int ret = 0, min_scale;
  struct dpu_plane *pdpu = to_dpu_plane(plane);
  struct dpu_plane_state *pstate = 
to_dpu_plane_state(new_plane_state);

+    struct dpu_sw_pipe *pipe = >pipe;
+    struct dpu_sw_pipe *r_pipe = >r_pipe;
  const struct drm_crtc_state *crtc_state = NULL;
  const struct dpu_format *fmt;
  struct dpu_sw_pipe_cfg *pipe_cfg = >pipe_cfg;
+    struct dpu_sw_pipe_cfg *r_pipe_cfg = >r_pipe_cfg;
  struct drm_rect fb_rect = { 0 };
  uint32_t max_linewidth;
  unsigned int rotation;
@@ -985,8 +992,11 @@ static int dpu_plane_atomic_check(struct 
drm_plane *plane,

  if (!new_plane_state->visible)
  return 0;
-    pstate->pipe.multirect_index = DPU_SSPP_RECT_SOLO;
-    pstate->pipe.multirect_mode = DPU_SSPP_MULTIRECT_NONE;
+    pipe->multirect_index = DPU_SSPP_RECT_SOLO;
+    pipe->multirect_mode = DPU_SSPP_MULTIRECT_NONE;
+    r_pipe->multirect_index = DPU_SSPP_RECT_SOLO;
+    r_pipe->multirect_mode = DPU_SSPP_MULTIRECT_NONE;
+    r_pipe->sspp = NULL;
  pstate->stage = DPU_STAGE_0 + pstate->base.normalized_zpos;
  if (pstate->stage >= pdpu->catalog->caps->max_mixer_blendstages) {
@@ -1016,21 +1026,67 @@ static int dpu_plane_atomic_check(struct 
drm_plane *plane,

  return -E2BIG;
  }
+    fmt = to_dpu_format(msm_framebuffer_format(new_plane_state->fb));
+
  max_linewidth = pdpu->catalog->caps->max_linewidth;
-    /* check decimated source width */
  if (drm_rect_width(_cfg->src_rect) > max_linewidth) {
-    DPU_DEBUG_PLANE(pdpu, "invalid src " DRM_RECT_FMT " line:%u\n",
-    DRM_RECT_ARG(_cfg->src_rect), max_linewidth);
-    return -E2BIG;
-    }
+    /*
+ * In parallel multirect case only the half of the usual 

linux-next: build warning after merge of the drm tree

[Stephen Rothwell]

Hi all,

After merging the drm tree, today's linux-next build (htmldocs) produced
this warning:

include/uapi/linux/sync_file.h:77: warning: Function parameter or member 
'num_fences' not described in 'sync_file_info'

Revealed by commit

  d71c11cc79d2 ("dma-buf/sync_file: Surface sync-file uABI")

Introduced by commit

  2d75c88fefb2 ("staging/android: refactor SYNC IOCTLs")

in 2016.

-- 
Cheers,
Stephen Rothwell


pgpT0lQ6dJOqx.pgp
Description: OpenPGP digital signature

[PATCH v3 2/2] drm/mediatek: Add ovl_adaptor get format function

[Nancy . Lin]

1. Add ovl_adaptor get_format and get_num_formats component function.
The two functions are needed for getting the supported format in
mtk_plane_init().
2. Get supported format from the ovl_adaptor's rdma engine - mdp_rdma.

Signed-off-by: Nancy.Lin 
---
 drivers/gpu/drm/mediatek/mtk_disp_drv.h |  2 ++
 drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 14 ++
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |  2 ++
 3 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h 
b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index 17b169530beb..2254038519e1 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -124,6 +124,8 @@ void mtk_ovl_adaptor_start(struct device *dev);
 void mtk_ovl_adaptor_stop(struct device *dev);
 unsigned int mtk_ovl_adaptor_layer_nr(struct device *dev);
 struct device *mtk_ovl_adaptor_dma_dev_get(struct device *dev);
+const u32 *mtk_ovl_adaptor_get_formats(struct device *dev);
+size_t mtk_ovl_adaptor_get_num_formats(struct device *dev);
 
 void mtk_rdma_bypass_shadow(struct device *dev);
 int mtk_rdma_clk_enable(struct device *dev);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index 046217828ab3..c0a38f5217ee 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -297,6 +297,20 @@ void mtk_ovl_adaptor_disable_vblank(struct device *dev)

mtk_ethdr_disable_vblank(ovl_adaptor->ovl_adaptor_comp[OVL_ADAPTOR_ETHDR0]);
 }
 
+const u32 *mtk_ovl_adaptor_get_formats(struct device *dev)
+{
+   struct mtk_disp_ovl_adaptor *ovl_adaptor = dev_get_drvdata(dev);
+
+   return 
mtk_mdp_rdma_get_formats(ovl_adaptor->ovl_adaptor_comp[OVL_ADAPTOR_MDP_RDMA0]);
+}
+
+size_t mtk_ovl_adaptor_get_num_formats(struct device *dev)
+{
+   struct mtk_disp_ovl_adaptor *ovl_adaptor = dev_get_drvdata(dev);
+
+   return 
mtk_mdp_rdma_get_num_formats(ovl_adaptor->ovl_adaptor_comp[OVL_ADAPTOR_MDP_RDMA0]);
+}
+
 void mtk_ovl_adaptor_add_comp(struct device *dev, struct mtk_mutex *mutex)
 {
mtk_mutex_add_comp(mutex, DDP_COMPONENT_MDP_RDMA0);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 1a0c4f7e352a..f114da4d36a9 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -410,6 +410,8 @@ static const struct mtk_ddp_comp_funcs ddp_ovl_adaptor = {
.disconnect = mtk_ovl_adaptor_disconnect,
.add = mtk_ovl_adaptor_add_comp,
.remove = mtk_ovl_adaptor_remove_comp,
+   .get_formats = mtk_ovl_adaptor_get_formats,
+   .get_num_formats = mtk_ovl_adaptor_get_num_formats,
 };
 
 static const char * const mtk_ddp_comp_stem[MTK_DDP_COMP_TYPE_MAX] = {
-- 
2.18.0

[PATCH v3 0/2] drm/mediatek: Add ovl_adaptor get format function

[Nancy . Lin]

Add ovl_adaptor get_format and get_num_formats component function.
The two functions are needed for getting the supported format in
mtk_plane_init().

Changes in v3:
 - modify for reviewer's comment in v2.
   - add mdp-rdma get supported format api for ovl_adaptor driver.

Changes in v2:
 - remove change id

Signed-off-by: Nancy.Lin 

This series are based on the following patch:
[1] [v8,1/3] drm/mediatek: Refactor pixel format logic
  - 20230309210416.1167020-2-greenjus...@chromium.org

Nancy.Lin (2):
  drm/mediatek: Add mdp_rdma get format function
  drm/mediatek: Add ovl_adaptor get format function

 drivers/gpu/drm/mediatek/mtk_disp_drv.h   |  5 
 .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   | 14 +++
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c   |  2 ++
 drivers/gpu/drm/mediatek/mtk_mdp_rdma.c   | 24 +++
 4 files changed, 45 insertions(+)

-- 
2.18.0

[PATCH v3 1/2] drm/mediatek: Add mdp_rdma get format function

[Nancy . Lin]

Add mdp_rdma get_format and get_num_formats function.

Signed-off-by: Nancy.Lin 
---
 drivers/gpu/drm/mediatek/mtk_disp_drv.h |  3 +++
 drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 24 
 2 files changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h 
b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index 0d28b2e2069c..17b169530beb 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -152,4 +152,7 @@ void mtk_mdp_rdma_start(struct device *dev, struct cmdq_pkt 
*cmdq_pkt);
 void mtk_mdp_rdma_stop(struct device *dev, struct cmdq_pkt *cmdq_pkt);
 void mtk_mdp_rdma_config(struct device *dev, struct mtk_mdp_rdma_cfg *cfg,
 struct cmdq_pkt *cmdq_pkt);
+const u32 *mtk_mdp_rdma_get_formats(struct device *dev);
+size_t mtk_mdp_rdma_get_num_formats(struct device *dev);
+
 #endif
diff --git a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c 
b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
index eecfa98ff52e..e06db6e56b5f 100644
--- a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
@@ -62,6 +62,20 @@
 #define RDMA_CSC_FULL709_TO_RGB5
 #define RDMA_CSC_BT601_TO_RGB  6
 
+static const u32 formats[] = {
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_BGRX,
+   DRM_FORMAT_BGRA,
+   DRM_FORMAT_ABGR,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_RGB888,
+   DRM_FORMAT_BGR888,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_YUYV,
+};
+
 enum rdma_format {
RDMA_INPUT_FORMAT_RGB565 = 0,
RDMA_INPUT_FORMAT_RGB888 = 1,
@@ -219,6 +233,16 @@ void mtk_mdp_rdma_config(struct device *dev, struct 
mtk_mdp_rdma_cfg *cfg,
   MDP_RDMA_MF_CLIP_SIZE, FLD_MF_CLIP_H);
 }
 
+const u32 *mtk_mdp_rdma_get_formats(struct device *dev)
+{
+   return formats;
+}
+
+size_t mtk_mdp_rdma_get_num_formats(struct device *dev)
+{
+   return ARRAY_SIZE(formats);
+}
+
 int mtk_mdp_rdma_clk_enable(struct device *dev)
 {
struct mtk_mdp_rdma *rdma = dev_get_drvdata(dev);
-- 
2.18.0

Re: [PATCH v7 27/32] drm/msm/dpu: add support for wide planes

[Abhinav Kumar]

On 3/16/2023 9:16 AM, Dmitry Baryshkov wrote:

It is possible to use multirect feature and split source to use the SSPP
to output two consecutive rectangles. This commit brings in this
capability to support wider screen resolutions.

Tested-by: Abhinav Kumar  # sc7280
Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |  19 ++-
  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 136 +++---
  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h |   4 +
  3 files changed, 142 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 217a8112f1a2..90b406e409d3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -481,6 +481,15 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc 
*crtc,
   format, fb ? fb->modifier : 0,
   >pipe, 0, stage_cfg);
  
+		if (pstate->r_pipe.sspp) {

+   set_bit(pstate->r_pipe.sspp->idx, fetch_active);
+   _dpu_crtc_blend_setup_pipe(crtc, plane,
+  mixer, cstate->num_mixers,
+  pstate->stage,
+  format, fb ? fb->modifier : 
0,
+  >r_pipe, 1, 
stage_cfg);
+   }
+
/* blend config update */
for (lm_idx = 0; lm_idx < cstate->num_mixers; lm_idx++) {
_dpu_crtc_setup_blend_cfg(mixer + lm_idx, pstate, 
format);
@@ -1341,10 +1350,16 @@ static int _dpu_debugfs_status_show(struct seq_file *s, 
void *data)
seq_printf(s, "\tdst x:%4d dst_y:%4d dst_w:%4d dst_h:%4d\n",
state->crtc_x, state->crtc_y, state->crtc_w,
state->crtc_h);
-   seq_printf(s, "\tsspp:%s\n",
+   seq_printf(s, "\tsspp[0]:%s\n",
   pstate->pipe.sspp->cap->name);
-   seq_printf(s, "\tmultirect: mode: %d index: %d\n",
+   seq_printf(s, "\tmultirect[0]: mode: %d index: %d\n",
pstate->pipe.multirect_mode, 
pstate->pipe.multirect_index);
+   if (pstate->r_pipe.sspp) {
+   seq_printf(s, "\tsspp[1]:%s\n",
+  pstate->r_pipe.sspp->cap->name);
+   seq_printf(s, "\tmultirect[1]: mode: %d index: %d\n",
+  pstate->r_pipe.multirect_mode, 
pstate->r_pipe.multirect_index);
+   }
  
  		seq_puts(s, "\n");

}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index f52120b05b6e..73db15d76059 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -701,6 +701,10 @@ static void _dpu_plane_color_fill(struct dpu_plane *pdpu,
/* update sspp */
_dpu_plane_color_fill_pipe(pstate, >pipe, 
>pipe_cfg.dst_rect,
   fill_color, fmt);
+
+   if (pstate->r_pipe.sspp)
+   _dpu_plane_color_fill_pipe(pstate, >r_pipe, 
>r_pipe_cfg.dst_rect,
+  fill_color, fmt);
  }
  
  int dpu_plane_validate_multirect_v2(struct dpu_multirect_plane_states *plane)

@@ -959,9 +963,12 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
int ret = 0, min_scale;
struct dpu_plane *pdpu = to_dpu_plane(plane);
struct dpu_plane_state *pstate = to_dpu_plane_state(new_plane_state);
+   struct dpu_sw_pipe *pipe = >pipe;
+   struct dpu_sw_pipe *r_pipe = >r_pipe;
const struct drm_crtc_state *crtc_state = NULL;
const struct dpu_format *fmt;
struct dpu_sw_pipe_cfg *pipe_cfg = >pipe_cfg;
+   struct dpu_sw_pipe_cfg *r_pipe_cfg = >r_pipe_cfg;
struct drm_rect fb_rect = { 0 };
uint32_t max_linewidth;
unsigned int rotation;
@@ -985,8 +992,11 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
if (!new_plane_state->visible)
return 0;
  
-	pstate->pipe.multirect_index = DPU_SSPP_RECT_SOLO;

-   pstate->pipe.multirect_mode = DPU_SSPP_MULTIRECT_NONE;
+   pipe->multirect_index = DPU_SSPP_RECT_SOLO;
+   pipe->multirect_mode = DPU_SSPP_MULTIRECT_NONE;
+   r_pipe->multirect_index = DPU_SSPP_RECT_SOLO;
+   r_pipe->multirect_mode = DPU_SSPP_MULTIRECT_NONE;
+   r_pipe->sspp = NULL;
  
  	pstate->stage = DPU_STAGE_0 + pstate->base.normalized_zpos;

if (pstate->stage >= pdpu->catalog->caps->max_mixer_blendstages) {
@@ -1016,21 +1026,67 @@ static int dpu_plane_atomic_check(struct drm_plane 
*plane,
return -E2BIG;
}
  
+	fmt = to_dpu_format(msm_framebuffer_format(new_plane_state->fb));

+
max_linewidth = 

Re: [PATCH 1/2] drm/amdgpu: Reset GPU on S0ix when device supports BOCO

[Alex Deucher]

On Wed, Mar 29, 2023 at 8:49 PM Kai-Heng Feng
 wrote:
>
> On Wed, Mar 29, 2023 at 9:21 PM Alex Deucher  wrote:
> >
> > On Wed, Mar 29, 2023 at 6:00 AM Kai-Heng Feng
> >  wrote:
> > >
> > > When the power is lost due to ACPI power resources being turned off, the
> > > driver should reset the GPU so it can work anew.
> > >
> > > First, _PR3 support of the hierarchy needs to be found correctly. Since
> > > the GPU on some discrete GFX cards is behind a PCIe switch, checking the
> > > _PR3 on downstream port alone is not enough, as the _PR3 can associate
> > > to the root port above the PCIe switch.
> > >
> > > Once the _PR3 is found and BOCO support is correctly marked, use that
> > > information to inform the GPU should be reset. This solves an issue that
> > > system freeze on a Intel ADL desktop that uses S0ix for sleep and D3cold
> > > is supported for the GFX slot.
> >
> > I don't think we need to reset the GPU.  If the power is turned off, a
> > reset shouldn't be necessary. The reset is only necessary when the
> > power is not turned off to put the GPU into a known good state.  It
> > should be in that state already if the power is turn off.  It sounds
> > like the device is not actually getting powered off.
>
> I had the impression that the GPU gets reset because S3 turned the
> power rail off.
>
> So the actual intention for GPU reset is because S3 doesn't guarantee
> the power is being turned off?

For S4, the reset in freeze is there because once the boot kernel
transitions to the hibernated kernel, we need the reset to bring the
GPU back to a known state.  On dGPUs at least there are some engines
that can only be initialized once and then require a reset to be
initialized again.  The one in suspend was originally there to deal
with aborted suspends where we'd need to reset the GPU for the same
reason as S4.  However, it no longer really serves much purpose since
it got moved to noirq and it could probably be dropped.

Alex


>
> Kai-Heng
>
> >
> > Alex
> >
> > >
> > > Fixes: 0064b0ce85bb ("drm/amd/pm: enable ASPM by default")
> > > Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1885
> > > Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2458
> > > Signed-off-by: Kai-Heng Feng 
> > > ---
> > >  drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c   |  3 +++
> > >  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  7 ++-
> > >  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 12 +---
> > >  3 files changed, 14 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c 
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > > index 60b1857f469e..407456ac0e84 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > > @@ -987,6 +987,9 @@ bool amdgpu_acpi_should_gpu_reset(struct 
> > > amdgpu_device *adev)
> > > if (amdgpu_sriov_vf(adev))
> > > return false;
> > >
> > > +   if (amdgpu_device_supports_boco(adev_to_drm(adev)))
> > > +   return true;
> > > +
> > >  #if IS_ENABLED(CONFIG_SUSPEND)
> > > return pm_suspend_target_state != PM_SUSPEND_TO_IDLE;
> > >  #else
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > index f5658359ff5c..d56b7a2bafa6 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > @@ -2181,7 +2181,12 @@ static int amdgpu_device_ip_early_init(struct 
> > > amdgpu_device *adev)
> > >
> > > if (!(adev->flags & AMD_IS_APU)) {
> > > parent = pci_upstream_bridge(adev->pdev);
> > > -   adev->has_pr3 = parent ? pci_pr3_present(parent) : false;
> > > +   do {
> > > +   if (pci_pr3_present(parent)) {
> > > +   adev->has_pr3 = true;
> > > +   break;
> > > +   }
> > > +   } while ((parent = pci_upstream_bridge(parent)));
> > > }
> > >
> > > amdgpu_amdkfd_device_probe(adev);
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > index ba5def374368..5d81fcac4b0a 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > @@ -2415,10 +2415,11 @@ static int amdgpu_pmops_suspend(struct device 
> > > *dev)
> > > struct drm_device *drm_dev = dev_get_drvdata(dev);
> > > struct amdgpu_device *adev = drm_to_adev(drm_dev);
> > >
> > > -   if (amdgpu_acpi_is_s0ix_active(adev))
> > > -   adev->in_s0ix = true;
> > > -   else if (amdgpu_acpi_is_s3_active(adev))
> > > +   if (amdgpu_acpi_is_s3_active(adev) ||
> > > +   amdgpu_device_supports_boco(drm_dev))
> > > adev->in_s3 = true;
> > > +   else if (amdgpu_acpi_is_s0ix_active(adev))
> > > +   adev->in_s0ix = true;
> > >  

Re: [PATCH v2] drm/mediatek: Add ovl_adaptor get format function

[林欣螢]

Re: [PATCH v3 5/6] drm/etnaviv: expand driver support for the pci devices

[Sui Jingfeng]

Hi, pci_clear_master is located at pci.h.


 Added by commit 6a479079c07211bf348ac8a79754f26bea258f26 (PCI: Add 
pci_clear_master() as opposite of pci_set_master())



 I don't know what the reason arc architecture can't use this.


On 2023/3/30 08:07, kernel test robot wrote:

Hi Sui,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm/drm-next drm-intel/for-linux-next 
drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.3-rc4 
next-20230329]
[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/Sui-Jingfeng/drm-etnaviv-add-a-dedicate-function-to-register-irq-handler-for-the-gpu/20230330-045519
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20230329205129.1513734-6-15330273260%40189.cn
patch subject: [PATCH v3 5/6] drm/etnaviv: expand driver support for the pci 
devices
config: arc-randconfig-r043-20230329 
(https://download.01.org/0day-ci/archive/20230330/202303300759.e9lbkntq-...@intel.com/config)
compiler: arc-elf-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/cfc3554b9fbd8ca3f3f6731d45d811bfa7fdf777
 git remote add linux-review https://github.com/intel-lab-lkp/linux
 git fetch --no-tags linux-review 
Sui-Jingfeng/drm-etnaviv-add-a-dedicate-function-to-register-irq-handler-for-the-gpu/20230330-045519
 git checkout cfc3554b9fbd8ca3f3f6731d45d811bfa7fdf777
 # 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=arc olddefconfig
 COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 
O=build_dir ARCH=arc SHELL=/bin/bash drivers/gpu/drm/etnaviv/

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

All errors (new ones prefixed by >>):

drivers/gpu/drm/etnaviv/etnaviv_pci_drv.c: In function 
'etnaviv_gpu_pci_fini':

drivers/gpu/drm/etnaviv/etnaviv_pci_drv.c:32:9: error: implicit declaration of 
function 'pci_clear_master'; did you mean 'pci_set_master'? 
[-Werror=implicit-function-declaration]

   32 | pci_clear_master(pdev);
  | ^~~~
  | pci_set_master
cc1: some warnings being treated as errors


vim +32 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.c

 27 
 28 static void etnaviv_gpu_pci_fini(struct etnaviv_gpu *gpu, bool 
component)
 29 {
 30 struct pci_dev *pdev = to_pci_dev(gpu->dev);
 31 
   > 32  pci_clear_master(pdev);
 33 
 34 dev_dbg(gpu->dev, "component is %s\n",
 35 component ? "enabled" : "disabled");
 36 }
 37 

[PATCH -next] drm: bridge: samsung-dsim: fix platform_no_drv_owner.cocci warning

[Yang Li]

./drivers/gpu/drm/bridge/samsung-dsim.c:1957:6-11: No need to set .owner here. 
The core will do it.

Reported-by: Abaci Robot 
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4640
Signed-off-by: Yang Li 
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
b/drivers/gpu/drm/bridge/samsung-dsim.c
index e0a402a85787..10dc3315e69e 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1954,7 +1954,6 @@ static struct platform_driver samsung_dsim_driver = {
.remove = samsung_dsim_remove,
.driver = {
   .name = "samsung-dsim",
-  .owner = THIS_MODULE,
   .pm = _dsim_pm_ops,
   .of_match_table = samsung_dsim_of_match,
},
-- 
2.20.1.7.g153144c

Re: [PATCH 1/2] drm/amdgpu: Reset GPU on S0ix when device supports BOCO

[Kai-Heng Feng]

On Wed, Mar 29, 2023 at 9:21 PM Alex Deucher  wrote:
>
> On Wed, Mar 29, 2023 at 6:00 AM Kai-Heng Feng
>  wrote:
> >
> > When the power is lost due to ACPI power resources being turned off, the
> > driver should reset the GPU so it can work anew.
> >
> > First, _PR3 support of the hierarchy needs to be found correctly. Since
> > the GPU on some discrete GFX cards is behind a PCIe switch, checking the
> > _PR3 on downstream port alone is not enough, as the _PR3 can associate
> > to the root port above the PCIe switch.
> >
> > Once the _PR3 is found and BOCO support is correctly marked, use that
> > information to inform the GPU should be reset. This solves an issue that
> > system freeze on a Intel ADL desktop that uses S0ix for sleep and D3cold
> > is supported for the GFX slot.
>
> I don't think we need to reset the GPU.  If the power is turned off, a
> reset shouldn't be necessary. The reset is only necessary when the
> power is not turned off to put the GPU into a known good state.  It
> should be in that state already if the power is turn off.  It sounds
> like the device is not actually getting powered off.

I had the impression that the GPU gets reset because S3 turned the
power rail off.

So the actual intention for GPU reset is because S3 doesn't guarantee
the power is being turned off?

Kai-Heng

>
> Alex
>
> >
> > Fixes: 0064b0ce85bb ("drm/amd/pm: enable ASPM by default")
> > Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1885
> > Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2458
> > Signed-off-by: Kai-Heng Feng 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c   |  3 +++
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  7 ++-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 12 +---
> >  3 files changed, 14 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > index 60b1857f469e..407456ac0e84 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > @@ -987,6 +987,9 @@ bool amdgpu_acpi_should_gpu_reset(struct amdgpu_device 
> > *adev)
> > if (amdgpu_sriov_vf(adev))
> > return false;
> >
> > +   if (amdgpu_device_supports_boco(adev_to_drm(adev)))
> > +   return true;
> > +
> >  #if IS_ENABLED(CONFIG_SUSPEND)
> > return pm_suspend_target_state != PM_SUSPEND_TO_IDLE;
> >  #else
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > index f5658359ff5c..d56b7a2bafa6 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > @@ -2181,7 +2181,12 @@ static int amdgpu_device_ip_early_init(struct 
> > amdgpu_device *adev)
> >
> > if (!(adev->flags & AMD_IS_APU)) {
> > parent = pci_upstream_bridge(adev->pdev);
> > -   adev->has_pr3 = parent ? pci_pr3_present(parent) : false;
> > +   do {
> > +   if (pci_pr3_present(parent)) {
> > +   adev->has_pr3 = true;
> > +   break;
> > +   }
> > +   } while ((parent = pci_upstream_bridge(parent)));
> > }
> >
> > amdgpu_amdkfd_device_probe(adev);
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > index ba5def374368..5d81fcac4b0a 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > @@ -2415,10 +2415,11 @@ static int amdgpu_pmops_suspend(struct device *dev)
> > struct drm_device *drm_dev = dev_get_drvdata(dev);
> > struct amdgpu_device *adev = drm_to_adev(drm_dev);
> >
> > -   if (amdgpu_acpi_is_s0ix_active(adev))
> > -   adev->in_s0ix = true;
> > -   else if (amdgpu_acpi_is_s3_active(adev))
> > +   if (amdgpu_acpi_is_s3_active(adev) ||
> > +   amdgpu_device_supports_boco(drm_dev))
> > adev->in_s3 = true;
> > +   else if (amdgpu_acpi_is_s0ix_active(adev))
> > +   adev->in_s0ix = true;
> > if (!adev->in_s0ix && !adev->in_s3)
> > return 0;
> > return amdgpu_device_suspend(drm_dev, true);
> > @@ -2449,10 +2450,7 @@ static int amdgpu_pmops_resume(struct device *dev)
> > adev->no_hw_access = true;
> >
> > r = amdgpu_device_resume(drm_dev, true);
> > -   if (amdgpu_acpi_is_s0ix_active(adev))
> > -   adev->in_s0ix = false;
> > -   else
> > -   adev->in_s3 = false;
> > +   adev->in_s0ix = adev->in_s3 = false;
> > return r;
> >  }
> >
> > --
> > 2.34.1
> >

Re: [PATCH RFC 2/5] drm/msm: Add MSM-specific DSC helper methods

[Dmitry Baryshkov]

On 30/03/2023 02:18, Jessica Zhang wrote:

Introduce MSM-specific DSC helper methods, as some calculations are
common between DP and DSC.

Signed-off-by: Jessica Zhang 
---
  drivers/gpu/drm/msm/Makefile  |  1 +
  drivers/gpu/drm/msm/disp/msm_dsc_helper.c | 74 +++
  drivers/gpu/drm/msm/disp/msm_dsc_helper.h | 28 


Also: outside of disp, please.


  3 files changed, 103 insertions(+)



--
With best wishes
Dmitry

Re: [PATCH RFC 2/5] drm/msm: Add MSM-specific DSC helper methods

[Dmitry Baryshkov]

On 30/03/2023 02:18, Jessica Zhang wrote:

Introduce MSM-specific DSC helper methods, as some calculations are
common between DP and DSC.

Signed-off-by: Jessica Zhang 
---
  drivers/gpu/drm/msm/Makefile  |  1 +
  drivers/gpu/drm/msm/disp/msm_dsc_helper.c | 74 +++
  drivers/gpu/drm/msm/disp/msm_dsc_helper.h | 28 
  3 files changed, 103 insertions(+)

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 7274c41228ed..897a5b1c88f6 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -90,6 +90,7 @@ msm-y += \
disp/mdp_kms.o \
disp/msm_disp_snapshot.o \
disp/msm_disp_snapshot_util.o \
+   disp/msm_dsc_helper.o \
msm_atomic.o \
msm_atomic_tracepoints.o \
msm_debugfs.o \
diff --git a/drivers/gpu/drm/msm/disp/msm_dsc_helper.c 
b/drivers/gpu/drm/msm/disp/msm_dsc_helper.c
new file mode 100644
index ..ec15c0d829e8
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/msm_dsc_helper.c
@@ -0,0 +1,74 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved
+ */
+
+#include 
+#include 
+#include 
+
+#include "msm_drv.h"
+#include "msm_dsc_helper.h"
+
+static int get_comp_ratio(struct drm_dsc_config *dsc, u32 src_bpp)
+{
+   return mult_frac(100, src_bpp, DSC_BPP(*dsc));
+}
+
+static s64 get_bytes_per_soft_slice(struct drm_dsc_config *dsc, int 
intf_width, int comp_ratio)
+{
+   s64 comp_ratio_fp, num_bits_fp;
+   s64 numerator_fp, denominator_fp;
+
+   comp_ratio_fp = drm_fixp_from_fraction(comp_ratio, 100);


Please inline comp_ration calculation here. Don't use mult_frac().


+   num_bits_fp = drm_fixp_from_fraction(8, 1);


drm_int2fixp


+
+   numerator_fp = drm_fixp_from_fraction(dsc->slice_width * 
dsc->bits_per_component * 3, 1);


And here too.


+   denominator_fp = drm_fixp_mul(comp_ratio_fp, num_bits_fp);


And num_bits_fp can be inlined too.
denominator_fp = drm_fixp_from_fraction(src_bpp * 8, DSC_BPP)


+
+   return drm_fixp_div(numerator_fp, denominator_fp);


dsc->slice_width * bpc * 3 / (8 * src_bpp / DSC_BPP), thus:

drm_fixp_from_fraction(dsc->slice_width * bpc * 3 * DSC_BPP, 8 * src_bpp)

but I will not insist on this one.


+}
+
+u32 msm_dsc_get_eol_byte_num(struct drm_dsc_config *dsc, int intf_width, u32 
src_bpp)
+{
+   u32 bytes_per_ss, extra_eol_bytes, bytes_per_intf;
+   s64 bytes_per_ss_fp;
+   int slice_per_intf = msm_dsc_get_slice_per_intf(dsc, intf_width);
+   int comp_ratio = get_comp_ratio(dsc, src_bpp);
+
+   bytes_per_ss_fp = get_bytes_per_soft_slice(dsc, intf_width, comp_ratio);
+   bytes_per_ss = drm_fixp2int_ceil(bytes_per_ss_fp);


s/_ss/_soft_slice/g


+
+   bytes_per_intf = bytes_per_ss * slice_per_intf;
+   extra_eol_bytes = bytes_per_intf % 3;
+   if (extra_eol_bytes != 0)
+   extra_eol_bytes = 3 - extra_eol_bytes;
+
+   return extra_eol_bytes;
+}
+
+u32 msm_dsc_get_dce_bytes_per_line(struct drm_dsc_config *dsc, int intf_width)
+{
+   u32 bpp;
+   u32 dce_bytes_per_line;
+
+   bpp = DSC_BPP(*dsc);


Didn't this cause a warning on the unused-but-set variable?


+   dce_bytes_per_line = DIV_ROUND_UP(dsc->bits_per_pixel * intf_width, 8);
+
+   return dce_bytes_per_line;
+}


If you have msm_dsc_get_slice_per_intf() as a static inline, this 
function can be a static inline too. Nothing more than a single 
DIV_ROUND_UP.



+
+int msm_dsc_get_pclk_per_line(struct drm_dsc_config *dsc, int intf_width, u32 
src_bpp)
+{
+   s64 data_width;
+   int comp_ratio = get_comp_ratio(dsc, src_bpp);
+
+   if (!dsc->slice_width || (intf_width < dsc->slice_width))
+   return -EINVAL;
+
+   data_width = get_bytes_per_soft_slice(dsc, intf_width, comp_ratio);
+   data_width = drm_fixp_mul(dsc->slice_count, data_width);
+   data_width = drm_fixp_from_fraction(data_width, 3);


Reusing a variable is a nice trick, but it can be confusing. Not to 
mention that the last call should probably be drm_fixp_div()



+
+   return drm_fixp2int_ceil(data_width);
+}
diff --git a/drivers/gpu/drm/msm/disp/msm_dsc_helper.h 
b/drivers/gpu/drm/msm/disp/msm_dsc_helper.h
new file mode 100644
index ..308069b2b5a4
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/msm_dsc_helper.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved
+ */
+
+#ifndef MSM_DSC_HELPER_H_
+#define MSM_DSC_HELPER_H_
+
+#include 
+#include 
+
+/*
+ * Helper methods for MSM specific DSC calculations that are common between 
timing engine,
+ * DSI, and DP.
+ */
+
+#define MSM_DSC_SLICE_PER_PKT 1
+#define DSC_BPP(config) ((config).bits_per_pixel >> 4)


Oh. Please. If you have used (config)->bits_per_pixel here, you wouldn't 
have to use clumsy DSC_BPP(*dsc). It might make sense to add:

Re: [Intel-gfx] [PATCH v6 5/8] drm/i915/pxp: Add ARB session creation and cleanup

[Teres Alexis, Alan Previn]

On Wed, 2023-03-29 at 08:43 +0100, Tvrtko Ursulin wrote:
> On 28/03/2023 18:52, Rodrigo Vivi wrote:
> > On Tue, Mar 28, 2023 at 05:01:36PM +, Teres Alexis, Alan Previn wrote:
> > > On Mon, 2023-03-27 at 17:15 +0100, Tvrtko Ursulin wrote:
> > > 
alan:snip
> How will the context create path look like on those platforms:
> 
> 1. Block, then potentially error out if the full initialization failed.
> 2. Error out "in progress" while initializing, error out "something 
> else" if initialization failed.
> 
alan:i was thinking of taking a page from huc-authentication's get-param where 
we could return different values based on startup progress - in all cases we 
never block:
 1. we dont support it in hw/kernel (i.e. not pxp in device-info or not enough 
CONFIG_foo - reusing intel_pxp_is_supported?)
 2. we support it in kernel but internal dependencies are still in progress 
(i.e. we have not yet completed huc-loading/huc-authen/proxy-init - UAPI spec 
should include how many
max seconds delay per platform)
 3. we support it in kernel but internal dependencies failed (i.e. we know 
huc-load/authent. failed ... or we know proxy-init failed).
 4. we support it in kernel but platform has no support (at this stage we 
actually attempt to create a PXP context or create the arb-session from inside 
i915-get-param but we ended
up a PXP fw error indicating select list of failures such as fusing / 
BIOS-config / wrong-version.
 0. we support it completely i.e. step 4's attempt to create active PXP session 
succeeded

I want to differentiate 3 and 4 (as opposed to return x-means-ENODEV) because i 
have am sure it will save debug time when facing customer issues.
Ofc we will have to optimize the checking sequences above but at #4, we would 
be creating a session which might take up to ~200 milisecs for the round trip 
response from fw.
We could store a flag in i915-pxp-internal-struct to indicate if we ever did 
succeed a pxp creation after a fresh boot ... intel_pxp_is_ready_for_active()? 
... true only if we ever did allocate a slot successfully at least once since 
boot.
This also ensure mesa init will return almost immediately except at the first 
time when hitting #4.

Re: [PATCH v3 5/6] drm/etnaviv: expand driver support for the pci devices

[kernel test robot]

Hi Sui,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm/drm-next drm-intel/for-linux-next 
drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.3-rc4 
next-20230329]
[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/Sui-Jingfeng/drm-etnaviv-add-a-dedicate-function-to-register-irq-handler-for-the-gpu/20230330-045519
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20230329205129.1513734-6-15330273260%40189.cn
patch subject: [PATCH v3 5/6] drm/etnaviv: expand driver support for the pci 
devices
config: arc-randconfig-r043-20230329 
(https://download.01.org/0day-ci/archive/20230330/202303300759.e9lbkntq-...@intel.com/config)
compiler: arc-elf-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/cfc3554b9fbd8ca3f3f6731d45d811bfa7fdf777
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Sui-Jingfeng/drm-etnaviv-add-a-dedicate-function-to-register-irq-handler-for-the-gpu/20230330-045519
git checkout cfc3554b9fbd8ca3f3f6731d45d811bfa7fdf777
# 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=arc olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 
O=build_dir ARCH=arc SHELL=/bin/bash drivers/gpu/drm/etnaviv/

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

All errors (new ones prefixed by >>):

   drivers/gpu/drm/etnaviv/etnaviv_pci_drv.c: In function 
'etnaviv_gpu_pci_fini':
>> drivers/gpu/drm/etnaviv/etnaviv_pci_drv.c:32:9: error: implicit declaration 
>> of function 'pci_clear_master'; did you mean 'pci_set_master'? 
>> [-Werror=implicit-function-declaration]
  32 | pci_clear_master(pdev);
 | ^~~~
 | pci_set_master
   cc1: some warnings being treated as errors


vim +32 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.c

27  
28  static void etnaviv_gpu_pci_fini(struct etnaviv_gpu *gpu, bool 
component)
29  {
30  struct pci_dev *pdev = to_pci_dev(gpu->dev);
31  
  > 32  pci_clear_master(pdev);
33  
34  dev_dbg(gpu->dev, "component is %s\n",
35  component ? "enabled" : "disabled");
36  }
37  

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

Re: [PATCH RFC 3/5] drm/msm/dpu: Use DRM DSC helper for det_thresh_flatness

[Dmitry Baryshkov]

On 30/03/2023 02:45, Jessica Zhang wrote:



On 3/29/2023 4:31 PM, Dmitry Baryshkov wrote:

On 30/03/2023 02:18, Jessica Zhang wrote:

Signed-off-by: Jessica Zhang 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

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

index 619926da1441..648c530b5d05 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
@@ -3,6 +3,8 @@
   * Copyright (c) 2020-2022, Linaro Limited
   */
+#include 
+
  #include "dpu_kms.h"
  #include "dpu_hw_catalog.h"
  #include "dpu_hwio.h"
@@ -102,7 +104,7 @@ static void dpu_hw_dsc_config(struct dpu_hw_dsc 
*hw_dsc,

  data |= dsc->final_offset;
  DPU_REG_WRITE(c, DSC_DSC_OFFSET, data);
-    det_thresh_flatness = 7 + 2 * (dsc->bits_per_component - 8);
+    det_thresh_flatness = drm_dsc_calculate_det_thresh_flatness(dsc);


But this changes the value! Compare:

bpc | old | new
8   | 7   | 2
10  | 11  | 8
12  | 15  | 256

If this is intentional, please state so and maybe add a Fixes tag.


Hi Dmitry,

Yep this was intentional to match downstream and the spec. Will add a 
fixes tag for this.


Good! I found corresponding change in msm-4.14, so now I understand why 
previously we had what we had.




Thanks,

Jessica Zhang





  data = det_thresh_flatness << 10;
  data |= dsc->flatness_max_qp << 5;
  data |= dsc->flatness_min_qp;



--
With best wishes
Dmitry



--
With best wishes
Dmitry

Re: [PATCH RFC 5/5] drm/msm/dsi: Use MSM and DRM DSC helper methods

[Dmitry Baryshkov]

On 30/03/2023 02:18, Jessica Zhang wrote:

Use MSM and DRM DSC helper methods.

Signed-off-by: Jessica Zhang 
---
  drivers/gpu/drm/msm/dsi/dsi_host.c | 18 --
  1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 74d38f90398a..7419fe58a941 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -31,6 +31,7 @@
  #include "msm_kms.h"
  #include "msm_gem.h"
  #include "phy/dsi_phy.h"
+#include "disp/msm_dsc_helper.h"
  
  #define DSI_RESET_TOGGLE_DELAY_MS 20
  
@@ -841,14 +842,14 @@ static void dsi_update_dsc_timing(struct msm_dsi_host *msm_host, bool is_cmd_mod

  {
struct drm_dsc_config *dsc = msm_host->dsc;
u32 reg, reg_ctrl, reg_ctrl2;
-   u32 slice_per_intf, total_bytes_per_intf;
+   u32 slice_per_intf;
u32 pkt_per_line;
u32 eol_byte_num;
  
  	/* first calculate dsc parameters and then program

 * compress mode registers
 */
-   slice_per_intf = DIV_ROUND_UP(hdisplay, dsc->slice_width);
+   slice_per_intf = msm_dsc_get_slice_per_intf(dsc, hdisplay);


This looks good

  
  	/*

 * If slice_count is greater than slice_per_intf
@@ -858,10 +859,10 @@ static void dsi_update_dsc_timing(struct msm_dsi_host 
*msm_host, bool is_cmd_mod
if (dsc->slice_count > slice_per_intf)
dsc->slice_count = 1;
  
-	total_bytes_per_intf = dsc->slice_chunk_size * slice_per_intf;

+   eol_byte_num = msm_dsc_get_eol_byte_num(msm_host->dsc, hdisplay,
+   dsi_get_bpp(msm_host->format));
  
-	eol_byte_num = total_bytes_per_intf % 3;

-   pkt_per_line = slice_per_intf / dsc->slice_count;
+   pkt_per_line = slice_per_intf / MSM_DSC_SLICE_PER_PKT;


And for these values the result is definitely changed. Separate patch & 
description please. Just in case, "values per downstream kernel" is not 
a proper description for such changes.


  
  	if (is_cmd_mode) /* packet data type */

reg = 
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_DATATYPE(MIPI_DSI_DCS_LONG_WRITE);
@@ -911,6 +912,11 @@ static void dsi_timing_setup(struct msm_dsi_host 
*msm_host, bool is_bonded_dsi)
  
  	DBG("");
  
+	if (msm_host->mode_flags & MIPI_DSI_MODE_VIDEO)

+   /* Default widebus_en to false for now. */
+   hdisplay = msm_dsc_get_pclk_per_line(msm_host->dsc, 
mode->hdisplay,
+   dsi_get_bpp(msm_host->format));
+


This is definitely something new and thus should probably go into a 
separate patch and be described. Also I'm not sure how does that 
interact with the hdisplay-related calculations below, under the if(dsc) 
clause.



/*
 * For bonded DSI mode, the current DRM mode has
 * the complete width of the panel. Since, the complete
@@ -1759,7 +1765,7 @@ static int dsi_populate_dsc_params(struct msm_dsi_host 
*msm_host, struct drm_dsc
return ret;
}
  
-	dsc->initial_scale_value = 32;

+   dsc->initial_scale_value = drm_dsc_calculate_initial_scale_value(dsc);


This is fine, we only support 8bpp where these values match.


dsc->line_buf_depth = dsc->bits_per_component + 1;
  
  	return drm_dsc_compute_rc_parameters(dsc);




--
With best wishes
Dmitry

Re: [PATCH RFC 1/5] drm/display/dsc: Add flatness and initial scale value calculations

[Jessica Zhang]

On 3/29/2023 4:25 PM, Dmitry Baryshkov wrote:

On 30/03/2023 02:18, Jessica Zhang wrote:

Add helpers to calculate det_thresh_flatness and initial_scale_value as
these calculations are defined within the DSC spec.

Signed-off-by: Jessica Zhang 
---
  include/drm/display/drm_dsc_helper.h | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/include/drm/display/drm_dsc_helper.h 
b/include/drm/display/drm_dsc_helper.h

index 4448c482b092..63175650a45e 100644
--- a/include/drm/display/drm_dsc_helper.h
+++ b/include/drm/display/drm_dsc_helper.h
@@ -17,6 +17,16 @@ enum drm_dsc_params_kind {
  DRM_DSC_1_2_420,
  };
+static inline int drm_dsc_calculate_initial_scale_value(struct 
drm_dsc_config *dsc)

+{
+    return 8 * dsc->rc_model_size / (dsc->rc_model_size - 
dsc->initial_offset);


Just set this in drm_dsc_config, like other functions do.


Hi Dmitry,

Thanks for the feedback. Acked for both comments here.

Thanks,

Jessica Zhang




+}
+
+static inline int drm_dsc_calculate_det_thresh_flatness(struct 
drm_dsc_config *dsc)

+{
+    return 2 << (dsc->bits_per_component - 8);
+}


this is flatness_det_thresh, per the standard.

Otherwise LGTM


+
  void drm_dsc_dp_pps_header_init(struct dp_sdp_header *pps_header);
  int drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8 
rc_buffer_size);
  void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set 
*pps_sdp,




--
With best wishes
Dmitry

Re: [PATCH RFC 3/5] drm/msm/dpu: Use DRM DSC helper for det_thresh_flatness

[Jessica Zhang]

On 3/29/2023 4:31 PM, Dmitry Baryshkov wrote:

On 30/03/2023 02:18, Jessica Zhang wrote:

Signed-off-by: Jessica Zhang 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

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

index 619926da1441..648c530b5d05 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
@@ -3,6 +3,8 @@
   * Copyright (c) 2020-2022, Linaro Limited
   */
+#include 
+
  #include "dpu_kms.h"
  #include "dpu_hw_catalog.h"
  #include "dpu_hwio.h"
@@ -102,7 +104,7 @@ static void dpu_hw_dsc_config(struct dpu_hw_dsc 
*hw_dsc,

  data |= dsc->final_offset;
  DPU_REG_WRITE(c, DSC_DSC_OFFSET, data);
-    det_thresh_flatness = 7 + 2 * (dsc->bits_per_component - 8);
+    det_thresh_flatness = drm_dsc_calculate_det_thresh_flatness(dsc);


But this changes the value! Compare:

bpc | old | new
8   | 7   | 2
10  | 11  | 8
12  | 15  | 256

If this is intentional, please state so and maybe add a Fixes tag.


Hi Dmitry,

Yep this was intentional to match downstream and the spec. Will add a 
fixes tag for this.


Thanks,

Jessica Zhang





  data = det_thresh_flatness << 10;
  data |= dsc->flatness_max_qp << 5;
  data |= dsc->flatness_min_qp;



--
With best wishes
Dmitry

Re: [PATCH RFC 4/5] drm/msm/dpu: Fix slice_last_group_size calculation

[Dmitry Baryshkov]

On 30/03/2023 02:18, Jessica Zhang wrote:

Correct the math for slice_last_group_size so that it matches the
calculations downstream.

Signed-off-by: Jessica Zhang 


Fixes: c110cfd1753e ("drm/msm/disp/dpu1: Add support for DSC")
Reviewed-by: Dmitry Baryshkov 


---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
index 648c530b5d05..1a1a0f6523f6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
@@ -56,7 +56,11 @@ static void dpu_hw_dsc_config(struct dpu_hw_dsc *hw_dsc,
if (is_cmd_mode)
initial_lines += 1;
  
-	slice_last_group_size = 3 - (dsc->slice_width % 3);

+   slice_last_group_size = dsc->slice_width % 3;
+
+   if (slice_last_group_size == 0)
+   slice_last_group_size = 3;
+
data = (initial_lines << 20);
data |= ((slice_last_group_size - 1) << 18);
/* bpp is 6.4 format, 4 LSBs bits are for fractional part */



--
With best wishes
Dmitry

Re: [PATCH RFC 3/5] drm/msm/dpu: Use DRM DSC helper for det_thresh_flatness

[Dmitry Baryshkov]

On 30/03/2023 02:18, Jessica Zhang wrote:

Signed-off-by: Jessica Zhang 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
index 619926da1441..648c530b5d05 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
@@ -3,6 +3,8 @@
   * Copyright (c) 2020-2022, Linaro Limited
   */
  
+#include 

+
  #include "dpu_kms.h"
  #include "dpu_hw_catalog.h"
  #include "dpu_hwio.h"
@@ -102,7 +104,7 @@ static void dpu_hw_dsc_config(struct dpu_hw_dsc *hw_dsc,
data |= dsc->final_offset;
DPU_REG_WRITE(c, DSC_DSC_OFFSET, data);
  
-	det_thresh_flatness = 7 + 2 * (dsc->bits_per_component - 8);

+   det_thresh_flatness = drm_dsc_calculate_det_thresh_flatness(dsc);


But this changes the value! Compare:

bpc | old | new
8   | 7   | 2
10  | 11  | 8
12  | 15  | 256

If this is intentional, please state so and maybe add a Fixes tag.



data = det_thresh_flatness << 10;
data |= dsc->flatness_max_qp << 5;
data |= dsc->flatness_min_qp;



--
With best wishes
Dmitry

Re: [PATCH RFC 1/5] drm/display/dsc: Add flatness and initial scale value calculations

[Dmitry Baryshkov]

On 30/03/2023 02:18, Jessica Zhang wrote:

Add helpers to calculate det_thresh_flatness and initial_scale_value as
these calculations are defined within the DSC spec.

Signed-off-by: Jessica Zhang 
---
  include/drm/display/drm_dsc_helper.h | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/include/drm/display/drm_dsc_helper.h 
b/include/drm/display/drm_dsc_helper.h
index 4448c482b092..63175650a45e 100644
--- a/include/drm/display/drm_dsc_helper.h
+++ b/include/drm/display/drm_dsc_helper.h
@@ -17,6 +17,16 @@ enum drm_dsc_params_kind {
DRM_DSC_1_2_420,
  };
  
+static inline int drm_dsc_calculate_initial_scale_value(struct drm_dsc_config *dsc)

+{
+   return 8 * dsc->rc_model_size / (dsc->rc_model_size - 
dsc->initial_offset);


Just set this in drm_dsc_config, like other functions do.


+}
+
+static inline int drm_dsc_calculate_det_thresh_flatness(struct drm_dsc_config 
*dsc)
+{
+   return 2 << (dsc->bits_per_component - 8);
+}


this is flatness_det_thresh, per the standard.

Otherwise LGTM


+
  void drm_dsc_dp_pps_header_init(struct dp_sdp_header *pps_header);
  int drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8 rc_buffer_size);
  void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set *pps_sdp,



--
With best wishes
Dmitry

[PATCH RFC 4/5] drm/msm/dpu: Fix slice_last_group_size calculation

[Jessica Zhang]

Correct the math for slice_last_group_size so that it matches the
calculations downstream.

Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
index 648c530b5d05..1a1a0f6523f6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
@@ -56,7 +56,11 @@ static void dpu_hw_dsc_config(struct dpu_hw_dsc *hw_dsc,
if (is_cmd_mode)
initial_lines += 1;
 
-   slice_last_group_size = 3 - (dsc->slice_width % 3);
+   slice_last_group_size = dsc->slice_width % 3;
+
+   if (slice_last_group_size == 0)
+   slice_last_group_size = 3;
+
data = (initial_lines << 20);
data |= ((slice_last_group_size - 1) << 18);
/* bpp is 6.4 format, 4 LSBs bits are for fractional part */

-- 
2.39.2

[PATCH RFC 5/5] drm/msm/dsi: Use MSM and DRM DSC helper methods

[Jessica Zhang]

Use MSM and DRM DSC helper methods.

Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 74d38f90398a..7419fe58a941 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -31,6 +31,7 @@
 #include "msm_kms.h"
 #include "msm_gem.h"
 #include "phy/dsi_phy.h"
+#include "disp/msm_dsc_helper.h"
 
 #define DSI_RESET_TOGGLE_DELAY_MS 20
 
@@ -841,14 +842,14 @@ static void dsi_update_dsc_timing(struct msm_dsi_host 
*msm_host, bool is_cmd_mod
 {
struct drm_dsc_config *dsc = msm_host->dsc;
u32 reg, reg_ctrl, reg_ctrl2;
-   u32 slice_per_intf, total_bytes_per_intf;
+   u32 slice_per_intf;
u32 pkt_per_line;
u32 eol_byte_num;
 
/* first calculate dsc parameters and then program
 * compress mode registers
 */
-   slice_per_intf = DIV_ROUND_UP(hdisplay, dsc->slice_width);
+   slice_per_intf = msm_dsc_get_slice_per_intf(dsc, hdisplay);
 
/*
 * If slice_count is greater than slice_per_intf
@@ -858,10 +859,10 @@ static void dsi_update_dsc_timing(struct msm_dsi_host 
*msm_host, bool is_cmd_mod
if (dsc->slice_count > slice_per_intf)
dsc->slice_count = 1;
 
-   total_bytes_per_intf = dsc->slice_chunk_size * slice_per_intf;
+   eol_byte_num = msm_dsc_get_eol_byte_num(msm_host->dsc, hdisplay,
+   dsi_get_bpp(msm_host->format));
 
-   eol_byte_num = total_bytes_per_intf % 3;
-   pkt_per_line = slice_per_intf / dsc->slice_count;
+   pkt_per_line = slice_per_intf / MSM_DSC_SLICE_PER_PKT;
 
if (is_cmd_mode) /* packet data type */
reg = 
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_DATATYPE(MIPI_DSI_DCS_LONG_WRITE);
@@ -911,6 +912,11 @@ static void dsi_timing_setup(struct msm_dsi_host 
*msm_host, bool is_bonded_dsi)
 
DBG("");
 
+   if (msm_host->mode_flags & MIPI_DSI_MODE_VIDEO)
+   /* Default widebus_en to false for now. */
+   hdisplay = msm_dsc_get_pclk_per_line(msm_host->dsc, 
mode->hdisplay,
+   dsi_get_bpp(msm_host->format));
+
/*
 * For bonded DSI mode, the current DRM mode has
 * the complete width of the panel. Since, the complete
@@ -1759,7 +1765,7 @@ static int dsi_populate_dsc_params(struct msm_dsi_host 
*msm_host, struct drm_dsc
return ret;
}
 
-   dsc->initial_scale_value = 32;
+   dsc->initial_scale_value = drm_dsc_calculate_initial_scale_value(dsc);
dsc->line_buf_depth = dsc->bits_per_component + 1;
 
return drm_dsc_compute_rc_parameters(dsc);

-- 
2.39.2

[PATCH RFC 3/5] drm/msm/dpu: Use DRM DSC helper for det_thresh_flatness

[Jessica Zhang]

Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
index 619926da1441..648c530b5d05 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
@@ -3,6 +3,8 @@
  * Copyright (c) 2020-2022, Linaro Limited
  */
 
+#include 
+
 #include "dpu_kms.h"
 #include "dpu_hw_catalog.h"
 #include "dpu_hwio.h"
@@ -102,7 +104,7 @@ static void dpu_hw_dsc_config(struct dpu_hw_dsc *hw_dsc,
data |= dsc->final_offset;
DPU_REG_WRITE(c, DSC_DSC_OFFSET, data);
 
-   det_thresh_flatness = 7 + 2 * (dsc->bits_per_component - 8);
+   det_thresh_flatness = drm_dsc_calculate_det_thresh_flatness(dsc);
data = det_thresh_flatness << 10;
data |= dsc->flatness_max_qp << 5;
data |= dsc->flatness_min_qp;

-- 
2.39.2

[PATCH RFC 2/5] drm/msm: Add MSM-specific DSC helper methods

[Jessica Zhang]

Introduce MSM-specific DSC helper methods, as some calculations are
common between DP and DSC.

Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/msm/Makefile  |  1 +
 drivers/gpu/drm/msm/disp/msm_dsc_helper.c | 74 +++
 drivers/gpu/drm/msm/disp/msm_dsc_helper.h | 28 
 3 files changed, 103 insertions(+)

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 7274c41228ed..897a5b1c88f6 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -90,6 +90,7 @@ msm-y += \
disp/mdp_kms.o \
disp/msm_disp_snapshot.o \
disp/msm_disp_snapshot_util.o \
+   disp/msm_dsc_helper.o \
msm_atomic.o \
msm_atomic_tracepoints.o \
msm_debugfs.o \
diff --git a/drivers/gpu/drm/msm/disp/msm_dsc_helper.c 
b/drivers/gpu/drm/msm/disp/msm_dsc_helper.c
new file mode 100644
index ..ec15c0d829e8
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/msm_dsc_helper.c
@@ -0,0 +1,74 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved
+ */
+
+#include 
+#include 
+#include 
+
+#include "msm_drv.h"
+#include "msm_dsc_helper.h"
+
+static int get_comp_ratio(struct drm_dsc_config *dsc, u32 src_bpp)
+{
+   return mult_frac(100, src_bpp, DSC_BPP(*dsc));
+}
+
+static s64 get_bytes_per_soft_slice(struct drm_dsc_config *dsc, int 
intf_width, int comp_ratio)
+{
+   s64 comp_ratio_fp, num_bits_fp;
+   s64 numerator_fp, denominator_fp;
+
+   comp_ratio_fp = drm_fixp_from_fraction(comp_ratio, 100);
+   num_bits_fp = drm_fixp_from_fraction(8, 1);
+
+   numerator_fp = drm_fixp_from_fraction(dsc->slice_width * 
dsc->bits_per_component * 3, 1);
+   denominator_fp = drm_fixp_mul(comp_ratio_fp, num_bits_fp);
+
+   return drm_fixp_div(numerator_fp, denominator_fp);
+}
+
+u32 msm_dsc_get_eol_byte_num(struct drm_dsc_config *dsc, int intf_width, u32 
src_bpp)
+{
+   u32 bytes_per_ss, extra_eol_bytes, bytes_per_intf;
+   s64 bytes_per_ss_fp;
+   int slice_per_intf = msm_dsc_get_slice_per_intf(dsc, intf_width);
+   int comp_ratio = get_comp_ratio(dsc, src_bpp);
+
+   bytes_per_ss_fp = get_bytes_per_soft_slice(dsc, intf_width, comp_ratio);
+   bytes_per_ss = drm_fixp2int_ceil(bytes_per_ss_fp);
+
+   bytes_per_intf = bytes_per_ss * slice_per_intf;
+   extra_eol_bytes = bytes_per_intf % 3;
+   if (extra_eol_bytes != 0)
+   extra_eol_bytes = 3 - extra_eol_bytes;
+
+   return extra_eol_bytes;
+}
+
+u32 msm_dsc_get_dce_bytes_per_line(struct drm_dsc_config *dsc, int intf_width)
+{
+   u32 bpp;
+   u32 dce_bytes_per_line;
+
+   bpp = DSC_BPP(*dsc);
+   dce_bytes_per_line = DIV_ROUND_UP(dsc->bits_per_pixel * intf_width, 8);
+
+   return dce_bytes_per_line;
+}
+
+int msm_dsc_get_pclk_per_line(struct drm_dsc_config *dsc, int intf_width, u32 
src_bpp)
+{
+   s64 data_width;
+   int comp_ratio = get_comp_ratio(dsc, src_bpp);
+
+   if (!dsc->slice_width || (intf_width < dsc->slice_width))
+   return -EINVAL;
+
+   data_width = get_bytes_per_soft_slice(dsc, intf_width, comp_ratio);
+   data_width = drm_fixp_mul(dsc->slice_count, data_width);
+   data_width = drm_fixp_from_fraction(data_width, 3);
+
+   return drm_fixp2int_ceil(data_width);
+}
diff --git a/drivers/gpu/drm/msm/disp/msm_dsc_helper.h 
b/drivers/gpu/drm/msm/disp/msm_dsc_helper.h
new file mode 100644
index ..308069b2b5a4
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/msm_dsc_helper.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved
+ */
+
+#ifndef MSM_DSC_HELPER_H_
+#define MSM_DSC_HELPER_H_
+
+#include 
+#include 
+
+/*
+ * Helper methods for MSM specific DSC calculations that are common between 
timing engine,
+ * DSI, and DP.
+ */
+
+#define MSM_DSC_SLICE_PER_PKT 1
+#define DSC_BPP(config) ((config).bits_per_pixel >> 4)
+
+static inline int msm_dsc_get_slice_per_intf(struct drm_dsc_config *dsc, int 
intf_width)
+{
+   return DIV_ROUND_UP(intf_width, dsc->slice_width);
+}
+
+u32 msm_dsc_get_eol_byte_num(struct drm_dsc_config *dsc, int intf_width, u32 
src_bpp);
+u32 msm_dsc_get_dce_bytes_per_line(struct drm_dsc_config *dsc, int intf_width);
+int msm_dsc_get_pclk_per_line(struct drm_dsc_config *dsc, int intf_width, u32 
src_bpp);
+#endif /* MSM_DSC_HELPER_H_ */

-- 
2.39.2

[PATCH RFC 0/5] Introduce MSM-specific DSC helpers

[Jessica Zhang]

There are some overlap in calculations for MSM-specific DSC variables between 
DP and DSI. In addition, the calculations for initial_scale_value and 
det_thresh_flatness that are defined within the DSC 1.2 specifications, but 
aren't yet included in drm_dsc_helper.c.

This series moves these calculations to a shared msm_dsc_helper.c file and 
defines drm_dsc_helper methods for initial_scale_value and det_thresh_flatness.

Note: For now, the MSM specific helper methods are only called for the DSI 
path, but will called for DP once DSC 1.2 support for DP has been added.

Depends on: "drm/i915: move DSC RC tables to drm_dsc_helper.c" [1]

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

---
Jessica Zhang (5):
  drm/display/dsc: Add flatness and initial scale value calculations
  drm/msm: Add MSM-specific DSC helper methods
  drm/msm/dpu: Use DRM DSC helper for det_thresh_flatness
  drm/msm/dpu: Fix slice_last_group_size calculation
  drm/msm/dsi: Use MSM and DRM DSC helper methods

 drivers/gpu/drm/msm/Makefile   |  1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 10 +++-
 drivers/gpu/drm/msm/disp/msm_dsc_helper.c  | 74 ++
 drivers/gpu/drm/msm/disp/msm_dsc_helper.h  | 28 +++
 drivers/gpu/drm/msm/dsi/dsi_host.c | 18 +---
 include/drm/display/drm_dsc_helper.h   | 10 
 6 files changed, 133 insertions(+), 8 deletions(-)
---
base-commit: 56777fc93a145afcf71b92ba4281250f59ba6d9b
change-id: 20230329-rfc-msm-dsc-helper-981a95edfbd0

Best regards,
-- 
Jessica Zhang 

[PATCH RFC 1/5] drm/display/dsc: Add flatness and initial scale value calculations

[Jessica Zhang]

Add helpers to calculate det_thresh_flatness and initial_scale_value as
these calculations are defined within the DSC spec.

Signed-off-by: Jessica Zhang 
---
 include/drm/display/drm_dsc_helper.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/drm/display/drm_dsc_helper.h 
b/include/drm/display/drm_dsc_helper.h
index 4448c482b092..63175650a45e 100644
--- a/include/drm/display/drm_dsc_helper.h
+++ b/include/drm/display/drm_dsc_helper.h
@@ -17,6 +17,16 @@ enum drm_dsc_params_kind {
DRM_DSC_1_2_420,
 };
 
+static inline int drm_dsc_calculate_initial_scale_value(struct drm_dsc_config 
*dsc)
+{
+   return 8 * dsc->rc_model_size / (dsc->rc_model_size - 
dsc->initial_offset);
+}
+
+static inline int drm_dsc_calculate_det_thresh_flatness(struct drm_dsc_config 
*dsc)
+{
+   return 2 << (dsc->bits_per_component - 8);
+}
+
 void drm_dsc_dp_pps_header_init(struct dp_sdp_header *pps_header);
 int drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8 rc_buffer_size);
 void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set *pps_sdp,

-- 
2.39.2

[PATCH] drm/nouveau/svm: remove unused ret variable

[Tom Rix]

clang with W=1 reports
drivers/gpu/drm/nouveau/nouveau_svm.c:929:6: error: variable
  'ret' set but not used [-Werror,-Wunused-but-set-variable]
int ret;
^
This variable is not used so remove it.

Signed-off-by: Tom Rix 
---
 drivers/gpu/drm/nouveau/nouveau_svm.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c 
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index a74ba8d84ba7..e072d610f2f9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_svm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
@@ -926,15 +926,14 @@ nouveau_pfns_map(struct nouveau_svmm *svmm, struct 
mm_struct *mm,
 unsigned long addr, u64 *pfns, unsigned long npages)
 {
struct nouveau_pfnmap_args *args = nouveau_pfns_to_args(pfns);
-   int ret;
 
args->p.addr = addr;
args->p.size = npages << PAGE_SHIFT;
 
mutex_lock(>mutex);
 
-   ret = nvif_object_ioctl(>vmm->vmm.object, args,
-   struct_size(args, p.phys, npages), NULL);
+   nvif_object_ioctl(>vmm->vmm.object, args,
+ struct_size(args, p.phys, npages), NULL);
 
mutex_unlock(>mutex);
 }
-- 
2.27.0

[RFC PATCH 3/3] arm64: dts: qcom: specify power domains for the GPU

[Dmitry Baryshkov]

The GPU on msm8996 is powered on by several power domains. Add
configuration for the GFX CPR and MX domains.

Signed-off-by: Dmitry Baryshkov 
---
 arch/arm64/boot/dts/qcom/msm8996.dtsi | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi 
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 905678e7175d..ff4fb30f9075 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -521,6 +521,10 @@ rpmpd_opp5: opp5 {
rpmpd_opp6: opp6 {
opp-level = <6>;
};
+
+   rpmpd_opp7: opp7 {
+   opp-level = <7>;
+   };
};
};
};
@@ -1228,7 +1232,8 @@ gpu: gpu@b0 {
interconnects = < MASTER_GRAPHICS_3D  
SLAVE_EBI_CH0>;
interconnect-names = "gfx-mem";
 
-   power-domains = < GPU_GX_GDSC>;
+   power-domains = < GPU_GX_GDSC>, < 
MSM8996_VDDMX>;
+   power-domain-names = "gx", "mx";
iommus = <_smmu 0>;
 
nvmem-cells = <_efuse>;
@@ -1251,30 +1256,37 @@ gpu_opp_table: opp-table {
opp-62400 {
opp-hz = /bits/ 64 <62400>;
opp-supported-hw = <0x09>;
+   required-opps = <_opp7>;
};
opp-56000 {
opp-hz = /bits/ 64 <56000>;
opp-supported-hw = <0x0d>;
+   required-opps = <_opp7>;
};
opp-51000 {
opp-hz = /bits/ 64 <51000>;
opp-supported-hw = <0xff>;
+   required-opps = <_opp5>;
};
opp-40180 {
opp-hz = /bits/ 64 <40180>;
opp-supported-hw = <0xff>;
+   required-opps = <_opp5>;
};
opp-31500 {
opp-hz = /bits/ 64 <31500>;
opp-supported-hw = <0xff>;
+   required-opps = <_opp4>;
};
opp-21400 {
opp-hz = /bits/ 64 <21400>;
opp-supported-hw = <0xff>;
+   required-opps = <_opp4>;
};
opp-13300 {
opp-hz = /bits/ 64 <13300>;
opp-supported-hw = <0xff>;
+   required-opps = <_opp4>;
};
};
 
-- 
2.39.2

[RFC PATCH 1/3] dt-bindings: display/msm/gpu: allow specifying MX domain A5xx

[Dmitry Baryshkov]

Some a5xx Adreno devices might need additional power domains to handle
voltage scaling. While we do not (yet) have support for CPR3 providing
voltage scaling, allow specifying MX domain to scale the memory cell
voltage.

Signed-off-by: Dmitry Baryshkov 
---
 Documentation/devicetree/bindings/display/msm/gpu.yaml | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml 
b/Documentation/devicetree/bindings/display/msm/gpu.yaml
index d4191cca71fb..4dc1f6b2cdbf 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/gpu.yaml
@@ -78,7 +78,14 @@ properties:
 type: object
 
   power-domains:
-maxItems: 1
+minItems: 1
+maxItems: 2
+
+  power-domain-names:
+items:
+  - const: gx
+  - const: mx
+minItems: 1
 
   zap-shader:
 type: object
-- 
2.39.2

[RFC PATCH 2/3] drm/msm/a5xx: scale MX domain following the frequncy changes

[Dmitry Baryshkov]

For some a5xx Adrenos we have to specify both GX and MX power domains.
GX is used to power up the GPU clocks and logic. MX is used for scaling
voltage of memory cells.

In case the DT specifies several (GX, MX) power domains, none will be
bound by the core. We have to manage GX manually. Also make sure that
the MX domain is resumed and scaled to the proper performance state
following the desired frequency.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 52 +++
 drivers/gpu/drm/msm/adreno/a5xx_gpu.h |  3 ++
 2 files changed, 55 insertions(+)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 0372f8908202..36b3d11dd5b0 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "msm_gem.h"
 #include "msm_mmu.h"
@@ -1053,6 +1054,13 @@ static void a5xx_destroy(struct msm_gpu *gpu)
}
 
adreno_gpu_cleanup(adreno_gpu);
+
+   if (a5xx_gpu->mx_link)
+   device_link_del(a5xx_gpu->mx_link);
+
+   if (a5xx_gpu->gxpd)
+   dev_pm_domain_detach(a5xx_gpu->gxpd, true);
+
kfree(a5xx_gpu);
 }
 
@@ -1339,8 +1347,15 @@ static void a5xx_dump(struct msm_gpu *gpu)
 static int a5xx_pm_resume(struct msm_gpu *gpu)
 {
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+   struct a5xx_gpu *a5xx_gpu = to_a5xx_gpu(adreno_gpu);
int ret;
 
+   if (a5xx_gpu->gxpd) {
+   ret = pm_runtime_resume_and_get(a5xx_gpu->gxpd);
+   if (ret < 0)
+   return ret;
+   }
+
/* Turn on the core power */
ret = msm_gpu_pm_resume(gpu);
if (ret)
@@ -1414,6 +1429,9 @@ static int a5xx_pm_suspend(struct msm_gpu *gpu)
if (ret)
return ret;
 
+   if (a5xx_gpu->gxpd)
+   pm_runtime_put(a5xx_gpu->gxpd);
+
if (a5xx_gpu->has_whereami)
for (i = 0; i < gpu->nr_rings; i++)
a5xx_gpu->shadow[i] = 0;
@@ -1762,6 +1780,40 @@ struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
 
a5xx_gpu->lm_leakage = 0x4E001A;
 
+   /*
+* If the device has several power domain (gx and mx), none are 
attached by the core.
+*/
+   if (!pdev->dev.pm_domain) {
+   struct device **opp_virt_dev;
+   struct device *pd;
+
+   /* FIXME: add cpr once it is supported */
+   static const char *genpd_names[] = { "mx", NULL };
+
+   pd = dev_pm_domain_attach_by_name(>dev, "gx");
+   if (IS_ERR(pd))
+   return ERR_CAST(pd);
+
+   /* GX is required for GPU to function */
+   if (pd == NULL)
+   return ERR_PTR(-EINVAL);
+
+   a5xx_gpu->gxpd = pd;
+
+   ret = devm_pm_opp_attach_genpd(>dev, genpd_names, 
_virt_dev);
+   if (ret) {
+   dev_pm_domain_detach(a5xx_gpu->gxpd, true);
+   return ERR_PTR(ret);
+   }
+
+   a5xx_gpu->mx_link = device_link_add(>dev, opp_virt_dev[0],
+   DL_FLAG_RPM_ACTIVE |
+   DL_FLAG_PM_RUNTIME |
+   DL_FLAG_STATELESS);
+   if (!a5xx_gpu->mx_link)
+   return ERR_PTR(-ENODEV);
+   }
+
check_speed_bin(>dev);
 
nr_rings = 4;
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.h 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.h
index c7187bcc5e90..36e910397c14 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.h
@@ -44,6 +44,9 @@ struct a5xx_gpu {
 
/* True if the microcode supports the WHERE_AM_I opcode */
bool has_whereami;
+
+   struct device *gxpd;
+   struct device_link *mx_link;
 };
 
 #define to_a5xx_gpu(x) container_of(x, struct a5xx_gpu, base)
-- 
2.39.2

[RFC PATCH 0/3] drm/msm/a5xx: scale MX following the frequency changes

[Dmitry Baryshkov]

Konrad brought up the topic of scaling the MX domain according to the
OPP changes. Here is my RFC for this functionality. I post it as an RFC
for two reasons:

1) I'm not sure that we should scale MX if we are not scaling main
voltage following the CPR3

2) With this patchset I'm getting the following huuuge backtrace from
lockdep, which I was not able to solve and which, I believe, is a false
positive. An independent opinion is appreciated.

==
WARNING: possible circular locking dependency detected
6.3.0-rc2-00329-g761f7b50599b #348 Not tainted
--
ring2/111 is trying to acquire lock:
8ca79078 (>lock){+.+.}-{3:3}, at: 
qos_min_notifier_call+0x28/0x88

but task is already holding lock:
8b7d64e8 (&(c->notifiers)->rwsem){}-{3:3}, at: 
blocking_notifier_call_chain+0x34/0xa0

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #4 (&(c->notifiers)->rwsem){}-{3:3}:
   lock_acquire+0x68/0x84
   down_write+0x40/0xe4
   blocking_notifier_chain_register+0x30/0x8c
   freq_qos_add_notifier+0x68/0x7c
   dev_pm_qos_add_notifier+0xa0/0xf8
   devfreq_add_device.part.0+0x360/0x5c8
   devm_devfreq_add_device+0x74/0xe0
   msm_devfreq_init+0xa0/0x16c
   msm_gpu_init+0x2fc/0x588
   adreno_gpu_init+0x180/0x2c8
   a5xx_gpu_init+0x128/0x378
   adreno_bind+0x180/0x290
   component_bind_all+0x118/0x24c
   msm_drm_bind+0x1ac/0x66c
   try_to_bring_up_aggregate_device+0x168/0x1d4
   __component_add+0xa8/0x170
   component_add+0x14/0x20
   msm_hdmi_dev_probe+0x474/0x5bc
   platform_probe+0x68/0xd8
   really_probe+0x148/0x2b4
   __driver_probe_device+0x78/0xe0
   driver_probe_device+0xd8/0x160
   __device_attach_driver+0xb8/0x138
   bus_for_each_drv+0x84/0xe0
   __device_attach+0xa8/0x1b0
   device_initial_probe+0x14/0x20
   bus_probe_device+0xb0/0xb4
   deferred_probe_work_func+0x8c/0xc8
   process_one_work+0x288/0x6b0
   worker_thread+0x23c/0x440
   kthread+0x10c/0x110
   ret_from_fork+0x10/0x20

-> #3 (dev_pm_qos_mtx){+.+.}-{3:3}:
   lock_acquire+0x68/0x84
   __mutex_lock+0x84/0x400
   mutex_lock_nested+0x2c/0x38
   dev_pm_qos_add_notifier+0x38/0xf8
   genpd_add_device+0x150/0x340
   __genpd_dev_pm_attach+0xa4/0x264
   genpd_dev_pm_attach+0x60/0x70
   dev_pm_domain_attach+0x20/0x34
   platform_probe+0x50/0xd8
   really_probe+0x148/0x2b4
   __driver_probe_device+0x78/0xe0
   driver_probe_device+0xd8/0x160
   __device_attach_driver+0xb8/0x138
   bus_for_each_drv+0x84/0xe0
   __device_attach+0xa8/0x1b0
   device_initial_probe+0x14/0x20
   bus_probe_device+0xb0/0xb4
   deferred_probe_work_func+0x8c/0xc8
   process_one_work+0x288/0x6b0
   worker_thread+0x23c/0x440
   kthread+0x10c/0x110
   ret_from_fork+0x10/0x20

-> #2 (gpd_list_lock){+.+.}-{3:3}:
   lock_acquire+0x68/0x84
   __mutex_lock+0x84/0x400
   mutex_lock_nested+0x2c/0x38
   __genpd_dev_pm_attach+0x78/0x264
   genpd_dev_pm_attach_by_id.part.0+0xa4/0x158
   genpd_dev_pm_attach_by_name+0x64/0x8c
   dev_pm_domain_attach_by_name+0x20/0x2c
   dev_pm_opp_set_config+0x3e4/0x688
   devm_pm_opp_set_config+0x18/0x70
   a5xx_gpu_init+0x1d8/0x378
   adreno_bind+0x180/0x290
   component_bind_all+0x118/0x24c
   msm_drm_bind+0x1ac/0x66c
   try_to_bring_up_aggregate_device+0x168/0x1d4
   __component_add+0xa8/0x170
   component_add+0x14/0x20
   msm_hdmi_dev_probe+0x474/0x5bc
   platform_probe+0x68/0xd8
   really_probe+0x148/0x2b4
   __driver_probe_device+0x78/0xe0
   driver_probe_device+0xd8/0x160
   __device_attach_driver+0xb8/0x138
   bus_for_each_drv+0x84/0xe0
   __device_attach+0xa8/0x1b0
   device_initial_probe+0x14/0x20
   bus_probe_device+0xb0/0xb4
   deferred_probe_work_func+0x8c/0xc8
   process_one_work+0x288/0x6b0
   worker_thread+0x23c/0x440
   kthread+0x10c/0x110
   ret_from_fork+0x10/0x20

-> #1 (_table->genpd_virt_dev_lock){+.+.}-{3:3}:
   lock_acquire+0x68/0x84
   __mutex_lock+0x84/0x400
   mutex_lock_nested+0x2c/0x38
   _set_required_opps+0x64/0x180
   _set_opp+0x190/0x438
   dev_pm_opp_set_rate+0x18c/0x274
   msm_devfreq_target+0x19c/0x224
   devfreq_set_target+0x84/0x2f8
   devfreq_update_target+0xc4/0xec
   devfreq_monitor+0x38/0x1f0
   process_one_work+0x288/0x6b0
   worker_thread+0x74/0x440
   kthread+0x10c/0x110
   ret_from_fork+0x10/0x20

-> #0 (>lock){+.+.}-{3:3}:
   __lock_acquire+0x138c/0x2218
   lock_acquire.part.0+0xc4/0x1fc
   lock_acquire+0x68/0x84
   __mutex_lock+0x84/0x400
   mutex_lock_nested+0x2c/0x38
   qos_min_notifier_call+0x28/0x88
   

[pull] amdgpu drm-fixes-6.3

[Alex Deucher]

Hi Dave, Daniel,

Fixes for 6.3.

The following changes since commit 197b6b60ae7bc51dd0814953c562833143b292aa:

  Linux 6.3-rc4 (2023-03-26 14:40:20 -0700)

are available in the Git repository at:

  https://gitlab.freedesktop.org/agd5f/linux.git 
tags/amd-drm-fixes-6.3-2023-03-29

for you to fetch changes up to 68dc1846c3a44d5e633be145c169ce2fd5420695:

  drm/amd/display: Take FEC Overhead into Timeslot Calculation (2023-03-29 
17:21:06 -0400)


amd-drm-fixes-6.3-2023-03-29:

amdgpu:
- Two DP MST fixes


Fangzhi Zuo (2):
  drm/amd/display: Add DSC Support for Synaptics Cascaded MST Hub
  drm/amd/display: Take FEC Overhead into Timeslot Calculation

 .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 51 ++
 .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.h| 15 +++
 2 files changed, 58 insertions(+), 8 deletions(-)

[PATCH v3 6/6] drm/etnaviv: allow usperspace create cached coherent bo

[Sui Jingfeng]

From: Sui Jingfeng 

 As Lucas pointed, there should have some way to let mesa query the kernel
 about the host platform whether support cached coherent mode or not. This
 should touch the ioctl stuff I think, bad design may lead new mesa or
 libdrm crash old kernel. It need more instruction how to implement this,
 maybe another patch to do this. Making this driver works on loongson
 platform is far enough for me.

Signed-off-by: Sui Jingfeng 
---
 drivers/gpu/drm/etnaviv/etnaviv_drv.c   |  2 +-
 drivers/gpu/drm/etnaviv/etnaviv_gem.c   | 22 +++--
 drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c |  9 -
 include/uapi/drm/etnaviv_drm.h  | 11 ++-
 4 files changed, 35 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index dbca3bf7fba2..91aeedb837e9 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -276,7 +276,7 @@ static int etnaviv_ioctl_gem_new(struct drm_device *dev, 
void *data,
struct drm_etnaviv_gem_new *args = data;
 
if (args->flags & ~(ETNA_BO_CACHED | ETNA_BO_WC | ETNA_BO_UNCACHED |
-   ETNA_BO_FORCE_MMU))
+   ETNA_BO_CACHED_COHERENT | ETNA_BO_FORCE_MMU))
return -EINVAL;
 
return etnaviv_gem_new_handle(dev, file, args->size,
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index b5f73502e3dd..d8b559bd33d3 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -343,6 +343,7 @@ void *etnaviv_gem_vmap(struct drm_gem_object *obj)
 static void *etnaviv_gem_vmap_impl(struct etnaviv_gem_object *obj)
 {
struct page **pages;
+   pgprot_t prot;
 
lockdep_assert_held(>lock);
 
@@ -350,8 +351,20 @@ static void *etnaviv_gem_vmap_impl(struct 
etnaviv_gem_object *obj)
if (IS_ERR(pages))
return NULL;
 
-   return vmap(pages, obj->base.size >> PAGE_SHIFT,
-   VM_MAP, pgprot_writecombine(PAGE_KERNEL));
+   switch (obj->flags) {
+   case ETNA_BO_CACHED_COHERENT:
+   case ETNA_BO_CACHED:
+   prot = PAGE_KERNEL;
+   break;
+   case ETNA_BO_UNCACHED:
+   prot = pgprot_noncached(PAGE_KERNEL);
+   break;
+   case ETNA_BO_WC:
+   default:
+   prot = pgprot_writecombine(PAGE_KERNEL);
+   }
+
+   return vmap(pages, obj->base.size >> PAGE_SHIFT, VM_MAP, prot);
 }
 
 static inline enum dma_data_direction etnaviv_op_to_dma_dir(u32 op)
@@ -545,6 +558,7 @@ static const struct drm_gem_object_funcs 
etnaviv_gem_object_funcs = {
 static int etnaviv_gem_new_impl(struct drm_device *dev, u32 size, u32 flags,
const struct etnaviv_gem_ops *ops, struct drm_gem_object **obj)
 {
+   struct etnaviv_drm_private *priv = dev->dev_private;
struct etnaviv_gem_object *etnaviv_obj;
unsigned sz = sizeof(*etnaviv_obj);
bool valid = true;
@@ -555,6 +569,10 @@ static int etnaviv_gem_new_impl(struct drm_device *dev, 
u32 size, u32 flags,
case ETNA_BO_CACHED:
case ETNA_BO_WC:
break;
+   case ETNA_BO_CACHED_COHERENT:
+   if (priv->has_cached_coherent)
+   break;
+   fallthrough;
default:
valid = false;
}
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
index 7031db145a77..9364874918e3 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
@@ -104,11 +104,18 @@ static const struct etnaviv_gem_ops etnaviv_gem_prime_ops 
= {
 struct drm_gem_object *etnaviv_gem_prime_import_sg_table(struct drm_device 
*dev,
struct dma_buf_attachment *attach, struct sg_table *sgt)
 {
+   struct etnaviv_drm_private *priv = dev->dev_private;
struct etnaviv_gem_object *etnaviv_obj;
size_t size = PAGE_ALIGN(attach->dmabuf->size);
+   u32 cache_flags;
int ret, npages;
 
-   ret = etnaviv_gem_new_private(dev, size, ETNA_BO_WC,
+   if (priv->has_cached_coherent)
+   cache_flags = ETNA_BO_CACHED_COHERENT;
+   else
+   cache_flags = ETNA_BO_WC;
+
+   ret = etnaviv_gem_new_private(dev, size, cache_flags,
  _gem_prime_ops, _obj);
if (ret < 0)
return ERR_PTR(ret);
diff --git a/include/uapi/drm/etnaviv_drm.h b/include/uapi/drm/etnaviv_drm.h
index af024d90453d..474b0db286de 100644
--- a/include/uapi/drm/etnaviv_drm.h
+++ b/include/uapi/drm/etnaviv_drm.h
@@ -90,13 +90,14 @@ struct drm_etnaviv_param {
  * GEM buffers:
  */
 
-#define ETNA_BO_CACHE_MASK   0x000f
+#define ETNA_BO_CACHE_MASK  0x000f
 /* cache modes */
-#define ETNA_BO_CACHED   0x0001
-#define ETNA_BO_WC   

[PATCH v3 3/6] drm/etnaviv: add dedicate functions to create and destroy platform device

[Sui Jingfeng]

From: Sui Jingfeng 

 Also rename the virtual master device as etnaviv_platform_device, for
 better reflection that it is a platform device, not the drm device control
 structure. Another benefit is that we no longer need to call of_node_put()
 for three different case. Instead, we only need call it once.

Signed-off-by: Sui Jingfeng 
---
 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 56 +++
 1 file changed, 39 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 44ca803237a5..ce0537af80bd 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -697,12 +697,44 @@ static struct platform_driver etnaviv_platform_driver = {
},
 };
 
-static struct platform_device *etnaviv_drm;
+static struct platform_device *etnaviv_platform_device;
 
-static int __init etnaviv_init(void)
+static int etnaviv_create_platform_device(const char *name,
+ struct platform_device **ppdev)
 {
struct platform_device *pdev;
int ret;
+
+   pdev = platform_device_alloc(name, PLATFORM_DEVID_NONE);
+   if (!pdev)
+   return -ENOMEM;
+
+   ret = platform_device_add(pdev);
+   if (ret) {
+   platform_device_put(pdev);
+   return ret;
+   }
+
+   *ppdev = pdev;
+
+   return 0;
+}
+
+static void etnaviv_destroy_platform_device(struct platform_device **ppdev)
+{
+   struct platform_device *pdev = *ppdev;
+
+   if (!pdev)
+   return;
+
+   *ppdev = NULL;
+
+   platform_device_unregister(pdev);
+}
+
+static int __init etnaviv_init(void)
+{
+   int ret;
struct device_node *np;
 
etnaviv_validate_init();
@@ -723,22 +755,12 @@ static int __init etnaviv_init(void)
if (!of_device_is_available(np))
continue;
 
-   pdev = platform_device_alloc("etnaviv", PLATFORM_DEVID_NONE);
-   if (!pdev) {
-   ret = -ENOMEM;
-   of_node_put(np);
-   goto unregister_platform_driver;
-   }
-
-   ret = platform_device_add(pdev);
-   if (ret) {
-   platform_device_put(pdev);
-   of_node_put(np);
+   ret = etnaviv_create_platform_device("etnaviv",
+_platform_device);
+   of_node_put(np);
+   if (ret)
goto unregister_platform_driver;
-   }
 
-   etnaviv_drm = pdev;
-   of_node_put(np);
break;
}
 
@@ -754,7 +776,7 @@ module_init(etnaviv_init);
 
 static void __exit etnaviv_exit(void)
 {
-   platform_device_unregister(etnaviv_drm);
+   etnaviv_destroy_platform_device(_platform_device);
platform_driver_unregister(_platform_driver);
platform_driver_unregister(_gpu_driver);
 }
-- 
2.25.1

[PATCH v3 5/6] drm/etnaviv: expand driver support for the pci devices

[Sui Jingfeng]

From: Sui Jingfeng 

 This patch add pci driver support to etnaviv on the top of what already
 have, take the gc1000 in ls7a1000 and ls2k1000 as the first instance of
 the generic pci device driver.

 There is only one gpu core for the gc1000 in ls7a1000 and ls2k1000,
 component framework can be avoid on such a case. Because we want to
 bind the drm driver service to the pci gpu driver manually at a first.
 step.

 We avoid to using component framework, because userspace lib use
 libpciaccess to find available GPU in the system before initialization,
 the virtual drm master device will not be get used without a force
 override. X server is one of the examples, yet, mesa loader will do the
 similar thing, it will try to find the pci device to use in the system
 by default and then get a gallium driver name from the pci device id.
 The idea of create a virtual master for the system with pci gpu cause
 unnecessary troubles.

 I not saying that component framework is not impossible, it is just that
 the solo pci device should be the master. Creating a virtual platform
 device is still useful, as we can bind some software service to the real
 GPU master to control the dpendency or loading order.

 This is not only for pci devices, platform gpu with single core can also
 choose to try the non componment code path.

Signed-off-by: Sui Jingfeng 
---
 drivers/gpu/drm/etnaviv/Makefile  |  1 +
 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 62 ---
 drivers/gpu/drm/etnaviv/etnaviv_drv.h |  3 +
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 97 ---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 12 +++
 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.c | 88 
 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.h | 10 +++
 7 files changed, 232 insertions(+), 41 deletions(-)
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.c
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.h

diff --git a/drivers/gpu/drm/etnaviv/Makefile b/drivers/gpu/drm/etnaviv/Makefile
index 46e5ffad69a6..3f8b99664a58 100644
--- a/drivers/gpu/drm/etnaviv/Makefile
+++ b/drivers/gpu/drm/etnaviv/Makefile
@@ -13,6 +13,7 @@ etnaviv-y := \
etnaviv_iommu_v2.o \
etnaviv_iommu.o \
etnaviv_mmu.o \
+   etnaviv_pci_drv.o \
etnaviv_perfmon.o \
etnaviv_sched.o
 
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 93dfa4b1a38b..dbca3bf7fba2 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -21,6 +22,7 @@
 #include "etnaviv_gpu.h"
 #include "etnaviv_gem.h"
 #include "etnaviv_mmu.h"
+#include "etnaviv_pci_drv.h"
 #include "etnaviv_perfmon.h"
 #include "common.xml.h"
 
@@ -566,6 +568,16 @@ static int etnaviv_alloc_private(struct device *dev,
return ret;
}
 
+   /*
+* Loongson Mips and LoongArch CPU(ls3a5000, ls3c5000, ls2k1000la)
+* maintain cache coherency by hardware
+*/
+   if (IS_ENABLED(CONFIG_CPU_LOONGSON64) || IS_ENABLED(CONFIG_LOONGARCH))
+   priv->has_cached_coherent = true;
+
+   dev_info(dev, "Cached coherent mode is %s\n",
+priv->has_cached_coherent ? "support" : "not support");
+
*ppriv = priv;
 
return 0;
@@ -580,10 +592,9 @@ static void etnaviv_free_private(struct 
etnaviv_drm_private *priv)
kfree(priv);
 }
 
-/*
- * Platform driver:
- */
-static int etnaviv_bind(struct device *dev)
+static struct etnaviv_drm_private *etna_private_s;
+
+int etnaviv_drm_bind(struct device *dev, bool component)
 {
struct etnaviv_drm_private *priv;
struct drm_device *drm;
@@ -599,12 +610,15 @@ static int etnaviv_bind(struct device *dev)
 
priv->drm = drm;
drm->dev_private = priv;
+   etna_private_s = priv;
 
dma_set_max_seg_size(dev, SZ_2G);
 
-   dev_set_drvdata(dev, drm);
+   if (component)
+   ret = component_bind_all(dev, drm);
+   else
+   ret = etnaviv_gpu_bind(dev, NULL, drm);
 
-   ret = component_bind_all(dev, drm);
if (ret < 0)
goto out_free_priv;
 
@@ -626,14 +640,17 @@ static int etnaviv_bind(struct device *dev)
return ret;
 }
 
-static void etnaviv_unbind(struct device *dev)
+void etnaviv_drm_unbind(struct device *dev, bool component)
 {
-   struct drm_device *drm = dev_get_drvdata(dev);
-   struct etnaviv_drm_private *priv = drm->dev_private;
+   struct etnaviv_drm_private *priv = etna_private_s;
+   struct drm_device *drm = priv->drm;
 
drm_dev_unregister(drm);
 
-   component_unbind_all(dev, drm);
+   if (component)
+   component_unbind_all(dev, drm);
+   else
+   etnaviv_gpu_unbind(dev, NULL, drm);
 
etnaviv_free_private(priv);
 
@@ -642,9 +659,22 @@ static void etnaviv_unbind(struct device 

[PATCH v3 4/6] drm/etnaviv: add helpers for private data construction and destruction

[Sui Jingfeng]

From: Sui Jingfeng 

 struct etnaviv_drm_private contains a lot of common resources that is
 shared by all GPUs, members of it is large enough. This patch introduce
 two dedicate functions which is for the construction and destruction of
 the instance of this structure. The idea is avoid to leak its members
 to outside, then the error handling code can be simplified.

Signed-off-by: Sui Jingfeng 
---
 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 71 +--
 drivers/gpu/drm/etnaviv/etnaviv_drv.h |  4 ++
 2 files changed, 50 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index ce0537af80bd..93dfa4b1a38b 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -539,28 +539,17 @@ static const struct drm_driver etnaviv_drm_driver = {
.minor  = 3,
 };
 
-/*
- * Platform driver:
- */
-static int etnaviv_bind(struct device *dev)
+static int etnaviv_alloc_private(struct device *dev,
+struct etnaviv_drm_private **ppriv)
 {
struct etnaviv_drm_private *priv;
-   struct drm_device *drm;
int ret;
 
-   drm = drm_dev_alloc(_drm_driver, dev);
-   if (IS_ERR(drm))
-   return PTR_ERR(drm);
-
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv) {
dev_err(dev, "failed to allocate private data\n");
-   ret = -ENOMEM;
-   goto out_put;
+   return -ENOMEM;
}
-   drm->dev_private = priv;
-
-   dma_set_max_seg_size(dev, SZ_2G);
 
xa_init_flags(>active_contexts, XA_FLAGS_ALLOC);
 
@@ -569,18 +558,55 @@ static int etnaviv_bind(struct device *dev)
priv->num_gpus = 0;
priv->shm_gfp_mask = GFP_HIGHUSER | __GFP_RETRY_MAYFAIL | __GFP_NOWARN;
 
-   priv->cmdbuf_suballoc = etnaviv_cmdbuf_suballoc_new(drm->dev);
+   priv->cmdbuf_suballoc = etnaviv_cmdbuf_suballoc_new(dev);
if (IS_ERR(priv->cmdbuf_suballoc)) {
-   dev_err(drm->dev, "Failed to create cmdbuf suballocator\n");
+   dev_err(dev, "Failed to create cmdbuf suballocator\n");
ret = PTR_ERR(priv->cmdbuf_suballoc);
-   goto out_free_priv;
+   kfree(priv);
+   return ret;
}
 
+   *ppriv = priv;
+
+   return 0;
+}
+
+static void etnaviv_free_private(struct etnaviv_drm_private *priv)
+{
+   etnaviv_cmdbuf_suballoc_destroy(priv->cmdbuf_suballoc);
+
+   xa_destroy(>active_contexts);
+
+   kfree(priv);
+}
+
+/*
+ * Platform driver:
+ */
+static int etnaviv_bind(struct device *dev)
+{
+   struct etnaviv_drm_private *priv;
+   struct drm_device *drm;
+   int ret;
+
+   drm = drm_dev_alloc(_drm_driver, dev);
+   if (IS_ERR(drm))
+   return PTR_ERR(drm);
+
+   ret = etnaviv_alloc_private(dev, );
+   if (ret)
+   goto out_put;
+
+   priv->drm = drm;
+   drm->dev_private = priv;
+
+   dma_set_max_seg_size(dev, SZ_2G);
+
dev_set_drvdata(dev, drm);
 
ret = component_bind_all(dev, drm);
if (ret < 0)
-   goto out_destroy_suballoc;
+   goto out_free_priv;
 
load_gpu(drm);
 
@@ -592,10 +618,8 @@ static int etnaviv_bind(struct device *dev)
 
 out_unbind:
component_unbind_all(dev, drm);
-out_destroy_suballoc:
-   etnaviv_cmdbuf_suballoc_destroy(priv->cmdbuf_suballoc);
 out_free_priv:
-   kfree(priv);
+   etnaviv_free_private(priv);
 out_put:
drm_dev_put(drm);
 
@@ -611,12 +635,9 @@ static void etnaviv_unbind(struct device *dev)
 
component_unbind_all(dev, drm);
 
-   etnaviv_cmdbuf_suballoc_destroy(priv->cmdbuf_suballoc);
-
-   xa_destroy(>active_contexts);
+   etnaviv_free_private(priv);
 
drm->dev_private = NULL;
-   kfree(priv);
 
drm_dev_put(drm);
 }
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
index b3eb1662e90c..87fb52c03c5e 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
@@ -35,6 +35,7 @@ struct etnaviv_file_private {
 };
 
 struct etnaviv_drm_private {
+   struct drm_device *drm;
int num_gpus;
struct etnaviv_gpu *gpu[ETNA_MAX_PIPES];
gfp_t shm_gfp_mask;
@@ -45,6 +46,9 @@ struct etnaviv_drm_private {
struct xarray active_contexts;
u32 next_context_id;
 
+   /* hint for platform support cached coherent caching mode */
+   bool has_cached_coherent;
+
/* list of GEM objects: */
struct mutex gem_lock;
struct list_head gem_list;
-- 
2.25.1

[PATCH v3 2/6] drm/etnaviv: add a dedicate function to get clock

[Sui Jingfeng]

From: Sui Jingfeng 

 Because it is also platform dependent, there are environment which
 without clk subsystem support, we don't want the driver rage quit
 because of no clk subsystem driver support. There are discrete graphics
 card which integrate vivante gpu IP.

 For the GPU in ls7a1000 and lsak2000, working frequency of the gpu is
 changed by configuring the PLL register directly.

Signed-off-by: Sui Jingfeng 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 62 ++-
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h |  1 +
 2 files changed, 42 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 636d3f39ddcb..4937580551a5 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1565,10 +1565,45 @@ static irqreturn_t irq_handler(int irq, void *data)
return ret;
 }
 
+static int etnaviv_gpu_clk_get(struct etnaviv_gpu *gpu)
+{
+   struct device *dev = gpu->dev;
+
+   if (gpu->no_clk)
+   return 0;
+
+   gpu->clk_reg = devm_clk_get_optional(dev, "reg");
+   DBG("clk_reg: %p", gpu->clk_reg);
+   if (IS_ERR(gpu->clk_reg))
+   return PTR_ERR(gpu->clk_reg);
+
+   gpu->clk_bus = devm_clk_get_optional(dev, "bus");
+   DBG("clk_bus: %p", gpu->clk_bus);
+   if (IS_ERR(gpu->clk_bus))
+   return PTR_ERR(gpu->clk_bus);
+
+   gpu->clk_core = devm_clk_get(dev, "core");
+   DBG("clk_core: %p", gpu->clk_core);
+   if (IS_ERR(gpu->clk_core))
+   return PTR_ERR(gpu->clk_core);
+   gpu->base_rate_core = clk_get_rate(gpu->clk_core);
+
+   gpu->clk_shader = devm_clk_get_optional(dev, "shader");
+   DBG("clk_shader: %p", gpu->clk_shader);
+   if (IS_ERR(gpu->clk_shader))
+   return PTR_ERR(gpu->clk_shader);
+   gpu->base_rate_shader = clk_get_rate(gpu->clk_shader);
+
+   return 0;
+}
+
 static int etnaviv_gpu_clk_enable(struct etnaviv_gpu *gpu)
 {
int ret;
 
+   if (gpu->no_clk)
+   return 0;
+
ret = clk_prepare_enable(gpu->clk_reg);
if (ret)
return ret;
@@ -1599,6 +1634,9 @@ static int etnaviv_gpu_clk_enable(struct etnaviv_gpu *gpu)
 
 static int etnaviv_gpu_clk_disable(struct etnaviv_gpu *gpu)
 {
+   if (gpu->no_clk)
+   return 0;
+
clk_disable_unprepare(gpu->clk_shader);
clk_disable_unprepare(gpu->clk_core);
clk_disable_unprepare(gpu->clk_bus);
@@ -1865,27 +1903,9 @@ static int etnaviv_gpu_platform_probe(struct 
platform_device *pdev)
return err;
 
/* Get Clocks: */
-   gpu->clk_reg = devm_clk_get_optional(>dev, "reg");
-   DBG("clk_reg: %p", gpu->clk_reg);
-   if (IS_ERR(gpu->clk_reg))
-   return PTR_ERR(gpu->clk_reg);
-
-   gpu->clk_bus = devm_clk_get_optional(>dev, "bus");
-   DBG("clk_bus: %p", gpu->clk_bus);
-   if (IS_ERR(gpu->clk_bus))
-   return PTR_ERR(gpu->clk_bus);
-
-   gpu->clk_core = devm_clk_get(>dev, "core");
-   DBG("clk_core: %p", gpu->clk_core);
-   if (IS_ERR(gpu->clk_core))
-   return PTR_ERR(gpu->clk_core);
-   gpu->base_rate_core = clk_get_rate(gpu->clk_core);
-
-   gpu->clk_shader = devm_clk_get_optional(>dev, "shader");
-   DBG("clk_shader: %p", gpu->clk_shader);
-   if (IS_ERR(gpu->clk_shader))
-   return PTR_ERR(gpu->clk_shader);
-   gpu->base_rate_shader = clk_get_rate(gpu->clk_shader);
+   err = etnaviv_gpu_clk_get(gpu);
+   if (err)
+   return err;
 
/* TODO: figure out max mapped size */
dev_set_drvdata(dev, gpu);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
index 98c6f9c320fc..6da5209a7d64 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
@@ -148,6 +148,7 @@ struct etnaviv_gpu {
struct clk *clk_reg;
struct clk *clk_core;
struct clk *clk_shader;
+   bool no_clk;
 
unsigned int freq_scale;
unsigned long base_rate_core;
-- 
2.25.1

[PATCH v3 0/6] drm/etnaviv: add pci device driver support

[Sui Jingfeng]

From: Sui Jingfeng 

  There is a Vivante GC1000(v5037) in LS2K1000 and LS7A1000, the gpu is a
  PCI device and it has 2D and 3D core in the same gpu device. Therefore,
  this patch trying to add PCI device driver support on the great works
  already done by etnaviv folks.

  LS7A1000 is a bridge chip for LS3A5000(4 core 2.5Ghz loongarch cpu) and
  LS3A4000(4 core 1.8gHz Mips64r5 cpu), While LS2K1000 is just a slow SoC
  (2 core 1.0Ghz mips64r2). Loongson CPU support cached coherent caching
  mode, both the GPU and DC device snoop CPU cache by default firmware
  configuration.

Sui Jingfeng (6):
  drm/etnaviv: add a dedicate function to register irq handler for the
gpu
  drm/etnaviv: add a dedicate function to get clock
  drm/etnaviv: add dedicate functions to create and destroy platform
device
  drm/etnaviv: add helpers for private data construction and destruction
  drm/etnaviv: expand driver support for the pci devices
  drm/etnaviv: allow usperspace create cached coherent bo

 drivers/gpu/drm/etnaviv/Makefile|   1 +
 drivers/gpu/drm/etnaviv/etnaviv_drv.c   | 183 +--
 drivers/gpu/drm/etnaviv/etnaviv_drv.h   |   7 +
 drivers/gpu/drm/etnaviv/etnaviv_gem.c   |  22 ++-
 drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c |   9 +-
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c   | 185 ++--
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h   |  13 ++
 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.c   |  88 ++
 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.h   |  10 ++
 include/uapi/drm/etnaviv_drm.h  |  11 +-
 10 files changed, 415 insertions(+), 114 deletions(-)
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.c
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.h

-- 
2.25.1

[PATCH v3 1/6] drm/etnaviv: add a dedicate function to register irq handler for the gpu

[Sui Jingfeng]

From: Sui Jingfeng 

 Because get irq from a device is platform dependent, pci device has
 different method to get irq. This patch is a preparation before we
 introduce support for the pci device.

Signed-off-by: Sui Jingfeng 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 34 ---
 1 file changed, 25 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index de8c9894967c..636d3f39ddcb 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1817,6 +1817,29 @@ static const struct of_device_id etnaviv_gpu_match[] = {
 };
 MODULE_DEVICE_TABLE(of, etnaviv_gpu_match);
 
+static int etnaviv_gpu_register_irq(struct etnaviv_gpu *gpu, int irq)
+{
+   struct device *dev = gpu->dev;
+   int err;
+
+   if (irq < 0) {
+   dev_err(dev, "failed to get irq: %d\n", irq);
+   return irq;
+   }
+
+   err = devm_request_irq(dev, irq, irq_handler, 0, dev_name(dev), gpu);
+   if (err) {
+   dev_err(dev, "failed to request IRQ %u: %d\n", irq, err);
+   return err;
+   }
+
+   gpu->irq = irq;
+
+   dev_info(dev, "IRQ handler registered, irq = %d\n", irq);
+
+   return 0;
+}
+
 static int etnaviv_gpu_platform_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -1837,16 +1860,9 @@ static int etnaviv_gpu_platform_probe(struct 
platform_device *pdev)
return PTR_ERR(gpu->mmio);
 
/* Get Interrupt: */
-   gpu->irq = platform_get_irq(pdev, 0);
-   if (gpu->irq < 0)
-   return gpu->irq;
-
-   err = devm_request_irq(>dev, gpu->irq, irq_handler, 0,
-  dev_name(gpu->dev), gpu);
-   if (err) {
-   dev_err(dev, "failed to request IRQ%u: %d\n", gpu->irq, err);
+   err = etnaviv_gpu_register_irq(gpu,  platform_get_irq(pdev, 0));
+   if (err)
return err;
-   }
 
/* Get Clocks: */
gpu->clk_reg = devm_clk_get_optional(>dev, "reg");
-- 
2.25.1

Re: [v2,18/50] drm/msm/dpu: split SM8550 catalog entry to the separate file

[Konrad Dybcio]

On 12.02.2023 00:12, Dmitry Baryshkov wrote:
> Signed-off-by: Dmitry Baryshkov 
> ---
>  .../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h| 178 +
>  .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 181 +-
>  2 files changed, 180 insertions(+), 179 deletions(-)
>  create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h 
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
> new file mode 100644
> index ..b44b9981431b
> --- /dev/null
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
> @@ -0,0 +1,178 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (c) 2022. Qualcomm Innovation Center, Inc. All rights reserved.
> + * Copyright (c) 2015-2018, 2020 The Linux Foundation. All rights reserved.
> + */
> +
> +#ifndef _DPU_9_0_SM8550_H
> +#define _DPU_9_0_SM8550_H
> +
> +static const struct dpu_caps sm8550_dpu_caps = {
> + .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
> + .max_mixer_blendstages = 0xb,
> + .qseed_type = DPU_SSPP_SCALER_QSEED4,
> + .smart_dma_rev = DPU_SSPP_SMART_DMA_V2, /* TODO: v2.5 */
That needs to be rebased on:

a4188f96d0a0 ("drm/msm/dpu: drop smart_dma_rev from dpu_caps")

But with that:

Reviewed-by: Konrad DYbcio 

Konrad
> + .has_src_split = true,
> + .has_dim_layer = true,
> + .has_idle_pc = true,
> + .has_3d_merge = true,
> + .max_linewidth = 5120,
> + .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
> +};
> +
> +static const struct dpu_ubwc_cfg sm8550_ubwc_cfg = {
> + .ubwc_version = DPU_HW_UBWC_VER_40,
> + .highest_bank_bit = 0x3, /* TODO: 2 for LP_DDR4 */
> +};
> +
> +static const struct dpu_mdp_cfg sm8550_mdp[] = {
> + {
> + .name = "top_0", .id = MDP_TOP,
> + .base = 0, .len = 0x494,
> + .features = BIT(DPU_MDP_PERIPH_0_REMOVED),
> + .clk_ctrls[DPU_CLK_CTRL_VIG0] = { .reg_off = 0x4330, .bit_off = 0 },
> + .clk_ctrls[DPU_CLK_CTRL_VIG1] = { .reg_off = 0x6330, .bit_off = 0 },
> + .clk_ctrls[DPU_CLK_CTRL_VIG2] = { .reg_off = 0x8330, .bit_off = 0 },
> + .clk_ctrls[DPU_CLK_CTRL_VIG3] = { .reg_off = 0xa330, .bit_off = 0 },
> + .clk_ctrls[DPU_CLK_CTRL_DMA0] = { .reg_off = 0x24330, .bit_off = 0 },
> + .clk_ctrls[DPU_CLK_CTRL_DMA1] = { .reg_off = 0x26330, .bit_off = 0 },
> + .clk_ctrls[DPU_CLK_CTRL_DMA2] = { .reg_off = 0x28330, .bit_off = 0 },
> + .clk_ctrls[DPU_CLK_CTRL_DMA3] = { .reg_off = 0x2a330, .bit_off = 0 },
> + .clk_ctrls[DPU_CLK_CTRL_DMA4] = { .reg_off = 0x2c330, .bit_off = 0 },
> + .clk_ctrls[DPU_CLK_CTRL_DMA5] = { .reg_off = 0x2e330, .bit_off = 0 },
> + .clk_ctrls[DPU_CLK_CTRL_REG_DMA] = { .reg_off = 0x2bc, .bit_off = 20 },
> + },
> +};
> +
> +static const struct dpu_ctl_cfg sm8550_ctl[] = {
> + {
> + .name = "ctl_0", .id = CTL_0,
> + .base = 0x15000, .len = 0x290,
> + .features = CTL_SM8550_MASK | BIT(DPU_CTL_SPLIT_DISPLAY),
> + .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
> + },
> + {
> + .name = "ctl_1", .id = CTL_1,
> + .base = 0x16000, .len = 0x290,
> + .features = CTL_SM8550_MASK | BIT(DPU_CTL_SPLIT_DISPLAY),
> + .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 10),
> + },
> + {
> + .name = "ctl_2", .id = CTL_2,
> + .base = 0x17000, .len = 0x290,
> + .features = CTL_SM8550_MASK,
> + .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 11),
> + },
> + {
> + .name = "ctl_3", .id = CTL_3,
> + .base = 0x18000, .len = 0x290,
> + .features = CTL_SM8550_MASK,
> + .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 12),
> + },
> + {
> + .name = "ctl_4", .id = CTL_4,
> + .base = 0x19000, .len = 0x290,
> + .features = CTL_SM8550_MASK,
> + .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 13),
> + },
> + {
> + .name = "ctl_5", .id = CTL_5,
> + .base = 0x1a000, .len = 0x290,
> + .features = CTL_SM8550_MASK,
> + .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 23),
> + },
> +};
> +
> +static const struct dpu_sspp_cfg sm8550_sspp[] = {
> + SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, 0x344, VIG_SC7180_MASK,
> + sm8550_vig_sblk_0, 0, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG0),
> + SSPP_BLK("sspp_1", SSPP_VIG1, 0x6000, 0x344, VIG_SC7180_MASK,
> + sm8550_vig_sblk_1, 4, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG1),
> + SSPP_BLK("sspp_2", SSPP_VIG2, 0x8000, 0x344, VIG_SC7180_MASK,
> + sm8550_vig_sblk_2, 8, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG2),
> + SSPP_BLK("sspp_3", SSPP_VIG3, 0xa000, 0x344, VIG_SC7180_MASK,
> + sm8550_vig_sblk_3, 12, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG3),
> + SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000, 0x344, DMA_SDM845_MASK,
> + sdm845_dma_sblk_0, 1, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA0),
> + SSPP_BLK("sspp_9", SSPP_DMA1, 0x26000, 0x344, DMA_SDM845_MASK,
> + sdm845_dma_sblk_1, 5, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA1),
> 

Re: [v2,17/50] drm/msm/dpu: move UBWC/memory configuration to separate struct

[Konrad Dybcio]

On 12.02.2023 00:12, Dmitry Baryshkov wrote:
> UBWC and highest bank settings differ slightly between different DPU
> units of the same generation, while the dpu_caps and dpu_mdp_cfg are
> much more stable. To ease configuration reuse move ubwc_swizzle and
> highest_bank_bit data to separate structure.
> 
> Signed-off-by: Dmitry Baryshkov 
> ---
I don't see anything wrong!

Reviewed-by: Konrad Dybcio 

Konrad
>  .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 112 +-
>  .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h|  19 ++-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c   |  18 +--
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h   |   4 +-
>  4 files changed, 107 insertions(+), 46 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> index c983413cc3c2..bd213b2913f5 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> @@ -303,7 +303,6 @@ static const struct dpu_caps msm8998_dpu_caps = {
>   .max_mixer_blendstages = 0x7,
>   .qseed_type = DPU_SSPP_SCALER_QSEED3,
>   .smart_dma_rev = DPU_SSPP_SMART_DMA_V1,
> - .ubwc_version = DPU_HW_UBWC_VER_10,
>   .has_src_split = true,
>   .has_dim_layer = true,
>   .has_idle_pc = true,
> @@ -329,7 +328,6 @@ static const struct dpu_caps sdm845_dpu_caps = {
>   .max_mixer_blendstages = 0xb,
>   .qseed_type = DPU_SSPP_SCALER_QSEED3,
>   .smart_dma_rev = DPU_SSPP_SMART_DMA_V2,
> - .ubwc_version = DPU_HW_UBWC_VER_20,
>   .has_src_split = true,
>   .has_dim_layer = true,
>   .has_idle_pc = true,
> @@ -345,7 +343,6 @@ static const struct dpu_caps sc7180_dpu_caps = {
>   .max_mixer_blendstages = 0x9,
>   .qseed_type = DPU_SSPP_SCALER_QSEED4,
>   .smart_dma_rev = DPU_SSPP_SMART_DMA_V2,
> - .ubwc_version = DPU_HW_UBWC_VER_20,
>   .has_dim_layer = true,
>   .has_idle_pc = true,
>   .max_linewidth = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
> @@ -357,7 +354,6 @@ static const struct dpu_caps sm6115_dpu_caps = {
>   .max_mixer_blendstages = 0x4,
>   .qseed_type = DPU_SSPP_SCALER_QSEED4,
>   .smart_dma_rev = DPU_SSPP_SMART_DMA_V2, /* TODO: v2.5 */
> - .ubwc_version = DPU_HW_UBWC_VER_10,
>   .has_dim_layer = true,
>   .has_idle_pc = true,
>   .max_linewidth = 2160,
> @@ -369,7 +365,6 @@ static const struct dpu_caps sm8150_dpu_caps = {
>   .max_mixer_blendstages = 0xb,
>   .qseed_type = DPU_SSPP_SCALER_QSEED3,
>   .smart_dma_rev = DPU_SSPP_SMART_DMA_V2, /* TODO: v2.5 */
> - .ubwc_version = DPU_HW_UBWC_VER_30,
>   .has_src_split = true,
>   .has_dim_layer = true,
>   .has_idle_pc = true,
> @@ -385,7 +380,6 @@ static const struct dpu_caps sc8180x_dpu_caps = {
>   .max_mixer_blendstages = 0xb,
>   .qseed_type = DPU_SSPP_SCALER_QSEED3,
>   .smart_dma_rev = DPU_SSPP_SMART_DMA_V2, /* TODO: v2.5 */
> - .ubwc_version = DPU_HW_UBWC_VER_30,
>   .has_src_split = true,
>   .has_dim_layer = true,
>   .has_idle_pc = true,
> @@ -401,7 +395,6 @@ static const struct dpu_caps sc8280xp_dpu_caps = {
>   .max_mixer_blendstages = 11,
>   .qseed_type = DPU_SSPP_SCALER_QSEED4,
>   .smart_dma_rev = DPU_SSPP_SMART_DMA_V2, /* TODO: v2.5 */
> - .ubwc_version = DPU_HW_UBWC_VER_40,
>   .has_src_split = true,
>   .has_dim_layer = true,
>   .has_idle_pc = true,
> @@ -415,7 +408,6 @@ static const struct dpu_caps sm8250_dpu_caps = {
>   .max_mixer_blendstages = 0xb,
>   .qseed_type = DPU_SSPP_SCALER_QSEED4,
>   .smart_dma_rev = DPU_SSPP_SMART_DMA_V2, /* TODO: v2.5 */
> - .ubwc_version = DPU_HW_UBWC_VER_40,
>   .has_src_split = true,
>   .has_dim_layer = true,
>   .has_idle_pc = true,
> @@ -429,7 +421,6 @@ static const struct dpu_caps sm8350_dpu_caps = {
>   .max_mixer_blendstages = 0xb,
>   .qseed_type = DPU_SSPP_SCALER_QSEED4,
>   .smart_dma_rev = DPU_SSPP_SMART_DMA_V2, /* TODO: v2.5 */
> - .ubwc_version = DPU_HW_UBWC_VER_40,
>   .has_src_split = true,
>   .has_dim_layer = true,
>   .has_idle_pc = true,
> @@ -443,7 +434,6 @@ static const struct dpu_caps sm8450_dpu_caps = {
>   .max_mixer_blendstages = 0xb,
>   .qseed_type = DPU_SSPP_SCALER_QSEED4,
>   .smart_dma_rev = DPU_SSPP_SMART_DMA_V2, /* TODO: v2.5 */
> - .ubwc_version = DPU_HW_UBWC_VER_40,
>   .has_src_split = true,
>   .has_dim_layer = true,
>   .has_idle_pc = true,
> @@ -457,7 +447,6 @@ static const struct dpu_caps sm8550_dpu_caps = {
>   .max_mixer_blendstages = 0xb,
>   .qseed_type = DPU_SSPP_SCALER_QSEED4,
>   .smart_dma_rev = DPU_SSPP_SMART_DMA_V2, /* TODO: v2.5 */
> - .ubwc_version = DPU_HW_UBWC_VER_40,
>   .has_src_split = true,
>   .has_dim_layer = true,
>   .has_idle_pc = true,
> @@ -471,19 +460,86 @@ static const struct dpu_caps sc7280_dpu_caps = {
>   .max_mixer_blendstages = 0x7,
>   

Re: [v2,16/50] drm/msm/dpu: mark remaining pp data as const

[Konrad Dybcio]

On 12.02.2023 00:12, Dmitry Baryshkov wrote:
> Fix several leftover _pp strutures and mark them as const, making all hw
> catalog fit into the rodata section.
> 
> Signed-off-by: Dmitry Baryshkov 
> ---
Reviewed-by: Konrad Dybcio 

Konrad
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> index 54d706dfdbec..c983413cc3c2 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> @@ -1652,12 +1652,12 @@ static const struct dpu_pingpong_cfg sdm845_pp[] = {
>   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 15)),
>  };
>  
> -static struct dpu_pingpong_cfg sc7180_pp[] = {
> +static const struct dpu_pingpong_cfg sc7180_pp[] = {
>   PP_BLK_TE("pingpong_0", PINGPONG_0, 0x7, 0, sdm845_pp_sblk_te, -1, 
> -1),
>   PP_BLK_TE("pingpong_1", PINGPONG_1, 0x70800, 0, sdm845_pp_sblk_te, -1, 
> -1),
>  };
>  
> -static struct dpu_pingpong_cfg sc8280xp_pp[] = {
> +static const struct dpu_pingpong_cfg sc8280xp_pp[] = {
>   PP_BLK_TE("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0, 
> sdm845_pp_sblk_te,
> DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8), -1),
>   PP_BLK_TE("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0, 
> sdm845_pp_sblk_te,
> @@ -1721,7 +1721,7 @@ static const struct dpu_pingpong_cfg sc7280_pp[] = {
>   PP_BLK("pingpong_3", PINGPONG_3, 0x6c000, 0, sc7280_pp_sblk, -1, -1),
>  };
>  
> -static struct dpu_pingpong_cfg qcm2290_pp[] = {
> +static const struct dpu_pingpong_cfg qcm2290_pp[] = {
>   PP_BLK("pingpong_0", PINGPONG_0, 0x7, 0, sdm845_pp_sblk,
>   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
>   DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 12)),

Re: [PATCH v3 0/7] drm/msm: add support for SM8550

[Dmitry Baryshkov]

On 29/03/2023 22:52, Rob Herring wrote:

On Tue, Mar 28, 2023 at 5:38 PM Dmitry Baryshkov
 wrote:



On Mon, 09 Jan 2023 11:15:17 +0100, Neil Armstrong wrote:

This adds support for the MDSS/DPU/DSI on the Qualcomm SM8550 platform.

This patchset is based on the SM8450 display support serie at [1].

In order to work, the following patchsets are required:
- PM8550 LDO fix at [2]
- DISPCC driver at [3]

[...]


Applied, thanks!

[2/7] dt-bindings: display/msm: document DPU on SM8550
   https://gitlab.freedesktop.org/lumag/msm/-/commit/4557e40338d2
[3/7] dt-bindings: display/msm: document MDSS on SM8550
   https://gitlab.freedesktop.org/lumag/msm/-/commit/0e4205eb8663


And now failing on linux-next just as my bot reported:

Documentation/devicetree/bindings/display/msm/qcom,sm8550-dpu.example.dts:24:18:
fatal error: dt-bindings/interconnect/qcom,sm8550.h: No such file or
directory
24 | #include 
   |  ^~~~
compilation terminated.
make[1]: *** [scripts/Makefile.lib:419:
Documentation/devicetree/bindings/display/msm/qcom,sm8550-dpu.example.dtb]
Error 1
Documentation/devicetree/bindings/display/msm/qcom,sm8550-mdss.example.dts:25:18:
fatal error: dt-bindings/interconnect/qcom,sm8550.h: No such file or
directory
25 | #include 
   |  ^~~~
compilation terminated.

Please fix. And quickly please. Fixes in the DRM tree seem to take
forever to get in...


I pushed the fix, so it will arrive in linux-next tomorrow or the day 
after tomorrow. Please excuse me for breaking it again. I checked that 
the patches were merged, but didn't notice that the header name was 
changed in the process. Mea culpa.


--
With best wishes
Dmitry

[PATCH v2] dt-bindings: display: seiko, 43wvf1g: Change the maintainer's contact

[Fabio Estevam]

From: Fabio Estevam 

Marco's NXP email is no longer valid.

Marco told me offline that he has no interest to be listed as the
maintainer contact for this binding, so add my contact.

Signed-off-by: Fabio Estevam 
---
Changes since v1:
- Use my contact instead of Marco's personal email.

 .../devicetree/bindings/display/panel/seiko,43wvf1g.yaml| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.yaml 
b/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.yaml
index a5426586b473..1df3cbb51ff9 100644
--- a/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.yaml
+++ b/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
 title: Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480) TFT with Touch-Panel
 
 maintainers:
-  - Marco Franchi 
+  - Fabio Estevam 
 
 allOf:
   - $ref: panel-common.yaml#
-- 
2.34.1

Re: [PATCH v2 43/65] ASoC: tlv320aic32x4: Add a determine_rate hook

[Stephen Boyd]

Quoting Maxime Ripard (2023-03-29 12:50:49)
> On Wed, Mar 22, 2023 at 04:31:04PM -0700, Stephen Boyd wrote:
> 
> > The clk_set_parent() path is valid for those cases. Probably nobody
> > cares about determine_rate because they don't set rates on these clks.
> > Some drivers even explicitly left out determine_rate()/round_rate()
> > because they didn't want to have some other clk round up to the mux
> > and change the parent.
> > 
> > Eventually we want drivers to migrate to determine_rate op so we can get
> > rid of the round_rate op and save a pointer (we're so greedy). It's been
> > 10 years though, and that hasn't been done. Sigh! I can see value in
> > this series from the angle of migrating, but adding a determine_rate op
> > when there isn't a round_rate op makes it hard to reason about. What if
> > something copies the clk_ops or sets a different flag? Now we've just
> > added parent changing support to clk_set_rate(). What if the clk has
> > CLK_SET_RATE_PARENT flag set? Now we're going to ask the parent clk to
> > change rate. Fun bugs.
> > 
> > TL;DR: If the set_parent op exists but determine_rate/round_rate doesn't
> > then the clk is a mux that doesn't want to support clk_set_rate(). Make
> > a new mux function that's the contents of the CLK_SET_RATE_NO_REPARENT
> > branch in clk_mux_determine_rate_flags() and call that directly from the
> > clk_ops so it is clear what's happening,
> > clk_hw_mux_same_parent_determine_rate() or something with a better name.
> > Otherwise migrate the explicit determine_rate op to this new function
> > and don't set the flag.
> > 
> > It may be possible to entirely remove the CLK_SET_RATE_NO_REPARENT flag
> > with this design, if the determine_rate clk_op can call the inner
> > wrapper function instead of __clk_mux_determine_rate*() (those
> > underscores are awful, we should just prefix them with clk_hw_mux_*()
> > and live happier). That should be another patch series.
> 
> Sorry but it's not really clear to me what you expect in the v2 of this
> series (if you even expect one). It looks that you don't like the
> assignment-if-missing idea Mark suggested, but should I just
> rebase/resend or did you expect something else?
> 

Yes, we want explicit code. Just rebase & resend. Don't add a
determine_rate if there isn't a round_rate. Don't add more users of
CLK_SET_RATE_NO_REPARENT. Instead, make an explicit determine_rate
function for that. If you want to work on the removal of
CLK_SET_RATE_NO_REPARENT go for it. Otherwise I'll take care of it after
this series.

Re: [PATCH v2 14/50] drm/msm/dpu: Allow variable SSPP/INTF_BLK size

[Dmitry Baryshkov]

On 13/02/2023 13:18, Dmitry Baryshkov wrote:

On 13/02/2023 13:01, Konrad Dybcio wrote:



On 12.02.2023 00:12, Dmitry Baryshkov wrote:

From: Konrad Dybcio 

These blocks are of variable length on different SoCs. Set the
correct values where I was able to retrieve it from downstream
DTs and leave the old defaults (0x1c8 for sspp and 0x280 for
intf) otherwise.

Signed-off-by: Konrad Dybcio 
[DB: fixed some of lengths]
Signed-off-by: Dmitry Baryshkov 
---

Oh you fixed it quicker than I could respond!


Yes, I wanted to include it into this patchset, so I had to fix it.



Still, I think the 8280 sspp size should not be
2x the norm..


Let's doublecheck this with somebody having access to docs.


The additional research shows that all of us were wrong here. I'll 
update it to 0x2ac for the next revision of the patchset.


--
With best wishes
Dmitry

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

[Maxime Ripard]

On Tue, Mar 28, 2023 at 01:48:33AM +0200, Roman Beranek wrote:
> On Mon Mar 27, 2023 at 10:20 PM CEST, Maxime Ripard wrote:
> >
> > On Sat, Mar 25, 2023 at 12:40:04PM +0100, Frank Oltmanns wrote:
> > > Claiming to set the divider to a different value (bpp / lanes) than what 
> > > we’re actually using in
> > > the end (SUN6I_DSIO_TCON_DIV) is somehow bugging me. I feel like the 
> > > proposal that I submitted is
> > > more direct: 
> > > 
> >
> > Yeah, this patch looks better to me too: it's simpler, more 
> > straightforward. If Roman can confirm it
> > works with his testing, I'll be happy to merge it.
> >
> 
> So I've just found out that my understanding of what sun4i_dotclock is
> was wrong the whole time. I treated it as a virtual clock representing
> the true CRTC pixel clock and only coincidentally also matching what
> A64 Reference Manual labels as TCON0 data clock (a coincidence to which
> DSI is an exception).
> 
> Now that I finally see dotclock as 'what could dclk be an abbreviation
> to', I to agree that it's not only straightforward but also correct to
> keep the divider at 4 and adjust the rate as is done it the patch Frank
> submitted.
> 
> In order to preserve semantic correctness however, I propose to preface
> the change with a patch that renames sun4i_dotclock and tcon-pixel-clock
> such that dot/pixel is replaced with d/data. What do you think?

I don't think it's exposed to the userspace in any way so it makes sense to me

Maxime


signature.asc
Description: PGP signature

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

[Maxime Ripard]

Hi,

On Tue, Mar 28, 2023 at 09:28:19PM +0200, Frank Oltmanns wrote:
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -819,6 +819,34 @@ static void sun6i_dsi_encoder_disable(struct drm_encoder 
> *encoder)
>   regulator_disable(dsi->regulator);
>  }
> 
> +static bool sun6i_dsi_encoder_mode_fixup(
> +struct drm_encoder *encoder,
> +const struct drm_display_mode *mode,
> +struct drm_display_mode *adjusted_mode)

So, mode_fixup is kind of deprecated in favour of atomic_check

> +{
> + if (encoder->encoder_type == DRM_MODE_ENCODER_DSI) {
> + /*
> +  * For DSI the PLL rate has to respect the bits per pixel and
> +  * number of lanes.
> +  *
> +  * According to the BSP code:
> +  * PLL rate = DOTCLOCK * bpp / lanes
> +  *
> +  * Therefore, the clock has to be adjusted in order to set the
> +  * correct PLL rate when actually setting the clock.
> +  */
> + struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
> + struct mipi_dsi_device *device = dsi->device;
> + u8 bpp = mipi_dsi_pixel_format_to_bpp(device->format);
> + u8 lanes = device->lanes;
> +
> + adjusted_mode->crtc_clock = mode->crtc_clock
> +  * bpp / (lanes * SUN6I_DSI_TCON_DIV);

And that's visible to the userspace, so it's not where we should store
that value. I guess the best way to do something similar would be to
store it into crtc_state, and then reuse it there. But it starts to make
a lot of rather complicated code compared to your previous patch.

Maxime


signature.asc
Description: PGP signature

Re: [PATCH v3 0/7] drm/msm: add support for SM8550

[Rob Herring]

On Tue, Mar 28, 2023 at 5:38 PM Dmitry Baryshkov
 wrote:
>
>
> On Mon, 09 Jan 2023 11:15:17 +0100, Neil Armstrong wrote:
> > This adds support for the MDSS/DPU/DSI on the Qualcomm SM8550 platform.
> >
> > This patchset is based on the SM8450 display support serie at [1].
> >
> > In order to work, the following patchsets are required:
> > - PM8550 LDO fix at [2]
> > - DISPCC driver at [3]
> >
> > [...]
>
> Applied, thanks!
>
> [2/7] dt-bindings: display/msm: document DPU on SM8550
>   https://gitlab.freedesktop.org/lumag/msm/-/commit/4557e40338d2
> [3/7] dt-bindings: display/msm: document MDSS on SM8550
>   https://gitlab.freedesktop.org/lumag/msm/-/commit/0e4205eb8663

And now failing on linux-next just as my bot reported:

Documentation/devicetree/bindings/display/msm/qcom,sm8550-dpu.example.dts:24:18:
fatal error: dt-bindings/interconnect/qcom,sm8550.h: No such file or
directory
   24 | #include 
  |  ^~~~
compilation terminated.
make[1]: *** [scripts/Makefile.lib:419:
Documentation/devicetree/bindings/display/msm/qcom,sm8550-dpu.example.dtb]
Error 1
Documentation/devicetree/bindings/display/msm/qcom,sm8550-mdss.example.dts:25:18:
fatal error: dt-bindings/interconnect/qcom,sm8550.h: No such file or
directory
   25 | #include 
  |  ^~~~
compilation terminated.

Please fix. And quickly please. Fixes in the DRM tree seem to take
forever to get in...

Rob

Re: [PATCH v2 43/65] ASoC: tlv320aic32x4: Add a determine_rate hook

[Maxime Ripard]

Hi Stephen,

On Wed, Mar 22, 2023 at 04:31:04PM -0700, Stephen Boyd wrote:
> > It's also replacing one implicit behavior by another. The point of this
> > series was to raise awareness on that particular point, so I'm not sure
> > it actually fixes things. We'll see what Stephen thinks about it.
> > 
> 
> Right. A decade ago (!) when determine_rate() was introduced we
> introduced CLK_SET_RATE_NO_REPARENT and set it on each mux user (see
> commit  819c1de344c5 ("clk: add CLK_SET_RATE_NO_REPARENT flag")). This
> way driver behavior wouldn't change and the status quo would be
> maintained, i.e. that clk_set_rate() on a mux wouldn't change parents.
> We didn't enforce that determine_rate exists if the set_parent() op
> existed at the same time though. Probably an oversight.
> 
> Most of the replies to this series have been "DT is setting the parent",
> which makes me believe that there are 'assigned-clock-parents' being
> used.

Yes, that's my understanding as well.

> The clk_set_parent() path is valid for those cases. Probably nobody
> cares about determine_rate because they don't set rates on these clks.
> Some drivers even explicitly left out determine_rate()/round_rate()
> because they didn't want to have some other clk round up to the mux
> and change the parent.
> 
> Eventually we want drivers to migrate to determine_rate op so we can get
> rid of the round_rate op and save a pointer (we're so greedy). It's been
> 10 years though, and that hasn't been done. Sigh! I can see value in
> this series from the angle of migrating, but adding a determine_rate op
> when there isn't a round_rate op makes it hard to reason about. What if
> something copies the clk_ops or sets a different flag? Now we've just
> added parent changing support to clk_set_rate(). What if the clk has
> CLK_SET_RATE_PARENT flag set? Now we're going to ask the parent clk to
> change rate. Fun bugs.
> 
> TL;DR: If the set_parent op exists but determine_rate/round_rate doesn't
> then the clk is a mux that doesn't want to support clk_set_rate(). Make
> a new mux function that's the contents of the CLK_SET_RATE_NO_REPARENT
> branch in clk_mux_determine_rate_flags() and call that directly from the
> clk_ops so it is clear what's happening,
> clk_hw_mux_same_parent_determine_rate() or something with a better name.
> Otherwise migrate the explicit determine_rate op to this new function
> and don't set the flag.
> 
> It may be possible to entirely remove the CLK_SET_RATE_NO_REPARENT flag
> with this design, if the determine_rate clk_op can call the inner
> wrapper function instead of __clk_mux_determine_rate*() (those
> underscores are awful, we should just prefix them with clk_hw_mux_*()
> and live happier). That should be another patch series.

Sorry but it's not really clear to me what you expect in the v2 of this
series (if you even expect one). It looks that you don't like the
assignment-if-missing idea Mark suggested, but should I just
rebase/resend or did you expect something else?

Maxime


signature.asc
Description: PGP signature

Re: [v2,15/50] drm/msm/dpu: constify DSC data structures

[Konrad Dybcio]

On 12.02.2023 00:12, Dmitry Baryshkov wrote:
> DSC hw catalog data is not supposed to be changed, so mark it as const
> data.
> 
> Signed-off-by: Dmitry Baryshkov 
> ---
Reviewed-by: Konrad Dybcio 

Konrad
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 4 ++--
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 4 ++--
>  3 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> index 2d53ed92de85..54d706dfdbec 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> @@ -1829,14 +1829,14 @@ static const struct dpu_merge_3d_cfg 
> sm8550_merge_3d[] = {
>   .features = _features, \
>   }
>  
> -static struct dpu_dsc_cfg sdm845_dsc[] = {
> +static const struct dpu_dsc_cfg sdm845_dsc[] = {
>   DSC_BLK("dsc_0", DSC_0, 0x8, 0),
>   DSC_BLK("dsc_1", DSC_1, 0x80400, 0),
>   DSC_BLK("dsc_2", DSC_2, 0x80800, 0),
>   DSC_BLK("dsc_3", DSC_3, 0x80c00, 0),
>  };
>  
> -static struct dpu_dsc_cfg sm8150_dsc[] = {
> +static const struct dpu_dsc_cfg sm8150_dsc[] = {
>   DSC_BLK("dsc_0", DSC_0, 0x8, BIT(DPU_DSC_OUTPUT_CTRL)),
>   DSC_BLK("dsc_1", DSC_1, 0x80400, BIT(DPU_DSC_OUTPUT_CTRL)),
>   DSC_BLK("dsc_2", DSC_2, 0x80800, BIT(DPU_DSC_OUTPUT_CTRL)),
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> index e6590302b3bf..a56581b34ddf 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> @@ -867,7 +867,7 @@ struct dpu_mdss_cfg {
>   const struct dpu_merge_3d_cfg *merge_3d;
>  
>   u32 dsc_count;
> - struct dpu_dsc_cfg *dsc;
> + const struct dpu_dsc_cfg *dsc;
>  
>   u32 intf_count;
>   const struct dpu_intf_cfg *intf;
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
> index 619926da1441..4e1396575e6a 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
> @@ -175,7 +175,7 @@ static void dpu_hw_dsc_bind_pingpong_blk(
>   DPU_REG_WRITE(c, dsc_ctl_offset, mux_cfg);
>  }
>  
> -static struct dpu_dsc_cfg *_dsc_offset(enum dpu_dsc dsc,
> +static const struct dpu_dsc_cfg *_dsc_offset(enum dpu_dsc dsc,
>  const struct dpu_mdss_cfg *m,
>  void __iomem *addr,
>  struct dpu_hw_blk_reg_map *b)
> @@ -207,7 +207,7 @@ struct dpu_hw_dsc *dpu_hw_dsc_init(enum dpu_dsc idx, void 
> __iomem *addr,
>  const struct dpu_mdss_cfg *m)
>  {
>   struct dpu_hw_dsc *c;
> - struct dpu_dsc_cfg *cfg;
> + const struct dpu_dsc_cfg *cfg;
>  
>   c = kzalloc(sizeof(*c), GFP_KERNEL);
>   if (!c)

Re: [PATCH] drm/msm/adreno: adreno_gpu: Use suspend() instead of idle() on load error

[Dmitry Baryshkov]

On Wed, 29 Mar 2023 at 18:48, Konrad Dybcio  wrote:
>
>
>
> On 29.03.2023 16:37, Johan Hovold wrote:
> > On Wed, Mar 29, 2023 at 04:04:44PM +0200, Konrad Dybcio wrote:
> >> If we fail to initialize the GPU for whatever reason (say we don't
> >> embed the GPU firmware files in the initrd), the error path involves
> >> pm_runtime_put_sync() which then calls idle() instead of suspend().
> >>
> >> This is suboptimal, as it means that we're not going through the
> >> clean shutdown sequence. With at least A619_holi, this makes the GPU
> >> not wake up until it goes through at least one more start-fail-stop
> >> cycle. Fix that by using pm_runtime_put_sync_suspend to force a clean
> >> shutdown.
> >
> > This does not sound right. If pm_runtime_put_sync() fails to suspend the
> > device when the usage count drops to zero, then you have a bug somewhere
> > else.
> I was surprised to see that it was not called as well, but I wasn't able
> to track it down before..

Could you please check that it's autosuspend who kicks in? In other
words, if we disable autosuspend, the pm_runtime_put_sync is enough()?

That would probably mean that we lack some kind of reset in the hw_init path.

On the other hand, I do not know how the device will react to the
error-in-the-middle state. Modems for example, can enter the state
where you can not properly turn it off once it starts the boot
process.

And if we remember the efforts that Akhil has put into making sure
that the GPU is properly reset in case of an _error_, it might be
nearly impossible to shut it down in a proper way.

Thus said, I think that unless there is an obvious way to restart the
init process, Korad's pm_runtime_put_sync_suspend() looks like a
correct fix to me.

> > Also since commit 2c087a336676 ("drm/msm/adreno: Load the firmware
> > before bringing up the hardware") the firmware is loaded before even
> > hitting these paths so the above description does not sound right in
> > that respect either (or is missing some details).
> ..but I did some more digging and I found that the precise "firmware"
> that fails is the ZAP blob, which is not checked like SQE in the
> commit you mentioned!
>
> Now I don't think that we can easily check for it as-is since
> zap_shader_load_mdt() does the entire find-load-authenticate
> dance which is required with secure assets, but it's obviously
> possible to rip out the find-load part of that and go on from
> there.

Yes, I think we should load all firmware early. ZAP shader is a bit
unique since the DT can override the name, but it might be nice to
check for its presence earlier.

At the same time it probably should not stop us from fixing the idle()
vs suspend() bug.

>
> Do you think that would be a better solution?
>
> Konrad
>
> >
> >> Test cases:
> >> 1. firmware baked into kernel
> >> 2. error loading fw in initrd -> load from rootfs at DE start
> >>
> >> Both succeed on A619_holi (SM6375) and A630 (SDM845).
> >>
> >> Fixes: 0d997f95b70f ("drm/msm/adreno: fix runtime PM imbalance at gpu 
> >> load")
> >> Signed-off-by: Konrad Dybcio 
> >> ---
> >>  drivers/gpu/drm/msm/adreno/adreno_device.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
> >> b/drivers/gpu/drm/msm/adreno/adreno_device.c
> >> index f61896629be6..59f3302e8167 100644
> >> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> >> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> >> @@ -477,7 +477,7 @@ struct msm_gpu *adreno_load_gpu(struct drm_device *dev)
> >>  return gpu;
> >>
> >>  err_put_rpm:
> >> -pm_runtime_put_sync(>dev);
> >> +pm_runtime_put_sync_suspend(>dev);
> >>  err_disable_rpm:
> >>  pm_runtime_disable(>dev);
> >
> > Johan



-- 
With best wishes
Dmitry

Re: [PATCH 1/6] dt-bindings: display: panel-simple: merge Innolux p120zdg-bf1

[Rob Herring]

On Sun, Mar 26, 2023 at 05:54:20PM +0200, Krzysztof Kozlowski wrote:
> There is nothing special in Innolux p120zdg-bf1 panel, so just like
> other Innolux panels it can be made part of panel-simple.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  .../display/panel/innolux,p120zdg-bf1.yaml| 43 ---
>  .../bindings/display/panel/panel-simple.yaml  |  2 +
>  2 files changed, 2 insertions(+), 43 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.yaml

Series applied to drm-misc-next.

Rob

Re: [PATCH v2 2/2] drm/amd/display: Mark function 'optc3_wait_drr_doublebuffer_pending_clear' as static

[Hamza Mahfooz]

On 3/29/23 14:05, Caio Novais wrote:

Compiling AMD GPU drivers displays a warning:

drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_optc.c:294:6: warning: no 
previous prototype for ‘optc3_wait_drr_doublebuffer_pending_clear’ 
[-Wmissing-prototypes]

Get rid of it by marking the function as static

Signed-off-by: Caio Novais 


Applied, thanks!


---
  drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.c 
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.c
index 08b92715e2e6..c95f000b63b2 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.c
@@ -291,7 +291,7 @@ static void optc3_set_timing_double_buffer(struct 
timing_generator *optc, bool e
   OTG_DRR_TIMING_DBUF_UPDATE_MODE, mode);
  }
  
-void optc3_wait_drr_doublebuffer_pending_clear(struct timing_generator *optc)

+static void optc3_wait_drr_doublebuffer_pending_clear(struct timing_generator 
*optc)
  {
struct optc *optc1 = DCN10TG_FROM_TG(optc);
  

--
Hamza

Re: [PATCH] drm/ttm: set TTM allocated pages as reserved

[Sean Christopherson]

On Wed, Mar 29, 2023, Christian K�nig wrote:
> Am 29.03.23 um 19:39 schrieb Sean Christopherson:
> > On Wed, Mar 29, 2023, Christian K�nig wrote:
> > > Am 29.03.23 um 19:22 schrieb Sean Christopherson:
> > > > +David
> > > > 
> > > > On Wed, Mar 29, 2023, Paolo Bonzini wrote:
> > > > > On 3/29/23 18:43, Christian K�nig wrote:
> > > > > > > 3) other uses of kmap() must switch to MMU-notifier protection.
> > > > > > I would rather suggest to return the page additionally to the pfn 
> > > > > > from
> > > > > > hva_to_pfn() when the function was able to grab a reference to it.
> > > > > > 
> > > > > > When the page is then not available you can't call kmap() on that 
> > > > > > either.
> > > > > > 
> > > > > > > If the DRM people are okay with SetPageReserved() as a temporary
> > > > > > > hack, we can change or remove the WARN in 
> > > > > > > kvm_is_zone_device_page(),
> > > > > > > since that is what you are referring to in the commit message.
> > > > > > Adding Daniel for additional comments on this, but essentially we 
> > > > > > have
> > > > > > changed quite some infrastructure to make sure that everybody uses
> > > > > > VM_PFNMAP to prevent stuff like this from happening.
> > > > > > 
> > > > > > I would really prefer a proper solution in KVM instead.
> > > > > Hmm... Now that I think about it that would be
> > > > > 
> > > > > https://lore.kernel.org/kvm/yc4h+dgfk83ba...@google.com/t/
> > > > > 
> > > > > Time to resurrect that work.
> > > > Ya.  I had previously asked David to first eliminated the usage that 
> > > > isn't
> > > > protected by mmu_notifiers, but after seeing the resulting complexity, 
> > > > I had a
> > > > change of heart[2].  Can you weigh in on the latter thread, 
> > > > specifically my
> > > > proposal of using a module param to let the admin opt-in to "unsafe" 
> > > > kmap usage.
> > > I don't think that this is something an admin should be able to decide.
> > Why not?  Assuming the admin has CAP_SYS_ADMIN, they can reboot the host in 
> > a
> > myriad of ways.  The idea with the KVM module param is to allow curated 
> > setups
> > where the userspace VMM is trusted to a large extent, e.g. AWS' Nitro, to 
> > opt-in
> > to the unsafe behavior.  I.e. by enabling the flag, the admin is 
> > acknowledging
> > that bad things can happen if untrusted/compromised userspace gets ahold of
> > /dev/kvm.
> 
> Well exactly that's the point, you don't need untrusted/compromised
> userspace the system could just go spontaneously into nirvana during normal
> operation.

The proposal is that the module param is off by default, and the expectation is
that it would be turned on only by very specific setups.  I would not object to
making it even more difficult to enable, burying it behind a Kconfig, but IMO
that is unnecessary.

> This would result in very very hard to debug problems since the issues only
> happen rather rarely.
> 
> On the other hand why do you need the kmap() in the first place?

The Nitro setup manages guest memory in userspace, and hides that memory from
the kernel, e.g. to avoid struct page overhead..  To enable KVM to access guest
memory in select flows, e.g. for paravirtualization, without taking on too much
complexity, KVM supports kmap() of that memory.

For some uses, e.g. nested virtualization, switching to uaccess might be 
feasible,
but the paravirt stuff, especially Xen support, would likely be insanely complex
to do without kmap().

Re: [PATCH v3 0/5] Add generic-display-mux driver and bindings

[Jagan Teki]

On Sat, Feb 18, 2023 at 4:47 PM Pin-yen Lin  wrote:
>
> This series is developed for and tested on MT8173 board, and the layout is:
>
>   /-- anx7688
> -- MT8173 HDMI bridge -- GPIO mux
>   \-- native HDMI

What is the part number of this GPIO mux? Does mux gpio interrupt
based and able to switch output HDMI and DP. If so, how this gpio
interrupt is different than the HPD in native HDMI? I mean does HPD
have any detection bottlenecks with mux gpio interrupt?

I do have GPIO Mux that input DSI and two outputs DMD/HDMI Input and
HDMI Out. 2x1 with 1x2 mux.

I'm thinking having a generic mux to select the specific out number of
outputs with associated interface outputs can be a viable solution to
address all use cases here.

Thanks,
Jagan.

[PATCH v2 2/2] drm/amd/display: Mark function 'optc3_wait_drr_doublebuffer_pending_clear' as static

[Caio Novais]

Compiling AMD GPU drivers displays a warning:

drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_optc.c:294:6: warning: no 
previous prototype for ‘optc3_wait_drr_doublebuffer_pending_clear’ 
[-Wmissing-prototypes]

Get rid of it by marking the function as static

Signed-off-by: Caio Novais 
---
 drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.c 
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.c
index 08b92715e2e6..c95f000b63b2 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.c
@@ -291,7 +291,7 @@ static void optc3_set_timing_double_buffer(struct 
timing_generator *optc, bool e
   OTG_DRR_TIMING_DBUF_UPDATE_MODE, mode);
 }
 
-void optc3_wait_drr_doublebuffer_pending_clear(struct timing_generator *optc)
+static void optc3_wait_drr_doublebuffer_pending_clear(struct timing_generator 
*optc)
 {
struct optc *optc1 = DCN10TG_FROM_TG(optc);
 
-- 
2.40.0

[PATCH v2 1/2] drm/amd/display: Remove unused variable 'scl_enable'

[Caio Novais]

Compiling AMD GPU drivers displays a warning:

drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/display_rq_dlg_calc_314.c: 
In function ‘dml_rq_dlg_get_dlg_params’:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/display_rq_dlg_calc_314.c:991:14:
 warning: variable ‘scl_enable’ set but not used [-Wunused-but-set-variable]

Get rid of it by removing the variable 'scl_enable'.

Signed-off-by: Caio Novais 
---
 .../gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c | 2 --
 1 file changed, 2 deletions(-)

diff --git 
a/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c 
b/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c
index d1c2693a2e28..ea4eb66066c4 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c
@@ -988,7 +988,6 @@ static void dml_rq_dlg_get_dlg_params(
double hratio_c;
double vratio_l;
double vratio_c;
-   bool scl_enable;
 
unsigned int swath_width_ub_l;
unsigned int dpte_groups_per_row_ub_l;
@@ -1117,7 +1116,6 @@ static void dml_rq_dlg_get_dlg_params(
hratio_c = scl->hscl_ratio_c;
vratio_l = scl->vscl_ratio;
vratio_c = scl->vscl_ratio_c;
-   scl_enable = scl->scl_enable;
 
swath_width_ub_l = rq_dlg_param->rq_l.swath_width_ub;
dpte_groups_per_row_ub_l = rq_dlg_param->rq_l.dpte_groups_per_row_ub;
-- 
2.40.0

[PATCH v2 0/2] drm/amd/display: Remove a unused variable and mark a function as static

[Caio Novais]

This patchset removes one unused variable and mark a function as static.

Caio Novais (2):
  drm/amd/display: Remove unused variable 'scl_enable'
  drm/amd/display: Mark function
'optc3_wait_drr_doublebuffer_pending_clear' as static

 drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.c   | 2 +-
 .../gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c | 2 --
 2 files changed, 1 insertion(+), 3 deletions(-)

-- 
2.40.0

Re: [PATCH] drm/ttm: set TTM allocated pages as reserved

[Christian König]

Am 29.03.23 um 19:39 schrieb Sean Christopherson:

On Wed, Mar 29, 2023, Christian K�nig wrote:

Am 29.03.23 um 19:22 schrieb Sean Christopherson:

+David

On Wed, Mar 29, 2023, Paolo Bonzini wrote:

On 3/29/23 18:43, Christian K�nig wrote:

3) other uses of kmap() must switch to MMU-notifier protection.

I would rather suggest to return the page additionally to the pfn from
hva_to_pfn() when the function was able to grab a reference to it.

When the page is then not available you can't call kmap() on that either.


If the DRM people are okay with SetPageReserved() as a temporary
hack, we can change or remove the WARN in kvm_is_zone_device_page(),
since that is what you are referring to in the commit message.

Adding Daniel for additional comments on this, but essentially we have
changed quite some infrastructure to make sure that everybody uses
VM_PFNMAP to prevent stuff like this from happening.

I would really prefer a proper solution in KVM instead.

Hmm... Now that I think about it that would be

https://lore.kernel.org/kvm/yc4h+dgfk83ba...@google.com/t/

Time to resurrect that work.

Ya.  I had previously asked David to first eliminated the usage that isn't
protected by mmu_notifiers, but after seeing the resulting complexity, I had a
change of heart[2].  Can you weigh in on the latter thread, specifically my
proposal of using a module param to let the admin opt-in to "unsafe" kmap usage.

I don't think that this is something an admin should be able to decide.

Why not?  Assuming the admin has CAP_SYS_ADMIN, they can reboot the host in a
myriad of ways.  The idea with the KVM module param is to allow curated setups
where the userspace VMM is trusted to a large extent, e.g. AWS' Nitro, to opt-in
to the unsafe behavior.  I.e. by enabling the flag, the admin is acknowledging
that bad things can happen if untrusted/compromised userspace gets ahold of
/dev/kvm.


Well exactly that's the point, you don't need untrusted/compromised 
userspace the system could just go spontaneously into nirvana during 
normal operation.


This would result in very very hard to debug problems since the issues 
only happen rather rarely.


On the other hand why do you need the kmap() in the first place?

Regards,
Christian.




x86 system are rather grateful, but if you kmap() pages accessed by GPUs on
ARM the system might just reboot spontaneously.

FWIW, the dangers of an unsafe kmap() are arguably far worse than spontaneous
reboots, e.g. there's potential for use-after-free and possibly even write 
access
to arbitrary memory.

Re: [PATCH] drm/ttm: set TTM allocated pages as reserved

[Sean Christopherson]

On Wed, Mar 29, 2023, Christian K�nig wrote:
> Am 29.03.23 um 19:22 schrieb Sean Christopherson:
> > +David
> > 
> > On Wed, Mar 29, 2023, Paolo Bonzini wrote:
> > > On 3/29/23 18:43, Christian K�nig wrote:
> > > > > 
> > > > > 3) other uses of kmap() must switch to MMU-notifier protection.
> > > > I would rather suggest to return the page additionally to the pfn from
> > > > hva_to_pfn() when the function was able to grab a reference to it.
> > > > 
> > > > When the page is then not available you can't call kmap() on that 
> > > > either.
> > > > 
> > > > > If the DRM people are okay with SetPageReserved() as a temporary
> > > > > hack, we can change or remove the WARN in kvm_is_zone_device_page(),
> > > > > since that is what you are referring to in the commit message.
> > > > Adding Daniel for additional comments on this, but essentially we have
> > > > changed quite some infrastructure to make sure that everybody uses
> > > > VM_PFNMAP to prevent stuff like this from happening.
> > > > 
> > > > I would really prefer a proper solution in KVM instead.
> > > Hmm... Now that I think about it that would be
> > > 
> > > https://lore.kernel.org/kvm/yc4h+dgfk83ba...@google.com/t/
> > > 
> > > Time to resurrect that work.
> > Ya.  I had previously asked David to first eliminated the usage that isn't
> > protected by mmu_notifiers, but after seeing the resulting complexity, I 
> > had a
> > change of heart[2].  Can you weigh in on the latter thread, specifically my
> > proposal of using a module param to let the admin opt-in to "unsafe" kmap 
> > usage.
> 
> I don't think that this is something an admin should be able to decide.

Why not?  Assuming the admin has CAP_SYS_ADMIN, they can reboot the host in a
myriad of ways.  The idea with the KVM module param is to allow curated setups
where the userspace VMM is trusted to a large extent, e.g. AWS' Nitro, to opt-in
to the unsafe behavior.  I.e. by enabling the flag, the admin is acknowledging
that bad things can happen if untrusted/compromised userspace gets ahold of
/dev/kvm.

> x86 system are rather grateful, but if you kmap() pages accessed by GPUs on
> ARM the system might just reboot spontaneously.

FWIW, the dangers of an unsafe kmap() are arguably far worse than spontaneous
reboots, e.g. there's potential for use-after-free and possibly even write 
access
to arbitrary memory.

Re: [PATCH] drm/ttm: set TTM allocated pages as reserved

[Christian König]

Am 29.03.23 um 19:22 schrieb Sean Christopherson:

+David

On Wed, Mar 29, 2023, Paolo Bonzini wrote:

On 3/29/23 18:43, Christian K�nig wrote:


3) other uses of kmap() must switch to MMU-notifier protection.

I would rather suggest to return the page additionally to the pfn from
hva_to_pfn() when the function was able to grab a reference to it.

When the page is then not available you can't call kmap() on that either.


If the DRM people are okay with SetPageReserved() as a temporary
hack, we can change or remove the WARN in kvm_is_zone_device_page(),
since that is what you are referring to in the commit message.

Adding Daniel for additional comments on this, but essentially we have
changed quite some infrastructure to make sure that everybody uses
VM_PFNMAP to prevent stuff like this from happening.

I would really prefer a proper solution in KVM instead.

Hmm... Now that I think about it that would be

https://lore.kernel.org/kvm/yc4h+dgfk83ba...@google.com/t/

Time to resurrect that work.

Ya.  I had previously asked David to first eliminated the usage that isn't
protected by mmu_notifiers, but after seeing the resulting complexity, I had a
change of heart[2].  Can you weigh in on the latter thread, specifically my
proposal of using a module param to let the admin opt-in to "unsafe" kmap usage.


I don't think that this is something an admin should be able to decide.

x86 system are rather grateful, but if you kmap() pages accessed by GPUs 
on ARM the system might just reboot spontaneously.


Robin Murphy  can fill you in on the hw details if 
needed.


Christian.



[1] https://lore.kernel.org/kvm/ydhq5ahw+jfo1...@google.com
[2] https://lore.kernel.org/all/zbeeqtmtnpaeq...@google.com/

Re: [PATCH] drm/msm/adreno: adreno_gpu: Use suspend() instead of idle() on load error

[Konrad Dybcio]

On 29.03.2023 19:30, Rob Clark wrote:
> On Wed, Mar 29, 2023 at 8:48 AM Konrad Dybcio  
> wrote:
>>
>>
>>
>> On 29.03.2023 16:37, Johan Hovold wrote:
>>> On Wed, Mar 29, 2023 at 04:04:44PM +0200, Konrad Dybcio wrote:
 If we fail to initialize the GPU for whatever reason (say we don't
 embed the GPU firmware files in the initrd), the error path involves
 pm_runtime_put_sync() which then calls idle() instead of suspend().

 This is suboptimal, as it means that we're not going through the
 clean shutdown sequence. With at least A619_holi, this makes the GPU
 not wake up until it goes through at least one more start-fail-stop
 cycle. Fix that by using pm_runtime_put_sync_suspend to force a clean
 shutdown.
>>>
>>> This does not sound right. If pm_runtime_put_sync() fails to suspend the
>>> device when the usage count drops to zero, then you have a bug somewhere
>>> else.
>> I was surprised to see that it was not called as well, but I wasn't able
>> to track it down before..
>>
>>>
>>> Also since commit 2c087a336676 ("drm/msm/adreno: Load the firmware
>>> before bringing up the hardware") the firmware is loaded before even
>>> hitting these paths so the above description does not sound right in
>>> that respect either (or is missing some details).
>> ..but I did some more digging and I found that the precise "firmware"
>> that fails is the ZAP blob, which is not checked like SQE in the
>> commit you mentioned!
>>
>> Now I don't think that we can easily check for it as-is since
>> zap_shader_load_mdt() does the entire find-load-authenticate
>> dance which is required with secure assets, but it's obviously
>> possible to rip out the find-load part of that and go on from
>> there.
>>
>> Do you think that would be a better solution?
> 
> Hmm, to hit this it sounds like you'd need all the fw _except_ the zap
> in the initrd?
Correct.

Konrad
> 
> BR,
> -R
> 
>> Konrad
>>
>>>
 Test cases:
 1. firmware baked into kernel
 2. error loading fw in initrd -> load from rootfs at DE start

 Both succeed on A619_holi (SM6375) and A630 (SDM845).

 Fixes: 0d997f95b70f ("drm/msm/adreno: fix runtime PM imbalance at gpu 
 load")
 Signed-off-by: Konrad Dybcio 
 ---
  drivers/gpu/drm/msm/adreno/adreno_device.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
 b/drivers/gpu/drm/msm/adreno/adreno_device.c
 index f61896629be6..59f3302e8167 100644
 --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
 +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
 @@ -477,7 +477,7 @@ struct msm_gpu *adreno_load_gpu(struct drm_device *dev)
  return gpu;

  err_put_rpm:
 -pm_runtime_put_sync(>dev);
 +pm_runtime_put_sync_suspend(>dev);
  err_disable_rpm:
  pm_runtime_disable(>dev);
>>>
>>> Johan

Re: [PATCH] drm/msm/adreno: adreno_gpu: Use suspend() instead of idle() on load error

[Rob Clark]

On Wed, Mar 29, 2023 at 8:48 AM Konrad Dybcio  wrote:
>
>
>
> On 29.03.2023 16:37, Johan Hovold wrote:
> > On Wed, Mar 29, 2023 at 04:04:44PM +0200, Konrad Dybcio wrote:
> >> If we fail to initialize the GPU for whatever reason (say we don't
> >> embed the GPU firmware files in the initrd), the error path involves
> >> pm_runtime_put_sync() which then calls idle() instead of suspend().
> >>
> >> This is suboptimal, as it means that we're not going through the
> >> clean shutdown sequence. With at least A619_holi, this makes the GPU
> >> not wake up until it goes through at least one more start-fail-stop
> >> cycle. Fix that by using pm_runtime_put_sync_suspend to force a clean
> >> shutdown.
> >
> > This does not sound right. If pm_runtime_put_sync() fails to suspend the
> > device when the usage count drops to zero, then you have a bug somewhere
> > else.
> I was surprised to see that it was not called as well, but I wasn't able
> to track it down before..
>
> >
> > Also since commit 2c087a336676 ("drm/msm/adreno: Load the firmware
> > before bringing up the hardware") the firmware is loaded before even
> > hitting these paths so the above description does not sound right in
> > that respect either (or is missing some details).
> ..but I did some more digging and I found that the precise "firmware"
> that fails is the ZAP blob, which is not checked like SQE in the
> commit you mentioned!
>
> Now I don't think that we can easily check for it as-is since
> zap_shader_load_mdt() does the entire find-load-authenticate
> dance which is required with secure assets, but it's obviously
> possible to rip out the find-load part of that and go on from
> there.
>
> Do you think that would be a better solution?

Hmm, to hit this it sounds like you'd need all the fw _except_ the zap
in the initrd?

BR,
-R

> Konrad
>
> >
> >> Test cases:
> >> 1. firmware baked into kernel
> >> 2. error loading fw in initrd -> load from rootfs at DE start
> >>
> >> Both succeed on A619_holi (SM6375) and A630 (SDM845).
> >>
> >> Fixes: 0d997f95b70f ("drm/msm/adreno: fix runtime PM imbalance at gpu 
> >> load")
> >> Signed-off-by: Konrad Dybcio 
> >> ---
> >>  drivers/gpu/drm/msm/adreno/adreno_device.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
> >> b/drivers/gpu/drm/msm/adreno/adreno_device.c
> >> index f61896629be6..59f3302e8167 100644
> >> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> >> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> >> @@ -477,7 +477,7 @@ struct msm_gpu *adreno_load_gpu(struct drm_device *dev)
> >>  return gpu;
> >>
> >>  err_put_rpm:
> >> -pm_runtime_put_sync(>dev);
> >> +pm_runtime_put_sync_suspend(>dev);
> >>  err_disable_rpm:
> >>  pm_runtime_disable(>dev);
> >
> > Johan

Re: [PATCH] drm/ttm: set TTM allocated pages as reserved

[Sean Christopherson]

+David

On Wed, Mar 29, 2023, Paolo Bonzini wrote:
> On 3/29/23 18:43, Christian K�nig wrote:
> > > 
> > > 
> > > 3) other uses of kmap() must switch to MMU-notifier protection.
> > 
> > I would rather suggest to return the page additionally to the pfn from
> > hva_to_pfn() when the function was able to grab a reference to it.
> > 
> > When the page is then not available you can't call kmap() on that either.
> > 
> > > 
> > > If the DRM people are okay with SetPageReserved() as a temporary
> > > hack, we can change or remove the WARN in kvm_is_zone_device_page(),
> > > since that is what you are referring to in the commit message.
> > 
> > Adding Daniel for additional comments on this, but essentially we have
> > changed quite some infrastructure to make sure that everybody uses
> > VM_PFNMAP to prevent stuff like this from happening.
> > 
> > I would really prefer a proper solution in KVM instead.
> 
> Hmm... Now that I think about it that would be
> 
> https://lore.kernel.org/kvm/yc4h+dgfk83ba...@google.com/t/
> 
> Time to resurrect that work.

Ya.  I had previously asked David to first eliminated the usage that isn't
protected by mmu_notifiers, but after seeing the resulting complexity, I had a
change of heart[2].  Can you weigh in on the latter thread, specifically my
proposal of using a module param to let the admin opt-in to "unsafe" kmap usage.

[1] https://lore.kernel.org/kvm/ydhq5ahw+jfo1...@google.com
[2] https://lore.kernel.org/all/zbeeqtmtnpaeq...@google.com/

Re: [PATCH v7 10/12] drm/bridge: Implement enable_next_first to alter bridge init order

[Dave Stevenson]

Hi Maxime

On Wed, 29 Mar 2023 at 17:46, Maxime Ripard  wrote:
>
> On Wed, Mar 29, 2023 at 05:28:28PM +0100, Dave Stevenson wrote:
> > On Wed, 29 Mar 2023 at 14:19, Jagan Teki  wrote:
> > >
> > > DSI sink devices typically send the MIPI-DCS commands to the DSI host
> > > via general MIPI_DSI_DCS read and write API.
> > >
> > > The classical DSI sequence mentioned that the DSI host receives MIPI-DCS
> > > commands from the DSI sink first in order to switch HS mode properly.
> > > Once the DSI host switches to HS mode any MIPI-DCS commands from the
> > > DSI sink are unfunctional.
> >
> > That statement contradicts the spec.
> > The DSI spec section 8.11.1 Transmission Packet Sequences says that
> > during any BLLP (Blanking or Low Power) period the host can do any of:
> > - remain in LP-11
> > - transmit one or more non-video packets from host to peripheral in escape 
> > mode
> > - transmit one or more non-video packets from host to peripheral in
> > using HS mode
> > - receive one or more packets from peripheral to host using escape mode
> > - transmit data on a different virtual channel.
> >
> > Indeed if the sink doesn't set MIPI_DSI_MODE_LPM /
> > MIPI_DSI_MSG_USE_LPM, then the expectation is that any data transfer
> > will be in HS mode.
> >
> > That makes me confused as to the need for this patch.
>
> Yeah, and it looks like that would break the expectation that, in
> enable, a bridge can expect its controller to be in HS mode.
>
> I think that was Jagan is trying to do is to work around an issue with
> the Allwinner DSI driver:
> https://elixir.bootlin.com/linux/v6.3-rc4/source/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c#L775
>
> This is working mostly fine since we only have panel support and can
> control that, but with bridge support added in the latest patch, then it
> probably doesn't work anymore.
>
> The proper way to fix this isn't to put more logic into the framework,
> it's to make the DSI driver behave as expected by KMS.
>
> Unfortunately, that controller is not documented, so it's not clear to
> me how we can fix it.
>
> IIRC, it's basically a state machine where you would encode the
> transitions between one DSI state and the next depending on what your
> expectations are.
>
> I think there's two problem with the driver that need to be addressed:
>
>   - First the driver will drop back to LP11 mode to submit commands. I
> don't think it's needed and could even be hurtful to the video
> stream if it was to happen during HS mode:
> 
> https://elixir.bootlin.com/linux/v6.3-rc4/source/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c#L877
>
>   - And then, it looks like, in HSD mode, we never get to go to the
> state LPTX is in (LPDT). It would be interesting to test whether
> adding a transition to that state makes it work or not.

Ooh, not fun.
I'll agree with your assessment - it looks like sunxi driver has
significant limitations on the modes of operation it supports. If
there is no information on sending HS commands, I wonder if it's
possible to note the video state in transfer and stop video, send the
command, and resume video again. Ugly as heck, but possibly the only
real option without documentation. It does raise the question of do
other blocks (eg crtc) need to be stopped as well, or does stopping
the PHY and/or DSI block stop the pixel data getting clocked out.

I can only guess at the meaning of the enum sun6i_dsi_start_inst and
enum sun6i_dsi_inst_id states. LPTX and LPRX are largely obvious, but
HSC(ommand) and HSD(ata) perhaps?
I thought on initial reading that the setup in sun6i_dsi_start made
sense as a sequence of commands, but looking closer at the bitmasking
and shifting I'm not so convinced. Are the DSI_INST_ID_xxx defines
shifts or the bitmask values to or in, as they get used for both.

  Dave

[PATCH] drm/pl111: Fix missing unwind goto in pl111_amba_probe()

[Harshit Mogalapalli]

Smatch reports:
drivers/gpu/drm/pl111/pl111_drv.c:300
pl111_amba_probe() warn: missing unwind goto?

When devm_request_irq() returns non-zero value, we need to drop the
reference for drm device and also release reserved memory which is
done in "dev_put" label. So instead of directly returning, goto dev_put
to fix this bug.

Fixes: bed41005e617 ("drm/pl111: Initial drm/kms driver for pl111")
Signed-off-by: Harshit Mogalapalli 
---
This is based on static analysis, Only Compile tested.
---
 drivers/gpu/drm/pl111/pl111_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
b/drivers/gpu/drm/pl111/pl111_drv.c
index 4b2a9e9753f6..72c5d3681b47 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -297,7 +297,7 @@ static int pl111_amba_probe(struct amba_device *amba_dev,
   variant->name, priv);
if (ret != 0) {
dev_err(dev, "%s failed irq %d\n", __func__, ret);
-   return ret;
+   goto dev_put;
}
 
ret = pl111_modeset_init(drm);
-- 
2.38.1

[PATCH] drm/scdc-helper: Pimp SCDC debugs

[Ville Syrjala]

From: Ville Syrjälä 

Include the device and connector information in the SCDC
debugs. Makes it easier to figure out who did what.

Cc: Andrzej Hajda 
Cc: Neil Armstrong 
Cc: Robert Foss 
Cc: Laurent Pinchart 
Cc: Jonas Karlman 
Cc: Jernej Skrabec 
Cc: Thierry Reding 
Cc: Emma Anholt 
Cc: Maxime Ripard 
Cc: intel-...@lists.freedesktop.org
Cc: linux-te...@vger.kernel.org
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  8 ++---
 drivers/gpu/drm/display/drm_scdc_helper.c | 36 ++-
 drivers/gpu/drm/i915/display/intel_ddi.c  |  4 +--
 drivers/gpu/drm/i915/display/intel_hdmi.c |  4 +--
 drivers/gpu/drm/tegra/sor.c   | 10 +++
 drivers/gpu/drm/vc4/vc4_hdmi.c| 21 +++--
 include/drm/display/drm_scdc_helper.h | 12 ++--
 7 files changed, 62 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index aa51c61a78c7..7f57ca168ab6 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1426,9 +1426,9 @@ void dw_hdmi_set_high_tmds_clock_ratio(struct dw_hdmi 
*hdmi,
/* Control for TMDS Bit Period/TMDS Clock-Period Ratio */
if (dw_hdmi_support_scdc(hdmi, display)) {
if (mtmdsclock > HDMI14_MAX_TMDSCLK)
-   drm_scdc_set_high_tmds_clock_ratio(hdmi->ddc, 1);
+   drm_scdc_set_high_tmds_clock_ratio(>connector, 
hdmi->ddc, 1);
else
-   drm_scdc_set_high_tmds_clock_ratio(hdmi->ddc, 0);
+   drm_scdc_set_high_tmds_clock_ratio(>connector, 
hdmi->ddc, 0);
}
 }
 EXPORT_SYMBOL_GPL(dw_hdmi_set_high_tmds_clock_ratio);
@@ -2116,7 +2116,7 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
min_t(u8, bytes, SCDC_MIN_SOURCE_VERSION));
 
/* Enabled Scrambling in the Sink */
-   drm_scdc_set_scrambling(hdmi->ddc, 1);
+   drm_scdc_set_scrambling(>connector, hdmi->ddc, 1);
 
/*
 * To activate the scrambler feature, you must ensure
@@ -2132,7 +2132,7 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
hdmi_writeb(hdmi, 0, HDMI_FC_SCRAMBLER_CTRL);
hdmi_writeb(hdmi, (u8)~HDMI_MC_SWRSTZ_TMDSSWRST_REQ,
HDMI_MC_SWRSTZ);
-   drm_scdc_set_scrambling(hdmi->ddc, 0);
+   drm_scdc_set_scrambling(>connector, hdmi->ddc, 0);
}
}
 
diff --git a/drivers/gpu/drm/display/drm_scdc_helper.c 
b/drivers/gpu/drm/display/drm_scdc_helper.c
index c3ad4ab2b456..2b124152384c 100644
--- a/drivers/gpu/drm/display/drm_scdc_helper.c
+++ b/drivers/gpu/drm/display/drm_scdc_helper.c
@@ -26,6 +26,8 @@
 #include 
 
 #include 
+#include 
+#include 
 #include 
 
 /**
@@ -140,6 +142,7 @@ EXPORT_SYMBOL(drm_scdc_write);
 
 /**
  * drm_scdc_get_scrambling_status - what is status of scrambling?
+ * @connector: connector
  * @adapter: I2C adapter for DDC channel
  *
  * Reads the scrambler status over SCDC, and checks the
@@ -148,14 +151,17 @@ EXPORT_SYMBOL(drm_scdc_write);
  * Returns:
  * True if the scrambling is enabled, false otherwise.
  */
-bool drm_scdc_get_scrambling_status(struct i2c_adapter *adapter)
+bool drm_scdc_get_scrambling_status(struct drm_connector *connector,
+   struct i2c_adapter *adapter)
 {
u8 status;
int ret;
 
ret = drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, );
if (ret < 0) {
-   DRM_DEBUG_KMS("Failed to read scrambling status: %d\n", ret);
+   drm_dbg_kms(connector->dev,
+   "[CONNECTOR:%d:%s] Failed to read scrambling 
status: %d\n",
+   connector->base.id, connector->name, ret);
return false;
}
 
@@ -165,6 +171,7 @@ EXPORT_SYMBOL(drm_scdc_get_scrambling_status);
 
 /**
  * drm_scdc_set_scrambling - enable scrambling
+ * @connector: connector
  * @adapter: I2C adapter for DDC channel
  * @enable: bool to indicate if scrambling is to be enabled/disabled
  *
@@ -175,14 +182,18 @@ EXPORT_SYMBOL(drm_scdc_get_scrambling_status);
  * Returns:
  * True if scrambling is set/reset successfully, false otherwise.
  */
-bool drm_scdc_set_scrambling(struct i2c_adapter *adapter, bool enable)
+bool drm_scdc_set_scrambling(struct drm_connector *connector,
+struct i2c_adapter *adapter,
+bool enable)
 {
u8 config;
int ret;
 
ret = drm_scdc_readb(adapter, SCDC_TMDS_CONFIG, );
if (ret < 0) {
-   DRM_DEBUG_KMS("Failed to read TMDS config: %d\n", ret);
+   drm_dbg_kms(connector->dev,
+   "[CONNECTOR:%d:%s] Failed to read TMDS config: 
%d\n",
+   

[PATCH 4/4] drm/i915/gsc: add support for GSC proxy interrupt

[Daniele Ceraolo Spurio]

The GSC notifies us of a proxy request via the HECI2 interrupt. The
interrupt must be enabled both in the HECI layer and in our usual gt irq
programming; for the latter, the interrupt is enabled via the same enable
register as the GSC CS, but it does have its own mask register. When the
interrupt is received, we also need to de-assert it in both layers.

The handling of the proxy request is deferred to the same worker that we
use for GSC load. New flags have been added to distinguish between the
init case and the proxy interrupt.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
---
 drivers/gpu/drm/i915/gt/intel_gt_irq.c   | 22 --
 drivers/gpu/drm/i915/gt/intel_gt_regs.h  |  3 ++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c | 44 +++-
 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.h |  1 +
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c| 44 
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h|  3 ++
 6 files changed, 103 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c 
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index 1b25a6039152..c433ffdb3380 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -15,6 +15,7 @@
 #include "intel_uncore.h"
 #include "intel_rps.h"
 #include "pxp/intel_pxp_irq.h"
+#include "uc/intel_gsc_proxy.h"
 
 static void guc_irq_handler(struct intel_guc *guc, u16 iir)
 {
@@ -81,6 +82,9 @@ gen11_other_irq_handler(struct intel_gt *gt, const u8 
instance,
if (instance == OTHER_GSC_INSTANCE)
return intel_gsc_irq_handler(gt, iir);
 
+   if (instance == OTHER_GSC_HECI_2_INSTANCE)
+   return intel_gsc_proxy_irq_handler(>uc.gsc, iir);
+
WARN_ONCE(1, "unhandled other interrupt instance=0x%x, iir=0x%x\n",
  instance, iir);
 }
@@ -100,6 +104,8 @@ static struct intel_gt *pick_gt(struct intel_gt *gt, u8 
class, u8 instance)
case VIDEO_ENHANCEMENT_CLASS:
return media_gt;
case OTHER_CLASS:
+   if (instance == OTHER_GSC_HECI_2_INSTANCE)
+   return media_gt;
if (instance == OTHER_GSC_INSTANCE && HAS_ENGINE(media_gt, 
GSC0))
return media_gt;
fallthrough;
@@ -256,6 +262,7 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
u32 irqs = GT_RENDER_USER_INTERRUPT;
u32 guc_mask = intel_uc_wants_guc(>uc) ? GUC_INTR_GUC2HOST : 0;
u32 gsc_mask = 0;
+   u32 heci_mask = 0;
u32 dmask;
u32 smask;
 
@@ -267,10 +274,16 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
dmask = irqs << 16 | irqs;
smask = irqs << 16;
 
-   if (HAS_ENGINE(gt, GSC0))
+   if (HAS_ENGINE(gt, GSC0)) {
+   /*
+* the heci2 interrupt is enabled via the same register as the
+* GSC interrupt, but it has its own mask register.
+*/
gsc_mask = irqs;
-   else if (HAS_HECI_GSC(gt->i915))
+   heci_mask = GSC_IRQ_INTF(1); /* HECI2 IRQ for SW Proxy*/
+   } else if (HAS_HECI_GSC(gt->i915)) {
gsc_mask = GSC_IRQ_INTF(0) | GSC_IRQ_INTF(1);
+   }
 
BUILD_BUG_ON(irqs & 0x);
 
@@ -280,7 +293,7 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
if (CCS_MASK(gt))
intel_uncore_write(uncore, GEN12_CCS_RSVD_INTR_ENABLE, smask);
if (gsc_mask)
-   intel_uncore_write(uncore, GEN11_GUNIT_CSME_INTR_ENABLE, 
gsc_mask);
+   intel_uncore_write(uncore, GEN11_GUNIT_CSME_INTR_ENABLE, 
gsc_mask | heci_mask);
 
/* Unmask irqs on RCS, BCS, VCS and VECS engines. */
intel_uncore_write(uncore, GEN11_RCS0_RSVD_INTR_MASK, ~smask);
@@ -308,6 +321,9 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
intel_uncore_write(uncore, GEN12_CCS2_CCS3_INTR_MASK, ~dmask);
if (gsc_mask)
intel_uncore_write(uncore, GEN11_GUNIT_CSME_INTR_MASK, 
~gsc_mask);
+   if (heci_mask)
+   intel_uncore_write(uncore, GEN11_HECI2_RSVD_INTR_MASK,
+  ~REG_FIELD_PREP(ENGINE1_MASK, heci_mask));
 
if (guc_mask) {
/* the enable bit is common for both GTs but the masks are 
separate */
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 4aecb5a7b631..da11ce5ca99e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1577,6 +1577,7 @@
 
 #define GEN11_GT_INTR_DW(x)_MMIO(0x190018 + ((x) * 4))
 #define   GEN11_CSME   (31)
+#define   GEN12_HECI_2 (30)
 #define   GEN11_GUNIT  (28)
 #define   GEN11_GUC(25)
 #define   MTL_MGUC (24)
@@ -1618,6 +1619,7 @@
 /* irq instances for OTHER_CLASS */
 

[PATCH 2/4] mei: gsc_proxy: add gsc proxy driver

[Daniele Ceraolo Spurio]

From: Alexander Usyskin 

Add GSC proxy driver. It to allows messaging between GSC component
on Intel on board graphics card and CSE device.

Cc: Daniele Ceraolo Spurio 
Cc: Alan Previn 
Signed-off-by: Alexander Usyskin 
Signed-off-by: Tomas Winkler 
Acked-by: Greg Kroah-Hartman 
---
 drivers/misc/mei/Kconfig   |   2 +-
 drivers/misc/mei/Makefile  |   1 +
 drivers/misc/mei/gsc_proxy/Kconfig |  14 ++
 drivers/misc/mei/gsc_proxy/Makefile|   7 +
 drivers/misc/mei/gsc_proxy/mei_gsc_proxy.c | 208 +
 5 files changed, 231 insertions(+), 1 deletion(-)
 create mode 100644 drivers/misc/mei/gsc_proxy/Kconfig
 create mode 100644 drivers/misc/mei/gsc_proxy/Makefile
 create mode 100644 drivers/misc/mei/gsc_proxy/mei_gsc_proxy.c

diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig
index d21486d69df2..37db142de413 100644
--- a/drivers/misc/mei/Kconfig
+++ b/drivers/misc/mei/Kconfig
@@ -62,4 +62,4 @@ config INTEL_MEI_GSC
 
 source "drivers/misc/mei/hdcp/Kconfig"
 source "drivers/misc/mei/pxp/Kconfig"
-
+source "drivers/misc/mei/gsc_proxy/Kconfig"
diff --git a/drivers/misc/mei/Makefile b/drivers/misc/mei/Makefile
index fb740d754900..14aee253ae48 100644
--- a/drivers/misc/mei/Makefile
+++ b/drivers/misc/mei/Makefile
@@ -30,3 +30,4 @@ CFLAGS_mei-trace.o = -I$(src)
 
 obj-$(CONFIG_INTEL_MEI_HDCP) += hdcp/
 obj-$(CONFIG_INTEL_MEI_PXP) += pxp/
+obj-$(CONFIG_INTEL_MEI_GSC_PROXY) += gsc_proxy/
diff --git a/drivers/misc/mei/gsc_proxy/Kconfig 
b/drivers/misc/mei/gsc_proxy/Kconfig
new file mode 100644
index ..fd45ce8c1df4
--- /dev/null
+++ b/drivers/misc/mei/gsc_proxy/Kconfig
@@ -0,0 +1,14 @@
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (c) 2022-2023, Intel Corporation. All rights reserved.
+#
+config INTEL_MEI_GSC_PROXY
+   tristate "Intel GSC Proxy services of ME Interface"
+   select INTEL_MEI_ME
+   depends on DRM_I915
+   help
+ MEI Support for GSC Proxy Services on Intel platforms.
+
+ MEI GSC proxy enables messaging between GSC service on
+ Intel graphics on-board card and services on CSE (MEI)
+ firmware residing SoC or PCH.
+
diff --git a/drivers/misc/mei/gsc_proxy/Makefile 
b/drivers/misc/mei/gsc_proxy/Makefile
new file mode 100644
index ..358847e9aaa9
--- /dev/null
+++ b/drivers/misc/mei/gsc_proxy/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Copyright (c) 2022-2023, Intel Corporation. All rights reserved.
+#
+# Makefile - GSC Proxy client driver for Intel MEI Bus Driver.
+
+obj-$(CONFIG_INTEL_MEI_GSC_PROXY) += mei_gsc_proxy.o
diff --git a/drivers/misc/mei/gsc_proxy/mei_gsc_proxy.c 
b/drivers/misc/mei/gsc_proxy/mei_gsc_proxy.c
new file mode 100644
index ..953eda1a16fb
--- /dev/null
+++ b/drivers/misc/mei/gsc_proxy/mei_gsc_proxy.c
@@ -0,0 +1,208 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2022-2023 Intel Corporation
+ */
+
+/**
+ * DOC: MEI_GSC_PROXY Client Driver
+ *
+ * The mei_gsc_proxy driver acts as a translation layer between
+ * proxy user (I915) and ME FW by proxying messages to ME FW
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * mei_gsc_proxy_send - Sends a proxy message to ME FW.
+ * @dev: device corresponding to the mei_cl_device
+ * @buf: a message buffer to send
+ * @size: size of the message
+ * Return: bytes sent on Success, <0 on Failure
+ */
+static int mei_gsc_proxy_send(struct device *dev, const void *buf, size_t size)
+{
+   ssize_t ret;
+
+   if (!dev || !buf)
+   return -EINVAL;
+
+   ret = mei_cldev_send(to_mei_cl_device(dev), buf, size);
+   if (ret < 0)
+   dev_dbg(dev, "mei_cldev_send failed. %zd\n", ret);
+
+   return ret;
+}
+
+/**
+ * mei_gsc_proxy_recv - Receives a proxy message from ME FW.
+ * @dev: device corresponding to the mei_cl_device
+ * @buf: a message buffer to contain the received message
+ * @size: size of the buffer
+ * Return: bytes received on Success, <0 on Failure
+ */
+static int mei_gsc_proxy_recv(struct device *dev, void *buf, size_t size)
+{
+   ssize_t ret;
+
+   if (!dev || !buf)
+   return -EINVAL;
+
+   ret = mei_cldev_recv(to_mei_cl_device(dev), buf, size);
+   if (ret < 0)
+   dev_dbg(dev, "mei_cldev_recv failed. %zd\n", ret);
+
+   return ret;
+}
+
+static const struct i915_gsc_proxy_component_ops mei_gsc_proxy_ops = {
+   .owner = THIS_MODULE,
+   .send = mei_gsc_proxy_send,
+   .recv = mei_gsc_proxy_recv,
+};
+
+static int mei_component_master_bind(struct device *dev)
+{
+   struct mei_cl_device *cldev = to_mei_cl_device(dev);
+   struct i915_gsc_proxy_component *comp_master = 
mei_cldev_get_drvdata(cldev);
+
+   comp_master->ops = _gsc_proxy_ops;
+   comp_master->mei_dev = dev;
+   return component_bind_all(dev, comp_master);
+}
+
+static void 

[PATCH 3/4] drm/i915/gsc: add initial support for GSC proxy

[Daniele Ceraolo Spurio]

The GSC uC needs to communicate with the CSME to perform certain
operations. Since the GSC can't perform this communication directly
on platforms where it is integrated in GT, i915 needs to transfer the
messages from GSC to CSME and back.
The proxy flow is as follow:
1 - i915 submits a request to GSC asking for the message to CSME
2 - GSC replies with the proxy header + payload for CSME
3 - i915 sends the reply from GSC as-is to CSME via the mei proxy
component
4 - CSME replies with the proxy header + payload for GSC
5 - i915 submits a request to GSC with the reply from CSME
6 - GSC replies either with a new header + payload (same as step 2,
so we restart from there) or with an end message.

After GSC load, i915 is expected to start the first proxy message chain,
while all subsequent ones will be triggered by the GSC via interrupt.

To communicate with the CSME, we use a dedicated mei component, which
means that we need to wait for it to bind before we can initialize the
proxies. This usually happens quite fast, but given that there is a
chance that we'll have to wait a few seconds the GSC work has been moved
to a dedicated WQ to not stall other processes.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c  | 384 ++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.h  |  17 +
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c |  40 +-
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h |  14 +-
 .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h |   1 +
 6 files changed, 452 insertions(+), 5 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 057ef22fa9c6..aae041137f93 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -194,6 +194,7 @@ i915-y += \
 # general-purpose microcontroller (GuC) support
 i915-y += \
  gt/uc/intel_gsc_fw.o \
+ gt/uc/intel_gsc_proxy.o \
  gt/uc/intel_gsc_uc.o \
  gt/uc/intel_gsc_uc_heci_cmd_submit.o\
  gt/uc/intel_guc.o \
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
new file mode 100644
index ..ed8f68e78c26
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
@@ -0,0 +1,384 @@
+#include "intel_gsc_proxy.h"
+
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+#include "drm/i915_gsc_proxy_mei_interface.h"
+#include "drm/i915_component.h"
+
+#include "gt/intel_gt.h"
+#include "gt/intel_gt_print.h"
+#include "intel_gsc_uc.h"
+#include "intel_gsc_uc_heci_cmd_submit.h"
+#include "i915_drv.h"
+
+/*
+ * GSC proxy:
+ * The GSC uC needs to communicate with the CSME to perform certain operations.
+ * Since the GSC can't perform this communication directly on platforms where 
it
+ * is integrated in GT, i915 needs to transfer the messages from GSC to CSME
+ * and back. i915 must manually start the proxy flow after the GSC is loaded to
+ * signal to GSC that we're ready to handle its messages and allow it to query
+ * its init data from CSME; GSC will then trigger an HECI2 interrupt if it 
needs
+ * to send messages to CSME again.
+ * The proxy flow is as follow:
+ * 1 - i915 submits a request to GSC asking for the message to CSME
+ * 2 - GSC replies with the proxy header + payload for CSME
+ * 3 - i915 sends the reply from GSC as-is to CSME via the mei proxy component
+ * 4 - CSME replies with the proxy header + payload for GSC
+ * 5 - i915 submits a request to GSC with the reply from CSME
+ * 6 - GSC replies either with a new header + payload (same as step 2, so we
+ * restart from there) or with an end message.
+ */
+
+/*
+ * The component should load quite quickly in most cases, but it could take
+ * a bit. Using a very big timeout just to cover the worst case scenario
+ */
+#define GSC_PROXY_INIT_TIMEOUT_MS 2
+
+/* the protocol supports up to 32K in each direction */
+#define GSC_PROXY_BUFFER_SIZE SZ_32K
+#define GSC_PROXY_CHANNEL_SIZE (GSC_PROXY_BUFFER_SIZE * 2)
+#define GSC_PROXY_MAX_MSG_SIZE (GSC_PROXY_BUFFER_SIZE - sizeof(struct 
intel_gsc_mtl_header))
+
+/* FW-defined proxy header */
+struct intel_gsc_proxy_header
+{
+   /*
+* hdr:
+* Bits 0-7: type of the proxy message (see enum intel_gsc_proxy_type)
+* Bits 8-15: rsvd
+* Bits 16-31: length in bytes of the payload following the proxy header
+*/
+   u32 hdr;
+#define GSC_PROXY_TYPE  GENMASK(7, 0)
+#define GSC_PROXY_PAYLOAD_LENGTH GENMASK(31, 16)
+
+   u32 source; /* Source of the Proxy message */
+   u32 destination;/* Destination of the Proxy message */
+#define GSC_PROXY_ADDRESSING_KMD  0x1
+#define GSC_PROXY_ADDRESSING_GSC  0x2
+#define 

[PATCH 0/4] drm/i915: Add support for MTL GSC SW Proxy

[Daniele Ceraolo Spurio]

On platforms where the GSC is part of GT, it needs to communicate with
CSME for some of its operations. However, there is no direct HW
communication channel, so the i915 and mei drivers must carry the
messages back and forth between the 2 units. The protocol is fully
described in the i915 patch that adds the initial support, but it
basically amounts to SW blindly moving messages back and forth until the
GSC tells us to stop.

Implementing this features requires a new mei component to handle
the mei side of things. The patches for this have already been
reviewed on the char-misc ML and we already have an ack from Greg to
merge them via the drm tree [1].

[1] 
https://lore.kernel.org/lkml/20230208142358.1401618-1-tomas.wink...@intel.com/t/

Cc: Alan Previn 
Cc: Suraj Kandpal 
Cc: Alexander Usyskin 
Cc: Greg Kroah-Hartman 

Alexander Usyskin (2):
  drm/i915/mtl: Define GSC Proxy component interface
  mei: gsc_proxy: add gsc proxy driver

Daniele Ceraolo Spurio (2):
  drm/i915/gsc: add initial support for GSC proxy
  drm/i915/gsc: add support for GSC proxy interrupt

 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/gt/intel_gt_irq.c|  22 +-
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   |   3 +
 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c  | 424 ++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.h  |  18 +
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c |  66 ++-
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h |  17 +-
 .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h |   1 +
 drivers/misc/mei/Kconfig  |   2 +-
 drivers/misc/mei/Makefile |   1 +
 drivers/misc/mei/gsc_proxy/Kconfig|  14 +
 drivers/misc/mei/gsc_proxy/Makefile   |   7 +
 drivers/misc/mei/gsc_proxy/mei_gsc_proxy.c| 208 +
 include/drm/i915_component.h  |   3 +-
 include/drm/i915_gsc_proxy_mei_interface.h|  36 ++
 15 files changed, 813 insertions(+), 10 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.h
 create mode 100644 drivers/misc/mei/gsc_proxy/Kconfig
 create mode 100644 drivers/misc/mei/gsc_proxy/Makefile
 create mode 100644 drivers/misc/mei/gsc_proxy/mei_gsc_proxy.c
 create mode 100644 include/drm/i915_gsc_proxy_mei_interface.h

-- 
2.37.3

[PATCH 1/4] drm/i915/mtl: Define GSC Proxy component interface

[Daniele Ceraolo Spurio]

From: Alexander Usyskin 

GSC Proxy component is used for communication between the
Intel graphics driver and MEI driver.

Cc: Daniele Ceraolo Spurio 
Cc: Alan Previn 
Signed-off-by: Alexander Usyskin 
Signed-off-by: Tomas Winkler 
Acked-by: Greg Kroah-Hartman 
---
 include/drm/i915_component.h   |  3 +-
 include/drm/i915_gsc_proxy_mei_interface.h | 36 ++
 2 files changed, 38 insertions(+), 1 deletion(-)
 create mode 100644 include/drm/i915_gsc_proxy_mei_interface.h

diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h
index c1e2a43d2d1e..56a84ee1c64c 100644
--- a/include/drm/i915_component.h
+++ b/include/drm/i915_component.h
@@ -29,7 +29,8 @@
 enum i915_component_type {
I915_COMPONENT_AUDIO = 1,
I915_COMPONENT_HDCP,
-   I915_COMPONENT_PXP
+   I915_COMPONENT_PXP,
+   I915_COMPONENT_GSC_PROXY,
 };
 
 /* MAX_PORT is the number of port
diff --git a/include/drm/i915_gsc_proxy_mei_interface.h 
b/include/drm/i915_gsc_proxy_mei_interface.h
new file mode 100644
index ..e817bb316d5c
--- /dev/null
+++ b/include/drm/i915_gsc_proxy_mei_interface.h
@@ -0,0 +1,36 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright (c) 2022-2023 Intel Corporation
+ */
+
+#ifndef _I915_GSC_PROXY_MEI_INTERFACE_H_
+#define _I915_GSC_PROXY_MEI_INTERFACE_H_
+
+#include 
+#include 
+
+/**
+ * struct i915_gsc_proxy_component_ops - ops for GSC Proxy services.
+ * @owner: Module providing the ops
+ * @send: sends data through GSC proxy
+ * @recv: receives data through GSC proxy
+ */
+struct i915_gsc_proxy_component_ops {
+   struct module *owner;
+
+   int (*send)(struct device *dev, const void *buf, size_t size);
+   int (*recv)(struct device *dev, void *buf, size_t size);
+};
+
+/**
+ * struct i915_gsc_proxy_component - Used for communication between i915 and
+ * MEI drivers for GSC proxy services
+ * @mei_dev: device that provide the GSC proxy service.
+ * @ops: Ops implemented by GSC proxy driver, used by i915 driver.
+ */
+struct i915_gsc_proxy_component {
+   struct device *mei_dev;
+   const struct i915_gsc_proxy_component_ops *ops;
+};
+
+#endif /* _I915_GSC_PROXY_MEI_INTERFACE_H_ */
-- 
2.37.3

Re: [PATCH] drm/ttm: set TTM allocated pages as reserved

[Paolo Bonzini]

On 3/29/23 18:43, Christian König wrote:



3) other uses of kmap() must switch to MMU-notifier protection.


I would rather suggest to return the page additionally to the pfn from 
hva_to_pfn() when the function was able to grab a reference to it.


When the page is then not available you can't call kmap() on that either.



If the DRM people are okay with SetPageReserved() as a temporary hack, 
we can change or remove the WARN in kvm_is_zone_device_page(), since 
that is what you are referring to in the commit message.


Adding Daniel for additional comments on this, but essentially we have 
changed quite some infrastructure to make sure that everybody uses 
VM_PFNMAP to prevent stuff like this from happening.


I would really prefer a proper solution in KVM instead.


Hmm... Now that I think about it that would be

https://lore.kernel.org/kvm/yc4h+dgfk83ba...@google.com/t/

Time to resurrect that work.

Paolo

Re: [PATCH v7 10/12] drm/bridge: Implement enable_next_first to alter bridge init order

[Maxime Ripard]

On Wed, Mar 29, 2023 at 05:28:28PM +0100, Dave Stevenson wrote:
> On Wed, 29 Mar 2023 at 14:19, Jagan Teki  wrote:
> >
> > DSI sink devices typically send the MIPI-DCS commands to the DSI host
> > via general MIPI_DSI_DCS read and write API.
> >
> > The classical DSI sequence mentioned that the DSI host receives MIPI-DCS
> > commands from the DSI sink first in order to switch HS mode properly.
> > Once the DSI host switches to HS mode any MIPI-DCS commands from the
> > DSI sink are unfunctional.
> 
> That statement contradicts the spec.
> The DSI spec section 8.11.1 Transmission Packet Sequences says that
> during any BLLP (Blanking or Low Power) period the host can do any of:
> - remain in LP-11
> - transmit one or more non-video packets from host to peripheral in escape 
> mode
> - transmit one or more non-video packets from host to peripheral in
> using HS mode
> - receive one or more packets from peripheral to host using escape mode
> - transmit data on a different virtual channel.
> 
> Indeed if the sink doesn't set MIPI_DSI_MODE_LPM /
> MIPI_DSI_MSG_USE_LPM, then the expectation is that any data transfer
> will be in HS mode.
> 
> That makes me confused as to the need for this patch.

Yeah, and it looks like that would break the expectation that, in
enable, a bridge can expect its controller to be in HS mode.

I think that was Jagan is trying to do is to work around an issue with
the Allwinner DSI driver:
https://elixir.bootlin.com/linux/v6.3-rc4/source/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c#L775

This is working mostly fine since we only have panel support and can
control that, but with bridge support added in the latest patch, then it
probably doesn't work anymore.

The proper way to fix this isn't to put more logic into the framework,
it's to make the DSI driver behave as expected by KMS.

Unfortunately, that controller is not documented, so it's not clear to
me how we can fix it.

IIRC, it's basically a state machine where you would encode the
transitions between one DSI state and the next depending on what your
expectations are.

I think there's two problem with the driver that need to be addressed:

  - First the driver will drop back to LP11 mode to submit commands. I
don't think it's needed and could even be hurtful to the video
stream if it was to happen during HS mode:

https://elixir.bootlin.com/linux/v6.3-rc4/source/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c#L877

  - And then, it looks like, in HSD mode, we never get to go to the
state LPTX is in (LPDT). It would be interesting to test whether
adding a transition to that state makes it work or not.

Maxime


signature.asc
Description: PGP signature

Re: [PATCH] drm/ttm: set TTM allocated pages as reserved

[Christian König]

Am 29.03.23 um 17:51 schrieb Paolo Bonzini:

On 3/29/23 17:29, Christian König wrote:
First, is it a _host_ corruption or a guest corruption/crash?  A 
guest crash would be KVM doing exactly what it's meant to do: it 
detects the non-reserved, non-refcounted page and refuses to map it 
into the guest.


Yes I think that this is what happens.


Ok I was worried all the time that this was host corruption/crash; 
which obviously would have been much worse.



The use case and mapping is indeed valid as far as I can see, but
the handling that KVM does here is really problematic.

What needs to happen instead is that when both hva_to_pfn_fast() and 
hva_to_pfn_slow() fails you don't try to convert the PFN into a page 
and so also don't get a reference to the page.


This somehow needs to be communicated to the callers of hva_to_pfn() 
so that kvm_release_pfn() knows what to do.


There's a bit more complication here:

1) in the guest page fault path we can avoid taking the reference 
altogether


2) in other MMU-notifier-protected paths, we can also avoid taking the 
reference but we also must stop using kmap() in virt/kvm/pfncache.c.


3) other uses of kmap() must switch to MMU-notifier protection.


I would rather suggest to return the page additionally to the pfn from 
hva_to_pfn() when the function was able to grab a reference to it.


When the page is then not available you can't call kmap() on that either.



If the DRM people are okay with SetPageReserved() as a temporary hack, 
we can change or remove the WARN in kvm_is_zone_device_page(), since 
that is what you are referring to in the commit message.


Adding Daniel for additional comments on this, but essentially we have 
changed quite some infrastructure to make sure that everybody uses 
VM_PFNMAP to prevent stuff like this from happening.


I would really prefer a proper solution in KVM instead.

Christian.



Paolo

Re: [PATCH v7 10/12] drm/bridge: Implement enable_next_first to alter bridge init order

[Dave Stevenson]

Hi Jagan

On Wed, 29 Mar 2023 at 14:19, Jagan Teki  wrote:
>
> DSI sink devices typically send the MIPI-DCS commands to the DSI host
> via general MIPI_DSI_DCS read and write API.
>
> The classical DSI sequence mentioned that the DSI host receives MIPI-DCS
> commands from the DSI sink first in order to switch HS mode properly.
> Once the DSI host switches to HS mode any MIPI-DCS commands from the
> DSI sink are unfunctional.

That statement contradicts the spec.
The DSI spec section 8.11.1 Transmission Packet Sequences says that
during any BLLP (Blanking or Low Power) period the host can do any of:
- remain in LP-11
- transmit one or more non-video packets from host to peripheral in escape mode
- transmit one or more non-video packets from host to peripheral in
using HS mode
- receive one or more packets from peripheral to host using escape mode
- transmit data on a different virtual channel.

Indeed if the sink doesn't set MIPI_DSI_MODE_LPM /
MIPI_DSI_MSG_USE_LPM, then the expectation is that any data transfer
will be in HS mode.

That makes me confused as to the need for this patch.

  Dave

> DSI sink uses the @enable function to send the MIPI-DCS commands. In a
> typical DSI host, sink pipeline the @enable call chain start with the
> DSI host, and then the DSI sink which is the "wrong" order as DSI host
> @enable is called and switched to HS mode before DSI sink @enable.
>
> If the DSI host enables with the @enable_next_first flag then the
> @enable for the DSI sink will be called first before the @enable of
> the DSI host. This alter bridge init order makes sure that the MIPI-DCS
> commands send first and then switch to the HS mode properly by DSI host.
>
> This new flag @enable_next_first that any bridg can set to swap the
> order of @enable (and #disable) for that and the immediately next bridge.
>
> [enable]
> If a bridge sets @enable_next_first, then the @enable for the next bridge
> will be called first before enable of this bridge.
>
> [disable]
> If a bridge sets @enable_next_first, then the @disable for the next bridge
> will be called first before @disable of this bridge to reverse the @enable
> calling direction.
>
> eg:
> - Panel
> - Bridge 1
> - Bridge 2 enable_next_first
> - Bridge 3
> - Bridge 4 enable_next_first
> - Bridge 5 enable_next_first
> - Bridge 6
> - Encoder
>
> Would result in enable's being called as Encoder, Bridge 6, Bridge 3,
> Bridge 4, Bridge 5, Bridge 1, Bridge 2, Panel.
>
> and the result in disable's being called as Panel, Bridge 2, Bridge 1,
> Bridge 5, Bridge 4, Bridge 3, Bridge 6, Encoder.
>
> Signed-off-by: Jagan Teki 
> ---
> Changes for v7:
> - new patch
>
>  drivers/gpu/drm/drm_bridge.c | 171 ++-
>  include/drm/drm_bridge.h |   8 ++
>  2 files changed, 154 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index caf0f341e524..cdc2669b3512 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -577,6 +577,24 @@ void drm_bridge_chain_mode_set(struct drm_bridge *bridge,
>  }
>  EXPORT_SYMBOL(drm_bridge_chain_mode_set);
>
> +static void drm_atomic_bridge_call_disable(struct drm_bridge *bridge,
> +  struct drm_atomic_state *old_state)
> +{
> +   if (old_state && bridge->funcs->atomic_disable) {
> +   struct drm_bridge_state *old_bridge_state;
> +
> +   old_bridge_state =
> +   drm_atomic_get_old_bridge_state(old_state,
> +   bridge);
> +   if (WARN_ON(!old_bridge_state))
> +   return;
> +
> +   bridge->funcs->atomic_disable(bridge, old_bridge_state);
> +   } else if (bridge->funcs->disable) {
> +   bridge->funcs->disable(bridge);
> +   }
> +}
> +
>  /**
>   * drm_atomic_bridge_chain_disable - disables all bridges in the encoder 
> chain
>   * @bridge: bridge control structure
> @@ -587,33 +605,73 @@ EXPORT_SYMBOL(drm_bridge_chain_mode_set);
>   * starting from the last bridge to the first. These are called before 
> calling
>   * _encoder_helper_funcs.atomic_disable
>   *
> + * If a bridge sets @enable_next_first, then the @disable for the next bridge
> + * will be called first before @disable of this bridge to reverse the @enable
> + * calling direction.
> + *
> + * Example:
> + * Bridge A ---> Bridge B ---> Bridge C ---> Bridge D ---> Bridge E
> + *
> + * With enable_next_first flag enable in Bridge A, C, D then the resulting
> + * @disable order would be,
> + * Bridge C, Bridge D, Bridge E, Bridge A, Bridge B.
> + *
>   * Note: the bridge passed should be the one closest to the encoder
>   */
>  void drm_atomic_bridge_chain_disable(struct drm_bridge *bridge,
>  struct drm_atomic_state *old_state)
>  {
> struct drm_encoder *encoder;
> -   struct drm_bridge *iter;
> +   struct drm_bridge 

Re: [PATCH v7 02/12] drm: bridge: panel: Implement drmm_of_dsi_get_bridge helper

[Maxime Ripard]

On Wed, Mar 29, 2023 at 08:56:29PM +0530, Jagan Teki wrote:
> On Wed, Mar 29, 2023 at 8:33 PM Maxime Ripard  wrote:
> >
> > On Wed, Mar 29, 2023 at 06:46:08PM +0530, Jagan Teki wrote:
> > > Implement a DRM-managed action helper that returns the next DSI bridge
> > > in the chain.
> > >
> > > Unlike general bridge return helper drmm_of_get_bridge, this helper
> > > uses the dsi specific panel_or_bridge helper to find the next DSI
> > > device in the pipeline.
> > >
> > > Helper lookup a given downstream DSI device that has been added via
> > > child or OF-graph port or ports node.
> > >
> > > Upstream DSI looks for downstream devices using drm pointer, port and
> > > endpoint number. Downstream devices added via child node don't affect
> > > the port and endpoint number arguments.
> > >
> > > Signed-off-by: Jagan Teki 
> >
> > If you intend to use it with the sun4i driver, then don't. The sun4i
> > driver is barely using drm-managed resources, so chances are all its
> > resources will be freed by the time this action will run.
> 
> Any idea how to check all resources will be freed before this
> DRM-managed action helper runs? I did test the panel insertion and
> removal at runtime and I can see that the action helper
> (drmm_drm_panel_bridge_release) is triggered at removal time.
> 
> Here is the log for it.
> # insmod panel-bananapi-s070wv20-icn6211.ko
> [   11.411894] sun4i-drm display-engine: bound
> 1e0.display-frontend (ops 0xc0951eb4)
> [   11.420253] sun4i-drm display-engine: bound 1e6.display-backend
> (ops 0xc0951620)
> [   11.428128] sun4i-drm display-engine: bound 1e7.drc (ops 0xc0951150)
> [   11.435574] sun4i-drm display-engine: No panel or bridge found...
> RGB output disabled
> [   11.443484] sun4i-drm display-engine: bound 1c0c000.lcd-controller
> (ops 0xc094fdb0)
> [   11.451264] sun4i-drm display-engine: bound 1ca.dsi (ops 0xc0952f04)
> [   11.462479] [drm] Initialized sun4i-drm 1.0.0 20150629 for
> display-engine on minor 1
> [   11.963246] Console: switching to colour frame buffer device 100x30
> [   12.046329] sun4i-drm display-engine: [drm] fb0: sun4i-drmdrmfb
> frame buffer device
> [   12.082641] sun6i-mipi-dsi 1ca.dsi: Attached device s070wv20-ct16-icn62
> # rmmod panel-bananapi-s070wv20-icn6211.ko
> [   16.306388] Console: switching to colour dummy device 80x30
> [   16.466963] drmm_drm_panel_bridge_release: In

Enable KASAN, unload the DSI controller module or unbind its device,
and watch things go boom :)

Maxime


signature.asc
Description: PGP signature

Re: [PATCH v7 12/12] drm: sun4: dsi: Convert to bridge driver

[Maxime Ripard]

On Wed, Mar 29, 2023 at 09:08:17PM +0530, Jagan Teki wrote:
> On Wed, Mar 29, 2023 at 8:29 PM Maxime Ripard  wrote:
> >
> > Hi,
> >
> > The patch prefix should be drm/sun4i:
> 
> I did follow my previous prefix, I will update this.
> 
> >
> > On Wed, Mar 29, 2023 at 06:49:29PM +0530, Jagan Teki wrote:
> > > Convert the encoder to bridge driver in order to standardize on a
> > > single API by supporting all varients of downstream bridge devices.
> >
> > Which variant, and why do we need to convert to a bridge to support all of 
> > them?
> 
> Downstream bridge variants like DSI panel, DSI bridge and
> I2C-Configured DSI bridges. Bridge conversion would be required for
> the DSI host to access the more variety and complex downstream bridges
> in a standardized bridge chain way which is indeed complex for encoder
> driven DSI hosts.
> 
> >
> > > The drm_encoder can't be removed as it's exposed to userspace, so it
> > > then becomes a dumb encoder, without any operation implemented.
> > >
> > > Tested on DSI Panel, DSI Bridge, I2C-Configured DSI Bridge.
> > >
> > > Signed-off-by: Jagan Teki 
> >
> > [...]
> >
> > > +static const struct component_ops sun6i_dsi_ops;
> > > +
> > >  static int sun6i_dsi_attach(struct mipi_dsi_host *host,
> > >   struct mipi_dsi_device *device)
> > >  {
> > >   struct sun6i_dsi *dsi = host_to_sun6i_dsi(host);
> > > - struct drm_panel *panel = of_drm_find_panel(device->dev.of_node);
> >
> > That one looks unrelated. Why do you need that change?
> 
> This was replaced with drmm_of_dsi_get_bridge for lookup of both panel
> and bridge. I think I will separate this into another patch.

So, it looks to me that you're doing two (unrelated) things in that patch:

  - You modify the existing driver to be a bridge

  - And you support downstream device being bridges.

Both are orthogonal, can (and should!) be done separately, and I'm
pretty sure you don't actually need to do the former at all.

Maxime


signature.asc
Description: PGP signature

Re: [PATCH 2/2] drm/amd/display: Add previous prototype to 'optc3_wait_drr_doublebuffer_pending_clear'

[Hamza Mahfooz]

On 3/28/23 18:09, Caio Novais wrote:

Compiling AMD GPU drivers displays a warning:

drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_optc.c:294:6: warning: no 
previous prototype for ‘optc3_wait_drr_doublebuffer_pending_clear’ 
[-Wmissing-prototypes]

Get rid of it by adding a function prototype

'optc3_wait_drr_doublebuffer_pending_clear(struct timing_generator *optc)' on 
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.h

Signed-off-by: Caio Novais 
---
  drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.h | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.h 
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.h
index fb06dc9a4893..2e3ba6e2f336 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.h
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.h
@@ -331,6 +331,8 @@ void optc3_lock_doublebuffer_enable(struct timing_generator 
*optc);
  
  void optc3_lock_doublebuffer_disable(struct timing_generator *optc);
  
+void optc3_wait_drr_doublebuffer_pending_clear(struct timing_generator *optc);


I would prefer if you marked the function as static instead, since it is
only used in dcn30_optc.c.


+
  void optc3_set_drr_trigger_window(struct timing_generator *optc,
uint32_t window_start, uint32_t window_end);
  


--
Hamza

Re: [PATCH 1/2] drm/amd/display: Remove unused variable 'scl_enable'

[Hamza Mahfooz]

On 3/28/23 18:09, Caio Novais wrote:

Compiling AMD GPU drivers displays a warning:

drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/display_rq_dlg_calc_314.c: 
In function ‘dml_rq_dlg_get_dlg_params’:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/display_rq_dlg_calc_314.c:991:14:
 warning: variable ‘scl_enable’ set but not used [-Wunused-but-set-variable]

Get rid of it by removing the variable 'scl_enable'.

Signed-off-by: Caio Novais 


Applied, thanks!


---
  .../gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c | 2 --
  1 file changed, 2 deletions(-)

diff --git 
a/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c 
b/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c
index d1c2693a2e28..ea4eb66066c4 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c
@@ -988,7 +988,6 @@ static void dml_rq_dlg_get_dlg_params(
double hratio_c;
double vratio_l;
double vratio_c;
-   bool scl_enable;
  
  	unsigned int swath_width_ub_l;

unsigned int dpte_groups_per_row_ub_l;
@@ -1117,7 +1116,6 @@ static void dml_rq_dlg_get_dlg_params(
hratio_c = scl->hscl_ratio_c;
vratio_l = scl->vscl_ratio;
vratio_c = scl->vscl_ratio_c;
-   scl_enable = scl->scl_enable;
  
  	swath_width_ub_l = rq_dlg_param->rq_l.swath_width_ub;

dpte_groups_per_row_ub_l = rq_dlg_param->rq_l.dpte_groups_per_row_ub;


--
Hamza

Re: [PATCH v2 0/9] drm/i915: Replace kmap_atomic() with kmap_local_page()

[Fabio M. De Francesco]

On mercoledì 29 marzo 2023 09:32:11 CEST Zhao Liu wrote:
> From: Zhao Liu 
> 
> Hi list,
> 
> Sorry for a long delay since v1 [1]. This patchset is based on 197b6b6
> (Linux 6.3-rc4).
> 
> Welcome and thanks for your review and comments!
> 
> 
> # Purpose of this patchset
> 
> The purpose of this pacthset is to replace all uses of kmap_atomic() in
> i915 with kmap_local_page() because the use of kmap_atomic() is being
> deprecated in favor of kmap_local_page()[1]. And 92b64bd (mm/highmem:
> add notes about conversions from kmap{,_atomic}()) has declared the
> deprecation of kmap_atomic().
> 
> 
> # Motivation for deprecating kmap_atomic() and using kmap_local_page()
> 
> The main difference between atomic and local mappings is that local
> mappings doesn't disable page faults or preemption (the preemption is
> disabled for !PREEMPT_RT case, otherwise it only disables migration).
> 
> With kmap_local_page(), we can avoid the often unwanted side effect of
> unnecessary page faults and preemption disables.
> 
> 
> # Patch summary
> 
> Patch 1, 4-6 and 8-9 replace kamp_atomic()/kunmap_atomic() with
> kmap_local_page()/kunmap_local() directly. With thses local
> mappings, the page faults and preemption are allowed.
> 
> Patch 2 and 7 use memcpy_from_page() and memcpy_to_page() to replace
> kamp_atomic()/kunmap_atomic(). These two variants of memcpy()
> are based on the local mapping, so page faults and preemption
> are also allowed in these two interfaces.
> 
> Patch 3 replaces kamp_atomic()/kunmap_atomic() with kmap_local_page()/
> kunmap_local() and also diable page fault since the for special
> handling (pls see the commit message).
> 
> 
> # Changes since v1
> 
> * Dropped hot plug related description in commit message since it has
>   nothing to do with kmap_local_page().
> * Emphasized the motivation for using kmap_local_page() in commit
>   message.
> * Rebased patch 1 on f47e630 (drm/i915/gem: Typecheck page lookups) to
>   keep the "idx" variable of type pgoff_t here.
> * Used memcpy_from_page() and memcpy_to_page() to replace
>   kmap_local_page() + memcpy() in patch 2.
> 
> 
> # Reference
> 
> [1]:
> https://lore.kernel.org/lkml/20221017093726.2070674-1-zhao1.liu@linux.intel.c
> om/ [1]:
> https://lore.kernel.org/all/20220813220034.806698-1-ira.we...@intel.com ---
> Zhao Liu (9):
>   drm/i915: Use kmap_local_page() in gem/i915_gem_object.c
>   drm/i915: Use memcpy_[from/to]_page() in gem/i915_gem_pyhs.c
>   drm/i915: Use kmap_local_page() in gem/i915_gem_shmem.c
>   drm/i915: Use kmap_local_page() in gem/selftests/huge_pages.c
>   drm/i915: Use kmap_local_page() in gem/selftests/i915_gem_coherency.c
>   drm/i915: Use kmap_local_page() in gem/selftests/i915_gem_context.c
>   drm/i915: Use memcpy_from_page() in gt/uc/intel_uc_fw.c
>   drm/i915: Use kmap_local_page() in i915_cmd_parser.c
>   drm/i915: Use kmap_local_page() in gem/i915_gem_execbuffer.c
> 

I _think_ that the "long delay" you mentioned in the first sentence has paid 
off in full. 

I don't see things to improve (except all those "kamp_atomic()" typo in the 
patches summary; however, typos are only in the cover so I'm sure they won't 
hurt anybody). 

Each of the nine patches listed above looks good to me, so they are all…

Reviewed-by: Fabio M. De Francesco 

Thanks!

Fabio

PS: Obviously there was no need to reconfirm my tag for patch 3/9. A single 
tag that catches all patches is easier for a lazy person like me :-)

>
>  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c   | 10 +-
>  drivers/gpu/drm/i915/gem/i915_gem_object.c   |  8 +++-
>  drivers/gpu/drm/i915/gem/i915_gem_phys.c | 10 ++
>  drivers/gpu/drm/i915/gem/i915_gem_shmem.c|  6 --
>  drivers/gpu/drm/i915/gem/selftests/huge_pages.c  |  6 +++---
>  .../gpu/drm/i915/gem/selftests/i915_gem_coherency.c  | 12 
>  .../gpu/drm/i915/gem/selftests/i915_gem_context.c|  8 
>  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c |  5 +
>  drivers/gpu/drm/i915/i915_cmd_parser.c   |  4 ++--
>  9 files changed, 28 insertions(+), 41 deletions(-)
> 
> --
> 2.34.1

Re: [PATCH] drm/ttm: set TTM allocated pages as reserved

[Paolo Bonzini]

On 3/29/23 17:29, Christian König wrote:
First, is it a _host_ corruption or a guest corruption/crash?  A guest 
crash would be KVM doing exactly what it's meant to do: it detects the 
non-reserved, non-refcounted page and refuses to map it into the guest.


Yes I think that this is what happens.


Ok I was worried all the time that this was host corruption/crash; which 
obviously would have been much worse.



The use case and mapping is indeed valid as far as I can see, but
the handling that KVM does here is really problematic.

What needs to happen instead is that when both hva_to_pfn_fast() and 
hva_to_pfn_slow() fails you don't try to convert the PFN into a page and 
so also don't get a reference to the page.


This somehow needs to be communicated to the callers of hva_to_pfn() so 
that kvm_release_pfn() knows what to do.


There's a bit more complication here:

1) in the guest page fault path we can avoid taking the reference altogether

2) in other MMU-notifier-protected paths, we can also avoid taking the 
reference but we also must stop using kmap() in virt/kvm/pfncache.c.


3) other uses of kmap() must switch to MMU-notifier protection.


If the DRM people are okay with SetPageReserved() as a temporary hack, 
we can change or remove the WARN in kvm_is_zone_device_page(), since 
that is what you are referring to in the commit message.


Paolo

[PATCH v9 2/2] drm: add kms driver for loongson display controller

[Sui Jingfeng]

From: Sui Jingfeng 

Loongson display controller IP has been integrated in both Loongson
North Bridge chipset(ls7a1000 and ls7a2000) and Loongson SoCs(ls2k1000
and ls2k2000 etc), it even has been included in Loongson BMC products.

This display controller is a PCI device, it has two display pipe. For
the DC in LS7A1000 and LS2K1000 each way has a DVO output interface
which provide RGB888 signals, vertical & horizontal synchronisations,
and the pixel clock. Each CRTC is able to support 1920x1080@60Hz,
the maximum resolution is 2048x2048 according to the hardware spec.

For the DC in LS7A2000, each display pipe is equipped with a built-in
HDMI encoder which is compliant with HDMI 1.4 specification, thus it
support 3840x2160@30Hz. The first display pipe is also equipped with
a transparent vga encoder which is parallel with the HDMI encoder.
The DC in LS7A2000 is more complete, besides above feature, it has
two hardware cursors, two hardware vblank counter and two scanout
position recorders.

 v1 -> v2:
  1) Use hpd status reg when polling for ls7a2000
  2) Fix all warnings emerged when compile with W=1

 v2 -> v3:
  1) Add COMPILE_TEST in Kconfig and make the driver off by default
  2) Alphabetical sorting headers (Thomas)
  3) Untangle register access functions as much as possible (Thomas)
  4) Switch to TTM based memory manager and prefer cached mapping
 for Loongson SoC (Thomas)
  5) Add chip id detection method, now all models are distinguishable.
  6) Revise builtin HDMI phy driver, nearly all main stream mode
 below 4K@30Hz is tested, this driver supported these mode very
 well including clone display mode and extend display mode.

 v3 -> v4:
  1) Quickly fix a small mistake.

 v4 -> v5:
  1) Drop potential support for Loongson 2K series SoC temporary,
 this part should be resend with the DT binding patch in the future.
  2) Add per display pipe debugfs support to the builtin HDMI encoder.
  3) Rewrite atomic_update() for hardware cursors plane(Thomas)
  4) Rewrite encoder and connector initialization part, untangle it
 according to the chip(Thomas).

 v5 -> v6:
  1) Remove stray code which didn't get used, say lsdc_of_get_reserved_ram
  2) Fix all typos I could found, make sentences and code more readable
  3) Untangle lsdc_hdmi*_connector_detect() function according to the pipe
  4) After a serious consideration, we rename this driver as loongson.
 Because we also have drivers toward the LoongGPU IP in LS7A2000 and
 LS2K2000. Besides, there are also drivers about the external encoder,
 HDMI audio driver and vbios support etc. This patch only provide DC
 driver part, my teammate Li Yi believe that loongson will be more
 suitable for loongson graphics than lsdc in the long run.

 loongson.ko = LSDC + LoongGPU + encoders driver + vbios/DT ...

  v6 -> v7:
   1) Add prime support, self-sharing is works. sharing buffer with etnaviv
  is also tested, and its works with limitation.
   2) Implement buffer objects tracking with list_head.
   3) S3(sleep to RAM) is tested on ls3a5000+ls7a2000 evb and it works.
   4) Rewrite lsdc_bo_move, since ttm core stop allocating resources
  during BO creation. Patch V1 ~ V6 of this series no longer works
  on latest kernel. Thus, we send V7 to revival them.

  v7 -> v8:
   1) Zero a compile warnnings on 32-bit platform, compile with W=1
   2) Revise lsdc_bo_gpu_offset() and minor cleanup
   3) Pageflip tested on the virtual terminal with following commands

  modetest -M loongson -s 32:1920x1080 -v
  modetest -M loongson -s 34:1920x1080 -v -F tiles

 It works like a charm, when running pageflip test with dual screnn
 configuration, another two additional bo created by the modetest
 emerged, VRAM usage up to 40+MB, well we have at least 64MB, still
 enough.

 # cat bos

 bo[]: size: 8112kB VRAM
 bo[0001]: size:   16kB VRAM
 bo[0002]: size:   16kB VRAM
 bo[0003]: size:16208kB VRAM
 bo[0004]: size: 8112kB VRAM
 bo[0005]: size: 8112kB VRAM

  v8 -> v9:
   1) Select I2C and I2C_ALGOBIT in Kconfig and should depend on MMU.
   2) Using pci_get_domain_bus_and_slot to get the GPU device.
   3) Other minor improvements.

   Those patches are tested on ls3a5000 + ls7a1000 CRB, ls3a5000 + ls7a2000
   evb, and lemote a1901 board(ls3a4000 + ls7a1000). On loongson mips CPU,
   the write combine support should be enabled to get a decent performance
   for writing to the VRAM.

Signed-off-by: Li Yi 
Signed-off-by: Sui Jingfeng 
Signed-off-by: Sui Jingfeng <15330273...@189.cn>
---
 drivers/gpu/drm/Kconfig |   2 +
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/loongson/Kconfig|  17 +
 drivers/gpu/drm/loongson/Makefile   |  16 +
 drivers/gpu/drm/loongson/lsdc_crtc.c| 381 
 drivers/gpu/drm/loongson/lsdc_debugfs.c | 261 +++
 drivers/gpu/drm/loongson/lsdc_drv.c   

[PATCH v9 0/2] drm: add kms driver for loongson display controller

[Sui Jingfeng]

From: Sui Jingfeng 

Loongson display controller IP has been integrated in both Loongson
North Bridge chipset(ls7a1000 and ls7a2000) and Loongson SoCs(ls2k1000
and ls2k2000 etc), it even has been included in Loongson BMC products.

This display controller is a PCI device, it has two display pipe. For
the DC in LS7A1000 and LS2K1000 each way has a DVO output interface
which provide RGB888 signals, vertical & horizontal synchronisations,
and the pixel clock. Each CRTC is able to support 1920x1080@60Hz,
the maximum resolution is 2048x2048 according to the hardware spec.

For the DC in LS7A2000, each display pipe is equipped with a built-in
HDMI encoder which is compliant with HDMI 1.4 specification, thus it
support 3840x2160@30Hz. The first display pipe is also equipped with
a transparent vga encoder which is parallel with the HDMI encoder.
The DC in LS7A2000 is more complete, besides above feature, it has
two hardware cursors, two hardware vblank counter and two scanout
position recorders.

 v1 -> v2:
  1) Use hpd status reg when polling for ls7a2000
  2) Fix all warnings emerged when compile with W=1

 v2 -> v3:
  1) Add COMPILE_TEST in Kconfig and make the driver off by default
  2) Alphabetical sorting headers (Thomas)
  3) Untangle register access functions as much as possible (Thomas)
  4) Switch to TTM based memory manager and prefer cached mapping
 for Loongson SoC (Thomas)
  5) Add chip id detection method, now all models are distinguishable.
  6) Revise builtin HDMI phy driver, nearly all main stream mode
 below 4K@30Hz is tested, this driver supported these mode very
 well including clone display mode and extend display mode.

 v3 -> v4:
  1) Quickly fix a small mistake.

 v4 -> v5:
  1) Drop potential support for Loongson 2K series SoC temporary,
 this part should be resend with the DT binding patch in the future.
  2) Add per display pipe debugfs support to the builtin HDMI encoder.
  3) Rewrite atomic_update() for hardware cursors plane(Thomas)
  4) Rewrite encoder and connector initialization part, untangle it
 according to the chip(Thomas).

 v5 -> v6:
  1) Remove stray code which didn't get used, say lsdc_of_get_reserved_ram
  2) Fix all typos I could found, make sentences and code more readable
  3) Untangle lsdc_hdmi*_connector_detect() function according to the pipe
  4) After a serious consideration, we rename this driver as loongson.
 Because we also have drivers toward the LoongGPU IP in LS7A2000 and
 LS2K2000. Besides, there are also drivers about the external encoder,
 HDMI audio driver and vbios support etc. This patch only provide DC
 driver part, my teammate Li Yi believe that loongson will be more
 suitable for loongson graphics than lsdc in the long run.

 loongson.ko = LSDC + LoongGPU + encoders driver + vbios/DT ...

  v6 -> v7:
   1) Add prime support, self-sharing is works. sharing buffer with etnaviv
  is also tested, and its works with limitation.
   2) Implement buffer objects tracking with list_head.
   3) S3(sleep to RAM) is tested on ls3a5000+ls7a2000 evb and it works.
   4) Rewrite lsdc_bo_move, since ttm core stop allocating resources
  during BO creation. Patch V1 ~ V6 of this series no longer works
  on latest kernel. Thus, we send V7 to revival them.

  v7 -> v8:
   1) Zero a compile warnnings on 32-bit platform, compile with W=1
   2) Revise lsdc_bo_gpu_offset() and minor cleanup
   3) Pageflip tested on the virtual terminal with following commands

  modetest -M loongson -s 32:1920x1080 -v
  modetest -M loongson -s 34:1920x1080 -v -F tiles

 It works like a charm, when running pageflip test with dual screnn
 configuration, another two additional bo created by the modetest
 emerged, VRAM usage up to 40+MB, well we have at least 64MB, still
 enough.

 # cat bos

 bo[]: size: 8112kB VRAM
 bo[0001]: size:   16kB VRAM
 bo[0002]: size:   16kB VRAM
 bo[0003]: size:16208kB VRAM
 bo[0004]: size: 8112kB VRAM
 bo[0005]: size: 8112kB VRAM

  v8 -> v9:
   1) Select I2C and I2C_ALGOBIT in Kconfig and should depend on MMU.
   2) Using pci_get_domain_bus_and_slot to get the GPU device.
   3) Other minor improvements.

Sui Jingfeng (2):
  MAINTAINERS: add maintainers for DRM LOONGSON driver
  drm: add kms driver for loongson display controller

 MAINTAINERS |   7 +
 drivers/gpu/drm/Kconfig |   2 +
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/loongson/Kconfig|  17 +
 drivers/gpu/drm/loongson/Makefile   |  16 +
 drivers/gpu/drm/loongson/lsdc_crtc.c| 381 
 drivers/gpu/drm/loongson/lsdc_debugfs.c | 261 +++
 drivers/gpu/drm/loongson/lsdc_drv.c | 508 +
 drivers/gpu/drm/loongson/lsdc_drv.h | 324 ++
 drivers/gpu/drm/loongson/lsdc_gem.c | 294 +
 

[PATCH v9 1/2] MAINTAINERS: add maintainers for DRM LOONGSON driver

[Sui Jingfeng]

From: Sui Jingfeng 

 This patch add myself as maintainer to drm loongson driver

Signed-off-by: Sui Jingfeng 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9736e04d3bd3..d258c5b54407 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6919,6 +6919,13 @@ T:   git git://anongit.freedesktop.org/drm/drm-misc
 F: drivers/gpu/drm/lima/
 F: include/uapi/drm/lima_drm.h
 
+DRM DRIVERS FOR LOONGSON
+M: Sui Jingfeng 
+L: dri-devel@lists.freedesktop.org
+S: Supported
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: drivers/gpu/drm/loongson/
+
 DRM DRIVERS FOR MEDIATEK
 M: Chun-Kuang Hu 
 M: Philipp Zabel 
-- 
2.25.1

Re: [PATCH] drm/msm/adreno: adreno_gpu: Use suspend() instead of idle() on load error

[Konrad Dybcio]

On 29.03.2023 16:37, Johan Hovold wrote:
> On Wed, Mar 29, 2023 at 04:04:44PM +0200, Konrad Dybcio wrote:
>> If we fail to initialize the GPU for whatever reason (say we don't
>> embed the GPU firmware files in the initrd), the error path involves
>> pm_runtime_put_sync() which then calls idle() instead of suspend().
>>
>> This is suboptimal, as it means that we're not going through the
>> clean shutdown sequence. With at least A619_holi, this makes the GPU
>> not wake up until it goes through at least one more start-fail-stop
>> cycle. Fix that by using pm_runtime_put_sync_suspend to force a clean
>> shutdown.
> 
> This does not sound right. If pm_runtime_put_sync() fails to suspend the
> device when the usage count drops to zero, then you have a bug somewhere
> else.
I was surprised to see that it was not called as well, but I wasn't able
to track it down before..

> 
> Also since commit 2c087a336676 ("drm/msm/adreno: Load the firmware
> before bringing up the hardware") the firmware is loaded before even
> hitting these paths so the above description does not sound right in
> that respect either (or is missing some details).
..but I did some more digging and I found that the precise "firmware"
that fails is the ZAP blob, which is not checked like SQE in the
commit you mentioned!

Now I don't think that we can easily check for it as-is since
zap_shader_load_mdt() does the entire find-load-authenticate
dance which is required with secure assets, but it's obviously
possible to rip out the find-load part of that and go on from
there.

Do you think that would be a better solution?

Konrad

> 
>> Test cases:
>> 1. firmware baked into kernel
>> 2. error loading fw in initrd -> load from rootfs at DE start
>>
>> Both succeed on A619_holi (SM6375) and A630 (SDM845).
>>
>> Fixes: 0d997f95b70f ("drm/msm/adreno: fix runtime PM imbalance at gpu load")
>> Signed-off-by: Konrad Dybcio 
>> ---
>>  drivers/gpu/drm/msm/adreno/adreno_device.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
>> b/drivers/gpu/drm/msm/adreno/adreno_device.c
>> index f61896629be6..59f3302e8167 100644
>> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
>> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
>> @@ -477,7 +477,7 @@ struct msm_gpu *adreno_load_gpu(struct drm_device *dev)
>>  return gpu;
>>  
>>  err_put_rpm:
>> -pm_runtime_put_sync(>dev);
>> +pm_runtime_put_sync_suspend(>dev);
>>  err_disable_rpm:
>>  pm_runtime_disable(>dev);
> 
> Johan

Re: [PATCH v14 14/14] drm/msm/dp: set self refresh aware based on PSR support

[Doug Anderson]

Hi,

On Wed, Mar 29, 2023 at 8:16 AM Vinod Polimera
 wrote:
>
>
>
> > -Original Message-
> > From: Stephen Boyd 
> > Sent: Monday, March 27, 2023 9:58 PM
> > To: Bjorn Andersson ; Vinod Polimera (QUIC)
> > 
> > Cc: dri-devel@lists.freedesktop.org; linux-arm-...@vger.kernel.org;
> > freedr...@lists.freedesktop.org; devicet...@vger.kernel.org; linux-
> > ker...@vger.kernel.org; robdcl...@gmail.com; diand...@chromium.org;
> > Kalyan Thota (QUIC) ;
> > dmitry.barysh...@linaro.org; Kuogee Hsieh (QUIC)
> > ; Vishnuvardhan Prodduturi (QUIC)
> > ; Bjorn Andersson (QUIC)
> > ; Abhinav Kumar (QUIC)
> > ; Sankeerth Billakanti (QUIC)
> > 
> > Subject: Re: [PATCH v14 14/14] drm/msm/dp: set self refresh aware based
> > on PSR support
> >
> > Quoting Bjorn Andersson (2023-03-26 09:35:56)
> > > On Sun, Mar 26, 2023 at 09:27:23AM -0700, Bjorn Andersson wrote:
> > > > On Thu, Mar 02, 2023 at 10:03:17PM +0530, Vinod Polimera wrote:
> > > > > For the PSR to kick in, self_refresh_aware has to be set.
> > > > > Initialize it based on the PSR support for the eDP interface.
> > > > >
> > > >
> > > > When I boot my sc8280xp devices (CRD and X13s) to console with this
> > > > patch included I get a login prompt, and then there are no more screen
> > > > updates.
> > > >
> > > > Switching virtual terminal (ctrl+alt+fN) causes the screen to redraw.
> > > >
> > > > Blindly login in and launching Wayland works and from then on screen
> > > > updates works as expected.
> > > >
> > > > Switching from Wayland to another virtual terminal causes the problem
> > to
> > > > re-appear, no updates after the initial refresh, switching back go the
> > > > Wayland-terminal crashed the machine.
> > > >
> > >
> > > Also, trying to bring the eDP-screen back from DPMS gives me:
> > >
> > > <3>[ 2355.218099] [drm:dp_catalog_ctrl_set_pattern_state_bit [msm]]
> > *ERROR* set state_bit for link_train=1 failed
> > > <3>[ 2355.218926] [drm:dp_ctrl_setup_main_link [msm]] *ERROR* link
> > training #1 failed. ret=-110
> > > <3>[ 2355.262859] [drm:dp_catalog_ctrl_set_pattern_state_bit [msm]]
> > *ERROR* set state_bit for link_train=1 failed
> > > <3>[ 2355.263600] [drm:dp_ctrl_setup_main_link [msm]] *ERROR* link
> > training #1 failed. ret=-110
> > > <3>[ 2355.305211] [drm:dp_catalog_ctrl_set_pattern_state_bit [msm]]
> > *ERROR* set state_bit for link_train=1 failed
> > > <3>[ 2355.305955] [drm:dp_ctrl_setup_main_link [msm]] *ERROR* link
> > training #1 failed. ret=-110
> > > <3>[ 2355.345250] [drm:dp_catalog_ctrl_set_pattern_state_bit [msm]]
> > *ERROR* set state_bit for link_train=1 failed
> > > <3>[ 2355.346026] [drm:dp_ctrl_setup_main_link [msm]] *ERROR* link
> > training #1 failed. ret=-110
> > > <3>[ 2355.405650] [drm:dp_display_process_hpd_high [msm]] *ERROR*
> > failed to complete DP link training
> > > <3>[ 2355.668988]
> > [drm:dpu_encoder_phys_vid_wait_for_commit_done:488] [dpu
> > error]vblank timeout
> > > <3>[ 2355.669030] [drm:dpu_kms_wait_for_commit_done:510] [dpu
> > error]wait for commit done returned -110
> > > <3>[ 2355.699989] [drm:dpu_encoder_frame_done_timeout:2398] [dpu
> > error]enc35 frame done timeout
> > >
> > > And then the machine just resets.
> > >
> >
> > I saw similar behavior on ChromeOS after we picked the PSR patches into
> > our kernel. I suspect it's the same problem. I switched back and forth
> > between VT2 and the OOBE screen with ctrl+alt+forward and that showed
> > what I typed on the virtual terminal after switching back and forth.
> > It's like the redraw only happens once on the switch and never again. I
> > switched back and forth enough times that it eventually crashed the
> > kernel and rebooted. This was on CRD (sc7280-herobrine-crd.dts).
> >
> > There's an animation on the OOBE screen that is working though, so
> > perhaps PSR is working with the chrome compositor but not the virtual
> > terminal? I haven't investigated.
>
> I was able to reproduce the issue where in virtual terminal, I don't see any 
> screen refresh despite typing in.
> In the VT mode, I see that PSR is entered, but despite typing in there are no 
> atomic commits triggered, hence the last buffer was always refreshed.
>
> Queries from my side to Rob & Doug:
> 1) In VT mode, does the framework operates in single buffer mode without any 
> commit for new updates ?
> 2) if above is true then, how does driver know if the framework operates in 
> single buffer mode, to make any appropriate action
> 3) what is the expected behavior with the driver here ? should it return 
> atomic_check failure, for single buffer mode operation or, it should exit PSR 
> ?
> 4) is there any HINT passed down to the driver so that we can bank on it and 
> act accordingly?

I haven't looked at this detail about PSR before, and I left my
PSR-enabled device at home so I can't easily test this right now. That
being said, from a bit of searching I would guess that
msm_framebuffer_dirtyfb() is somehow involved here. Are things better
if you get rid of the test 

Re: [PATCH 1/2] dt-bindings: display: exynos: dsim: Add 'lane-polarities'

[Jagan Teki]

On Wed, Mar 29, 2023 at 8:12 PM Fabio Estevam  wrote:
>
> From: Fabio Estevam 
>
> The Samsung DSIM IP block allows the inversion of the clock and
> data lanes.
>
> Add an optional property called 'lane-polarities' that describes the
> polarities of the MIPI DSI clock and data lanes.
>
> This is property is useful for properly describing the hardware
> when the board designer decided to switch the polarities of the MIPI DSI
> clock and/or data lanes.
>
> Signed-off-by: Fabio Estevam 
> ---

Reviewed-by: Jagan Teki 

Re: [PATCH 2/2] drm/exynos: Implement support for DSI clock and data lane polarity swap

[Jagan Teki]

On Wed, Mar 29, 2023 at 8:12 PM Fabio Estevam  wrote:
>
> From: Marek Vasut 
>
> Implement support for DSI clock and data lane DN/DP polarity swap by
> means of decoding 'lane-polarities' DT property. The controller does
> support DN/DP swap of clock lane and all data lanes, the controller
> does not support polarity swap of individual data lane bundles, add
> a check which verifies all data lanes have the same polarity.
>
> This has been validated on an imx8mm board that actually has the MIPI DSI
> clock lanes inverted.
>
> Signed-off-by: Marek Vasut 
> Signed-off-by: Fabio Estevam 
> ---

Prefix would be "drm: bridge: samsung-dsim: "

Otherwise look good to me, I will give a test and update.

Reviewed-by: Jagan Teki