Re: [PATCH] drm/i915/pcode: Wait 10 seconds for pcode to settle

[Gwan-gyeong Mun]

On 1/27/23 11:00 AM, Andi Shyti wrote:

Hi Gwan-gyeong,

thanks for the review and the thorough explanation.

On Fri, Jan 27, 2023 at 08:50:26AM +0200, Gwan-gyeong Mun wrote:



On 1/11/23 5:36 PM, Andi Shyti wrote:

On Wed, Jan 11, 2023 at 03:18:38PM +0200, Jani Nikula wrote:

On Wed, 11 Jan 2023, Andi Shyti  wrote:

From: Aravind Iddamsetty 

During module load not all the punit transaction have completed
and we might end up timing out, as shown by the following
warning:


Root cause?


Hi Andi, looking at the log where this problem is reported,

https://gitlab.freedesktop.org/drm/intel/-/issues/7814

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1294/bat-atsm-1/igt@i915_module_l...@resize-bar.html#dmesg-warnings17324

<4> [268.276908] i915 :4d:00.0: drm_WARN_ON_ONCE(timeout_base_ms > 3)

In the code above, the call stack is output, and the return value of
intel_pcode_init() returns -11 (-EAGAIN).

<3> [268.329058] i915 :4d:00.0: [drm] *ERROR* gt0: intel_pcode_init
failed -11


If you simplify the function call flow, you can see it as below. (The call
of _wait_for(COND, timeout_base_ms * 1000, 10, 10) in skl_pcode_request() is
omitted)

-
intel_pcode_init()
  |
  +-> skl_pcode_request(uncore, DG1_PCODE_STATUS,
DG1_UNCORE_GET_INIT_STATUS,
DG1_UNCORE_INIT_STATUS_COMPLETE,
DG1_UNCORE_INIT_STATUS_COMPLETE, 18);
|
+-> skl_pcode_try_request()
  |
  +->  *status = __snb_pcode_rw(uncore, mbox, , NULL,
500, 0, true);

-
static int __snb_pcode_rw(struct intel_uncore *uncore, u32 mbox,
  u32 *val, u32 *val1,
  int fast_timeout_us, int slow_timeout_ms,
  bool is_read)
{
...

if (intel_uncore_read_fw(uncore, GEN6_PCODE_MAILBOX) & GEN6_PCODE_READY)
return -EAGAIN;

intel_uncore_write_fw(uncore, GEN6_PCODE_DATA, *val);
intel_uncore_write_fw(uncore, GEN6_PCODE_DATA1, val1 ? *val1 : 0);
intel_uncore_write_fw(uncore,
  GEN6_PCODE_MAILBOX, GEN6_PCODE_READY | mbox);

if (__intel_wait_for_register_fw(uncore,
 GEN6_PCODE_MAILBOX,
 GEN6_PCODE_READY, 0,
 fast_timeout_us,
 slow_timeout_ms,
 ))
return -ETIMEDOUT;

...
}
-

The case where skl_pcode_request() returns -EAGAIN can be considered as the
following scenario.
1. 1. When checking the GEN6_PCODE_MAILBOX register status before writing
the value to the GEN6_PCODE_DATA register in __snb_pcode_rw(), it is always
BUSY


correct! We fail with EAGAIN because we are not able to
communicate with the punit because the punit is busy.

Talking about this case we are in boot time and the gpu is
performing its boot routine, the punit as well. While the punit
is working we try communicate with it, but unfortunately, being
busy, we fail with -EAGAIN exactly where you pointed.

Adding an extra wait_for_register_fw, i.e. waiting until the
PCODE_READY register tells that the punit is ready, makes sure
that the read/write will succeed.

Thus Chris has added a 10 seconds wait before the very first read
and write. If the punit is not ready we don't fail with -EAGAIN
and give up the driver loading as it happens now. But we give it
another chance trying to probe it again later.


2. _wait_for(COND, timeout_base_ms * 1000, 10, 10) of skl_pcode_request()
returns -EAGAIN if the GEN6_PCODE_MAILBOX register indicates BUSY even after
waiting 500us after writing a value to the GEN6_PCODE_DATA register in
__snb_pcode_rw()


Isn't it the same as '1'?


(Even if skl_pcode_request() gives a timeout of 180 seconds, the time used
each time __snb_pcode_rw() is called is up to 500us. The rest of the time is
used for sleep.)


There is one big, massive, huge difference... the timeout in
skl_pcode_request() after the read/write, not before. So that at
the first communication we fail, return -EAGAIN and give up
probing without starting any timer.

Be aware of the fact that the timeout is not for the current
communication, but for the next one. De facto we start the
timeout after communicating, this makes sure that the next
communication will work.

But no one makes sure that the very first communication works
during probe. Thus the extra wait.


Hi Andi,
In the call flow invoked by intel_pcode_init(), I've added brief 
comments where further clarification is needed in this scenario, and a 
description of the suspicious scenario at the bottom.

Re: linux-6.2-rc4+ hangs on poweroff/reboot: Bisected

[Linux kernel regression tracking (Thorsten Leemhuis)]

On 27.01.23 20:46, Chris Clayton wrote:
> [Resend because the mail client on my phone decided to turn HTML on behind my 
> back, so my reply got bounced.]
> 
> Thanks Thorsten.
> 
> I did try to revert but it didnt revert cleanly and I don't have the 
> knowledge to fix it up.
> 
> The patch was part of a merge that included a number of related patches. 
> Tomorrow, I'll try to revert the lot and report
> back.

You are free to do so, but there is no need for that from my side. I
only wanted to know if a simple revert would do the trick; if it
doesn't, it in my experience often is best to leave things to the
developers of the code in question, as they know it best and thus have a
better idea which hidden side effect a more complex revert might have.

Ciao, Thorsten

> On 27/01/2023 11:20, Linux kernel regression tracking (Thorsten Leemhuis) 
> wrote:
>> Hi, this is your Linux kernel regression tracker. Top-posting for once,
>> to make this easily accessible to everyone.
>>
>> @nouveau-maintainers, did anyone take a look at this? The report is
>> already 8 days old and I don't see a single reply. Sure, we'll likely
>> get a -rc8, but still it would be good to not fix this on the finish line.
>>
>> Chris, btw, did you try if you can revert the commit on top of latest
>> mainline? And if so, does it fix the problem?
>>
>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>> --
>> Everything you wanna know about Linux kernel regression tracking:
>> https://linux-regtracking.leemhuis.info/about/#tldr
>> If I did something stupid, please tell me, as explained on that page.
>>
>> #regzbot poke
>>
>> On 19.01.23 15:33, Linux kernel regression tracking (Thorsten Leemhuis)
>> wrote:
>>> [adding various lists and the two other nouveau maintainers to the list
>>> of recipients]
>>
>>> On 18.01.23 21:59, Chris Clayton wrote:
 Hi.

 I build and installed the lastest development kernel earlier this week. 
 I've found that when I try the laptop down (or
 reboot it), it hangs right at the end of closing the current session. The 
 last line I see on  the screen when rebooting is:

sd 4:0:0:0: [sda] Synchronising SCSI cache

 when closing down I see one additional line:

sd 4:0:0:0 [sda]Stopping disk

 In both cases the machine then hangs and I have to hold down the power 
 button fot a few seconds to switch it off.

 Linux 6.1 is OK but 6.2-rc1 hangs, so I bisected between this two and 
 landed on:

# first bad commit: [0e44c21708761977dcbea9b846b51a6fb684907a] 
 drm/nouveau/flcn: new code to load+boot simple HS FWs
 (VPR scrubber)

 I built and installed a kernel with 
 f15cde64b66161bfa74fb58f4e5697d8265b802e (the parent of the bad commit) 
 checked out
 and that shuts down and reboots fine. It the did the same with the bad 
 commit checked out and that does indeed hang, so
 I'm confident the bisect outcome is OK.

 Kernels 6.1.6 and 5.15.88 are also OK.

 My system had dual GPUs - one intel and one NVidia. Related extracts from 
 'lscpi -v' is:

 00:02.0 VGA compatible controller: Intel Corporation CometLake-H GT2 [UHD 
 Graphics] (rev 05) (prog-if 00 [VGA controller])
 Subsystem: CLEVO/KAPOK Computer CometLake-H GT2 [UHD Graphics]

 Flags: bus master, fast devsel, latency 0, IRQ 142

 Memory at c200 (64-bit, non-prefetchable) [size=16M]

 Memory at a000 (64-bit, prefetchable) [size=256M]

 I/O ports at 5000 [size=64]

 Expansion ROM at 000c [virtual] [disabled] [size=128K]

 Capabilities: [40] Vendor Specific Information: Len=0c 

 Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00

 Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit-

 Capabilities: [d0] Power Management version 2

 Kernel driver in use: i915

 Kernel modules: i915


 01:00.0 VGA compatible controller: NVIDIA Corporation TU117M [GeForce GTX 
 1650 Ti Mobile] (rev a1) (prog-if 00 [VGA
 controller])
 Subsystem: CLEVO/KAPOK Computer TU117M [GeForce GTX 1650 Ti Mobile]
 Flags: bus master, fast devsel, latency 0, IRQ 141
 Memory at c400 (32-bit, non-prefetchable) [size=16M]
 Memory at b000 (64-bit, prefetchable) [size=256M]
 Memory at c000 (64-bit, prefetchable) [size=32M]
 I/O ports at 4000 [size=128]
 Expansion ROM at c300 [disabled] [size=512K]
 Capabilities: [60] Power Management version 3
 Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
 Capabilities: [78] Express Legacy Endpoint, MSI 00
 Kernel driver in use: nouveau
 Kernel modules: nouveau

 DRI_PRIME=1 

[PATCH 2/2] drm/bridge: imx: Add i.MX93 parallel display format configuration support

[Liu Ying]

NXP i.MX93 mediamix blk-ctrl contains one DISPLAY_MUX register which
configures parallel display format by using the "PARALLEL_DISP_FORMAT"
field. Add a DRM bridge driver to support the display format configuration.

Signed-off-by: Liu Ying 
---
 drivers/gpu/drm/bridge/imx/Kconfig  |   8 +
 drivers/gpu/drm/bridge/imx/Makefile |   1 +
 drivers/gpu/drm/bridge/imx/imx93-pdfc.c | 209 
 3 files changed, 218 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/imx/imx93-pdfc.c

diff --git a/drivers/gpu/drm/bridge/imx/Kconfig 
b/drivers/gpu/drm/bridge/imx/Kconfig
index 608f47f41bcd..adbd75a924d1 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -44,4 +44,12 @@ config DRM_IMX8QXP_PIXEL_LINK_TO_DPI
  Choose this to enable pixel link to display pixel interface(PXL2DPI)
  found in Freescale i.MX8qxp processor.
 
+config DRM_IMX93_PARALLEL_DISP_FMT_CONFIG
+   tristate "NXP i.MX93 parallel display format configuration"
+   depends on OF
+   select DRM_KMS_HELPER
+   help
+ Choose this to enable parallel display format configuration
+ found in NXP i.MX93 processor.
+
 endif # ARCH_MXC || COMPILE_TEST
diff --git a/drivers/gpu/drm/bridge/imx/Makefile 
b/drivers/gpu/drm/bridge/imx/Makefile
index aa90ec8d5433..e88821733770 100644
--- a/drivers/gpu/drm/bridge/imx/Makefile
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o
 obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
 obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK) += imx8qxp-pixel-link.o
 obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK_TO_DPI) += imx8qxp-pxl2dpi.o
+obj-$(CONFIG_DRM_IMX93_PARALLEL_DISP_FMT_CONFIG) += imx93-pdfc.o
diff --git a/drivers/gpu/drm/bridge/imx/imx93-pdfc.c 
b/drivers/gpu/drm/bridge/imx/imx93-pdfc.c
new file mode 100644
index ..a891b1f6743a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx93-pdfc.c
@@ -0,0 +1,209 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright 2022,2023 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define DRIVER_NAME"imx93_pdfc"
+
+#define DISPLAY_MUX0x60
+#define  PARALLEL_DISP_FORMAT  0x700
+
+enum imx93_pdfc_format {
+   RGB888_TO_RGB888 = 0x0,
+   RGB888_TO_RGB666 = 0x1 << 8,
+   RGB565_TO_RGB565 = 0x2 << 8,
+};
+
+struct imx93_pdfc {
+   struct drm_bridge bridge;
+   struct drm_bridge *next_bridge;
+   struct device *dev;
+   struct regmap *regmap;
+   u32 format;
+};
+
+static int imx93_pdfc_bridge_attach(struct drm_bridge *bridge,
+   enum drm_bridge_attach_flags flags)
+{
+   struct imx93_pdfc *pdfc = bridge->driver_private;
+
+   return drm_bridge_attach(bridge->encoder, pdfc->next_bridge, bridge, 
flags);
+}
+
+static void
+imx93_pdfc_bridge_atomic_enable(struct drm_bridge *bridge,
+   struct drm_bridge_state *old_bridge_state)
+{
+   struct imx93_pdfc *pdfc = bridge->driver_private;
+
+   regmap_update_bits(pdfc->regmap, DISPLAY_MUX, PARALLEL_DISP_FORMAT,
+  pdfc->format);
+}
+
+static const u32 imx93_pdfc_bus_output_fmts[] = {
+   MEDIA_BUS_FMT_RGB888_1X24,
+   MEDIA_BUS_FMT_RGB666_1X18,
+   MEDIA_BUS_FMT_RGB565_1X16,
+   MEDIA_BUS_FMT_FIXED
+};
+
+static bool imx93_pdfc_bus_output_fmt_supported(u32 fmt)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(imx93_pdfc_bus_output_fmts); i++) {
+   if (imx93_pdfc_bus_output_fmts[i] == fmt)
+   return true;
+   }
+
+   return false;
+}
+
+static u32 *
+imx93_pdfc_bridge_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
+   struct drm_bridge_state 
*bridge_state,
+   struct drm_crtc_state *crtc_state,
+   struct drm_connector_state 
*conn_state,
+   u32 output_fmt,
+   unsigned int *num_input_fmts)
+{
+   u32 *input_fmts;
+
+   if (!imx93_pdfc_bus_output_fmt_supported(output_fmt))
+   return NULL;
+
+   input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
+   if (!input_fmts)
+   return NULL;
+
+   switch (output_fmt) {
+   case MEDIA_BUS_FMT_RGB888_1X24:
+   case MEDIA_BUS_FMT_RGB565_1X16:
+   input_fmts[0] = output_fmt;
+   break;
+   case MEDIA_BUS_FMT_RGB666_1X18:
+   case MEDIA_BUS_FMT_FIXED:
+   input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
+   break;
+   }
+
+   *num_input_fmts = 1;
+
+   return input_fmts;
+}
+
+static int imx93_pdfc_bridge_atomic_check(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+   

[PATCH 1/2] dt-bindings: display: bridge: Add NXP i.MX93 parallel display format configuration

[Liu Ying]

NXP i.MX93 mediamix blk-ctrl contains one DISPLAY_MUX register which
configures parallel display format by using the "PARALLEL_DISP_FORMAT"
field. Add device tree bindings for the display format configuration.

Signed-off-by: Liu Ying 
---
 .../display/bridge/nxp,imx93-pdfc.yaml| 78 +++
 1 file changed, 78 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/nxp,imx93-pdfc.yaml

diff --git 
a/Documentation/devicetree/bindings/display/bridge/nxp,imx93-pdfc.yaml 
b/Documentation/devicetree/bindings/display/bridge/nxp,imx93-pdfc.yaml
new file mode 100644
index ..a84bfb46b01d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/nxp,imx93-pdfc.yaml
@@ -0,0 +1,78 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/nxp,imx93-pdfc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP i.MX93 Parallel Display Format Configuration
+
+maintainers:
+  - Liu Ying 
+
+description: |
+  The i.MX93 mediamix blk-ctrl contains one DISPLAY_MUX register which
+  configures parallel display format by using the "PARALLEL_DISP_FORMAT"
+  field.
+
+properties:
+  compatible:
+const: nxp,imx93-pdfc
+
+  reg:
+maxItems: 1
+
+  ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+  port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Input port node to receive pixel data.
+
+  port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: Output port node to downstream pixel data receivers.
+
+required:
+  - port@0
+  - port@1
+
+required:
+  - compatible
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+
+blk-ctrl {
+#address-cells = <1>;
+#size-cells = <1>;
+
+bridge@60 {
+compatible = "nxp,imx93-pdfc";
+reg = <0x60 0x4>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+
+pdfc_from_lcdif: endpoint {
+remote-endpoint = <_to_pdfc>;
+};
+};
+
+port@1 {
+reg = <1>;
+
+pdfc_to_panel: endpoint {
+remote-endpoint = <_from_pdfc>;
+};
+};
+};
+};
+};
-- 
2.37.1

[PATCH 0/2] drm/bridge: imx: Add i.MX93 parallel display format configuration support

[Liu Ying]

Hi,

This patch aims to add NXP i.MX93 parallel display format configuration
DRM bridge driver support. i.MX93 mediamix blk-ctrl contains one
DISPLAY_MUX register which configures parallel display format by using
the "PARALLEL_DISP_FORMAT" field. i.MX93 LCDIF display controller's
parallel output connects with this piece of small logic to configure
parallel display format.

Patch 1/2 adds NXP i.MX93 parallel display format configuration dt-bindings.

Patch 2/2 adds NXP i.MX93 parallel display format configuration DRM bridge
driver support.

Liu Ying (2):
  dt-bindings: display: bridge: Add NXP i.MX93 parallel display format
configuration
  drm/bridge: imx: Add i.MX93 parallel display format configuration
support

 .../display/bridge/nxp,imx93-pdfc.yaml|  78 +++
 drivers/gpu/drm/bridge/imx/Kconfig|   8 +
 drivers/gpu/drm/bridge/imx/Makefile   |   1 +
 drivers/gpu/drm/bridge/imx/imx93-pdfc.c   | 209 ++
 4 files changed, 296 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/nxp,imx93-pdfc.yaml
 create mode 100644 drivers/gpu/drm/bridge/imx/imx93-pdfc.c

-- 
2.37.1

Re: [PATCH] drm/i915/guc: Fix missing ecodes

[John Harrison]

On 1/26/2023 11:17, Teres Alexis, Alan Previn wrote:

Firstly, thanks for catching this miss.
Since I only have one trivial nit and one non-blocker ask.
and the non-blocker ask will not impact the patch intent as it merely
tweaks an existing debug message, I believe we have an rb:

Reviewed-by: Alan Previn 

On Tue, 2023-01-24 at 16:49 -0800, Harrison, John C wrote:

From: John Harrison 

Error captures are tagged with an 'ecode'. This is a pseduo-unique magic
number that is meant to distinguish similar seeming bugs with
different underlying signatures. It is a combination of two ring state
registers. Unfortunately, the register state being used is only valid
in execlist mode. In GuC mode, the register state exists in a separate
list of arbitrary register address/value pairs rather than the named
entry structure. So, search through that list to find the two exciting
registers and copy them over to the structure's named members.

Signed-off-by: John Harrison 
Fixes: a6f0f9cf330a ("drm/i915/guc: Plumb GuC-capture into gpu_coredump")
Cc: Alan Previn 
Cc: Umesh Nerlige Ramappa 
Cc: Lucas De Marchi 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: Matt Roper 
Cc: Aravind Iddamsetty 
Cc: Michael Cheng 
Cc: Matthew Brost 
Cc: Bruce Chang 
Cc: Daniele Ceraolo Spurio 
Cc: Matthew Auld 
---
  .../gpu/drm/i915/gt/uc/intel_guc_capture.c    | 22 +++
  1 file changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index 1c1b85073b4bd..4e0b06ceed96d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -1571,6 +1571,27 @@ int intel_guc_capture_print_engine_node(struct 
drm_i915_error_state_buf *ebuf,
  
  #endif //CONFIG_DRM_I915_CAPTURE_ERROR
  
+static void guc_capture_find_ecode(struct intel_engine_coredump *ee)

+{
+   struct gcap_reg_list_info *reginfo;
+   struct guc_mmio_reg *regs;
+   i915_reg_t reg_ipehr = RING_IPEHR(0);
+   i915_reg_t reg_instdone = RING_INSTDONE(0);
+   int i;
+
+   if (!ee->guc_capture_node)
+   return;
+
+   reginfo = ee->guc_capture_node->reginfo + 
GUC_CAPTURE_LIST_TYPE_ENGINE_INSTANCE;
+   regs = reginfo->regs;
+   for (i = 0; i < reginfo->num_regs; i++) {
+   if (regs[i].offset == reg_ipehr.reg)
+   ee->ipehr = regs[i].value;
+   if (regs[i].offset == reg_instdone.reg)

nit: "else if"?

+   ee->instdone.instdone = regs[i].value;
+   }
+}
+
  void intel_guc_capture_free_node(struct intel_engine_coredump *ee)
  {
 if (!ee || !ee->guc_capture_node)
@@ -1612,6 +1633,7 @@ void intel_guc_capture_get_matching_node(struct intel_gt 
*gt,
 list_del(>link);
 ee->guc_capture_node = n;
 ee->capture = guc->capture;
+   guc_capture_find_ecode(ee);
 return;
 }
 }

alan: only one non-blocker request:
while we are here, could we update the debug message when we can't find a 
matching captured node?
Current code:
drm_dbg(>drm, "GuC capture can't match ee to node\n");
New suggestion:
drm_dbg(>drm, "GuC capture can't find node for ee-ctx: lcra = 0x%08x | 
gucid = 0x%08x\n",
ce->lrc.lrca, ce->guc_id.id);
Regarding the search test, there seem to be some incorrect terms in 
there. The if itself is also not the easiest to read with some terms 
across multiple lines and other lines with multiple terms. Breaking it down:

    (n->eng_inst == GUC_ID_TO_ENGINE_INSTANCE(ee->engine->guc_id) &&
    n->eng_class == GUC_ID_TO_ENGINE_CLASS(ee->engine->guc_id) &&
    n->guc_id &&
Why does the GuC id have to be non zero? Zero is a valid id. And even if 
it isn't, comparing to ce->guc_id.id is sufficient to filter out 
anything bad.

    n->guc_id == ce->guc_id.id &&
    (n->lrca & CTX_GTT_ADDRESS_MASK) &&
Again, address zero is not invalid but the next test makes this one 
redundant anyway.
    (n->lrca & CTX_GTT_ADDRESS_MASK) == (ce->lrc.lrca & 
CTX_GTT_ADDRESS_MASK)) {


Any objection to dropping the !zero tests and reformatting the whole thing?

John.

Re: [PATCH] drm/nouveau/mmu: fix Use after Free bug in nvkm_vmm_node_split

[Danilo Krummrich]

On Fri, Jan 27, 2023 at 01:10:46PM +0100, Takashi Iwai wrote:
> On Tue, 03 Jan 2023 15:07:55 +0100,
> Takashi Iwai wrote:
> > 
> > On Fri, 30 Dec 2022 08:27:58 +0100,
> > Zheng Wang wrote:
> > > 
> > > Here is a function call chain.
> > > nvkm_vmm_pfn_map->nvkm_vmm_pfn_split_merge->nvkm_vmm_node_split
> > > If nvkm_vma_tail return NULL in nvkm_vmm_node_split, it will
> > > finally invoke nvkm_vmm_node_merge->nvkm_vmm_node_delete, which
> > > will free the vma. However, nvkm_vmm_pfn_map didn't notice that.
> > > It goes into next label and UAF happens.
> > > 
> > > Fix it by returning the return-value of nvkm_vmm_node_merge
> > > instead of NULL.
> > > 
> > > Signed-off-by: Zheng Wang 
> > 
> > FWIW, CVE-2023-0030 has been assigned to this bug.
> > It's a question whether it really deserves as a security issue, but a
> > bug is a bug...
> > 
> > Ben, could you review this please?
> 
> A gentle ping as reminder.  The bug is still present.

This was also reported in [1]. I had a closer look and FWICT this code is fine
and there isn't a bug.

Zheng Wang, the reporter of the BZ, also confirmed this to be a false positive
from CodeQL.

Anyway, here's the explaination I also posted in the BZ:

"In nvkm_vmm_node_merge() nvkm_vmm_node_delete() is only called when prev is
set. However, prev is NULL unless we enter the "if (vma->addr != addr)" path in
nvkm_vmm_node_split(). In such a case the vma pointer, which is also passed to
nvkm_vmm_node_merge(), is set to a freshly allocated struct nvkm_vma with
nvkm_vma_tail() right before prev is set to the old vma pointer.

Hence, the only thing happening there when nvkm_vma_tail() fails in the
"if (vma->size != size)" path is that either nvkm_vmm_node_merge() does nothing
in case prev wasn't set or it merges and frees the new vma created in the
"if (vma->addr != addr)" path. Or in other words the proper cleanup for the
error condition is done.

I can't see any case where the original vma pointer given by nvkm_vmm_pfn_map()
is actually freed."

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2157041

- Danilo

> 
> 
> thanks,
> 
> Takashi
> 
> > 
> > 
> > thanks,
> > 
> > Takashi
> > 
> > > ---
> > >  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c 
> > > b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
> > > index ae793f400ba1..84d6fc87b2e8 100644
> > > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
> > > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
> > > @@ -937,8 +937,8 @@ nvkm_vmm_node_split(struct nvkm_vmm *vmm,
> > >   if (vma->size != size) {
> > >   struct nvkm_vma *tmp;
> > >   if (!(tmp = nvkm_vma_tail(vma, vma->size - size))) {
> > > - nvkm_vmm_node_merge(vmm, prev, vma, NULL, vma->size);
> > > - return NULL;
> > > + tmp = nvkm_vmm_node_merge(vmm, prev, vma, NULL, 
> > > vma->size);
> > > + return tmp;
> > >   }
> > >   tmp->part = true;
> > >   nvkm_vmm_node_insert(vmm, tmp);
> > > -- 
> > > 2.25.1
> > > 
> 

Re: [PATCH drm-next 03/14] drm: manager to keep track of GPUs VA mappings

[Danilo Krummrich]

On Fri, Jan 27, 2023 at 12:24:07AM +, Matthew Brost wrote:
> On Wed, Jan 18, 2023 at 07:12:45AM +0100, Danilo Krummrich wrote:
> > This adds the infrastructure for a manager implementation to keep track
> > of GPU virtual address (VA) mappings.
> > 
> > New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers
> > start implementing, allow userspace applications to request multiple and
> > arbitrary GPU VA mappings of buffer objects. The DRM GPU VA manager is
> > intended to serve the following purposes in this context.
> > 
> > 1) Provide a dedicated range allocator to track GPU VA allocations and
> >mappings, making use of the drm_mm range allocator.
> > 
> > 2) Generically connect GPU VA mappings to their backing buffers, in
> >particular DRM GEM objects.
> > 
> > 3) Provide a common implementation to perform more complex mapping
> >operations on the GPU VA space. In particular splitting and merging
> >of GPU VA mappings, e.g. for intersecting mapping requests or partial
> >unmap requests.
> > 
> > Idea-suggested-by: Dave Airlie 
> > Signed-off-by: Danilo Krummrich 
> 
> 
> 
> > +++ b/drivers/gpu/drm/drm_gpuva_mgr.c
> 
> 
> 
> > +struct drm_gpuva *
> > +drm_gpuva_find(struct drm_gpuva_manager *mgr,
> > +  u64 addr, u64 range)
> > +{
> > +   struct drm_gpuva *va;
> > +
> > +   drm_gpuva_for_each_va_in_range(va, mgr, addr, range) {
> 
> Last argument should be: range + addr, right?
> 

Thanks, good catch.

> > +   if (va->node.start == addr &&
> > +   va->node.size == range)
> > +   return va;
> > +   }
> > +
> > +   return NULL;
> > +}
> > +EXPORT_SYMBOL(drm_gpuva_find);
> > +
> > +/**
> > + * drm_gpuva_find_prev - find the _gpuva before the given address
> > + * @mgr: the _gpuva_manager to search in
> > + * @start: the given GPU VA's start address
> > + *
> > + * Find the adjacent _gpuva before the GPU VA with given  
> > address.
> > + *
> > + * Note that if there is any free space between the GPU VA mappings no 
> > mapping
> > + * is returned.
> > + *
> > + * Returns: a pointer to the found _gpuva or NULL if none was found
> > + */
> > +struct drm_gpuva *
> > +drm_gpuva_find_prev(struct drm_gpuva_manager *mgr, u64 start)
> > +{
> > +   struct drm_mm_node *node;
> > +
> > +   if (start <= mgr->mm_start ||
> > +   start > (mgr->mm_start + mgr->mm_range))
> > +   return NULL;
> > +
> > +   node = __drm_mm_interval_first(>va_mm, start - 1, start);
> > +   if (node == >va_mm.head_node)
> > +   return NULL;
> > +
> > +   return (struct drm_gpuva *)node;
> > +}
> > +EXPORT_SYMBOL(drm_gpuva_find_prev);
> > +
> > +/**
> > + * drm_gpuva_find_next - find the _gpuva after the given address
> > + * @mgr: the _gpuva_manager to search in
> > + * @end: the given GPU VA's end address
> > + *
> > + * Find the adjacent _gpuva after the GPU VA with given  address.
> > + *
> > + * Note that if there is any free space between the GPU VA mappings no 
> > mapping
> > + * is returned.
> > + *
> > + * Returns: a pointer to the found _gpuva or NULL if none was found
> > + */
> > +struct drm_gpuva *
> > +drm_gpuva_find_next(struct drm_gpuva_manager *mgr, u64 end)
> > +{
> > +   struct drm_mm_node *node;
> > +
> > +   if (end < mgr->mm_start ||
> > +   end >= (mgr->mm_start + mgr->mm_range))
> > +   return NULL;
> > +
> > +   node = __drm_mm_interval_first(>va_mm, end, end + 1);
> > +   if (node == >va_mm.head_node)
> > +   return NULL;
> > +
> > +   return (struct drm_gpuva *)node;
> > +}
> > +EXPORT_SYMBOL(drm_gpuva_find_next);
> > +
> > +/**
> > + * drm_gpuva_region_insert - insert a _gpuva_region
> > + * @mgr: the _gpuva_manager to insert the _gpuva in
> > + * @reg: the _gpuva_region to insert
> > + * @addr: the start address of the GPU VA
> > + * @range: the range of the GPU VA
> > + *
> > + * Insert a _gpuva_region with a given address and range into a
> > + * _gpuva_manager.
> > + *
> > + * Returns: 0 on success, negative error code on failure.
> > + */
> > +int
> > +drm_gpuva_region_insert(struct drm_gpuva_manager *mgr,
> > +   struct drm_gpuva_region *reg,
> > +   u64 addr, u64 range)
> > +{
> > +   int ret;
> > +
> > +   ret = drm_mm_insert_node_in_range(>region_mm, >node,
> > + range, 0,
> > + 0, addr,
> > + addr + range,
> > + DRM_MM_INSERT_LOW|
> > + DRM_MM_INSERT_ONCE);
> > +   if (ret)
> > +   return ret;
> > +
> > +   reg->mgr = mgr;
> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL(drm_gpuva_region_insert);
> > +
> > +/**
> > + * drm_gpuva_region_destroy - destroy a _gpuva_region
> > + * @mgr: the _gpuva_manager holding the region
> > + * @reg: the _gpuva to destroy
> > + *
> > + * This removes the given  from the underlaying range allocator.
> > + */
> > +void
> > 

[PATCH] drm/amdgpu/display: remove duplicate include header in files

[ye.xingchen]

From: ye xingchen 

opp.h is included more than once.

Signed-off-by: ye xingchen 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index 6475664baa8a..1a2ab934b4bd 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -46,7 +46,6 @@
 #include "dpcd_defs.h"
 #include "dmcu.h"
 #include "dsc.h"
-#include "opp.h"
 #include "hw/clk_mgr.h"
 #include "dce/dmub_psr.h"
 #include "dmub/dmub_srv.h"
-- 
2.25.1

Re: [Intel-gfx] [PATCH v2 1/8] drm/i915/guc: Add GuC oriented print macros

[John Harrison]

On 1/24/2023 09:05, Michal Wajdeczko wrote:

While we do have GT oriented print macros, add few more GuC
specific to have common look and feel across all messages
related to the GuC and to avoid chasing the gt pointer.

We will use these macros shortly in upcoming patches.

Signed-off-by: Michal Wajdeczko 
Cc: Tvrtko Ursulin 
Cc: John Harrison 

Reviewed-by: John Harrison 


---
  drivers/gpu/drm/i915/gt/uc/intel_guc_print.h | 48 
  1 file changed, 48 insertions(+)
  create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_print.h

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_print.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_print.h
new file mode 100644
index ..e75989d4ba06
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_print.h
@@ -0,0 +1,48 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+
+#ifndef __INTEL_GUC_PRINT__
+#define __INTEL_GUC_PRINT__
+
+#include "gt/intel_gt.h"
+#include "gt/intel_gt_print.h"
+
+#define guc_printk(_guc, _level, _fmt, ...) \
+   gt_##_level(guc_to_gt(_guc), "GUC: " _fmt, ##__VA_ARGS__)
+
+#define guc_err(_guc, _fmt, ...) \
+   guc_printk((_guc), err, _fmt, ##__VA_ARGS__)
+
+#define guc_warn(_guc, _fmt, ...) \
+   guc_printk((_guc), warn, _fmt, ##__VA_ARGS__)
+
+#define guc_notice(_guc, _fmt, ...) \
+   guc_printk((_guc), notice, _fmt, ##__VA_ARGS__)
+
+#define guc_info(_guc, _fmt, ...) \
+   guc_printk((_guc), info, _fmt, ##__VA_ARGS__)
+
+#define guc_dbg(_guc, _fmt, ...) \
+   guc_printk((_guc), dbg, _fmt, ##__VA_ARGS__)
+
+#define guc_err_ratelimited(_guc, _fmt, ...) \
+   guc_printk((_guc), err_ratelimited, _fmt, ##__VA_ARGS__)
+
+#define guc_probe_error(_guc, _fmt, ...) \
+   guc_printk((_guc), probe_error, _fmt, ##__VA_ARGS__)
+
+#define guc_WARN(_guc, _cond, _fmt, ...) \
+   gt_WARN(guc_to_gt(_guc), _cond, "GUC: " _fmt, ##__VA_ARGS__)
+
+#define guc_WARN_ONCE(_guc, _cond, _fmt, ...) \
+   gt_WARN_ONCE(guc_to_gt(_guc), _cond, "GUC: " _fmt, ##__VA_ARGS__)
+
+#define guc_WARN_ON(_guc, _cond) \
+   gt_WARN(guc_to_gt(_guc), _cond, "%s(%s)", "guc_WARN_ON", 
__stringify(_cond))
+
+#define guc_WARN_ON_ONCE(_guc, _cond) \
+   gt_WARN_ONCE(guc_to_gt(_guc), _cond, "%s(%s)", "guc_WARN_ON_ONCE", 
__stringify(_cond))
+
+#endif /* __INTEL_GUC_PRINT__ */

Re: [Intel-gfx] [PATCH v2 8/8] drm/i915/guc: Update GT/GuC messages in intel_uc.c

[John Harrison]

On 1/24/2023 09:05, Michal Wajdeczko wrote:

Use new macros to have common prefix that also include GT#.

v2: pass gt to print_fw_ver

Signed-off-by: Michal Wajdeczko 
Cc: John Harrison 
---
  drivers/gpu/drm/i915/gt/uc/intel_uc.c | 80 +--
  1 file changed, 39 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 9a8a1abf71d7..a750966ddcab 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -6,11 +6,13 @@
  #include 
  
  #include "gt/intel_gt.h"

+#include "gt/intel_gt_print.h"
  #include "gt/intel_reset.h"
  #include "intel_gsc_fw.h"
  #include "intel_gsc_uc.h"
  #include "intel_guc.h"
  #include "intel_guc_ads.h"
+#include "intel_guc_print.h"
  #include "intel_guc_submission.h"
  #include "gt/intel_rps.h"
  #include "intel_uc.h"
@@ -67,14 +69,14 @@ static int __intel_uc_reset_hw(struct intel_uc *uc)
  
  	ret = intel_reset_guc(gt);

if (ret) {
-   DRM_ERROR("Failed to reset GuC, ret = %d\n", ret);
+   gt_err(gt, "Failed to reset GuC, ret = %d\n", ret);
return ret;
}
  
  	guc_status = intel_uncore_read(gt->uncore, GUC_STATUS);

-   WARN(!(guc_status & GS_MIA_IN_RESET),
-"GuC status: 0x%x, MIA core expected to be in reset\n",
-guc_status);
+   gt_WARN(gt, !(guc_status & GS_MIA_IN_RESET),
+   "GuC status: 0x%x, MIA core expected to be in reset\n",
+   guc_status);
  
  	return ret;

  }
@@ -252,15 +254,13 @@ static int guc_enable_communication(struct intel_guc *guc)
intel_guc_ct_event_handler(>ct);
spin_unlock_irq(gt->irq_lock);
  
-	drm_dbg(>drm, "GuC communication enabled\n");

+   guc_dbg(guc, "communication enabled\n");
  
  	return 0;

  }
  
  static void guc_disable_communication(struct intel_guc *guc)

  {
-   struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
-
/*
 * Events generated during or after CT disable are logged by guc in
 * via mmio. Make sure the register is clear before disabling CT since
@@ -280,11 +280,12 @@ static void guc_disable_communication(struct intel_guc 
*guc)
 */
guc_get_mmio_msg(guc);
  
-	drm_dbg(>drm, "GuC communication disabled\n");

+   guc_dbg(guc, "communication disabled\n");
  }
  
  static void __uc_fetch_firmwares(struct intel_uc *uc)

  {
+   struct intel_gt *gt = uc_to_gt(uc);
int err;
  
  	GEM_BUG_ON(!intel_uc_wants_guc(uc));

@@ -293,15 +294,13 @@ static void __uc_fetch_firmwares(struct intel_uc *uc)
if (err) {
/* Make sure we transition out of transient "SELECTED" state */
if (intel_uc_wants_huc(uc)) {
-   drm_dbg(_to_gt(uc)->i915->drm,
-   "Failed to fetch GuC: %d disabling HuC\n", err);
+   gt_dbg(gt, "Failed to fetch GuC fw (%pe) disabling 
HuC\n", ERR_PTR(err));
intel_uc_fw_change_status(>huc.fw,
  INTEL_UC_FIRMWARE_ERROR);
}
  
  		if (intel_uc_wants_gsc_uc(uc)) {

-   drm_dbg(_to_gt(uc)->i915->drm,
-   "Failed to fetch GuC: %d disabling GSC\n", err);
+   gt_dbg(gt, "Failed to fetch GuC fw (%pe) disabling 
GSC\n", ERR_PTR(err));
intel_uc_fw_change_status(>gsc.fw,
  INTEL_UC_FIRMWARE_ERROR);
}
@@ -382,7 +381,7 @@ static int uc_init_wopcm(struct intel_uc *uc)
int err;
  
  	if (unlikely(!base || !size)) {

-   i915_probe_error(gt->i915, "Unsuccessful WOPCM partitioning\n");
+   gt_probe_error(gt, "Unsuccessful WOPCM partitioning\n");
return -E2BIG;
}
  
@@ -413,13 +412,13 @@ static int uc_init_wopcm(struct intel_uc *uc)

return 0;
  
  err_out:

-   i915_probe_error(gt->i915, "Failed to init uC WOPCM registers!\n");
-   i915_probe_error(gt->i915, "%s(%#x)=%#x\n", "DMA_GUC_WOPCM_OFFSET",
-i915_mmio_reg_offset(DMA_GUC_WOPCM_OFFSET),
-intel_uncore_read(uncore, DMA_GUC_WOPCM_OFFSET));
-   i915_probe_error(gt->i915, "%s(%#x)=%#x\n", "GUC_WOPCM_SIZE",
-i915_mmio_reg_offset(GUC_WOPCM_SIZE),
-intel_uncore_read(uncore, GUC_WOPCM_SIZE));
+   gt_probe_error(gt, "Failed to init uC WOPCM registers!\n");
+   gt_probe_error(gt, "%s(%#x)=%#x\n", "DMA_GUC_WOPCM_OFFSET",
+  i915_mmio_reg_offset(DMA_GUC_WOPCM_OFFSET),
+  intel_uncore_read(uncore, DMA_GUC_WOPCM_OFFSET));
+   gt_probe_error(gt, "%s(%#x)=%#x\n", "GUC_WOPCM_SIZE",
+  i915_mmio_reg_offset(GUC_WOPCM_SIZE),
+  intel_uncore_read(uncore, GUC_WOPCM_SIZE));
  
  	return err;

 

Re: [Intel-gfx] [PATCH v2 7/8] drm/i915/guc: Update GuC messages in intel_guc_submission.c

[John Harrison]

On 1/24/2023 09:05, Michal Wajdeczko wrote:

Use new macros to have common prefix that also include GT#.

v2: improve few existing messages

Signed-off-by: Michal Wajdeczko 
Cc: John Harrison 

Reviewed-by: John Harrison 


---
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 61 ---
  1 file changed, 26 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index b436dd7f12e4..b2250181f31b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -27,6 +27,7 @@
  
  #include "intel_guc_ads.h"

  #include "intel_guc_capture.h"
+#include "intel_guc_print.h"
  #include "intel_guc_submission.h"
  
  #include "i915_drv.h"

@@ -1443,8 +1444,7 @@ static void guc_init_engine_stats(struct intel_guc *guc)
int ret = guc_action_enable_usage_stats(guc);
  
  		if (ret)

-   drm_err(>i915->drm,
-   "Failed to enable usage stats: %d!\n", ret);
+   guc_err(guc, "Failed to enable usage stats: %pe\n", 
ERR_PTR(ret));
}
  }
  
@@ -3585,8 +3585,7 @@ static int guc_request_alloc(struct i915_request *rq)

intel_context_sched_disable_unpin(ce);
else if (intel_context_is_closed(ce))
if (wait_for(context_close_done(ce), 1500))
-   drm_warn(_to_gt(guc)->i915->drm,
-"timed out waiting on context sched close before 
realloc\n");
+   guc_warn(guc, "timed out waiting on context sched close 
before realloc\n");
/*
 * Call pin_guc_id here rather than in the pinning step as with
 * dma_resv, contexts can be repeatedly pinned / unpinned trashing the
@@ -4349,11 +4348,14 @@ static int __guc_action_set_scheduling_policies(struct 
intel_guc *guc,
  
  	ret = intel_guc_send(guc, (u32 *)>h2g,

 __guc_scheduling_policy_action_size(policy));
-   if (ret < 0)
+   if (ret < 0) {
+   guc_probe_error(guc, "Failed to configure global scheduling 
policies: %pe!\n",
+   ERR_PTR(ret));
return ret;
+   }
  
  	if (ret != policy->count) {

-   drm_warn(_to_gt(guc)->i915->drm, "GuC global scheduler policy 
processed %d of %d KLVs!",
+   guc_warn(guc, "global scheduler policy processed %d of %d 
KLVs!",
 ret, policy->count);
if (ret > policy->count)
return -EPROTO;
@@ -4367,7 +4369,7 @@ static int guc_init_global_schedule_policy(struct 
intel_guc *guc)
struct scheduling_policy policy;
struct intel_gt *gt = guc_to_gt(guc);
intel_wakeref_t wakeref;
-   int ret = 0;
+   int ret;
  
  	if (GUC_SUBMIT_VER(guc) < MAKE_GUC_VER(1, 1, 0))

return 0;
@@ -4385,10 +4387,6 @@ static int guc_init_global_schedule_policy(struct 
intel_guc *guc)
yield, ARRAY_SIZE(yield));
  
  		ret = __guc_action_set_scheduling_policies(guc, );

-   if (ret)
-   i915_probe_error(gt->i915,
-"Failed to configure global scheduling 
policies: %pe!\n",
-ERR_PTR(ret));
}
  
  	return ret;

@@ -4487,21 +4485,18 @@ g2h_context_lookup(struct intel_guc *guc, u32 ctx_id)
struct intel_context *ce;
  
  	if (unlikely(ctx_id >= GUC_MAX_CONTEXT_ID)) {

-   drm_err(_to_gt(guc)->i915->drm,
-   "Invalid ctx_id %u\n", ctx_id);
+   guc_err(guc, "Invalid ctx_id %u\n", ctx_id);
return NULL;
}
  
  	ce = __get_context(guc, ctx_id);

if (unlikely(!ce)) {
-   drm_err(_to_gt(guc)->i915->drm,
-   "Context is NULL, ctx_id %u\n", ctx_id);
+   guc_err(guc, "Context is NULL, ctx_id %u\n", ctx_id);
return NULL;
}
  
  	if (unlikely(intel_context_is_child(ce))) {

-   drm_err(_to_gt(guc)->i915->drm,
-   "Context is child, ctx_id %u\n", ctx_id);
+   guc_err(guc, "Context is child, ctx_id %u\n", ctx_id);
return NULL;
}
  
@@ -4516,7 +4511,7 @@ int intel_guc_deregister_done_process_msg(struct intel_guc *guc,

u32 ctx_id;
  
  	if (unlikely(len < 1)) {

-   drm_err(_to_gt(guc)->i915->drm, "Invalid length %u\n", len);
+   guc_err(guc, "Invalid length %u\n", len);
return -EPROTO;
}
ctx_id = msg[0];
@@ -4568,7 +4563,7 @@ int intel_guc_sched_done_process_msg(struct intel_guc 
*guc,
u32 ctx_id;
  
  	if (unlikely(len < 2)) {

-   drm_err(_to_gt(guc)->i915->drm, "Invalid length %u\n", len);
+   guc_err(guc, "Invalid length %u\n", 

Re: [Intel-gfx] [PATCH v2 6/8] drm/i915/guc: Update GuC messages in intel_guc_log.c

[John Harrison]

On 1/24/2023 09:05, Michal Wajdeczko wrote:

Use new macros to have common prefix that also include GT#.

v2: drop redundant GuC strings, minor improvements

Signed-off-by: Michal Wajdeczko 
Cc: John Harrison 
---
  drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 37 --
  1 file changed, 20 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index 68331c538b0a..290bb996b667 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -12,6 +12,7 @@
  #include "i915_memcpy.h"
  #include "intel_guc_capture.h"
  #include "intel_guc_log.h"
+#include "intel_guc_print.h"
  
  #if defined(CONFIG_DRM_I915_DEBUG_GUC)

  #define GUC_LOG_DEFAULT_CRASH_BUFFER_SIZE SZ_2M
@@ -39,7 +40,6 @@ struct guc_log_section {
  static void _guc_log_init_sizes(struct intel_guc_log *log)
  {
struct intel_guc *guc = log_to_guc(log);
-   struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
static const struct guc_log_section sections[GUC_LOG_SECTIONS_LIMIT] = {
{
GUC_LOG_CRASH_MASK >> GUC_LOG_CRASH_SHIFT,
@@ -82,12 +82,12 @@ static void _guc_log_init_sizes(struct intel_guc_log *log)
}
  
  		if (!IS_ALIGNED(log->sizes[i].bytes, log->sizes[i].units))

-   drm_err(>drm, "Mis-aligned GuC log %s size: 0x%X vs 
0x%X!",
+   guc_err(guc, "Mis-aligned log %s size: 0x%X vs 0x%X!\n",
sections[i].name, log->sizes[i].bytes, 
log->sizes[i].units);
log->sizes[i].count = log->sizes[i].bytes / log->sizes[i].units;
  
  		if (!log->sizes[i].count) {

-   drm_err(>drm, "Zero GuC log %s size!", 
sections[i].name);
+   guc_err(guc, "Zero log %s size!\n", sections[i].name);
} else {
/* Size is +1 unit */
log->sizes[i].count--;
@@ -95,15 +95,17 @@ static void _guc_log_init_sizes(struct intel_guc_log *log)
  
  		/* Clip to field size */

if (log->sizes[i].count > sections[i].max) {
-   drm_err(>drm, "GuC log %s size too large: %d vs 
%d!",
+   guc_err(guc, "log %s size too large: %d vs %d!\n",
sections[i].name, log->sizes[i].count + 1, 
sections[i].max + 1);
log->sizes[i].count = sections[i].max;
}
}
  
  	if (log->sizes[GUC_LOG_SECTIONS_CRASH].units != log->sizes[GUC_LOG_SECTIONS_DEBUG].units) {

-   drm_err(>drm, "Unit mis-match for GuC log crash and debug 
sections: %d vs %d!",
+   guc_err(guc, "Unit mis-match between log sections: %s = %d vs %s = 
%d!\n",
+   sections[GUC_LOG_SECTIONS_CRASH].name,
log->sizes[GUC_LOG_SECTIONS_CRASH].units,
+   sections[GUC_LOG_SECTIONS_DEBUG].name,
Sorry, didn't get to reply to your comment in time. This can only be a 
mis-match between crash and debug. And the 'name' field is just a string 
version of the array index enum. So I would have just gone with "Unit 
mismatch for crash and debug sections: %d vs %d".




log->sizes[GUC_LOG_SECTIONS_DEBUG].units);
log->sizes[GUC_LOG_SECTIONS_CRASH].units = 
log->sizes[GUC_LOG_SECTIONS_DEBUG].units;
log->sizes[GUC_LOG_SECTIONS_CRASH].count = 0;
@@ -374,6 +376,7 @@ size_t intel_guc_get_log_buffer_offset(struct intel_guc_log 
*log,
  
  static void _guc_log_copy_debuglogs_for_relay(struct intel_guc_log *log)

  {
+   struct intel_guc *guc = log_to_guc(log);
unsigned int buffer_size, read_offset, write_offset, bytes_to_copy, 
full_cnt;
struct guc_log_buffer_state *log_buf_state, *log_buf_snapshot_state;
struct guc_log_buffer_state log_buf_state_local;
@@ -383,7 +386,7 @@ static void _guc_log_copy_debuglogs_for_relay(struct 
intel_guc_log *log)
  
  	mutex_lock(>relay.lock);
  
-	if (WARN_ON(!intel_guc_log_relay_created(log)))

+   if (guc_WARN_ON(guc, !intel_guc_log_relay_created(log)))
goto out_unlock;
  
  	/* Get the pointer to shared GuC log buffer */

@@ -398,7 +401,7 @@ static void _guc_log_copy_debuglogs_for_relay(struct 
intel_guc_log *log)
 * Used rate limited to avoid deluge of messages, logs might be
 * getting consumed by User at a slow rate.
 */
-   DRM_ERROR_RATELIMITED("no sub-buffer to copy general logs\n");
+   guc_err_ratelimited(guc, "no sub-buffer to copy general 
logs\n");
log->relay.full_count++;
  
  		goto out_unlock;

@@ -451,7 +454,7 @@ static void _guc_log_copy_debuglogs_for_relay(struct 
intel_guc_log *log)
write_offset = buffer_size;
} else if (unlikely((read_offset > buffer_size) ||

Re: [Intel-gfx] [PATCH v2 4/8] drm/i915/guc: Update GuC messages in intel_guc_ct.c

[John Harrison]

On 1/24/2023 09:05, Michal Wajdeczko wrote:

Use new macros to have common prefix that also include GT#.

v2: drop unused helpers

Signed-off-by: Michal Wajdeczko 
Cc: John Harrison 

Reviewed-by: John Harrison 


---
  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 23 ---
  1 file changed, 4 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 2b22065e87bf..1803a633ed64 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -11,38 +11,23 @@
  
  #include "i915_drv.h"

  #include "intel_guc_ct.h"
-#include "gt/intel_gt.h"
+#include "intel_guc_print.h"
  
  static inline struct intel_guc *ct_to_guc(struct intel_guc_ct *ct)

  {
return container_of(ct, struct intel_guc, ct);
  }
  
-static inline struct intel_gt *ct_to_gt(struct intel_guc_ct *ct)

-{
-   return guc_to_gt(ct_to_guc(ct));
-}
-
-static inline struct drm_i915_private *ct_to_i915(struct intel_guc_ct *ct)
-{
-   return ct_to_gt(ct)->i915;
-}
-
-static inline struct drm_device *ct_to_drm(struct intel_guc_ct *ct)
-{
-   return _to_i915(ct)->drm;
-}
-
  #define CT_ERROR(_ct, _fmt, ...) \
-   drm_err(ct_to_drm(_ct), "CT: " _fmt, ##__VA_ARGS__)
+   guc_err(ct_to_guc(_ct), "CT: " _fmt, ##__VA_ARGS__)
  #ifdef CONFIG_DRM_I915_DEBUG_GUC
  #define CT_DEBUG(_ct, _fmt, ...) \
-   drm_dbg(ct_to_drm(_ct), "CT: " _fmt, ##__VA_ARGS__)
+   guc_dbg(ct_to_guc(_ct), "CT: " _fmt, ##__VA_ARGS__)
  #else
  #define CT_DEBUG(...) do { } while (0)
  #endif
  #define CT_PROBE_ERROR(_ct, _fmt, ...) \
-   i915_probe_error(ct_to_i915(ct), "CT: " _fmt, ##__VA_ARGS__)
+   guc_probe_error(ct_to_guc(ct), "CT: " _fmt, ##__VA_ARGS__)
  
  /**

   * DOC: CTB Blob

Re: [Intel-gfx] [PATCH v2 2/8] drm/i915/guc: Update GuC messages in intel_guc.c

[John Harrison]

On 1/24/2023 09:05, Michal Wajdeczko wrote:

Use new macros to have common prefix that also include GT#.

v2: drop now redundant "GuC" word from the message

Signed-off-by: Michal Wajdeczko 
Cc: John Harrison 

Reviewed-by: John Harrison 


---
  drivers/gpu/drm/i915/gt/uc/intel_guc.c | 31 +-
  1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 1bccc175f9e6..d76508fa3af7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -11,6 +11,7 @@
  #include "intel_guc.h"
  #include "intel_guc_ads.h"
  #include "intel_guc_capture.h"
+#include "intel_guc_print.h"
  #include "intel_guc_slpc.h"
  #include "intel_guc_submission.h"
  #include "i915_drv.h"
@@ -94,8 +95,8 @@ static void gen9_enable_guc_interrupts(struct intel_guc *guc)
assert_rpm_wakelock_held(>i915->runtime_pm);
  
  	spin_lock_irq(gt->irq_lock);

-   WARN_ON_ONCE(intel_uncore_read(gt->uncore, GEN8_GT_IIR(2)) &
-gt->pm_guc_events);
+   guc_WARN_ON_ONCE(guc, intel_uncore_read(gt->uncore, GEN8_GT_IIR(2)) &
+gt->pm_guc_events);
gen6_gt_pm_enable_irq(gt, gt->pm_guc_events);
spin_unlock_irq(gt->irq_lock);
  
@@ -342,7 +343,7 @@ static void guc_init_params(struct intel_guc *guc)

params[GUC_CTL_DEVID] = guc_ctl_devid(guc);
  
  	for (i = 0; i < GUC_CTL_MAX_DWORDS; i++)

-   DRM_DEBUG_DRIVER("param[%2d] = %#x\n", i, params[i]);
+   guc_dbg(guc, "param[%2d] = %#x\n", i, params[i]);
  }
  
  /*

@@ -389,7 +390,6 @@ void intel_guc_dump_time_info(struct intel_guc *guc, struct 
drm_printer *p)
  
  int intel_guc_init(struct intel_guc *guc)

  {
-   struct intel_gt *gt = guc_to_gt(guc);
int ret;
  
  	ret = intel_uc_fw_init(>fw);

@@ -451,7 +451,7 @@ int intel_guc_init(struct intel_guc *guc)
intel_uc_fw_fini(>fw);
  out:
intel_uc_fw_change_status(>fw, INTEL_UC_FIRMWARE_INIT_FAIL);
-   i915_probe_error(gt->i915, "failed with %d\n", ret);
+   guc_probe_error(guc, "failed with %pe\n", ERR_PTR(ret));
return ret;
  }
  
@@ -480,7 +480,6 @@ void intel_guc_fini(struct intel_guc *guc)

  int intel_guc_send_mmio(struct intel_guc *guc, const u32 *request, u32 len,
u32 *response_buf, u32 response_buf_size)
  {
-   struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
struct intel_uncore *uncore = guc_to_gt(guc)->uncore;
u32 header;
int i;
@@ -515,7 +514,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*request, u32 len,
   10, 10, );
if (unlikely(ret)) {
  timeout:
-   drm_err(>drm, "mmio request %#x: no reply %x\n",
+   guc_err(guc, "mmio request %#x: no reply %x\n",
request[0], header);
goto out;
}
@@ -537,7 +536,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*request, u32 len,
if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) == 
GUC_HXG_TYPE_NO_RESPONSE_RETRY) {
u32 reason = FIELD_GET(GUC_HXG_RETRY_MSG_0_REASON, header);
  
-		drm_dbg(>drm, "mmio request %#x: retrying, reason %u\n",

+   guc_dbg(guc, "mmio request %#x: retrying, reason %u\n",
request[0], reason);
goto retry;
}
@@ -546,7 +545,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*request, u32 len,
u32 hint = FIELD_GET(GUC_HXG_FAILURE_MSG_0_HINT, header);
u32 error = FIELD_GET(GUC_HXG_FAILURE_MSG_0_ERROR, header);
  
-		drm_err(>drm, "mmio request %#x: failure %x/%u\n",

+   guc_err(guc, "mmio request %#x: failure %x/%u\n",
request[0], error, hint);
ret = -ENXIO;
goto out;
@@ -554,7 +553,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*request, u32 len,
  
  	if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) != GUC_HXG_TYPE_RESPONSE_SUCCESS) {

  proto:
-   drm_err(>drm, "mmio request %#x: unexpected reply %#x\n",
+   guc_err(guc, "mmio request %#x: unexpected reply %#x\n",
request[0], header);
ret = -EPROTO;
goto out;
@@ -597,9 +596,9 @@ int intel_guc_to_host_process_recv_msg(struct intel_guc 
*guc,
msg = payload[0] & guc->msg_enabled_mask;
  
  	if (msg & INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED)

-   drm_err(_to_gt(guc)->i915->drm, "Received early GuC crash dump 
notification!\n");
+   guc_err(guc, "Received early crash dump notification!\n");
if (msg & INTEL_GUC_RECV_MSG_EXCEPTION)
-   drm_err(_to_gt(guc)->i915->drm, "Received early GuC exception 
notification!\n");
+   guc_err(guc, "Received early exception notification!\n");
  
  	return 0;

  }
@@ -653,7 +652,8 

Re: [RFC 10/12] cgroup/drm: Introduce weight based drm cgroup control

[Tejun Heo]

On Thu, Jan 12, 2023 at 04:56:07PM +, Tvrtko Ursulin wrote:
...
> + /*
> +  * 1st pass - reset working values and update hierarchical weights and
> +  * GPU utilisation.
> +  */
> + if (!__start_scanning(root, period_us))
> + goto out_retry; /*
> +  * Always come back later if scanner races with
> +  * core cgroup management. (Repeated pattern.)
> +  */
> +
> + css_for_each_descendant_pre(node, >css) {
> + struct drm_cgroup_state *drmcs = css_to_drmcs(node);
> + struct cgroup_subsys_state *css;
> + unsigned int over_weights = 0;
> + u64 unused_us = 0;
> +
> + if (!css_tryget_online(node))
> + goto out_retry;
> +
> + /*
> +  * 2nd pass - calculate initial budgets, mark over budget
> +  * siblings and add up unused budget for the group.
> +  */
> + css_for_each_child(css, >css) {
> + struct drm_cgroup_state *sibling = css_to_drmcs(css);
> +
> + if (!css_tryget_online(css)) {
> + css_put(node);
> + goto out_retry;
> + }
> +
> + sibling->per_s_budget_us  =
> + DIV_ROUND_UP_ULL(drmcs->per_s_budget_us *
> +  sibling->weight,
> +  drmcs->sum_children_weights);
> +
> + sibling->over = sibling->active_us >
> + sibling->per_s_budget_us;
> + if (sibling->over)
> + over_weights += sibling->weight;
> + else
> + unused_us += sibling->per_s_budget_us -
> +  sibling->active_us;
> +
> + css_put(css);
> + }
> +
> + /*
> +  * 3rd pass - spread unused budget according to relative weights
> +  * of over budget siblings.
> +  */
> + css_for_each_child(css, >css) {
> + struct drm_cgroup_state *sibling = css_to_drmcs(css);
> +
> + if (!css_tryget_online(css)) {
> + css_put(node);
> + goto out_retry;
> + }
> +
> + if (sibling->over) {
> + u64 budget_us =
> + DIV_ROUND_UP_ULL(unused_us *
> +  sibling->weight,
> +  over_weights);
> + sibling->per_s_budget_us += budget_us;
> + sibling->over = sibling->active_us  >
> + sibling->per_s_budget_us;
> + }
> +
> + css_put(css);
> + }
> +
> + css_put(node);
> + }
> +
> + /*
> +  * 4th pass - send out over/under budget notifications.
> +  */
> + css_for_each_descendant_post(node, >css) {
> + struct drm_cgroup_state *drmcs = css_to_drmcs(node);
> +
> + if (!css_tryget_online(node))
> + goto out_retry;
> +
> + if (drmcs->over || drmcs->over_budget)
> + signal_drm_budget(drmcs,
> +   drmcs->active_us,
> +   drmcs->per_s_budget_us);
> + drmcs->over_budget = drmcs->over;
> +
> + css_put(node);
> + }

It keeps bothering me that the distribution logic has no memory. Maybe this
is good enough for coarse control with long cycle durations but it likely
will get in trouble if pushed to finer grained control. State keeping
doesn't require a lot of complexity. The only state that needs tracking is
each cgroup's vtime and then the core should be able to tell specific
drivers how much each cgroup is over or under fairly accurately at any given
time.

That said, this isn't a blocker. What's implemented can work well enough
with coarse enough time grain and that might be enough for the time being
and we can get back to it later. I think Michal already mentioned it but it
might be a good idea to track active and inactive cgroups and build the
weight tree with only active ones. There are machines with a lot of mostly
idle cgroups (> tens of thousands) and tree wide scanning even at low
frequency can become a pretty bad bottleneck.

Thanks.

-- 
tejun

Re: [PATCH v3 5/8] drm/i915/pxp: Add ARB session creation with new PXP API Ver4.3

[Teres Alexis, Alan Previn]

With the acceptance of the explicit-px-fw-cmd-termination series upstream
(https://patchwork.freedesktop.org/series/113307/), this patch #5 of this
series will need a rerev with the addition of MTL's version of the
explicit termination as well.

...alan

On Wed, 2023-01-25 at 00:06 -0800, Teres Alexis, Alan Previn wrote:
> Add MTL's function for ARB session creation using PXP firmware
> version 4.3 ABI structure format.
> 
> Before checking the return status, look at the GSC-CS-Mem-Header's
> pending-bit which means the GSC firmware is busy and we should
> resubmit.
> 
> Signed-off-by: Alan Previn 
> ---
alan:snip

Re: [PATCH v2 05/27] drm/msm/dpu: drop EAGAIN check from dpu_format_populate_layout

[Abhinav Kumar]

On 1/26/2023 10:05 PM, Dmitry Baryshkov wrote:

On Fri, 27 Jan 2023 at 02:52, Abhinav Kumar  wrote:




On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote:

The pipe's layout is not cached, corresponding data structure is zeroed
out each time in the dpu_plane_sspp_atomic_update(), right before the
call to _dpu_plane_set_scanout() -> dpu_format_populate_layout().

Drop plane_addr comparison against previous layout and corresponding
EAGAIN handling.

Signed-off-by: Dmitry Baryshkov 


The change itself LGTM, hence

But, shouldnt we add this EAGAIN validation or in other words fix this
rather than drop this?


What for? Does it really save us anything? What's the price of
re-programming the SSPP_SRC0_ADDR registers?


There are 4 Src registers being programmed per sspp.

With number of layers going up this will be 4x.

So lets say there are 5 layers and only one of their address has 
changed, we need to reprogram only 4 regs but now will reprogram 20.


Thats why i thought this is a good optimization.

But still, that is a separate change so I am fine if this goes in first 
as its just removing dead code anyway.


Reviewed-by: Abhinav Kumar 



Like I wrote in the review last time, this makes sure to fail the commit
if the same addr is being programmed.


First, there is nothing wrong with committing the same source addr.
For example setting the atomic property incurs an internal
drm_atomic_commit() with no change to addresses at all.
And then, this doesn't make atomic_commit fail. Instead it just
shortcuts a call to SSPP->setup_sourceaddress.



Ack, yes it wont fail the commit but will skip programming the new address.




---
   drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c | 10 +-
   drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c   |  4 +---
   2 files changed, 2 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
index d95540309d4d..ec1001e10f4f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
@@ -918,8 +918,7 @@ int dpu_format_populate_layout(
   struct drm_framebuffer *fb,
   struct dpu_hw_fmt_layout *layout)
   {
- uint32_t plane_addr[DPU_MAX_PLANES];
- int i, ret;
+ int ret;

   if (!fb || !layout) {
   DRM_ERROR("invalid arguments\n");
@@ -940,9 +939,6 @@ int dpu_format_populate_layout(
   if (ret)
   return ret;

- for (i = 0; i < DPU_MAX_PLANES; ++i)
- plane_addr[i] = layout->plane_addr[i];
-
   /* Populate the addresses given the fb */
   if (DPU_FORMAT_IS_UBWC(layout->format) ||
   DPU_FORMAT_IS_TILE(layout->format))
@@ -950,10 +946,6 @@ int dpu_format_populate_layout(
   else
   ret = _dpu_format_populate_addrs_linear(aspace, fb, layout);

- /* check if anything changed */
- if (!ret && !memcmp(plane_addr, layout->plane_addr, sizeof(plane_addr)))
- ret = -EAGAIN;
-
   return ret;
   }

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index cdde7b9ec882..43fb8e00ada6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -476,9 +476,7 @@ static void _dpu_plane_set_scanout(struct drm_plane *plane,
   int ret;

   ret = dpu_format_populate_layout(aspace, fb, _cfg->layout);
- if (ret == -EAGAIN)
- DPU_DEBUG_PLANE(pdpu, "not updating same src addrs\n");
- else if (ret)
+ if (ret)
   DPU_ERROR_PLANE(pdpu, "failed to get format layout, %d\n", ret);
   else if (pdpu->pipe_hw->ops.setup_sourceaddress) {
   trace_dpu_plane_set_scanout(pdpu->pipe_hw->idx,

What happened to basic prime support of bochs driver?

[lepton]

Hi Gerd,

It seems in the latest kernel, there is no PRIME support for bochs-drm
driver, I've found that you have an old CL which adds basic prime
support to it.

https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1893205.html

Do you remember why it finally doesn't go through?

Thanks!

Re: [PATCH] gpu: host1x: fix uninitialized variable use

[Nathan Chancellor]

On Fri, Jan 27, 2023 at 11:14:00PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> The error handling for platform_get_irq() failing no longer
> works after a recent change, clang now points this out with
> a warning:
> 
> drivers/gpu/host1x/dev.c:520:6: error: variable 'syncpt_irq' is uninitialized 
> when used here [-Werror,-Wuninitialized]
> if (syncpt_irq < 0)
> ^~
> 
> Fix this by removing the variable and checking the correct
> error status.
> 
> Fixes: 625d4ffb438c ("gpu: host1x: Rewrite syncpoint interrupt handling")
> Signed-off-by: Arnd Bergmann 

I had the same diff pending but civic duty called today :)

Reviewed-by: Nathan Chancellor 

> ---
>  drivers/gpu/host1x/dev.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
> index 4872d183d860..aae2efeef503 100644
> --- a/drivers/gpu/host1x/dev.c
> +++ b/drivers/gpu/host1x/dev.c
> @@ -487,7 +487,6 @@ static int host1x_get_resets(struct host1x *host)
>  static int host1x_probe(struct platform_device *pdev)
>  {
>   struct host1x *host;
> - int syncpt_irq;
>   int err;
>  
>   host = devm_kzalloc(>dev, sizeof(*host), GFP_KERNEL);
> @@ -517,8 +516,8 @@ static int host1x_probe(struct platform_device *pdev)
>   }
>  
>   host->syncpt_irq = platform_get_irq(pdev, 0);
> - if (syncpt_irq < 0)
> - return syncpt_irq;
> + if (host->syncpt_irq < 0)
> + return host->syncpt_irq;
>  
>   mutex_init(>devices_lock);
>   INIT_LIST_HEAD(>devices);
> -- 
> 2.39.0
> 

[PATCH v3] drm/mediatek: Add support for AR30 and BA30

[Justin Green]

Add support for AR30 and BA30 pixel formats to the Mediatek DRM driver.

Tested using "modetest -P" on an MT8195.

Signed-off-by: Justin Green 
---
v2:
 * Rebase and resolve merge conflicts with the AFBC patch.
v3:
 * Moved 10-bit support detection to mtk_disk_ovl.c

 drivers/gpu/drm/mediatek/mtk_disp_drv.h |  1 +
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 37 +
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c |  3 +-
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |  1 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 10 ++
 drivers/gpu/drm/mediatek/mtk_drm_plane.c| 37 ++---
 drivers/gpu/drm/mediatek/mtk_drm_plane.h|  2 +-
 7 files changed, 84 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h 
b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index 33e61a136bbc..b75139da3032 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -96,6 +96,7 @@ void mtk_ovl_register_vblank_cb(struct device *dev,
 void mtk_ovl_unregister_vblank_cb(struct device *dev);
 void mtk_ovl_enable_vblank(struct device *dev);
 void mtk_ovl_disable_vblank(struct device *dev);
+int mtk_ovl_supports_10bit(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.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 84daeaffab6a..412a749a509e 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -41,6 +41,7 @@
 #define DISP_REG_OVL_RDMA_CTRL(n)  (0x00c0 + 0x20 * (n))
 #define DISP_REG_OVL_RDMA_GMC(n)   (0x00c8 + 0x20 * (n))
 #define DISP_REG_OVL_ADDR_MT2701   0x0040
+#define DISP_REG_OVL_CLRFMT_EXT0x02D0
 #define DISP_REG_OVL_ADDR_MT8173   0x0f40
 #define DISP_REG_OVL_ADDR(ovl, n)  ((ovl)->data->addr + 0x20 * (n))
 #define DISP_REG_OVL_HDR_ADDR(ovl, n)  ((ovl)->data->addr + 0x20 * (n) 
+ 0x04)
@@ -61,6 +62,10 @@
0 : OVL_CON_CLRFMT_RGB)
 #define OVL_CON_CLRFMT_RGB888(ovl) ((ovl)->data->fmt_rgb565_is_0 ? \
OVL_CON_CLRFMT_RGB : 0)
+#define OVL_CON_CLRFMT_BIT_DEPTH_MASK(ovl) (0xFF << 4 * (ovl))
+#define OVL_CON_CLRFMT_BIT_DEPTH(depth, ovl)   (depth << 4 * (ovl))
+#define OVL_CON_CLRFMT_8_BIT   0x00
+#define OVL_CON_CLRFMT_10_BIT  0x01
 #defineOVL_CON_AEN BIT(8)
 #defineOVL_CON_ALPHA   0xff
 #defineOVL_CON_VIRT_FLIP   BIT(9)
@@ -73,6 +78,7 @@ struct mtk_disp_ovl_data {
bool fmt_rgb565_is_0;
bool smi_id_en;
bool supports_afbc;
+   bool supports_10bit;
 };
 
 /*
@@ -188,6 +194,26 @@ static void mtk_ovl_set_afbc(struct mtk_disp_ovl *ovl, 
struct cmdq_pkt *cmdq_pkt
   DISP_REG_OVL_DATAPATH_CON, OVL_LAYER_AFBC_EN(idx));
 }
 
+static void mtk_ovl_set_bit_depth(struct device *dev, int idx, u32 format,
+ struct cmdq_pkt *cmdq_pkt)
+{
+   struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
+   unsigned int reg;
+   unsigned int bit_depth = OVL_CON_CLRFMT_8_BIT;
+
+   reg = readl(ovl->regs + DISP_REG_OVL_CLRFMT_EXT);
+   reg &= ~OVL_CON_CLRFMT_BIT_DEPTH_MASK(idx);
+
+   if (format == DRM_FORMAT_RGBA1010102 ||
+   format == DRM_FORMAT_BGRA1010102 ||
+   format == DRM_FORMAT_ARGB2101010)
+   bit_depth = OVL_CON_CLRFMT_10_BIT;
+
+   reg |= OVL_CON_CLRFMT_BIT_DEPTH(bit_depth, idx);
+
+   mtk_ddp_write(cmdq_pkt, reg, >cmdq_reg, ovl->regs, 
DISP_REG_OVL_CLRFMT_EXT);
+}
+
 void mtk_ovl_config(struct device *dev, unsigned int w,
unsigned int h, unsigned int vrefresh,
unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
@@ -216,6 +242,13 @@ unsigned int mtk_ovl_supported_rotations(struct device 
*dev)
   DRM_MODE_REFLECT_X | DRM_MODE_REFLECT_Y;
 }
 
+int mtk_ovl_supports_10bit(struct device *dev)
+{
+   struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
+
+   return ovl->data->supports_10bit;
+}
+
 int mtk_ovl_layer_check(struct device *dev, unsigned int idx,
struct mtk_plane_state *mtk_state)
 {
@@ -302,9 +335,11 @@ static unsigned int ovl_fmt_convert(struct mtk_disp_ovl 
*ovl, unsigned int fmt)
return OVL_CON_CLRFMT_ARGB;
case DRM_FORMAT_BGRX:
case DRM_FORMAT_BGRA:
+   case DRM_FORMAT_BGRA1010102:
return OVL_CON_CLRFMT_ARGB | OVL_CON_BYTE_SWAP;
case DRM_FORMAT_XRGB:
case DRM_FORMAT_ARGB:
+   case DRM_FORMAT_ARGB2101010:
return OVL_CON_CLRFMT_RGBA;
case DRM_FORMAT_XBGR:
case DRM_FORMAT_ABGR:
@@ -388,6 +423,7 @@ void mtk_ovl_layer_config(struct device *dev, unsigned int 
idx,
  

Re: [PATCH v2 03/27] drm/msm/dpu: move SSPP allocation to the RM

[Abhinav Kumar]

On 1/26/2023 9:56 PM, Dmitry Baryshkov wrote:

On Fri, 27 Jan 2023 at 01:29, Abhinav Kumar  wrote:




On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote:

Follow the example of all other hw blocks and initialize SSPP blocks in
Resource Manager.

Signed-off-by: Dmitry Baryshkov 
---
   drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 17 -
   drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 22 ++
   drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h| 12 
   3 files changed, 38 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index e1cdd71716f0..e443799de2c1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -1275,8 +1275,6 @@ static void dpu_plane_destroy(struct drm_plane *plane)
   /* this will destroy the states as well */
   drm_plane_cleanup(plane);

- dpu_hw_sspp_destroy(pdpu->pipe_hw);
-

We removed from here so the flow will be msm_drm_uninit calls
drm_mode_config_cleanup() which will call kms->destroy() which shall
call dpu_rm_destroy() where this will be released now right?


Yes. _dpu_kms_hw_destroy() calls dpu_rm_destroy(), which destroys all
RM-allocated objects.


Ack, thanks




   kfree(pdpu);
   }
   }
@@ -1482,14 +1480,10 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
   pdpu->pipe = pipe;

   /* initialize underlying h/w driver */
- pdpu->pipe_hw = dpu_hw_sspp_init(pipe, kms->mmio, kms->catalog);
- if (IS_ERR(pdpu->pipe_hw)) {
- DPU_ERROR("[%u]SSPP init failed\n", pipe);
- ret = PTR_ERR(pdpu->pipe_hw);
+ pdpu->pipe_hw = dpu_rm_get_sspp(>rm, pipe);
+ if (!pdpu->pipe_hw || !pdpu->pipe_hw->cap || !pdpu->pipe_hw->cap->sblk) {
+ DPU_ERROR("[%u]SSPP is invalid\n", pipe);


I know this was existing code but can there be a case where pipe_hw->cap
exists but pipe_hw->cap->sblk doesnt?


There is none up to now, granted that SSPP has a lot of extra data in
sblk. However, as you said, it's an existing code. No need to change
it here. And it's good as a safety net.
Granted that SRC offset is always 0, we can safely drop the src_sblk
and always access it via main register space.


Alright, since this is existing code, lets have it as a separate change.

Hence,

Reviewed-by: Abhinav Kumar 



   goto clean_plane;
- } else if (!pdpu->pipe_hw->cap || !pdpu->pipe_hw->cap->sblk) {
- DPU_ERROR("[%u]SSPP init returned invalid cfg\n", pipe);
- goto clean_sspp;
   }

   format_list = pdpu->pipe_hw->cap->sblk->format_list;
@@ -1499,7 +1493,7 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
   format_list, num_formats,
   supported_format_modifiers, type, NULL);
   if (ret)
- goto clean_sspp;
+ goto clean_plane;

   pdpu->catalog = kms->catalog;

@@ -1532,9 +1526,6 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
   pipe, plane->base.id);
   return plane;

-clean_sspp:
- if (pdpu && pdpu->pipe_hw)
- dpu_hw_sspp_destroy(pdpu->pipe_hw);
   clean_plane:
   kfree(pdpu);
   return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index 73b3442e7467..0668009cc9ed 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -8,6 +8,7 @@
   #include "dpu_hw_lm.h"
   #include "dpu_hw_ctl.h"
   #include "dpu_hw_pingpong.h"
+#include "dpu_hw_sspp.h"
   #include "dpu_hw_intf.h"
   #include "dpu_hw_wb.h"
   #include "dpu_hw_dspp.h"
@@ -91,6 +92,9 @@ int dpu_rm_destroy(struct dpu_rm *rm)
   for (i = 0; i < ARRAY_SIZE(rm->hw_wb); i++)
   dpu_hw_wb_destroy(rm->hw_wb[i]);

+ for (i = 0; i < ARRAY_SIZE(rm->hw_sspp); i++)
+ dpu_hw_sspp_destroy(rm->hw_sspp[i]);
+
   return 0;
   }

@@ -255,6 +259,24 @@ int dpu_rm_init(struct dpu_rm *rm,
   rm->dsc_blks[dsc->id - DSC_0] = >base;
   }

+ for (i = 0; i < cat->sspp_count; i++) {
+ struct dpu_hw_sspp *hw;
+ const struct dpu_sspp_cfg *sspp = >sspp[i];
+
+ if (sspp->id < SSPP_NONE || sspp->id >= SSPP_MAX) {
+ DPU_ERROR("skip intf %d with invalid id\n", sspp->id);
+ continue;
+ }
+
+ hw = dpu_hw_sspp_init(sspp->id, mmio, cat);
+ if (IS_ERR(hw)) {
+ rc = PTR_ERR(hw);
+ DPU_ERROR("failed sspp object creation: err %d\n", rc);
+ goto fail;
+ }
+ rm->hw_sspp[sspp->id - SSPP_NONE] = hw;
+ }
+
   return 0;

   fail:
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
index 59de72b381f9..d62c2edb2460 

[pull] amdgpu drm-next-6.3

[Alex Deucher]

Hi Dave, Daniel,

A few more new things for 6.3.

The following changes since commit b4a9b36e69e935104e52e561aa9a82d39b5efc36:

  Documentation/gpu: update dGPU asic info table (2023-01-19 17:24:26 -0500)

are available in the Git repository at:

  https://gitlab.freedesktop.org/agd5f/linux.git 
tags/amd-drm-next-6.3-2023-01-27

for you to fetch changes up to cdf657fc1f4c9758f86ae3adeb32ee68cbd90691:

  amdgpu: fix build on non-DCN platforms. (2023-01-27 17:25:40 -0500)


amd-drm-next-6.3-2023-01-27:

amdgpu:
- GC11 fixes
- SMU13 fixes
- Freesync fixes
- DP MST fixes
- DP MST code rework and cleanup
- AV1 fixes for VCN4
- DCN 3.2.x fixes
- PSR fixes
- DML optimizations
- DC link code rework


Alex Deucher (1):
  drm/amdgpu/vcn4: add missing encoder cap

Alvin Lee (4):
  drm/amd/display: Allow idle optimization after turning off all pipes
  drm/amd/display: Disable SubVP for PSR panels
  drm/amd/display: Use |= when assigning wm_optimized_required
  drm/amd/display: Set init freq for DCFCLK DS

Anthony Koo (1):
  drm/amd/display: [FW Promotion] Release 0.0.150.0

Aric Cyr (2):
  drm/amd/display: 3.2.219
  drm/amd/display: 3.2.220

Aurabindo Pillai (3):
  drm/amd/display: Revert "ignore msa parameter only if freesync is enabled"
  drm/amd/display: set allow_freesync parameter in DM
  drm/amd/display: Fix timing not changning when freesync video is enabled

Dave Airlie (1):
  amdgpu: fix build on non-DCN platforms.

David (Ming Qiang) Wu (1):
  drm/amdgpu: limit AV1 to the first instance on VCN4 encode

Dillon Varone (1):
  drm/amd/display: Disable MALL SS and messages for PSR supported configs

Evan Quan (1):
  drm/amd/pm: add missing AllowIHInterrupt message mapping for SMU13.0.0

Hamza Mahfooz (1):
  drm/amd/display: use a more appropriate return value in 
dp_retrieve_lttpr_cap()

Ilya Bakoulin (1):
  drm/amd/display: Speed up DML fast_validate path

Jingwen Zhu (1):
  drm/amd/display: avoid disable otg when dig was disabled

Jonathan Kim (1):
  drm/amdgpu: remove unconditional trap enable on add gfx11 queues

Li Ma (2):
  drm/amdgpu: enable imu firmware for GC 11.0.4
  drm/amdgpu: declare firmware for new MES 11.0.4

Lyude Paul (1):
  drm/amdgpu/display/mst: Fix mst_state->pbn_div and slot count assignments

Qingqing Zhuo (1):
  drm/amd/display: force connector state when bpc changes during compliance

Robin Chen (1):
  drm/amd/display: Pass DSC slice height to PSR FW

Roman Li (1):
  drm/amd/display: Set hvm_enabled flag for S/G mode

Saaem Rizvi (1):
  drm/amd/display: Correcting prefetch mode for fast validate

Samson Tam (1):
  drm/amd/display: adjust MALL size available for DCN32 and DCN321

Stylon Wang (2):
  drm/amd/display: Guard Freesync HDMI parsing with dc_lock
  drm/amd/display: Properly reuse completion structure

Sung Joon Kim (1):
  drm/amd/display: Enable AdaptiveSync in DC interface

Tim Huang (1):
  drm/amdgpu: skip psp suspend for IMU enabled ASICs mode2 reset

Wayne Lin (6):
  drm/amdgpu/display/mst: limit payload to be updated one by one
  drm/amdgpu/display/mst: update mst_mgr relevant variable when long HPD
  drm/drm_print: correct format problem
  drm/display/dp_mst: Correct the kref of port.
  drm/amdgpu/display/mst: adjust the naming of mst_port and port of 
aconnector
  drm/amdgpu/display/mst: adjust the logic in 2nd phase of updating payload

Wenjing Liu (5):
  drm/amd/display: create accessories, hwss and protocols sub folders in 
link
  drm/amd/display: move eDP panel control logic to link_edp_panel_control
  drm/amd/display: move dp irq handler functions from dc_link_dp to 
link_dp_irq_handler
  drm/amd/display: move dp cts functions from dc_link_dp to link_dp_cts
  drm/amd/display: merge dc_link_dp into dc_link

 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   12 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h   |4 +-
 drivers/gpu/drm/amd/amdgpu/imu_v11_0.c |1 +
 drivers/gpu/drm/amd/amdgpu/mes_v11_0.c |3 +-
 drivers/gpu/drm/amd/amdgpu/soc21.c |1 +
 drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c  |   62 +-
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  138 +-
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h  |9 +-
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c  |2 +-
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c  |   18 +-
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c  |  200 +-
 .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c|   54 +-
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c  |2 +-
 drivers/gpu/drm/amd/display/dc/Makefile|3 +-
 drivers/gpu/drm/amd/display/dc/clk_mgr/clk_mgr.c   |1 +
 .../amd/display/dc/clk_mgr/dcn31/dcn31_clk_mgr.c   |1 +
 

Re: [Freedreno] [RFT PATCH 2/2] drm/msm/dsi: Stop unconditionally powering up DSI hosts at modeset

[Abhinav Kumar]

On 1/27/2023 2:33 PM, Doug Anderson wrote:

Hi,

On Fri, Jan 27, 2023 at 10:54 AM Abhinav Kumar
 wrote:


On 1/13/2023 3:56 PM, Douglas Anderson wrote:

In commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset
time"), we moved powering up DSI hosts to modeset time. This wasn't
because it was an elegant design, but there were no better options.

That commit actually ended up breaking ps8640, and thus was born
commit ec7981e6c614 ("drm/msm/dsi: don't powerup at modeset time for
parade-ps8640") as a temporary hack to un-break ps8640 by moving it to
the old way of doing things. It turns out that ps8640 _really_ doesn't
like its pre_enable() function to be called after
dsi_mgr_bridge_power_on(). Specifically (from experimentation, not
because I have any inside knowledge), it looks like the assertion of
"RST#" in the ps8640 runtime resume handler seems like it's not
allowed to happen after dsi_mgr_bridge_power_on()

Recently, Dave Stevenson's series landed allowing bridges some control
over pre_enable ordering. The meaty commit for our purposes is commit
4fb912e5e190 ("drm/bridge: Introduce pre_enable_prev_first to alter
bridge init order"). As documented by that series, if a bridge doesn't
set "pre_enable_prev_first" then we should use the old ordering.

Now that we have the commit ("drm/bridge: tc358762: Set
pre_enable_prev_first") we can go back to the old ordering, which also
allows us to remove the ps8640 special case.

One last note is that even without reverting commit 7d8e9a90509f
("drm/msm/dsi: move DSI host powerup to modeset time"), if you _just_
revert the ps8640 special case and try it out then it doesn't seem to
fail anymore. I spent time bisecting / debugging this and it turns out
to be mostly luck, so we still want this patch to make sure it's
solid. Specifically the reason it sorta works these days is because
we implemented wait_hpd_asserted() in ps8640 now, plus the magic of
"pm_runtime" autosuspend. The fact that we have wait_hpd_asserted()
implemented means that we actually power the bridge chip up just a wee
bit earlier and then the bridge happens to stay on because of
autosuspend and thus ends up powered before dsi_mgr_bridge_power_on().

Cc: Dave Stevenson 
Cc: Dmitry Baryshkov 
Cc: Abhinav Kumar 
Signed-off-by: Douglas Anderson 


Why is the patch title showing 2/2? I am not seeing any 1/2 here.


Is it a problem with your mail filters? You can see it at:

https://lore.kernel.org/r/20230113155547.RFT.1.I723a3761d57ea60c5dd754c144aed6c3b2ea6f5a@changeid/

You are listed on the "To:" line. ;-)


Ah, I see what happened. The first patch did not have freedreno CCed but 
the second one did.


So freedreno PW got confused thinking , hey where is the first patch? :)

https://patchwork.freedesktop.org/series/112824/

And so did I :)

Perhaps freedreno should be CCed on both patches because its a series.





@@ -349,7 +297,16 @@ static void dsi_mgr_bridge_pre_enable(struct drm_bridge 
*bridge)
   host1_en_fail:
   msm_dsi_host_disable(host);
   host_en_fail:
-
+ msm_dsi_host_disable_irq(host);
+ if (is_bonded_dsi && msm_dsi1) {
+ msm_dsi_host_disable_irq(msm_dsi1->host);
+ msm_dsi_host_power_off(msm_dsi1->host);
+ }


In addition to Dmitry's comment of keeping the bridge_power_on() name,

this part of the change seems independent of the patch. This was missing
cleanup for DSI1 (esp the disable_irq part).

So can we break it up into two parts.

1) Add missing cleanup for DSI1
2) Just get rid of dsi_mgr_power_on_early() and keep the call
dsi_mgr_bridge_power_on() in dsi_mgr_bridge_pre_enable() unconditionally.


I didn't intentionally fix any bug in my patch--I just reverted it all
back to how it was before. ;-)

No sure what I am missing here but I certainly dont see 
msm_dsi_host_disable_irq() being part of any error handling labels which 
made me think you fixed that.



So looking more closely, it looks like overall the current code (AKA
what's landed today and without ${SUBJECT} patch) doesn't really
handle errors with dsi_mgr_bridge_power_on() very well. The normal
case of calling dsi_mgr_bridge_power_on() from modeset is totally
ignored because modeset returns no error. Then the special workaround
for ps8640 just followed the same pattern and assumed that
dsi_mgr_bridge_power_on() succeeded. It also assumed that if the rest
of dsi_mgr_bridge_pre_enable() failed that it didn't need to undo
dsi_mgr_bridge_power_on() because it wouldn't have undone it in the
modeset case.



Yes thats right.


While the current code isn't the best, it's not like the pre_enable()
call could have returned errors anyway. It probably wasn't truly the
end of the world to behave the way it did.

With all that, I guess my plan would be to do as Dmitry says and just
always call dsi_mgr_bridge_power_on() from
dsi_mgr_bridge_pre_enable(). In the first patch I'll just do that and
remove the ps8640 workaround. Then I can add a 2nd patch that improves
the error 

Re: [Freedreno] [RFT PATCH 2/2] drm/msm/dsi: Stop unconditionally powering up DSI hosts at modeset

[Doug Anderson]

Hi,

On Fri, Jan 27, 2023 at 10:54 AM Abhinav Kumar
 wrote:
>
> On 1/13/2023 3:56 PM, Douglas Anderson wrote:
> > In commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset
> > time"), we moved powering up DSI hosts to modeset time. This wasn't
> > because it was an elegant design, but there were no better options.
> >
> > That commit actually ended up breaking ps8640, and thus was born
> > commit ec7981e6c614 ("drm/msm/dsi: don't powerup at modeset time for
> > parade-ps8640") as a temporary hack to un-break ps8640 by moving it to
> > the old way of doing things. It turns out that ps8640 _really_ doesn't
> > like its pre_enable() function to be called after
> > dsi_mgr_bridge_power_on(). Specifically (from experimentation, not
> > because I have any inside knowledge), it looks like the assertion of
> > "RST#" in the ps8640 runtime resume handler seems like it's not
> > allowed to happen after dsi_mgr_bridge_power_on()
> >
> > Recently, Dave Stevenson's series landed allowing bridges some control
> > over pre_enable ordering. The meaty commit for our purposes is commit
> > 4fb912e5e190 ("drm/bridge: Introduce pre_enable_prev_first to alter
> > bridge init order"). As documented by that series, if a bridge doesn't
> > set "pre_enable_prev_first" then we should use the old ordering.
> >
> > Now that we have the commit ("drm/bridge: tc358762: Set
> > pre_enable_prev_first") we can go back to the old ordering, which also
> > allows us to remove the ps8640 special case.
> >
> > One last note is that even without reverting commit 7d8e9a90509f
> > ("drm/msm/dsi: move DSI host powerup to modeset time"), if you _just_
> > revert the ps8640 special case and try it out then it doesn't seem to
> > fail anymore. I spent time bisecting / debugging this and it turns out
> > to be mostly luck, so we still want this patch to make sure it's
> > solid. Specifically the reason it sorta works these days is because
> > we implemented wait_hpd_asserted() in ps8640 now, plus the magic of
> > "pm_runtime" autosuspend. The fact that we have wait_hpd_asserted()
> > implemented means that we actually power the bridge chip up just a wee
> > bit earlier and then the bridge happens to stay on because of
> > autosuspend and thus ends up powered before dsi_mgr_bridge_power_on().
> >
> > Cc: Dave Stevenson 
> > Cc: Dmitry Baryshkov 
> > Cc: Abhinav Kumar 
> > Signed-off-by: Douglas Anderson 
>
> Why is the patch title showing 2/2? I am not seeing any 1/2 here.

Is it a problem with your mail filters? You can see it at:

https://lore.kernel.org/r/20230113155547.RFT.1.I723a3761d57ea60c5dd754c144aed6c3b2ea6f5a@changeid/

You are listed on the "To:" line. ;-)


> > @@ -349,7 +297,16 @@ static void dsi_mgr_bridge_pre_enable(struct 
> > drm_bridge *bridge)
> >   host1_en_fail:
> >   msm_dsi_host_disable(host);
> >   host_en_fail:
> > -
> > + msm_dsi_host_disable_irq(host);
> > + if (is_bonded_dsi && msm_dsi1) {
> > + msm_dsi_host_disable_irq(msm_dsi1->host);
> > + msm_dsi_host_power_off(msm_dsi1->host);
> > + }
>
> In addition to Dmitry's comment of keeping the bridge_power_on() name,
>
> this part of the change seems independent of the patch. This was missing
> cleanup for DSI1 (esp the disable_irq part).
>
> So can we break it up into two parts.
>
> 1) Add missing cleanup for DSI1
> 2) Just get rid of dsi_mgr_power_on_early() and keep the call
> dsi_mgr_bridge_power_on() in dsi_mgr_bridge_pre_enable() unconditionally.

I didn't intentionally fix any bug in my patch--I just reverted it all
back to how it was before. ;-)

So looking more closely, it looks like overall the current code (AKA
what's landed today and without ${SUBJECT} patch) doesn't really
handle errors with dsi_mgr_bridge_power_on() very well. The normal
case of calling dsi_mgr_bridge_power_on() from modeset is totally
ignored because modeset returns no error. Then the special workaround
for ps8640 just followed the same pattern and assumed that
dsi_mgr_bridge_power_on() succeeded. It also assumed that if the rest
of dsi_mgr_bridge_pre_enable() failed that it didn't need to undo
dsi_mgr_bridge_power_on() because it wouldn't have undone it in the
modeset case.

While the current code isn't the best, it's not like the pre_enable()
call could have returned errors anyway. It probably wasn't truly the
end of the world to behave the way it did.

With all that, I guess my plan would be to do as Dmitry says and just
always call dsi_mgr_bridge_power_on() from
dsi_mgr_bridge_pre_enable(). In the first patch I'll just do that and
remove the ps8640 workaround. Then I can add a 2nd patch that improves
the error handling by having dsi_mgr_bridge_power_on() return an error
code and then adding a matching dsi_mgr_bridge_power_off() that will
undo it and include the extra cleanup.

-Doug

[PATCH] [v2] accel: fix CONFIG_DRM dependencies

[Arnd Bergmann]

From: Arnd Bergmann 

At the moment, accel drivers can be built-in even with CONFIG_DRM=m,
but this causes a link failure:

x86_64-linux-ld: drivers/accel/ivpu/ivpu_drv.o: in function `ivpu_dev_init':
ivpu_drv.c:(.text+0x1535): undefined reference to `drmm_kmalloc'
x86_64-linux-ld: ivpu_drv.c:(.text+0x1562): undefined reference to 
`drmm_kmalloc'
x86_64-linux-ld: drivers/accel/ivpu/ivpu_drv.o: in function `ivpu_remove':
ivpu_drv.c:(.text+0x1faa): undefined reference to `drm_dev_unregister'
x86_64-linux-ld: drivers/accel/ivpu/ivpu_drv.o: in function `ivpu_probe':
ivpu_drv.c:(.text+0x1fef): undefined reference to `__devm_drm_dev_alloc'

The problem is that DRM_ACCEL is a 'bool' symbol symbol, so driver that
only depend on DRM_ACCEL but not also on DRM do not see the restriction
to =m configs.

To ensure that each accel driver has an implied dependency on CONFIG_DRM,
enclose the entire Kconfig file in an if/endif check.

Fixes: 8bf4889762a8 ("drivers/accel: define kconfig and register a new major")
Signed-off-by: Arnd Bergmann 
---
v2: rearrage the DRM dependency rather than requiring DRM to be built-in
---
 drivers/accel/Kconfig | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/accel/Kconfig b/drivers/accel/Kconfig
index 834863902e16..c437206aa3f1 100644
--- a/drivers/accel/Kconfig
+++ b/drivers/accel/Kconfig
@@ -6,9 +6,10 @@
 # as, but not limited to, Machine-Learning and Deep-Learning acceleration
 # devices
 #
+if DRM
+
 menuconfig DRM_ACCEL
bool "Compute Acceleration Framework"
-   depends on DRM
help
  Framework for device drivers of compute acceleration devices, such
  as, but not limited to, Machine-Learning and Deep-Learning
@@ -25,3 +26,5 @@ menuconfig DRM_ACCEL
 
 source "drivers/accel/habanalabs/Kconfig"
 source "drivers/accel/ivpu/Kconfig"
+
+endif
-- 
2.39.0

[PATCH] gpu: host1x: fix uninitialized variable use

[Arnd Bergmann]

From: Arnd Bergmann 

The error handling for platform_get_irq() failing no longer
works after a recent change, clang now points this out with
a warning:

drivers/gpu/host1x/dev.c:520:6: error: variable 'syncpt_irq' is uninitialized 
when used here [-Werror,-Wuninitialized]
if (syncpt_irq < 0)
^~

Fix this by removing the variable and checking the correct
error status.

Fixes: 625d4ffb438c ("gpu: host1x: Rewrite syncpoint interrupt handling")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/host1x/dev.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index 4872d183d860..aae2efeef503 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -487,7 +487,6 @@ static int host1x_get_resets(struct host1x *host)
 static int host1x_probe(struct platform_device *pdev)
 {
struct host1x *host;
-   int syncpt_irq;
int err;
 
host = devm_kzalloc(>dev, sizeof(*host), GFP_KERNEL);
@@ -517,8 +516,8 @@ static int host1x_probe(struct platform_device *pdev)
}
 
host->syncpt_irq = platform_get_irq(pdev, 0);
-   if (syncpt_irq < 0)
-   return syncpt_irq;
+   if (host->syncpt_irq < 0)
+   return host->syncpt_irq;
 
mutex_init(>devices_lock);
INIT_LIST_HEAD(>devices);
-- 
2.39.0

Re: [PATCH v2] drm/mediatek: Add support for AR30 and BA30

[Justin Green]

Thanks for the suggestion! That's a lot cleaner than manually
traversing the device tree. Will send out another patch.

On Thu, Jan 26, 2023 at 7:36 PM Chun-Kuang Hu  wrote:
>
> Hi, Justin:
>
> Justin Green  於 2023年1月11日 週三 上午4:47寫道：
> >
> > Add support for AR30 and BA30 pixel formats to the Mediatek DRM driver.
> >
> > Tested using "modetest -P" on an MT8195.
> >
> > Signed-off-by: Justin Green 
> > ---
> > v2:
> >  * Rebase and resolve merge conflicts with the AFBC patch.
> >
> >  drivers/gpu/drm/mediatek/mtk_disp_ovl.c  | 28 +
> >  drivers/gpu/drm/mediatek/mtk_drm_crtc.c  | 19 +++-
> >  drivers/gpu/drm/mediatek/mtk_drm_plane.c | 39 +---
> >  drivers/gpu/drm/mediatek/mtk_drm_plane.h |  2 +-
> >  4 files changed, 81 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
> > b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > index 84daeaffab6a..667ae57c8754 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > @@ -41,6 +41,7 @@
> >  #define DISP_REG_OVL_RDMA_CTRL(n)  (0x00c0 + 0x20 * (n))
> >  #define DISP_REG_OVL_RDMA_GMC(n)   (0x00c8 + 0x20 * (n))
> >  #define DISP_REG_OVL_ADDR_MT2701   0x0040
> > +#define DISP_REG_OVL_CLRFMT_EXT0x02D0
> >  #define DISP_REG_OVL_ADDR_MT8173   0x0f40
> >  #define DISP_REG_OVL_ADDR(ovl, n)  ((ovl)->data->addr + 0x20 * 
> > (n))
> >  #define DISP_REG_OVL_HDR_ADDR(ovl, n)  ((ovl)->data->addr + 0x20 * 
> > (n) + 0x04)
> > @@ -61,6 +62,10 @@
> > 0 : OVL_CON_CLRFMT_RGB)
> >  #define OVL_CON_CLRFMT_RGB888(ovl) ((ovl)->data->fmt_rgb565_is_0 ? \
> > OVL_CON_CLRFMT_RGB : 0)
> > +#define OVL_CON_CLRFMT_BIT_DEPTH_MASK(ovl) (0xFF << 4 * (ovl))
> > +#define OVL_CON_CLRFMT_BIT_DEPTH(depth, ovl)   (depth << 4 * (ovl))
> > +#define OVL_CON_CLRFMT_8_BIT   0x00
> > +#define OVL_CON_CLRFMT_10_BIT  0x01
> >  #defineOVL_CON_AEN BIT(8)
> >  #defineOVL_CON_ALPHA   0xff
> >  #defineOVL_CON_VIRT_FLIP   BIT(9)
> > @@ -188,6 +193,26 @@ static void mtk_ovl_set_afbc(struct mtk_disp_ovl *ovl, 
> > struct cmdq_pkt *cmdq_pkt
> >DISP_REG_OVL_DATAPATH_CON, 
> > OVL_LAYER_AFBC_EN(idx));
> >  }
> >
> > +static void mtk_ovl_set_bit_depth(struct device *dev, int idx, u32 format,
> > + struct cmdq_pkt *cmdq_pkt)
> > +{
> > +   struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
> > +   unsigned int reg;
> > +   unsigned int bit_depth = OVL_CON_CLRFMT_8_BIT;
> > +
> > +   reg = readl(ovl->regs + DISP_REG_OVL_CLRFMT_EXT);
> > +   reg &= ~OVL_CON_CLRFMT_BIT_DEPTH_MASK(idx);
> > +
> > +   if (format == DRM_FORMAT_RGBA1010102 ||
> > +   format == DRM_FORMAT_BGRA1010102 ||
> > +   format == DRM_FORMAT_ARGB2101010)
> > +   bit_depth = OVL_CON_CLRFMT_10_BIT;
> > +
> > +   reg |= OVL_CON_CLRFMT_BIT_DEPTH(bit_depth, idx);
> > +
> > +   mtk_ddp_write(cmdq_pkt, reg, >cmdq_reg, ovl->regs, 
> > DISP_REG_OVL_CLRFMT_EXT);
> > +}
> > +
> >  void mtk_ovl_config(struct device *dev, unsigned int w,
> > unsigned int h, unsigned int vrefresh,
> > unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
> > @@ -302,9 +327,11 @@ static unsigned int ovl_fmt_convert(struct 
> > mtk_disp_ovl *ovl, unsigned int fmt)
> > return OVL_CON_CLRFMT_ARGB;
> > case DRM_FORMAT_BGRX:
> > case DRM_FORMAT_BGRA:
> > +   case DRM_FORMAT_BGRA1010102:
> > return OVL_CON_CLRFMT_ARGB | OVL_CON_BYTE_SWAP;
> > case DRM_FORMAT_XRGB:
> > case DRM_FORMAT_ARGB:
> > +   case DRM_FORMAT_ARGB2101010:
> > return OVL_CON_CLRFMT_RGBA;
> > case DRM_FORMAT_XBGR:
> > case DRM_FORMAT_ABGR:
> > @@ -388,6 +415,7 @@ void mtk_ovl_layer_config(struct device *dev, unsigned 
> > int idx,
> >   >cmdq_reg, ovl->regs, 
> > DISP_REG_OVL_PITCH_MSB(idx));
> > }
> >
> > +   mtk_ovl_set_bit_depth(dev, idx, fmt, cmdq_pkt);
> > mtk_ovl_layer_on(dev, idx, cmdq_pkt);
> >  }
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > index 112615817dcb..d50379c97c4b 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > @@ -842,6 +842,21 @@ enum drm_plane_type mtk_drm_crtc_plane_type(unsigned 
> > int plane_idx,
> >
> >  }
> >
> > +static const char *ovls_with_10bit_cap[] = {
> > +   "mediatek,mt8195-disp-ovl",
> > +};
> > +
> > +static bool is_10bit_cap_device(void)
> > +{
> > +   for (int i = 0; i < ARRAY_SIZE(ovls_with_10bit_cap); i++) {
> > +  

Re: [git pull] drm fixes for 6.2-rc6

[pr-tracker-bot]

The pull request you sent on Fri, 27 Jan 2023 15:22:36 +1000:

> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-01-27

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/76e26e3c6a49b368a6fd38e2da2b1b164470cc52

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [PATCH drm-next 05/14] drm/nouveau: new VM_BIND uapi interfaces

[Danilo Krummrich]

On 1/27/23 16:17, Christian König wrote:

Am 27.01.23 um 15:44 schrieb Danilo Krummrich:

[SNIP]


What you want is one component for tracking the VA allocations 
(drm_mm based) and a different component/interface for tracking the 
VA mappings (probably rb tree based).


That's what the GPUVA manager is doing. There are gpuva_regions 
which correspond to VA allocations and gpuvas which represent the 
mappings. Both are tracked separately (currently both with a 
separate drm_mm, though). However, the GPUVA manager needs to take 
regions into account when dealing with mappings to make sure the 
GPUVA manager doesn't propose drivers to merge over region 
boundaries. Speaking from userspace PoV, the kernel wouldn't merge 
mappings from different VKBuffer objects even if they're virtually 
and physically contiguous.


That are two completely different things and shouldn't be handled in 
a single component.


They are different things, but they're related in a way that for 
handling the mappings (in particular merging and sparse) the GPUVA 
manager needs to know the VA allocation (or region) boundaries.


I have the feeling there might be a misunderstanding. Userspace is in 
charge to actually allocate a portion of VA space and manage it. The 
GPUVA manager just needs to know about those VA space allocations and 
hence keeps track of them.


The GPUVA manager is not meant to be an allocator in the sense of 
finding and providing a hole for a given request.


Maybe the non-ideal choice of using drm_mm was implying something else.


Uff, well long story short that doesn't even remotely match the 
requirements. This way the GPUVA manager won't be usable for a whole 
bunch of use cases.


What we have are mappings which say X needs to point to Y with this and 
hw dependent flags.


The whole idea of having ranges is not going to fly. Neither with AMD 
GPUs and I strongly think not with Intels XA either.


A range in the sense of the GPUVA manager simply represents a VA space 
allocation (which in case of Nouveau is taken in userspace). Userspace 
allocates the portion of VA space and lets the kernel know about it. The 
current implementation needs that for the named reasons. So, I think 
there is no reason why this would work with one GPU, but not with 
another. It's just part of the design choice of the manager.


And I'm absolutely happy to discuss the details of the manager 
implementation though.




We should probably talk about the design of the GPUVA manager once 
more when this should be applicable to all GPU drivers.


That's what I try to figure out with this RFC, how to make it 
appicable for all GPU drivers, so I'm happy to discuss this. :-)


Yeah, that was really good idea :) That proposal here is really far away 
from the actual requirements.




And those are the ones I'm looking for. Do you mind sharing the 
requirements for amdgpu in particular?


For sparse residency the kernel also needs to know the region 
boundaries to make sure that it keeps sparse mappings around.


What?


When userspace creates a new VKBuffer with the 
VK_BUFFER_CREATE_SPARSE_BINDING_BIT the kernel may need to create 
sparse mappings in order to ensure that using this buffer without any 
memory backed mappings doesn't fault the GPU.


Currently, the implementation does this the following way:

1. Userspace creates a new VKBuffer and hence allocates a portion of 
the VA space for it. It calls into the kernel indicating the new VA 
space region and the fact that the region is sparse.


2. The kernel picks up the region and stores it in the GPUVA manager, 
the driver creates the corresponding sparse mappings / page table 
entries.


3. Userspace might ask the driver to create a couple of memory backed 
mappings for this particular VA region. The GPUVA manager stores the 
mapping parameters, the driver creates the corresponding page table 
entries.


4. Userspace might ask to unmap all the memory backed mappings from 
this particular VA region. The GPUVA manager removes the mapping 
parameters, the driver cleans up the corresponding page table entries. 
However, the driver also needs to re-create the sparse mappings, since 
it's a sparse buffer, hence it needs to know the boundaries of the 
region it needs to create the sparse mappings in.


Again, this is not how things are working. First of all the kernel 
absolutely should *NOT* know about those regions.


What we have inside the kernel is the information what happens if an 
address X is accessed. On AMD HW this can be:


1. Route to the PCIe bus because the mapped BO is stored in system memory.
2. Route to the internal MC because the mapped BO is stored in local 
memory.

3. Route to other GPUs in the same hive.
4. Route to some doorbell to kick of other work.
...
x. Ignore write, return 0 on reads (this is what is used for sparse 
mappings).

x+1. Trigger a recoverable page fault. This is used for things like SVA.
x+2. Trigger a non-recoverable page fault. This is used 

[PATCH] drm/arm/malidp: use sysfs_emit in show function callback

[Deepak R Varma]

According to Documentation/filesystems/sysfs.rst, the show() callback
function of kobject attributes should strictly use sysfs_emit() instead
of sprintf() family functions.
Issue identified using the device_attr_show.cocci Coccinelle script.

Signed-off-by: Deepak R Varma 
---
 drivers/gpu/drm/arm/malidp_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 589c1c66a6dc..cf040e2e9efe 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -649,7 +649,7 @@ static ssize_t core_id_show(struct device *dev, struct 
device_attribute *attr,
struct drm_device *drm = dev_get_drvdata(dev);
struct malidp_drm *malidp = drm_to_malidp(drm);
 
-   return snprintf(buf, PAGE_SIZE, "%08x\n", malidp->core_id);
+   return sysfs_emit(buf, "%08x\n", malidp->core_id);
 }
 
 static DEVICE_ATTR_RO(core_id);
-- 
2.34.1

[PATCH] dt-bindings: display: bridge: sil, sii8620: convert to dtschema

[Krzysztof Kozlowski]

Convert the Silicon Image SiI8620 HDMI/MHL bridge bindings to DT schema.

Signed-off-by: Krzysztof Kozlowski 
---
 .../bindings/display/bridge/sil,sii8620.yaml  | 107 ++
 .../bindings/display/bridge/sil-sii8620.txt   |  33 --
 2 files changed, 107 insertions(+), 33 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/sil,sii8620.yaml
 delete mode 100644 
Documentation/devicetree/bindings/display/bridge/sil-sii8620.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/sil,sii8620.yaml 
b/Documentation/devicetree/bindings/display/bridge/sil,sii8620.yaml
new file mode 100644
index ..90532bb99161
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/sil,sii8620.yaml
@@ -0,0 +1,107 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/sil,sii8620.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Silicon Image SiI8620 HDMI/MHL bridge
+
+maintainers:
+  - Krzysztof Kozlowski 
+
+properties:
+  compatible:
+const: sil,sii8620
+
+  reg:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+
+  clock-names:
+items:
+  - const: xtal
+
+  cvcc10-supply:
+description: Digital Core Supply Voltage (1.0V)
+
+  interrupts:
+maxItems: 1
+
+  iovcc18-supply:
+description: I/O Supply Voltage (1.8V)
+
+  reset-gpios:
+maxItems: 1
+
+  ports:
+$ref: /schemas/graph.yaml#/properties/ports
+unevaluatedProperties: false
+
+properties:
+  port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+  Video port for HDMI (encoder) input
+
+  port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+  MHL to connector port
+
+required:
+  - port@0
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - cvcc10-supply
+  - interrupts
+  - iovcc18-supply
+  - reset-gpios
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+bridge@39 {
+reg = <0x39>;
+compatible = "sil,sii8620";
+cvcc10-supply = <_reg>;
+iovcc18-supply = <_reg>;
+interrupt-parent = <>;
+interrupts = <2 IRQ_TYPE_LEVEL_HIGH>;
+reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+clocks = <_system_controller 0>;
+clock-names = "xtal";
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+mhl_to_hdmi: endpoint {
+remote-endpoint = <_to_mhl>;
+};
+};
+
+port@1 {
+reg = <1>;
+mhl_to_musb_con: endpoint {
+remote-endpoint = <_con_to_mhl>;
+};
+};
+};
+};
+};
diff --git a/Documentation/devicetree/bindings/display/bridge/sil-sii8620.txt 
b/Documentation/devicetree/bindings/display/bridge/sil-sii8620.txt
deleted file mode 100644
index b05052f7d62f..
--- a/Documentation/devicetree/bindings/display/bridge/sil-sii8620.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-Silicon Image SiI8620 HDMI/MHL bridge bindings
-
-Required properties:
-   - compatible: "sil,sii8620"
-   - reg: i2c address of the bridge
-   - cvcc10-supply: Digital Core Supply Voltage (1.0V)
-   - iovcc18-supply: I/O Supply Voltage (1.8V)
-   - interrupts: interrupt specifier of INT pin
-   - reset-gpios: gpio specifier of RESET pin
-   - clocks, clock-names: specification and name of "xtal" clock
-   - video interfaces: Device node can contain video interface port
-   node for HDMI encoder according to [1].
-
-[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
-
-Example:
-   sii8620@39 {
-   reg = <0x39>;
-   compatible = "sil,sii8620";
-   cvcc10-supply = <_reg>;
-   iovcc18-supply = <_reg>;
-   interrupt-parent = <>;
-   interrupts = <2 0>;
-   reset-gpio = < 0 0>;
-   clocks = <_system_controller 0>;
-   clock-names = "xtal";
-
-   port {
-   mhl_to_hdmi: endpoint {
-   remote-endpoint = <_to_mhl>;
-   };
-   };
-   };
-- 
2.34.1

Re: [PATCH v7 3/6] mei: clean pending read with vtag on bus

[Rodrigo Vivi]

On Fri, Jan 27, 2023 at 10:09:31AM +0100, Greg Kroah-Hartman wrote:
> On Wed, Jan 25, 2023 at 12:28:29PM -0500, Rodrigo Vivi wrote:
> > 
> > Greg, ack on getting these 3 mei patches merged through intel-gfx?
> 
> I only see 2 mei patches in this series, what am I missing?

right... 2 mei patches only... sorry for the noise and for the top posting.

thanks for the ack.

series pushed to drm-intel-next

> 
> thanks,
> 
> greg k-h

Re: [PATCH drm-next 05/14] drm/nouveau: new VM_BIND uapi interfaces

[David Airlie]

On Sat, Jan 28, 2023 at 1:17 AM Christian König
 wrote:
>
> Am 27.01.23 um 15:44 schrieb Danilo Krummrich:
> > [SNIP]
> 
>  What you want is one component for tracking the VA allocations
>  (drm_mm based) and a different component/interface for tracking the
>  VA mappings (probably rb tree based).
> >>>
> >>> That's what the GPUVA manager is doing. There are gpuva_regions
> >>> which correspond to VA allocations and gpuvas which represent the
> >>> mappings. Both are tracked separately (currently both with a
> >>> separate drm_mm, though). However, the GPUVA manager needs to take
> >>> regions into account when dealing with mappings to make sure the
> >>> GPUVA manager doesn't propose drivers to merge over region
> >>> boundaries. Speaking from userspace PoV, the kernel wouldn't merge
> >>> mappings from different VKBuffer objects even if they're virtually
> >>> and physically contiguous.
> >>
> >> That are two completely different things and shouldn't be handled in
> >> a single component.
> >
> > They are different things, but they're related in a way that for
> > handling the mappings (in particular merging and sparse) the GPUVA
> > manager needs to know the VA allocation (or region) boundaries.
> >
> > I have the feeling there might be a misunderstanding. Userspace is in
> > charge to actually allocate a portion of VA space and manage it. The
> > GPUVA manager just needs to know about those VA space allocations and
> > hence keeps track of them.
> >
> > The GPUVA manager is not meant to be an allocator in the sense of
> > finding and providing a hole for a given request.
> >
> > Maybe the non-ideal choice of using drm_mm was implying something else.
>
> Uff, well long story short that doesn't even remotely match the
> requirements. This way the GPUVA manager won't be usable for a whole
> bunch of use cases.
>
> What we have are mappings which say X needs to point to Y with this and
> hw dependent flags.
>
> The whole idea of having ranges is not going to fly. Neither with AMD
> GPUs and I strongly think not with Intels XA either.
>
> >> We should probably talk about the design of the GPUVA manager once
> >> more when this should be applicable to all GPU drivers.
> >
> > That's what I try to figure out with this RFC, how to make it
> > appicable for all GPU drivers, so I'm happy to discuss this. :-)
>
> Yeah, that was really good idea :) That proposal here is really far away
> from the actual requirements.
>
> >>> For sparse residency the kernel also needs to know the region
> >>> boundaries to make sure that it keeps sparse mappings around.
> >>
> >> What?
> >
> > When userspace creates a new VKBuffer with the
> > VK_BUFFER_CREATE_SPARSE_BINDING_BIT the kernel may need to create
> > sparse mappings in order to ensure that using this buffer without any
> > memory backed mappings doesn't fault the GPU.
> >
> > Currently, the implementation does this the following way:
> >
> > 1. Userspace creates a new VKBuffer and hence allocates a portion of
> > the VA space for it. It calls into the kernel indicating the new VA
> > space region and the fact that the region is sparse.
> >
> > 2. The kernel picks up the region and stores it in the GPUVA manager,
> > the driver creates the corresponding sparse mappings / page table
> > entries.
> >
> > 3. Userspace might ask the driver to create a couple of memory backed
> > mappings for this particular VA region. The GPUVA manager stores the
> > mapping parameters, the driver creates the corresponding page table
> > entries.
> >
> > 4. Userspace might ask to unmap all the memory backed mappings from
> > this particular VA region. The GPUVA manager removes the mapping
> > parameters, the driver cleans up the corresponding page table entries.
> > However, the driver also needs to re-create the sparse mappings, since
> > it's a sparse buffer, hence it needs to know the boundaries of the
> > region it needs to create the sparse mappings in.
>
> Again, this is not how things are working. First of all the kernel
> absolutely should *NOT* know about those regions.
>
> What we have inside the kernel is the information what happens if an
> address X is accessed. On AMD HW this can be:
>
> 1. Route to the PCIe bus because the mapped BO is stored in system memory.
> 2. Route to the internal MC because the mapped BO is stored in local memory.
> 3. Route to other GPUs in the same hive.
> 4. Route to some doorbell to kick of other work.
> ...
> x. Ignore write, return 0 on reads (this is what is used for sparse
> mappings).
> x+1. Trigger a recoverable page fault. This is used for things like SVA.
> x+2. Trigger a non-recoverable page fault. This is used for things like
> unmapped regions where access is illegal.
>
> All this is plus some hw specific caching flags.
>
> When Vulkan allocates a sparse VKBuffer what should happen is the following:
>
> 1. The Vulkan driver somehow figures out a VA region A..B for the
> buffer. This can be in userspace (libdrm_amdgpu) or 

[PATCH] drm/i915: Fix potential bit_17 double-free

[Rob Clark]

From: Rob Clark 

A userspace with multiple threads racing I915_GEM_SET_TILING to set the
tiling to I915_TILING_NONE could trigger a double free of the bit_17
bitmask.  (Or conversely leak memory on the transition to tiled.)  Move
allocation/free'ing of the bitmask within the section protected by the
obj lock.

Fixes: e9b73c67390a ("drm/i915: Reduce memory pressure during shrinker by 
preallocating swizzle pages")
Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c 
b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
index fd42b89b7162..bc21b1c2350a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
@@ -298,36 +298,37 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object 
*obj,
vma->fence_alignment =
i915_gem_fence_alignment(i915,
 vma->size, tiling, stride);
 
if (vma->fence)
vma->fence->dirty = true;
}
spin_unlock(>vma.lock);
 
obj->tiling_and_stride = tiling | stride;
-   i915_gem_object_unlock(obj);
-
-   /* Force the fence to be reacquired for GTT access */
-   i915_gem_object_release_mmap_gtt(obj);
 
/* Try to preallocate memory required to save swizzling on put-pages */
if (i915_gem_object_needs_bit17_swizzle(obj)) {
if (!obj->bit_17) {
obj->bit_17 = bitmap_zalloc(obj->base.size >> 
PAGE_SHIFT,
GFP_KERNEL);
}
} else {
bitmap_free(obj->bit_17);
obj->bit_17 = NULL;
}
 
+   i915_gem_object_unlock(obj);
+
+   /* Force the fence to be reacquired for GTT access */
+   i915_gem_object_release_mmap_gtt(obj);
+
return 0;
 }
 
 /**
  * i915_gem_set_tiling_ioctl - IOCTL handler to set tiling mode
  * @dev: DRM device
  * @data: data pointer for the ioctl
  * @file: DRM file for the ioctl call
  *
  * Sets the tiling mode of an object, returning the required swizzling of
-- 
2.38.1

Re: [PATCH 5/9] drm/display/dp_mst: Fix the payload VCPI check in drm_dp_mst_dump_topology()

[Imre Deak]

On Fri, Jan 27, 2023 at 09:42:39PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 25, 2023 at 01:48:48PM +0200, Imre Deak wrote:
> > Fix an off-by-one error in the VCPI check in drm_dp_mst_dump_topology().
> > 
> > Cc: Lyude Paul 
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
> > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > index 81cc0c3b1e000..619f616d69e20 100644
> > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > @@ -4770,7 +4770,7 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
> > list_for_each_entry(payload, >payloads, next) {
> > char name[14];
> >  
> > -   if (payload->vcpi != i || payload->delete)
> > +   if (payload->vcpi != i + 1 || payload->delete)
> 
> Why does this code even do that funny nested double loop?

The payload list is not ordered by VCPIs I think, but the printout wants
to list them in VCPI order.

> 
> > continue;
> >  
> > fetch_monitor_name(mgr, payload->port, name, 
> > sizeof(name));
> > -- 
> > 2.37.1
> 
> -- 
> Ville Syrjälä
> Intel

Re: linux-6.2-rc4+ hangs on poweroff/reboot: Bisected

[Chris Clayton]

[Resend because the mail client on my phone decided to turn HTML on behind my 
back, so my reply got bounced.]

Thanks Thorsten.

I did try to revert but it didnt revert cleanly and I don't have the knowledge 
to fix it up.

The patch was part of a merge that included a number of related patches. 
Tomorrow, I'll try to revert the lot and report
back.

Chris



On 27/01/2023 11:20, Linux kernel regression tracking (Thorsten Leemhuis) wrote:
> Hi, this is your Linux kernel regression tracker. Top-posting for once,
> to make this easily accessible to everyone.
> 
> @nouveau-maintainers, did anyone take a look at this? The report is
> already 8 days old and I don't see a single reply. Sure, we'll likely
> get a -rc8, but still it would be good to not fix this on the finish line.
> 
> Chris, btw, did you try if you can revert the commit on top of latest
> mainline? And if so, does it fix the problem?
> 
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
> 
> #regzbot poke
> 
> On 19.01.23 15:33, Linux kernel regression tracking (Thorsten Leemhuis)
> wrote:
>> [adding various lists and the two other nouveau maintainers to the list
>> of recipients]
> 
>> On 18.01.23 21:59, Chris Clayton wrote:
>>> Hi.
>>>
>>> I build and installed the lastest development kernel earlier this week. 
>>> I've found that when I try the laptop down (or
>>> reboot it), it hangs right at the end of closing the current session. The 
>>> last line I see on  the screen when rebooting is:
>>>
>>> sd 4:0:0:0: [sda] Synchronising SCSI cache
>>>
>>> when closing down I see one additional line:
>>>
>>> sd 4:0:0:0 [sda]Stopping disk
>>>
>>> In both cases the machine then hangs and I have to hold down the power 
>>> button fot a few seconds to switch it off.
>>>
>>> Linux 6.1 is OK but 6.2-rc1 hangs, so I bisected between this two and 
>>> landed on:
>>>
>>> # first bad commit: [0e44c21708761977dcbea9b846b51a6fb684907a] 
>>> drm/nouveau/flcn: new code to load+boot simple HS FWs
>>> (VPR scrubber)
>>>
>>> I built and installed a kernel with 
>>> f15cde64b66161bfa74fb58f4e5697d8265b802e (the parent of the bad commit) 
>>> checked out
>>> and that shuts down and reboots fine. It the did the same with the bad 
>>> commit checked out and that does indeed hang, so
>>> I'm confident the bisect outcome is OK.
>>>
>>> Kernels 6.1.6 and 5.15.88 are also OK.
>>>
>>> My system had dual GPUs - one intel and one NVidia. Related extracts from 
>>> 'lscpi -v' is:
>>>
>>> 00:02.0 VGA compatible controller: Intel Corporation CometLake-H GT2 [UHD 
>>> Graphics] (rev 05) (prog-if 00 [VGA controller])
>>> Subsystem: CLEVO/KAPOK Computer CometLake-H GT2 [UHD Graphics]
>>>
>>> Flags: bus master, fast devsel, latency 0, IRQ 142
>>>
>>> Memory at c200 (64-bit, non-prefetchable) [size=16M]
>>>
>>> Memory at a000 (64-bit, prefetchable) [size=256M]
>>>
>>> I/O ports at 5000 [size=64]
>>>
>>> Expansion ROM at 000c [virtual] [disabled] [size=128K]
>>>
>>> Capabilities: [40] Vendor Specific Information: Len=0c 
>>>
>>> Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
>>>
>>> Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit-
>>>
>>> Capabilities: [d0] Power Management version 2
>>>
>>> Kernel driver in use: i915
>>>
>>> Kernel modules: i915
>>>
>>>
>>> 01:00.0 VGA compatible controller: NVIDIA Corporation TU117M [GeForce GTX 
>>> 1650 Ti Mobile] (rev a1) (prog-if 00 [VGA
>>> controller])
>>> Subsystem: CLEVO/KAPOK Computer TU117M [GeForce GTX 1650 Ti Mobile]
>>> Flags: bus master, fast devsel, latency 0, IRQ 141
>>> Memory at c400 (32-bit, non-prefetchable) [size=16M]
>>> Memory at b000 (64-bit, prefetchable) [size=256M]
>>> Memory at c000 (64-bit, prefetchable) [size=32M]
>>> I/O ports at 4000 [size=128]
>>> Expansion ROM at c300 [disabled] [size=512K]
>>> Capabilities: [60] Power Management version 3
>>> Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
>>> Capabilities: [78] Express Legacy Endpoint, MSI 00
>>> Kernel driver in use: nouveau
>>> Kernel modules: nouveau
>>>
>>> DRI_PRIME=1 is exported in one of my init scripts (yes, I am still using 
>>> sysvinit).
>>>
>>> I've attached the bisect.log, but please let me know if I can provide any 
>>> other diagnostics. Please cc me as I'm not
>>> subscribed.
>>
>> Thanks for the report. To be sure the issue doesn't fall through the
>> cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
>> tracking bot:
>>
>> #regzbot ^introduced e44c2170876197
>> #regzbot title drm: nouveau: hangs on poweroff/reboot
>> #regzbot 

Re: [PATCH 5/9] drm/display/dp_mst: Fix the payload VCPI check in drm_dp_mst_dump_topology()

[Ville Syrjälä]

On Wed, Jan 25, 2023 at 01:48:48PM +0200, Imre Deak wrote:
> Fix an off-by-one error in the VCPI check in drm_dp_mst_dump_topology().
> 
> Cc: Lyude Paul 
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index 81cc0c3b1e000..619f616d69e20 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -4770,7 +4770,7 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
>   list_for_each_entry(payload, >payloads, next) {
>   char name[14];
>  
> - if (payload->vcpi != i || payload->delete)
> + if (payload->vcpi != i + 1 || payload->delete)

Why does this code even do that funny nested double loop?

>   continue;
>  
>   fetch_monitor_name(mgr, payload->port, name, 
> sizeof(name));
> -- 
> 2.37.1

-- 
Ville Syrjälä
Intel

Re: [PATCH] drm/nouveau/disp: Fix nvif_outp_acquire_dp() argument size

[Kees Cook]

On Wed, Jan 25, 2023 at 04:24:19PM -0500, Lyude Paul wrote:
> Sorry! I've been pretty busy until now, this is:
> 
> Reviewed-by: Lyude Paul 
> 
> Let me know if you've pushed it already or if you want me to push it to drm-
> misc

Either way is fine. I'm currently carrying it, but I can easily drop it
if you prefer it go via drm-misc.

Thanks!

-Kees

> 
> On Wed, 2023-01-25 at 12:15 -0800, Kees Cook wrote:
> > Ping. I'll take this via my tree unless someone else wants to take it...
> > 
> > On Sun, Nov 27, 2022 at 10:30:41AM -0800, Kees Cook wrote:
> > > Both Coverity and GCC with -Wstringop-overflow noticed that
> > > nvif_outp_acquire_dp() accidentally defined its second argument with 1
> > > additional element:
> > > 
> > > drivers/gpu/drm/nouveau/dispnv50/disp.c: In function 
> > > 'nv50_pior_atomic_enable':
> > > drivers/gpu/drm/nouveau/dispnv50/disp.c:1813:17: error: 
> > > 'nvif_outp_acquire_dp' accessing 16 bytes in a region of size 15 
> > > [-Werror=stringop-overflow=]
> > >  1813 | nvif_outp_acquire_dp(_encoder->outp, 
> > > nv_encoder->dp.dpcd, 0, 0, false, false);
> > >   | 
> > > ^~~
> > > drivers/gpu/drm/nouveau/dispnv50/disp.c:1813:17: note: referencing 
> > > argument 2 of type 'u8[16]' {aka 'unsigned char[16]'}
> > > drivers/gpu/drm/nouveau/include/nvif/outp.h:24:5: note: in a call to 
> > > function 'nvif_outp_acquire_dp'
> > >24 | int nvif_outp_acquire_dp(struct nvif_outp *, u8 dpcd[16],
> > >   | ^~~~
> > > 
> > > Avoid these warnings by defining the argument size using the matching
> > > define (DP_RECEIVER_CAP_SIZE, 15) instead of having it be a literal
> > > (and incorrect) value (16).
> > > 
> > > Reported-by: coverity-bot 
> > > Addresses-Coverity-ID: 1527269 ("Memory - corruptions")
> > > Addresses-Coverity-ID: 1527268 ("Memory - corruptions")
> > > Link: https://lore.kernel.org/lkml/202211100848.FFBA2432@keescook/
> > > Link: https://lore.kernel.org/lkml/202211100848.F4C2819BB@keescook/
> > > Fixes: 813443721331 ("drm/nouveau/disp: move DP link config into acquire")
> > > Cc: Ben Skeggs 
> > > Cc: Karol Herbst 
> > > Cc: Lyude Paul 
> > > Cc: David Airlie 
> > > Cc: Daniel Vetter 
> > > Cc: Dave Airlie 
> > > Cc: "Gustavo A. R. Silva" 
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: nouv...@lists.freedesktop.org
> > > Signed-off-by: Kees Cook 
> > > ---
> > >  drivers/gpu/drm/nouveau/include/nvif/outp.h | 3 ++-
> > >  drivers/gpu/drm/nouveau/nvif/outp.c | 2 +-
> > >  2 files changed, 3 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/nouveau/include/nvif/outp.h 
> > > b/drivers/gpu/drm/nouveau/include/nvif/outp.h
> > > index 45daadec3c0c..fa76a7b5e4b3 100644
> > > --- a/drivers/gpu/drm/nouveau/include/nvif/outp.h
> > > +++ b/drivers/gpu/drm/nouveau/include/nvif/outp.h
> > > @@ -3,6 +3,7 @@
> > >  #define __NVIF_OUTP_H__
> > >  #include 
> > >  #include 
> > > +#include 
> > >  struct nvif_disp;
> > >  
> > >  struct nvif_outp {
> > > @@ -21,7 +22,7 @@ int nvif_outp_acquire_rgb_crt(struct nvif_outp *);
> > >  int nvif_outp_acquire_tmds(struct nvif_outp *, int head,
> > >  bool hdmi, u8 max_ac_packet, u8 rekey, u8 scdc, bool 
> > > hda);
> > >  int nvif_outp_acquire_lvds(struct nvif_outp *, bool dual, bool bpc8);
> > > -int nvif_outp_acquire_dp(struct nvif_outp *, u8 dpcd[16],
> > > +int nvif_outp_acquire_dp(struct nvif_outp *outp, u8 
> > > dpcd[DP_RECEIVER_CAP_SIZE],
> > >int link_nr, int link_bw, bool hda, bool mst);
> > >  void nvif_outp_release(struct nvif_outp *);
> > >  int nvif_outp_infoframe(struct nvif_outp *, u8 type, struct 
> > > nvif_outp_infoframe_v0 *, u32 size);
> > > diff --git a/drivers/gpu/drm/nouveau/nvif/outp.c 
> > > b/drivers/gpu/drm/nouveau/nvif/outp.c
> > > index 7da39f1eae9f..c24bc5eae3ec 100644
> > > --- a/drivers/gpu/drm/nouveau/nvif/outp.c
> > > +++ b/drivers/gpu/drm/nouveau/nvif/outp.c
> > > @@ -127,7 +127,7 @@ nvif_outp_acquire(struct nvif_outp *outp, u8 proto, 
> > > struct nvif_outp_acquire_v0
> > >  }
> > >  
> > >  int
> > > -nvif_outp_acquire_dp(struct nvif_outp *outp, u8 dpcd[16],
> > > +nvif_outp_acquire_dp(struct nvif_outp *outp, u8 
> > > dpcd[DP_RECEIVER_CAP_SIZE],
> > >int link_nr, int link_bw, bool hda, bool mst)
> > >  {
> > >   struct nvif_outp_acquire_v0 args;
> > > -- 
> > > 2.34.1
> > > 
> > 
> 
> -- 
> Cheers,
>  Lyude Paul (she/her)
>  Software Engineer at Red Hat
> 

-- 
Kees Cook

Re: linux-6.2-rc4+ hangs on poweroff/reboot: Bisected

[Chris Clayton]

[Resend because the mail client on my phone dedcided to turn HTML on behinf my 
back, so my repluy got bounced.]

Thanks Karol.

I sent the original report to Ben and LKML. Thorsten then added you, Lyude Paul 
and the dri-devel and nouveau  mail
lists. So you should have received this report on or about January 19.

Chris

On 27/01/2023 11:35, Karol Herbst wrote:
> Where was the original email sent to anyway, because I don't have it at all.
> 
> Anyhow, I suspect we want to fetch logs to see what's happening, but
> due to the nature of this bug it might get difficult.
> 
> I'm checking out the laptops I have here if I can reproduce this
> issue, but I think all mine with Turing GPUs are fine.
> 
> Maybe Ben has any idea what might be wrong with
> 0e44c21708761977dcbea9b846b51a6fb684907a or if that's an issue which
> is already fixed by not upstreamed patches as I think I remember Ben
> to talk about something like that recently.
> 
> Karol
> 
> On Fri, Jan 27, 2023 at 12:20 PM Linux kernel regression tracking
> (Thorsten Leemhuis)  wrote:
>>
>> Hi, this is your Linux kernel regression tracker. Top-posting for once,
>> to make this easily accessible to everyone.
>>
>> @nouveau-maintainers, did anyone take a look at this? The report is
>> already 8 days old and I don't see a single reply. Sure, we'll likely
>> get a -rc8, but still it would be good to not fix this on the finish line.
>>
>> Chris, btw, did you try if you can revert the commit on top of latest
>> mainline? And if so, does it fix the problem?
>>
>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>> --
>> Everything you wanna know about Linux kernel regression tracking:
>> https://linux-regtracking.leemhuis.info/about/#tldr
>> If I did something stupid, please tell me, as explained on that page.
>>
>> #regzbot poke
>>
>> On 19.01.23 15:33, Linux kernel regression tracking (Thorsten Leemhuis)
>> wrote:
>>> [adding various lists and the two other nouveau maintainers to the list
>>> of recipients]
>>
>>> On 18.01.23 21:59, Chris Clayton wrote:
 Hi.

 I build and installed the lastest development kernel earlier this week. 
 I've found that when I try the laptop down (or
 reboot it), it hangs right at the end of closing the current session. The 
 last line I see on  the screen when rebooting is:

  sd 4:0:0:0: [sda] Synchronising SCSI cache

 when closing down I see one additional line:

  sd 4:0:0:0 [sda]Stopping disk

 In both cases the machine then hangs and I have to hold down the power 
 button fot a few seconds to switch it off.

 Linux 6.1 is OK but 6.2-rc1 hangs, so I bisected between this two and 
 landed on:

  # first bad commit: [0e44c21708761977dcbea9b846b51a6fb684907a] 
 drm/nouveau/flcn: new code to load+boot simple HS FWs
 (VPR scrubber)

 I built and installed a kernel with 
 f15cde64b66161bfa74fb58f4e5697d8265b802e (the parent of the bad commit) 
 checked out
 and that shuts down and reboots fine. It the did the same with the bad 
 commit checked out and that does indeed hang, so
 I'm confident the bisect outcome is OK.

 Kernels 6.1.6 and 5.15.88 are also OK.

 My system had dual GPUs - one intel and one NVidia. Related extracts from 
 'lscpi -v' is:

 00:02.0 VGA compatible controller: Intel Corporation CometLake-H GT2 [UHD 
 Graphics] (rev 05) (prog-if 00 [VGA controller])
 Subsystem: CLEVO/KAPOK Computer CometLake-H GT2 [UHD Graphics]

 Flags: bus master, fast devsel, latency 0, IRQ 142

 Memory at c200 (64-bit, non-prefetchable) [size=16M]

 Memory at a000 (64-bit, prefetchable) [size=256M]

 I/O ports at 5000 [size=64]

 Expansion ROM at 000c [virtual] [disabled] [size=128K]

 Capabilities: [40] Vendor Specific Information: Len=0c 

 Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00

 Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit-

 Capabilities: [d0] Power Management version 2

 Kernel driver in use: i915

 Kernel modules: i915


 01:00.0 VGA compatible controller: NVIDIA Corporation TU117M [GeForce GTX 
 1650 Ti Mobile] (rev a1) (prog-if 00 [VGA
 controller])
 Subsystem: CLEVO/KAPOK Computer TU117M [GeForce GTX 1650 Ti Mobile]
 Flags: bus master, fast devsel, latency 0, IRQ 141
 Memory at c400 (32-bit, non-prefetchable) [size=16M]
 Memory at b000 (64-bit, prefetchable) [size=256M]
 Memory at c000 (64-bit, prefetchable) [size=32M]
 I/O ports at 4000 [size=128]
 Expansion ROM at c300 [disabled] [size=512K]
 Capabilities: [60] Power Management version 3
 Capabilities: [68] MSI: 

Re: [PATCH v7 3/6] mei: clean pending read with vtag on bus

[Teres Alexis, Alan Previn]

Hi Greg, appreciate your time on this, 

Patch #2 adds a device link between i915 and mei
(at bind time) specifically for the PXP interface
that is subject to the issue being fixed.

Change is on i915 but implication is mei suspend-resume
aligfnent with i915. Rodrigo has already reviewed it
but Alex and himself felt you might wanna take a look.

...alan


On Fri, 2023-01-27 at 10:09 +0100, Greg Kroah-Hartman wrote:
> On Wed, Jan 25, 2023 at 12:28:29PM -0500, Rodrigo Vivi wrote:
> > 
> > Greg, ack on getting these 3 mei patches merged through intel-gfx?
> 
> I only see 2 mei patches in this series, what am I missing?
> 
> thanks,
> 
> greg k-h

Re: [PATCH 5/7] drm/vmwgfx: Cleanup the vmw bo usage in the cursor paths

[Martin Krastev (VMware)]

From: Martin Krastev 


Ah, good!
Reviewed-by: Martin Krastev 


Regards,
Martin


On 26.01.23 г. 19:38 ч., Zack Rusin wrote:

From: Zack Rusin 

Base mapped count is useless because the ttm unmap functions handle
null maps just fine so completely remove all the code related to it.
Rename dummy to is_iomem because that's what it is even if we're not
activelly using it. Makes the code easier to read.

Signed-off-by: Zack Rusin 
---
  drivers/gpu/drm/vmwgfx/vmwgfx_bo.h  |  4 
  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 28 +---
  2 files changed, 9 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h
index db85609ec01c..4dcf37235cb0 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h
@@ -44,7 +44,6 @@ struct vmw_resource;
   * struct vmw_bo - TTM buffer object with vmwgfx additions
   * @base: The TTM buffer object
   * @res_tree: RB tree of resources using this buffer object as a backing MOB
- * @base_mapped_count: ttm BO mapping count; used by KMS atomic helpers.
   * @cpu_writers: Number of synccpu write grabs. Protected by reservation when
   * increased. May be decreased without reservation.
   * @dx_query_ctx: DX context if this buffer object is used as a DX query MOB
@@ -55,8 +54,6 @@ struct vmw_resource;
  struct vmw_bo {
struct ttm_buffer_object base;
struct rb_root res_tree;
-   /* For KMS atomic helpers: ttm bo mapping count */
-   atomic_t base_mapped_count;
  
  	atomic_t cpu_writers;

/* Not ref-counted.  Protected by binding_mutex */
@@ -67,7 +64,6 @@ struct vmw_bo {
struct vmw_bo_dirty *dirty;
  };
  
-

  int vmw_bo_create_kernel(struct vmw_private *dev_priv,
 unsigned long size,
 struct ttm_placement *placement,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 6780391c57ea..e83286e08837 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -153,9 +153,9 @@ static void vmw_cursor_update_mob(struct vmw_private 
*dev_priv,
SVGAGBCursorHeader *header;
SVGAGBAlphaCursorHeader *alpha_header;
const u32 image_size = width * height * sizeof(*image);
-   bool dummy;
+   bool is_iomem;
  
-	header = ttm_kmap_obj_virtual(>cursor.map, );

+   header = ttm_kmap_obj_virtual(>cursor.map, _iomem);
alpha_header = >header.alphaHeader;
  
  	memset(header, 0, sizeof(*header));

@@ -185,13 +185,13 @@ static u32 vmw_du_cursor_mob_size(u32 w, u32 h)
   */
  static u32 *vmw_du_cursor_plane_acquire_image(struct vmw_plane_state *vps)
  {
-   bool dummy;
+   bool is_iomem;
if (vps->surf) {
if (vps->surf_mapped)
return vmw_bo_map_and_cache(vps->surf->res.backup);
return vps->surf->snooper.image;
} else if (vps->bo)
-   return ttm_kmap_obj_virtual(>bo->map, );
+   return ttm_kmap_obj_virtual(>bo->map, _iomem);
return NULL;
  }
  
@@ -364,7 +364,7 @@ void vmw_kms_cursor_snoop(struct vmw_surface *srf,

SVGA3dCopyBox *box;
unsigned box_count;
void *virtual;
-   bool dummy;
+   bool is_iomem;
struct vmw_dma_cmd {
SVGA3dCmdHeader header;
SVGA3dCmdSurfaceDMA dma;
@@ -424,7 +424,7 @@ void vmw_kms_cursor_snoop(struct vmw_surface *srf,
if (unlikely(ret != 0))
goto err_unreserve;
  
-	virtual = ttm_kmap_obj_virtual(, );

+   virtual = ttm_kmap_obj_virtual(, _iomem);
  
  	if (box->w == VMW_CURSOR_SNOOP_WIDTH && cmd->dma.guest.pitch == image_pitch) {

memcpy(srf->snooper.image, virtual,
@@ -658,19 +658,18 @@ vmw_du_cursor_plane_cleanup_fb(struct drm_plane *plane,
  {
struct vmw_cursor_plane *vcp = vmw_plane_to_vcp(plane);
struct vmw_plane_state *vps = vmw_plane_state_to_vps(old_state);
-   bool dummy;
+   bool is_iomem;
  
  	if (vps->surf_mapped) {

vmw_bo_unmap(vps->surf->res.backup);
vps->surf_mapped = false;
}
  
-	if (vps->bo && ttm_kmap_obj_virtual(>bo->map, )) {

+   if (vps->bo && ttm_kmap_obj_virtual(>bo->map, _iomem)) {
const int ret = ttm_bo_reserve(>bo->base, true, false, 
NULL);
  
  		if (likely(ret == 0)) {

-   if (atomic_read(>bo->base_mapped_count) == 0)
-   ttm_bo_kunmap(>bo->map);
+   ttm_bo_kunmap(>bo->map);
ttm_bo_unreserve(>bo->base);
}
}
@@ -744,9 +743,6 @@ vmw_du_cursor_plane_prepare_fb(struct drm_plane *plane,
  
  		ret = ttm_bo_kmap(>bo->base, 0, PFN_UP(size), >bo->map);
  
-		if (likely(ret == 0))

-   atomic_inc(>bo->base_mapped_count);
-
ttm_bo_unreserve(>bo->base);
  
  		if (unlikely(ret != 0))

@@ -786,7 

Re: [Freedreno] [RFT PATCH 2/2] drm/msm/dsi: Stop unconditionally powering up DSI hosts at modeset

[Abhinav Kumar]

On 1/13/2023 3:56 PM, Douglas Anderson wrote:

In commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset
time"), we moved powering up DSI hosts to modeset time. This wasn't
because it was an elegant design, but there were no better options.

That commit actually ended up breaking ps8640, and thus was born
commit ec7981e6c614 ("drm/msm/dsi: don't powerup at modeset time for
parade-ps8640") as a temporary hack to un-break ps8640 by moving it to
the old way of doing things. It turns out that ps8640 _really_ doesn't
like its pre_enable() function to be called after
dsi_mgr_bridge_power_on(). Specifically (from experimentation, not
because I have any inside knowledge), it looks like the assertion of
"RST#" in the ps8640 runtime resume handler seems like it's not
allowed to happen after dsi_mgr_bridge_power_on()

Recently, Dave Stevenson's series landed allowing bridges some control
over pre_enable ordering. The meaty commit for our purposes is commit
4fb912e5e190 ("drm/bridge: Introduce pre_enable_prev_first to alter
bridge init order"). As documented by that series, if a bridge doesn't
set "pre_enable_prev_first" then we should use the old ordering.

Now that we have the commit ("drm/bridge: tc358762: Set
pre_enable_prev_first") we can go back to the old ordering, which also
allows us to remove the ps8640 special case.

One last note is that even without reverting commit 7d8e9a90509f
("drm/msm/dsi: move DSI host powerup to modeset time"), if you _just_
revert the ps8640 special case and try it out then it doesn't seem to
fail anymore. I spent time bisecting / debugging this and it turns out
to be mostly luck, so we still want this patch to make sure it's
solid. Specifically the reason it sorta works these days is because
we implemented wait_hpd_asserted() in ps8640 now, plus the magic of
"pm_runtime" autosuspend. The fact that we have wait_hpd_asserted()
implemented means that we actually power the bridge chip up just a wee
bit earlier and then the bridge happens to stay on because of
autosuspend and thus ends up powered before dsi_mgr_bridge_power_on().

Cc: Dave Stevenson 
Cc: Dmitry Baryshkov 
Cc: Abhinav Kumar 
Signed-off-by: Douglas Anderson 


Why is the patch title showing 2/2? I am not seeing any 1/2 here.


---

  drivers/gpu/drm/msm/dsi/dsi_manager.c | 68 +--
  1 file changed, 11 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c 
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 3a1417397283..5e6b8d423b96 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -34,32 +34,6 @@ static struct msm_dsi_manager msm_dsim_glb;
  #define IS_SYNC_NEEDED()  (msm_dsim_glb.is_sync_needed)
  #define IS_MASTER_DSI_LINK(id)(msm_dsim_glb.master_dsi_link_id == id)
  
-#ifdef CONFIG_OF

-static bool dsi_mgr_power_on_early(struct drm_bridge *bridge)
-{
-   struct drm_bridge *next_bridge = drm_bridge_get_next_bridge(bridge);
-
-   /*
-* If the next bridge in the chain is the Parade ps8640 bridge chip
-* then don't power on early since it seems to violate the expectations
-* of the firmware that the bridge chip is running.
-*
-* NOTE: this is expected to be a temporary special case. It's expected
-* that we'll eventually have a framework that allows the next level
-* bridge to indicate whether it needs us to power on before it or
-* after it. When that framework is in place then we'll use it and
-* remove this special case.
-*/
-   return !(next_bridge && next_bridge->of_node &&
-of_device_is_compatible(next_bridge->of_node, 
"parade,ps8640"));
-}
-#else
-static inline bool dsi_mgr_power_on_early(struct drm_bridge *bridge)
-{
-   return true;
-}
-#endif
-
  static inline struct msm_dsi *dsi_mgr_get_dsi(int id)
  {
return msm_dsim_glb.dsi[id];
@@ -254,7 +228,7 @@ static void msm_dsi_manager_set_split_display(u8 id)
}
  }
  
-static void dsi_mgr_bridge_power_on(struct drm_bridge *bridge)

+static void dsi_mgr_bridge_pre_enable(struct drm_bridge *bridge)
  {
int id = dsi_mgr_bridge_get_id(bridge);
struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
@@ -300,36 +274,10 @@ static void dsi_mgr_bridge_power_on(struct drm_bridge 
*bridge)
if (is_bonded_dsi && msm_dsi1)
msm_dsi_host_enable_irq(msm_dsi1->host);
  
-	return;

-
-host1_on_fail:
-   msm_dsi_host_power_off(host);
-host_on_fail:
-   dsi_mgr_phy_disable(id);
-phy_en_fail:
-   return;
-}
-
-static void dsi_mgr_bridge_pre_enable(struct drm_bridge *bridge)
-{
-   int id = dsi_mgr_bridge_get_id(bridge);
-   struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
-   struct msm_dsi *msm_dsi1 = dsi_mgr_get_dsi(DSI_1);
-   struct mipi_dsi_host *host = msm_dsi->host;
-   bool is_bonded_dsi = IS_BONDED_DSI();
-   int ret;
-
-   DBG("id=%d", id);
-   if 

Re: [PATCH 4/7] drm/vmwgfx: Simplify fb pinning

[Martin Krastev (VMware)]

From: Martin Krastev 


LGTM!
Reviewed-by: Martin Krastev 


Regards,
Martin


On 26.01.23 г. 19:38 ч., Zack Rusin wrote:

From: Zack Rusin 

Only the legacy display unit requires pinning of the fb memory in vram.
Both the screen objects and screen targets can present from any buffer.
That makes the pinning abstraction pointless. Simplify all of the code
and move it to the legacy display unit, the only place that needs it.

Signed-off-by: Zack Rusin 
---
  drivers/gpu/drm/vmwgfx/vmwgfx_bo.c  |  8 ++--
  drivers/gpu/drm/vmwgfx/vmwgfx_bo.h  |  4 --
  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 66 -
  drivers/gpu/drm/vmwgfx/vmwgfx_kms.h |  4 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 57 +
  5 files changed, 54 insertions(+), 85 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index 586e1f1e9e49..fa289e67143d 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -86,10 +86,10 @@ static bool bo_is_vmw(struct ttm_buffer_object *bo)
   * Return: Zero on success, Negative error code on failure. In particular
   * -ERESTARTSYS if interrupted by a signal
   */
-int vmw_bo_pin_in_placement(struct vmw_private *dev_priv,
-   struct vmw_bo *buf,
-   struct ttm_placement *placement,
-   bool interruptible)
+static int vmw_bo_pin_in_placement(struct vmw_private *dev_priv,
+  struct vmw_bo *buf,
+  struct ttm_placement *placement,
+  bool interruptible)
  {
struct ttm_operation_ctx ctx = {interruptible, false };
struct ttm_buffer_object *bo = >base;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h
index 298406da1d79..db85609ec01c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h
@@ -83,10 +83,6 @@ int vmw_bo_init(struct vmw_private *dev_priv,
  int vmw_bo_unref_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file_priv);
  
-int vmw_bo_pin_in_placement(struct vmw_private *vmw_priv,

-   struct vmw_bo *bo,
-   struct ttm_placement *placement,
-   bool interruptible);
  int vmw_bo_pin_in_vram(struct vmw_private *dev_priv,
   struct vmw_bo *buf,
   bool interruptible);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index ad41396c0a5d..6780391c57ea 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1487,69 +1487,6 @@ static const struct drm_framebuffer_funcs 
vmw_framebuffer_bo_funcs = {
.dirty = vmw_framebuffer_bo_dirty_ext,
  };
  
-/*

- * Pin the bofer in a location suitable for access by the
- * display system.
- */
-static int vmw_framebuffer_pin(struct vmw_framebuffer *vfb)
-{
-   struct vmw_private *dev_priv = vmw_priv(vfb->base.dev);
-   struct vmw_bo *buf;
-   struct ttm_placement *placement;
-   int ret;
-
-   buf = vfb->bo ?  vmw_framebuffer_to_vfbd(>base)->buffer :
-   vmw_framebuffer_to_vfbs(>base)->surface->res.backup;
-
-   if (!buf)
-   return 0;
-
-   switch (dev_priv->active_display_unit) {
-   case vmw_du_legacy:
-   vmw_overlay_pause_all(dev_priv);
-   ret = vmw_bo_pin_in_start_of_vram(dev_priv, buf, false);
-   vmw_overlay_resume_all(dev_priv);
-   break;
-   case vmw_du_screen_object:
-   case vmw_du_screen_target:
-   if (vfb->bo) {
-   if (dev_priv->capabilities & SVGA_CAP_3D) {
-   /*
-* Use surface DMA to get content to
-* sreen target surface.
-*/
-   placement = _vram_gmr_placement;
-   } else {
-   /* Use CPU blit. */
-   placement = _sys_placement;
-   }
-   } else {
-   /* Use surface / image update */
-   placement = _mob_placement;
-   }
-
-   return vmw_bo_pin_in_placement(dev_priv, buf, placement, false);
-   default:
-   return -EINVAL;
-   }
-
-   return ret;
-}
-
-static int vmw_framebuffer_unpin(struct vmw_framebuffer *vfb)
-{
-   struct vmw_private *dev_priv = vmw_priv(vfb->base.dev);
-   struct vmw_bo *buf;
-
-   buf = vfb->bo ?  vmw_framebuffer_to_vfbd(>base)->buffer :
-   vmw_framebuffer_to_vfbs(>base)->surface->res.backup;
-
-   if (WARN_ON(!buf))
-   return 0;
-
-   return vmw_bo_unpin(dev_priv, buf, false);
-}
-
  /**
   * 

Re: [PATCH] drm/mediatek: Remove unused GEM DMA header include

[Doug Anderson]

Hi,

On Fri, Jan 27, 2023 at 8:54 AM Rob Clark  wrote:
>
> From: Rob Clark 
>
> No longer needed since the removal of dependency on DMA helper.
>
> Fixes: 2ea8aec56bf1 ("drm/mediatek: Remove dependency on GEM DMA helper")
> Signed-off-by: Rob Clark 

Reported-by: Douglas Anderson 
Reviewed-by: Douglas Anderson 

> ---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index cd5b18ef7951..7e2fad8e8444 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -20,8 +20,8 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
> +#include 

It took me a little while to realize why you needed this extra
include. I guess DEFINE_DRM_GEM_FOPS implicitly refers to drm_ioctl().
Seems like really drm_gem.h ought to be the one including drm_ioctl.h,
but maybe there's a good reason why we don't do that?

-Doug

Re: [PATCH v3 01/10] drm/client: Test for connectors before sending hotplug event

[Simon Ser]

On Wednesday, January 25th, 2023 at 21:04, Thomas Zimmermann 
 wrote:

> Not having connectors indicates a driver bug.

Is it? What if all connectors are of the DP-MST type, ie. they are
created on-the-fly?

Re: [RESEND PATCH v11 02/18] drm: bridge: panel: Add devm_drm_of_dsi_get_bridge helper

[Jagan Teki]

Hi,

On Thu, Jan 26, 2023 at 8:48 PM Jagan Teki  wrote:
>
> On Thu, Jan 26, 2023 at 5:42 PM Maxime Ripard  wrote:
> >
> > Hi,
> >
> > On Mon, Jan 23, 2023 at 08:41:56PM +0530, Jagan Teki wrote:
> > > Add devm OF helper to return the next DSI bridge in the chain.
> > >
> > > Unlike general bridge return helper devm_drm_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 child DSI node or a DT node's port and
> > > endpoint number, find the connected node and return either
> > > the associated struct drm_panel or drm_bridge device.
> >
> > I'm not sure that using a device managed helper is the right choice
> > here. The bridge will stay longer than the backing device so it will
> > create a use-after-free. You should probably use a DRM-managed action
> > here instead.
>
> Thanks for the comments. If I understand correctly we can use
> drmm_panel_bridge_add instead devm_drm_panel_bridge_add once we found
> the panel or bridge - am I correct?

Look like it is not possible to use DRM-managed action helper here as
devm_drm_of_dsi_get_bridge is calling from the DSI host attach hook in
which we cannot find drm_device pointer (as drm_device pointer is
mandatory for using DRM-managed action).
https://github.com/openedev/kernel/blob/imx8mm-dsi-v12/drivers/gpu/drm/bridge/samsung-dsim.c#L1545

Please check and correct me if I mentioned any incorrect details.

Thanks,
Jagan.

Re: [PATCH v3 04/10] drm/fbdev-generic: Initialize fb-helper structure in generic setup

[Sam Ravnborg]

On Fri, Jan 27, 2023 at 03:21:30PM +0100, Thomas Zimmermann wrote:
> Hi
> 
> Am 25.01.23 um 22:03 schrieb Sam Ravnborg:
> > Hi Thomas,
> > 
> > On Wed, Jan 25, 2023 at 09:04:09PM +0100, Thomas Zimmermann wrote:
> > > Initialize the fb-helper structure immediately after its allocation
> > > in drm_fbdev_generic_setup(). That will make it easier to fill it with
> > > driver-specific values, such as the preferred BPP.
> > > 
> > > Signed-off-by: Thomas Zimmermann 
> > > Reviewed-by: Javier Martinez Canillas 
> > > ---
> > >   drivers/gpu/drm/drm_fbdev_generic.c | 13 +
> > >   1 file changed, 9 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_fbdev_generic.c 
> > > b/drivers/gpu/drm/drm_fbdev_generic.c
> > > index 135d58b8007b..63f66325a8a5 100644
> > > --- a/drivers/gpu/drm/drm_fbdev_generic.c
> > > +++ b/drivers/gpu/drm/drm_fbdev_generic.c
> > > @@ -385,8 +385,6 @@ static int drm_fbdev_client_hotplug(struct 
> > > drm_client_dev *client)
> > >   if (dev->fb_helper)
> > >   return drm_fb_helper_hotplug_event(dev->fb_helper);
> > > - drm_fb_helper_prepare(dev, fb_helper, _fb_helper_generic_funcs);
> > > -
> > >   ret = drm_fb_helper_init(dev, fb_helper);
> > >   if (ret)
> > >   goto err;
> > 
> >  From the documentation:
> > The drm_fb_helper_prepare()
> > helper must be called first to initialize the minimum required to make
> > hotplug detection work.
> > ...
> > To finish up the fbdev helper initialization, the
> > drm_fb_helper_init() function is called.
> > 
> > So this change do not follow the documentation as drm_fb_helper_init()
> > is now called before drm_fb_helper_prepare()
> 
> No, we now call drm_fb_helper_prepare() from within
> drm_fbdev_generic_setup(), right after allocating the fb_helper.
> drm_fb_helper_init() will only be called after the client received a
> hot-plug event.
> 
> > 
> > I did not follow all the code - but my gut feeling is that the
> > documentation is right.
> 
> The docs are of low quality. The _prepare() helper is the actual init
> function and _init() only sets the fb_helper in the device instance.
OK, thanks for the follow-up.


Sam

Re: [RFT PATCH 2/2] drm/msm/dsi: Stop unconditionally powering up DSI hosts at modeset

[Dmitry Baryshkov]

On 27/01/2023 18:32, Doug Anderson wrote:

Hi,

On Thu, Jan 26, 2023 at 9:49 PM Dmitry Baryshkov
 wrote:


Hi,

On Sat, 14 Jan 2023 at 01:56, Douglas Anderson  wrote:


In commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset
time"), we moved powering up DSI hosts to modeset time. This wasn't
because it was an elegant design, but there were no better options.

That commit actually ended up breaking ps8640, and thus was born
commit ec7981e6c614 ("drm/msm/dsi: don't powerup at modeset time for
parade-ps8640") as a temporary hack to un-break ps8640 by moving it to
the old way of doing things. It turns out that ps8640 _really_ doesn't
like its pre_enable() function to be called after
dsi_mgr_bridge_power_on(). Specifically (from experimentation, not
because I have any inside knowledge), it looks like the assertion of
"RST#" in the ps8640 runtime resume handler seems like it's not
allowed to happen after dsi_mgr_bridge_power_on()

Recently, Dave Stevenson's series landed allowing bridges some control
over pre_enable ordering. The meaty commit for our purposes is commit
4fb912e5e190 ("drm/bridge: Introduce pre_enable_prev_first to alter
bridge init order"). As documented by that series, if a bridge doesn't
set "pre_enable_prev_first" then we should use the old ordering.

Now that we have the commit ("drm/bridge: tc358762: Set
pre_enable_prev_first") we can go back to the old ordering, which also
allows us to remove the ps8640 special case.

One last note is that even without reverting commit 7d8e9a90509f
("drm/msm/dsi: move DSI host powerup to modeset time"), if you _just_
revert the ps8640 special case and try it out then it doesn't seem to
fail anymore. I spent time bisecting / debugging this and it turns out
to be mostly luck, so we still want this patch to make sure it's
solid. Specifically the reason it sorta works these days is because
we implemented wait_hpd_asserted() in ps8640 now, plus the magic of
"pm_runtime" autosuspend. The fact that we have wait_hpd_asserted()
implemented means that we actually power the bridge chip up just a wee
bit earlier and then the bridge happens to stay on because of
autosuspend and thus ends up powered before dsi_mgr_bridge_power_on().


I had a small comment on your patch, but then I was distracted and
forgot to send it. See below.



Cc: Dave Stevenson 
Cc: Dmitry Baryshkov 
Cc: Abhinav Kumar 
Signed-off-by: Douglas Anderson 
---

  drivers/gpu/drm/msm/dsi/dsi_manager.c | 68 +--
  1 file changed, 11 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c 
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 3a1417397283..5e6b8d423b96 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -34,32 +34,6 @@ static struct msm_dsi_manager msm_dsim_glb;
  #define IS_SYNC_NEEDED()   (msm_dsim_glb.is_sync_needed)
  #define IS_MASTER_DSI_LINK(id) (msm_dsim_glb.master_dsi_link_id == id)

-#ifdef CONFIG_OF
-static bool dsi_mgr_power_on_early(struct drm_bridge *bridge)
-{
-   struct drm_bridge *next_bridge = drm_bridge_get_next_bridge(bridge);
-
-   /*
-* If the next bridge in the chain is the Parade ps8640 bridge chip
-* then don't power on early since it seems to violate the expectations
-* of the firmware that the bridge chip is running.
-*
-* NOTE: this is expected to be a temporary special case. It's expected
-* that we'll eventually have a framework that allows the next level
-* bridge to indicate whether it needs us to power on before it or
-* after it. When that framework is in place then we'll use it and
-* remove this special case.
-*/
-   return !(next_bridge && next_bridge->of_node &&
-of_device_is_compatible(next_bridge->of_node, 
"parade,ps8640"));
-}
-#else
-static inline bool dsi_mgr_power_on_early(struct drm_bridge *bridge)
-{
-   return true;
-}
-#endif
-
  static inline struct msm_dsi *dsi_mgr_get_dsi(int id)
  {
 return msm_dsim_glb.dsi[id];
@@ -254,7 +228,7 @@ static void msm_dsi_manager_set_split_display(u8 id)
 }
  }

-static void dsi_mgr_bridge_power_on(struct drm_bridge *bridge)
+static void dsi_mgr_bridge_pre_enable(struct drm_bridge *bridge)


Can you please keep the dsi_mgr_bridge_power_on() as is and just
remove the now-legacy dsi_mgr_power_on_early().


By this, I assume you mean keep the function separate but still remove
the call to it from "modeset" and unconditionally call it from
dsi_mgr_bridge_pre_enable(), right?


Yes, of course.





  {
 int id = dsi_mgr_bridge_get_id(bridge);
 struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
@@ -300,36 +274,10 @@ static void dsi_mgr_bridge_power_on(struct drm_bridge 
*bridge)
 if (is_bonded_dsi && msm_dsi1)
 msm_dsi_host_enable_irq(msm_dsi1->host);

-   return;
-
-host1_on_fail:
-   msm_dsi_host_power_off(host);
-host_on_fail:
-   

Re: [PATCH v3 01/10] drm/client: Test for connectors before sending hotplug event

[Sam Ravnborg]

On Fri, Jan 27, 2023 at 03:13:50PM +0100, Thomas Zimmermann wrote:
> Hi
> 
> Am 25.01.23 um 21:52 schrieb Sam Ravnborg:
> > Hi Thomas,
> > 
> > On Wed, Jan 25, 2023 at 09:04:06PM +0100, Thomas Zimmermann wrote:
> > > Test for connectors in the client code and remove a similar test
> > > from the generic fbdev emulation. Do nothing if the test fails.
> > > Not having connectors indicates a driver bug.
> > > 
> > > Signed-off-by: Thomas Zimmermann 
> > > Reviewed-by: Javier Martinez Canillas 
> > > ---
> > >   drivers/gpu/drm/drm_client.c| 5 +
> > >   drivers/gpu/drm/drm_fbdev_generic.c | 5 -
> > >   2 files changed, 5 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> > > index 262ec64d4397..09ac191c202d 100644
> > > --- a/drivers/gpu/drm/drm_client.c
> > > +++ b/drivers/gpu/drm/drm_client.c
> > > @@ -198,6 +198,11 @@ void drm_client_dev_hotplug(struct drm_device *dev)
> > >   if (!drm_core_check_feature(dev, DRIVER_MODESET))
> > >   return;
> > > + if (!dev->mode_config.num_connector) {
> > > + drm_dbg_kms(dev, "No connectors found, will not send hotplug 
> > > events!\n");
> > > + return;
> > This deserves a more visible logging - if a driver fails here it would
> > be good to spot it in the normal kernel log.
> > drm_info or drm_notice?
> 
> But is that really noteworthy? AFAIK, this situation can legally happen. So
> if it's expected, why should we print a message about it?
I was reading it as a driver error - as that's not the case current code
is fine.

Sam

Re: [PATCH 3/7] drm/vmwgfx: Rename vmw_buffer_object to vmw_bo

[Martin Krastev (VMware)]

From: Martin Krastev 


LGTM!
Reviewed-by: Martin Krastev 


Regards,
Martin


On 26.01.23 г. 19:38 ч., Zack Rusin wrote:

From: Zack Rusin 

The rest of the drivers which are using ttm have mostly standardized on
driver_prefix_bo as the name for subclasses of the TTM buffer object.
Make vmwgfx match the rest of the drivers and follow the same naming
semantics.

This is especially clear given that the name of the file in which the
object was defined is vmw_bo.c.

Signed-off-by: Zack Rusin 
---
  drivers/gpu/drm/vmwgfx/vmwgfx_bo.c   |  91 +
  drivers/gpu/drm/vmwgfx/vmwgfx_bo.h   | 191 +++
  drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c  |  10 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c   |   9 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_context.c  |  11 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c  |   9 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c  |   7 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_drv.h  | 182 ++
  drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c  |  53 +++--
  drivers/gpu/drm/vmwgfx/vmwgfx_fence.c|   2 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_gem.c  |  26 +--
  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  |  17 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_kms.h  |  12 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_mob.c  |   7 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c  |  18 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c   |  27 +--
  drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |  29 +--
  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c |  15 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_shader.c   |  15 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c |  13 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_streamoutput.c |   9 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_surface.c  |   9 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c   |   3 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_validation.c   |  30 +--
  drivers/gpu/drm/vmwgfx/vmwgfx_validation.h   |   6 +-
  25 files changed, 431 insertions(+), 370 deletions(-)
  create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_bo.h

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index 8aaeeecd2016..586e1f1e9e49 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -1,7 +1,7 @@
  // SPDX-License-Identifier: GPL-2.0 OR MIT
  /**
   *
- * Copyright © 2011-2018 VMware, Inc., Palo Alto, CA., USA
+ * Copyright © 2011-2023 VMware, Inc., Palo Alto, CA., USA
   * All Rights Reserved.
   *
   * Permission is hereby granted, free of charge, to any person obtaining a
@@ -26,55 +26,54 @@
   *
   **/
  
-#include 

-
+#include "vmwgfx_bo.h"
  #include "vmwgfx_drv.h"
-#include "ttm_object.h"
  
  
+#include 

+
  /**
- * vmw_buffer_object - Convert a struct ttm_buffer_object to a struct
- * vmw_buffer_object.
+ * vmw_bo - Convert a struct ttm_buffer_object to a struct vmw_bo.
   *
   * @bo: Pointer to the TTM buffer object.
- * Return: Pointer to the struct vmw_buffer_object embedding the
+ * Return: Pointer to the struct vmw_bo embedding the
   * TTM buffer object.
   */
-static struct vmw_buffer_object *
-vmw_buffer_object(struct ttm_buffer_object *bo)
+static struct vmw_bo *
+vmw_bo(struct ttm_buffer_object *bo)
  {
-   return container_of(bo, struct vmw_buffer_object, base);
+   return container_of(bo, struct vmw_bo, base);
  }
  
  /**

- * vmw_bo_bo_free - vmw buffer object destructor
+ * vmw_bo_free - vmw_bo destructor
   *
   * @bo: Pointer to the embedded struct ttm_buffer_object
   */
-static void vmw_bo_bo_free(struct ttm_buffer_object *bo)
+static void vmw_bo_free(struct ttm_buffer_object *bo)
  {
-   struct vmw_buffer_object *vmw_bo = vmw_buffer_object(bo);
+   struct vmw_bo *vbo = vmw_bo(bo);
  
-	WARN_ON(vmw_bo->dirty);

-   WARN_ON(!RB_EMPTY_ROOT(_bo->res_tree));
-   vmw_bo_unmap(vmw_bo);
+   WARN_ON(vbo->dirty);
+   WARN_ON(!RB_EMPTY_ROOT(>res_tree));
+   vmw_bo_unmap(vbo);
drm_gem_object_release(>base);
-   kfree(vmw_bo);
+   kfree(vbo);
  }
  
  /**

- * bo_is_vmw - check if the buffer object is a _buffer_object
+ * bo_is_vmw - check if the buffer object is a _bo
   * @bo: ttm buffer object to be checked
   *
   * Uses destroy function associated with the object to determine if this is
- * a _buffer_object.
+ * a _bo.
   *
   * Returns:
- * true if the object is of _buffer_object type, false if not.
+ * true if the object is of _bo type, false if not.
   */
  static bool bo_is_vmw(struct ttm_buffer_object *bo)
  {
-   return bo->destroy == _bo_bo_free;
+   return bo->destroy == _bo_free;
  }
  
  /**

@@ -88,7 +87,7 @@ static bool bo_is_vmw(struct ttm_buffer_object *bo)
   * -ERESTARTSYS if interrupted by a signal
   */
  int vmw_bo_pin_in_placement(struct vmw_private *dev_priv,
-   struct vmw_buffer_object 

[GIT PULL] drm/tegra: Changes for v6.3-rc1

[Thierry Reding]

Hi Dave, Daniel,

The following changes since commit 1b929c02afd37871d5afb9d498426f83432e71c2:

  Linux 6.2-rc1 (2022-12-25 13:41:39 -0800)

are available in the Git repository at:

  https://gitlab.freedesktop.org/drm/tegra.git tags/drm/tegra/for-6.3-rc1

for you to fetch changes up to 2abdd44e3126e29cc310cbf5f1eda7ca7d979df3:

  drm/tegra: nvdec: Use tegra_dev_iommu_get_stream_id() (2023-01-27 17:49:44 
+0100)

Thanks,
Thierry


drm/tegra: Changes for v6.3-rc1

This set of changes includes a rework of the custom syncpoint interrupt
code to take better advantage of existing DRM/KMS infrastructure.

There's also various bits of cleanup and fixes included.


Mikko Perttunen (7):
  gpu: host1x: Fix mask for syncpoint increment register
  gpu: host1x: Don't skip assigning syncpoints to channels
  drm/tegra: firewall: Check for is_addr_reg existence in IMM check
  gpu: host1x: Implement syncpoint wait using DMA fences
  gpu: host1x: Implement job tracking using DMA fences
  gpu: host1x: Rewrite syncpoint interrupt handling
  gpu: host1x: External timeout/cancellation for fences

Paul Cercueil (1):
  drm/tegra: Remove #ifdef guards for PM related functions

Thierry Reding (5):
  MAINTAINERS: Update Tegra DRM tree
  gpu: host1x: Use tegra_dev_iommu_get_stream_id()
  drm/tegra: Use tegra_dev_iommu_get_stream_id()
  drm/tegra: vic: Use tegra_dev_iommu_get_stream_id()
  drm/tegra: nvdec: Use tegra_dev_iommu_get_stream_id()

Yushan Zhou (1):
  drm/tegra: Remove redundant null checks before kfree

 MAINTAINERS|   2 +-
 drivers/gpu/drm/tegra/dpaux.c  |   6 +-
 drivers/gpu/drm/tegra/firewall.c   |   3 +
 drivers/gpu/drm/tegra/nvdec.c  |  16 +-
 drivers/gpu/drm/tegra/submit.c |  19 +-
 drivers/gpu/drm/tegra/vic.c|  39 ++--
 drivers/gpu/host1x/cdma.c  |  14 +-
 drivers/gpu/host1x/cdma.h  |   2 +
 drivers/gpu/host1x/context.c   |   8 +-
 drivers/gpu/host1x/debug.c |   7 +-
 drivers/gpu/host1x/dev.c   |   4 +-
 drivers/gpu/host1x/dev.h   |  10 +-
 drivers/gpu/host1x/fence.c | 118 +-
 drivers/gpu/host1x/fence.h |  19 +-
 drivers/gpu/host1x/hw/channel_hw.c |  60 +++---
 drivers/gpu/host1x/hw/hw_host1x06_uclass.h |   2 +-
 drivers/gpu/host1x/hw/hw_host1x07_uclass.h |   2 +-
 drivers/gpu/host1x/hw/hw_host1x08_uclass.h |   2 +-
 drivers/gpu/host1x/hw/intr_hw.c|  74 ++-
 drivers/gpu/host1x/hw/syncpt_hw.c  |   3 -
 drivers/gpu/host1x/intr.c  | 334 +
 drivers/gpu/host1x/intr.h  |  83 +--
 drivers/gpu/host1x/job.c   |  12 +-
 drivers/gpu/host1x/syncpt.c|  98 ++---
 drivers/gpu/host1x/syncpt.h|   3 +-
 include/linux/host1x.h |  10 +-
 26 files changed, 285 insertions(+), 665 deletions(-)

Re: [PATCH 2/7] drm/vmwgfx: Remove the duplicate bo_free function

[Martin Krastev (VMware)]

From: Martin Krastev 


LGTM!
Reviewed-by: Martin Krastev 


Regards,
Martin


On 26.01.23 г. 19:38 ч., Zack Rusin wrote:

From: Zack Rusin 

Remove the explicit bo_free parameter which was switching between
vmw_bo_bo_free and vmw_gem_destroy which had exactly the same
implementation.

It makes no sense to keep parameter which is always the same, remove it
and all code referencing it. Instead use the vmw_bo_bo_free directly.

Signed-off-by: Zack Rusin 
---
  drivers/gpu/drm/vmwgfx/vmwgfx_bo.c   | 49 ++--
  drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c  |  2 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c  |  3 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_drv.h  |  6 +--
  drivers/gpu/drm/vmwgfx/vmwgfx_gem.c  | 18 +
  drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |  3 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c |  2 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_shader.c   |  2 +-
  8 files changed, 27 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index aa1cd5126a32..8aaeeecd2016 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -46,6 +46,22 @@ vmw_buffer_object(struct ttm_buffer_object *bo)
return container_of(bo, struct vmw_buffer_object, base);
  }
  
+/**

+ * vmw_bo_bo_free - vmw buffer object destructor
+ *
+ * @bo: Pointer to the embedded struct ttm_buffer_object
+ */
+static void vmw_bo_bo_free(struct ttm_buffer_object *bo)
+{
+   struct vmw_buffer_object *vmw_bo = vmw_buffer_object(bo);
+
+   WARN_ON(vmw_bo->dirty);
+   WARN_ON(!RB_EMPTY_ROOT(_bo->res_tree));
+   vmw_bo_unmap(vmw_bo);
+   drm_gem_object_release(>base);
+   kfree(vmw_bo);
+}
+
  /**
   * bo_is_vmw - check if the buffer object is a _buffer_object
   * @bo: ttm buffer object to be checked
@@ -58,8 +74,7 @@ vmw_buffer_object(struct ttm_buffer_object *bo)
   */
  static bool bo_is_vmw(struct ttm_buffer_object *bo)
  {
-   return bo->destroy == _bo_bo_free ||
-  bo->destroy == _gem_destroy;
+   return bo->destroy == _bo_bo_free;
  }
  
  /**

@@ -376,23 +391,6 @@ void vmw_bo_unmap(struct vmw_buffer_object *vbo)
ttm_bo_kunmap(>map);
  }
  
-

-/**
- * vmw_bo_bo_free - vmw buffer object destructor
- *
- * @bo: Pointer to the embedded struct ttm_buffer_object
- */
-void vmw_bo_bo_free(struct ttm_buffer_object *bo)
-{
-   struct vmw_buffer_object *vmw_bo = vmw_buffer_object(bo);
-
-   WARN_ON(vmw_bo->dirty);
-   WARN_ON(!RB_EMPTY_ROOT(_bo->res_tree));
-   vmw_bo_unmap(vmw_bo);
-   drm_gem_object_release(>base);
-   kfree(vmw_bo);
-}
-
  /* default destructor */
  static void vmw_bo_default_destroy(struct ttm_buffer_object *bo)
  {
@@ -449,13 +447,10 @@ int vmw_bo_create_kernel(struct vmw_private *dev_priv, 
unsigned long size,
  int vmw_bo_create(struct vmw_private *vmw,
  size_t size, struct ttm_placement *placement,
  bool interruptible, bool pin,
- void (*bo_free)(struct ttm_buffer_object *bo),
  struct vmw_buffer_object **p_bo)
  {
int ret;
  
-	BUG_ON(!bo_free);

-
*p_bo = kmalloc(sizeof(**p_bo), GFP_KERNEL);
if (unlikely(!*p_bo)) {
DRM_ERROR("Failed to allocate a buffer.\n");
@@ -463,8 +458,7 @@ int vmw_bo_create(struct vmw_private *vmw,
}
  
  	ret = vmw_bo_init(vmw, *p_bo, size,

- placement, interruptible, pin,
- bo_free);
+ placement, interruptible, pin);
if (unlikely(ret != 0))
goto out_error;
  
@@ -484,7 +478,6 @@ int vmw_bo_create(struct vmw_private *vmw,

   * @placement: Initial placement.
   * @interruptible: Whether waits should be performed interruptible.
   * @pin: If the BO should be created pinned at a fixed location.
- * @bo_free: The buffer object destructor.
   * Returns: Zero on success, negative error code on error.
   *
   * Note that on error, the code will free the buffer object.
@@ -492,8 +485,7 @@ int vmw_bo_create(struct vmw_private *vmw,
  int vmw_bo_init(struct vmw_private *dev_priv,
struct vmw_buffer_object *vmw_bo,
size_t size, struct ttm_placement *placement,
-   bool interruptible, bool pin,
-   void (*bo_free)(struct ttm_buffer_object *bo))
+   bool interruptible, bool pin)
  {
struct ttm_operation_ctx ctx = {
.interruptible = interruptible,
@@ -503,7 +495,6 @@ int vmw_bo_init(struct vmw_private *dev_priv,
struct drm_device *vdev = _priv->drm;
int ret;
  
-	WARN_ON_ONCE(!bo_free);

memset(vmw_bo, 0, sizeof(*vmw_bo));
BUILD_BUG_ON(TTM_MAX_BO_PRIORITY <= 3);
vmw_bo->base.priority = 3;
@@ -513,7 +504,7 @@ int vmw_bo_init(struct vmw_private *dev_priv,
drm_gem_private_object_init(vdev, _bo->base.base, size);
  
  	ret = ttm_bo_init_reserved(bdev, _bo->base, 

[GIT PULL FOR v6.3] R-Car DU fixes and improvements

[Laurent Pinchart]

Hello Dave, Daniel,

The following changes since commit 1b929c02afd37871d5afb9d498426f83432e71c2:

  Linux 6.2-rc1 (2022-12-25 13:41:39 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/pinchartl/linux.git 
tags/drm-next-20230127

for you to fetch changes up to fd228eb0b482cf2e43847fab46d57ba7b06c6d48:

  drm: rcar-du: Stop accessing non-existent registers on gen4 (2023-01-24 
00:41:13 +0200)

Note that the changes to the DU driver depend on changes to the VSP1
driver, usually merged through the media tree. As there are no
conflicting changes for v6.3, Mauro has agreed that the simplest option
is to merge this all through a single tree and acked the first five
commits in this branch. They are based directly on top of v6.2-rc1 (and
pushed to the next/media/vsp/formats branch in the same repository), and
can thus be merged in the media tree as well should the need arise at
the last minute without creating any conflict.


Renesas R-Car DU fixes and improvements


Koji Matsuoka (1):
  drm: rcar-du: lvds: Fix stop sequence

Peter Robinson (1):
  drm: rcar-du: Depend on DRM_RCAR_DU for components on that SoC

Tomi Valkeinen (17):
  media: Add 2-10-10-10 RGB formats
  media: Add Y210, Y212 and Y216 formats
  media: renesas: vsp1: Change V3U to be gen4
  media: renesas: vsp1: Add V4H SoC version
  media: renesas: vsp1: Add new formats (2-10-10-10 ARGB, Y210, Y212)
  drm: rcar-du: Bump V3U to gen 4
  drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210)
  dt-bindings: display: renesas,du: Provide bindings for r8a779g0
  dt-bindings: display: bridge: renesas,dsi-csi2-tx: Add r8a779g0
  drm: rcar-du: Add r8a779g0 support
  drm: rcar-du: dsi: Add r8A779g0 support
  drm: rcar-du: dsi: Add 'select RESET_CONTROLLER'
  drm: rcar-du: lvds: Add runtime PM
  drm: rcar-du: lvds: Add reset control
  drm: rcar-du: Add quirk for H3 ES1.x pclk workaround
  drm: rcar-du: Fix setting a reserved bit in DPLLCR
  drm: rcar-du: Stop accessing non-existent registers on gen4

 .../display/bridge/renesas,dsi-csi2-tx.yaml|   3 +-
 .../devicetree/bindings/display/renesas,du.yaml|   2 +
 .../userspace-api/media/v4l/pixfmt-packed-yuv.rst  |  49 +-
 .../userspace-api/media/v4l/pixfmt-rgb.rst | 194 
 drivers/gpu/drm/rcar-du/Kconfig|   6 +
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c |  39 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c  |  73 ++-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h  |   2 +
 drivers/gpu/drm/rcar-du/rcar_du_group.c|  26 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c  |  30 ++
 drivers/gpu/drm/rcar-du/rcar_du_regs.h |   8 +-
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c  |  50 ++-
 drivers/gpu/drm/rcar-du/rcar_lvds.c|  92 +++-
 drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c| 497 +++--
 drivers/gpu/drm/rcar-du/rcar_mipi_dsi_regs.h   |   6 +-
 drivers/media/platform/renesas/vsp1/vsp1_drv.c |   4 +-
 drivers/media/platform/renesas/vsp1/vsp1_hgo.c |   4 +-
 drivers/media/platform/renesas/vsp1/vsp1_lif.c |   1 +
 drivers/media/platform/renesas/vsp1/vsp1_pipe.c|  18 +
 drivers/media/platform/renesas/vsp1/vsp1_regs.h|  26 +-
 drivers/media/platform/renesas/vsp1/vsp1_rpf.c |  64 ++-
 drivers/media/platform/renesas/vsp1/vsp1_video.c   |   4 +-
 drivers/media/platform/renesas/vsp1/vsp1_wpf.c |   4 +-
 drivers/media/v4l2-core/v4l2-ioctl.c   |   6 +
 include/uapi/linux/videodev2.h |  11 +
 25 files changed, 1034 insertions(+), 185 deletions(-)


-- 
Regards,

Laurent Pinchart

[PATCH] fbdev: Fix invalid page access after closing deferred I/O devices

[Takashi Iwai]

When a fbdev with deferred I/O is once opened and closed, the dirty
pages still remain queued in the pageref list, and eventually later
those may be processed in the delayed work.  This may lead to a
corruption of pages, hitting an Oops.

This patch makes sure to cancel the delayed work and clean up the
pageref list at closing the device for addressing the bug.  A part of
the cleanup code is factored out as a new helper function that is
called from the common fb_release().

Cc: 
Signed-off-by: Takashi Iwai 
---
 drivers/video/fbdev/core/fb_defio.c | 10 +-
 drivers/video/fbdev/core/fbmem.c|  2 ++
 include/linux/fb.h  |  1 +
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/core/fb_defio.c 
b/drivers/video/fbdev/core/fb_defio.c
index c730253ab85c..583cbcf09446 100644
--- a/drivers/video/fbdev/core/fb_defio.c
+++ b/drivers/video/fbdev/core/fb_defio.c
@@ -313,7 +313,7 @@ void fb_deferred_io_open(struct fb_info *info,
 }
 EXPORT_SYMBOL_GPL(fb_deferred_io_open);
 
-void fb_deferred_io_cleanup(struct fb_info *info)
+void fb_deferred_io_release(struct fb_info *info)
 {
struct fb_deferred_io *fbdefio = info->fbdefio;
struct page *page;
@@ -327,6 +327,14 @@ void fb_deferred_io_cleanup(struct fb_info *info)
page = fb_deferred_io_page(info, i);
page->mapping = NULL;
}
+}
+EXPORT_SYMBOL_GPL(fb_deferred_io_release);
+
+void fb_deferred_io_cleanup(struct fb_info *info)
+{
+   struct fb_deferred_io *fbdefio = info->fbdefio;
+
+   fb_deferred_io_release(info);
 
kvfree(info->pagerefs);
mutex_destroy(>lock);
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 3a6c8458eb8d..78c4cb5ee7c9 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1454,6 +1454,8 @@ __releases(>lock)
struct fb_info * const info = file->private_data;
 
lock_fb_info(info);
+   if (info->fbdefio)
+   fb_deferred_io_release(info);
if (info->fbops->fb_release)
info->fbops->fb_release(info,1);
module_put(info->fbops->owner);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 96b96323e9cb..73eb1f85ea8e 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -662,6 +662,7 @@ extern int  fb_deferred_io_init(struct fb_info *info);
 extern void fb_deferred_io_open(struct fb_info *info,
struct inode *inode,
struct file *file);
+extern void fb_deferred_io_release(struct fb_info *info);
 extern void fb_deferred_io_cleanup(struct fb_info *info);
 extern int fb_deferred_io_fsync(struct file *file, loff_t start,
loff_t end, int datasync);
-- 
2.35.3

[PATCH] drm/mediatek: Remove unused GEM DMA header include

[Rob Clark]

From: Rob Clark 

No longer needed since the removal of dependency on DMA helper.

Fixes: 2ea8aec56bf1 ("drm/mediatek: Remove dependency on GEM DMA helper")
Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index cd5b18ef7951..7e2fad8e8444 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -20,8 +20,8 @@
 #include 
 #include 
 #include 
-#include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.38.1

Re: [RFT PATCH 2/2] drm/msm/dsi: Stop unconditionally powering up DSI hosts at modeset

[Doug Anderson]

Hi,

On Thu, Jan 26, 2023 at 9:49 PM Dmitry Baryshkov
 wrote:
>
> Hi,
>
> On Sat, 14 Jan 2023 at 01:56, Douglas Anderson  wrote:
> >
> > In commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset
> > time"), we moved powering up DSI hosts to modeset time. This wasn't
> > because it was an elegant design, but there were no better options.
> >
> > That commit actually ended up breaking ps8640, and thus was born
> > commit ec7981e6c614 ("drm/msm/dsi: don't powerup at modeset time for
> > parade-ps8640") as a temporary hack to un-break ps8640 by moving it to
> > the old way of doing things. It turns out that ps8640 _really_ doesn't
> > like its pre_enable() function to be called after
> > dsi_mgr_bridge_power_on(). Specifically (from experimentation, not
> > because I have any inside knowledge), it looks like the assertion of
> > "RST#" in the ps8640 runtime resume handler seems like it's not
> > allowed to happen after dsi_mgr_bridge_power_on()
> >
> > Recently, Dave Stevenson's series landed allowing bridges some control
> > over pre_enable ordering. The meaty commit for our purposes is commit
> > 4fb912e5e190 ("drm/bridge: Introduce pre_enable_prev_first to alter
> > bridge init order"). As documented by that series, if a bridge doesn't
> > set "pre_enable_prev_first" then we should use the old ordering.
> >
> > Now that we have the commit ("drm/bridge: tc358762: Set
> > pre_enable_prev_first") we can go back to the old ordering, which also
> > allows us to remove the ps8640 special case.
> >
> > One last note is that even without reverting commit 7d8e9a90509f
> > ("drm/msm/dsi: move DSI host powerup to modeset time"), if you _just_
> > revert the ps8640 special case and try it out then it doesn't seem to
> > fail anymore. I spent time bisecting / debugging this and it turns out
> > to be mostly luck, so we still want this patch to make sure it's
> > solid. Specifically the reason it sorta works these days is because
> > we implemented wait_hpd_asserted() in ps8640 now, plus the magic of
> > "pm_runtime" autosuspend. The fact that we have wait_hpd_asserted()
> > implemented means that we actually power the bridge chip up just a wee
> > bit earlier and then the bridge happens to stay on because of
> > autosuspend and thus ends up powered before dsi_mgr_bridge_power_on().
>
> I had a small comment on your patch, but then I was distracted and
> forgot to send it. See below.
>
> >
> > Cc: Dave Stevenson 
> > Cc: Dmitry Baryshkov 
> > Cc: Abhinav Kumar 
> > Signed-off-by: Douglas Anderson 
> > ---
> >
> >  drivers/gpu/drm/msm/dsi/dsi_manager.c | 68 +--
> >  1 file changed, 11 insertions(+), 57 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c 
> > b/drivers/gpu/drm/msm/dsi/dsi_manager.c
> > index 3a1417397283..5e6b8d423b96 100644
> > --- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
> > +++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
> > @@ -34,32 +34,6 @@ static struct msm_dsi_manager msm_dsim_glb;
> >  #define IS_SYNC_NEEDED()   (msm_dsim_glb.is_sync_needed)
> >  #define IS_MASTER_DSI_LINK(id) (msm_dsim_glb.master_dsi_link_id == id)
> >
> > -#ifdef CONFIG_OF
> > -static bool dsi_mgr_power_on_early(struct drm_bridge *bridge)
> > -{
> > -   struct drm_bridge *next_bridge = drm_bridge_get_next_bridge(bridge);
> > -
> > -   /*
> > -* If the next bridge in the chain is the Parade ps8640 bridge chip
> > -* then don't power on early since it seems to violate the 
> > expectations
> > -* of the firmware that the bridge chip is running.
> > -*
> > -* NOTE: this is expected to be a temporary special case. It's 
> > expected
> > -* that we'll eventually have a framework that allows the next level
> > -* bridge to indicate whether it needs us to power on before it or
> > -* after it. When that framework is in place then we'll use it and
> > -* remove this special case.
> > -*/
> > -   return !(next_bridge && next_bridge->of_node &&
> > -of_device_is_compatible(next_bridge->of_node, 
> > "parade,ps8640"));
> > -}
> > -#else
> > -static inline bool dsi_mgr_power_on_early(struct drm_bridge *bridge)
> > -{
> > -   return true;
> > -}
> > -#endif
> > -
> >  static inline struct msm_dsi *dsi_mgr_get_dsi(int id)
> >  {
> > return msm_dsim_glb.dsi[id];
> > @@ -254,7 +228,7 @@ static void msm_dsi_manager_set_split_display(u8 id)
> > }
> >  }
> >
> > -static void dsi_mgr_bridge_power_on(struct drm_bridge *bridge)
> > +static void dsi_mgr_bridge_pre_enable(struct drm_bridge *bridge)
>
> Can you please keep the dsi_mgr_bridge_power_on() as is and just
> remove the now-legacy dsi_mgr_power_on_early().

By this, I assume you mean keep the function separate but still remove
the call to it from "modeset" and unconditionally call it from
dsi_mgr_bridge_pre_enable(), right?


> >  {
> > int id = dsi_mgr_bridge_get_id(bridge);
> > struct msm_dsi 

Re: [PATCH 1/7] drm/vmwgfx: Use the common gem mmap instead of the custom code

[Martin Krastev (VMware)]

From: Martin Krastev 


LGTM!
Reviewed-by: Martin Krastev 


Regards,
Martin

On 26.01.23 г. 19:38 ч., Zack Rusin wrote:

From: Zack Rusin 

Before vmwgfx supported gem it needed to implement the entire mmap logic
explicitly. With GEM support that's not needed and the generic code
can be used by simply setting the vm_ops to vmwgfx specific ones on the
gem object itself.

Removes a lot of code from vmwgfx without any functional difference.

Signed-off-by: Zack Rusin 
---
  drivers/gpu/drm/vmwgfx/Makefile  |   2 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c  |   2 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_drv.h  |   6 --
  drivers/gpu/drm/vmwgfx/vmwgfx_gem.c  |   8 ++
  drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 110 ---
  5 files changed, 10 insertions(+), 118 deletions(-)
  delete mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c

diff --git a/drivers/gpu/drm/vmwgfx/Makefile b/drivers/gpu/drm/vmwgfx/Makefile
index 2a644f035597..e94479d9cd5b 100644
--- a/drivers/gpu/drm/vmwgfx/Makefile
+++ b/drivers/gpu/drm/vmwgfx/Makefile
@@ -1,7 +1,7 @@
  # SPDX-License-Identifier: GPL-2.0
  vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o vmwgfx_drv.o \
vmwgfx_ioctl.o vmwgfx_resource.o vmwgfx_ttm_buffer.o \
-   vmwgfx_cmd.o vmwgfx_irq.o vmwgfx_ldu.o vmwgfx_ttm_glue.o \
+   vmwgfx_cmd.o vmwgfx_irq.o vmwgfx_ldu.o \
vmwgfx_overlay.o vmwgfx_gmrid_manager.o vmwgfx_fence.o \
vmwgfx_bo.o vmwgfx_scrn.o vmwgfx_context.o \
vmwgfx_surface.o vmwgfx_prime.o vmwgfx_mob.o vmwgfx_shader.o \
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index bd02cb0e6837..e0c2e3748015 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -1566,7 +1566,7 @@ static const struct file_operations vmwgfx_driver_fops = {
.open = drm_open,
.release = drm_release,
.unlocked_ioctl = vmw_unlocked_ioctl,
-   .mmap = vmw_mmap,
+   .mmap = drm_gem_mmap,
.poll = drm_poll,
.read = drm_read,
  #if defined(CONFIG_COMPAT)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 5acbf5849b27..4dfa5044a9e7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -1053,12 +1053,6 @@ vmw_is_cursor_bypass3_enabled(const struct vmw_private 
*dev_priv)
return (vmw_fifo_caps(dev_priv) & SVGA_FIFO_CAP_CURSOR_BYPASS_3) != 0;
  }
  
-/**

- * TTM glue - vmwgfx_ttm_glue.c
- */
-
-extern int vmw_mmap(struct file *filp, struct vm_area_struct *vma);
-
  /**
   * TTM buffer object driver - vmwgfx_ttm_buffer.c
   */
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c
index ce609e7d758f..ba4ddd9f7a7e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c
@@ -103,6 +103,13 @@ static struct sg_table *vmw_gem_object_get_sg_table(struct 
drm_gem_object *obj)
return drm_prime_pages_to_sg(obj->dev, vmw_tt->dma_ttm.pages, 
vmw_tt->dma_ttm.num_pages);
  }
  
+static const struct vm_operations_struct vmw_vm_ops = {

+   .pfn_mkwrite = vmw_bo_vm_mkwrite,
+   .page_mkwrite = vmw_bo_vm_mkwrite,
+   .fault = vmw_bo_vm_fault,
+   .open = ttm_bo_vm_open,
+   .close = ttm_bo_vm_close,
+};
  
  static const struct drm_gem_object_funcs vmw_gem_object_funcs = {

.free = vmw_gem_object_free,
@@ -115,6 +122,7 @@ static const struct drm_gem_object_funcs 
vmw_gem_object_funcs = {
.vmap = drm_gem_ttm_vmap,
.vunmap = drm_gem_ttm_vunmap,
.mmap = drm_gem_ttm_mmap,
+   .vm_ops = _vm_ops,
  };
  
  /**

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
deleted file mode 100644
index 265f7c48d856..
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
+++ /dev/null
@@ -1,110 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0 OR MIT
-/**
- *
- * Copyright 2009-2011 VMware, Inc., Palo Alto, CA., USA
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the
- * "Software"), to deal in the Software without restriction, including
- * without limitation the rights to use, copy, modify, merge, publish,
- * distribute, sub license, and/or sell copies of the Software, and to
- * permit persons to whom the Software is furnished to do so, subject to
- * the following conditions:
- *
- * The above copyright notice and this permission notice (including the
- * next paragraph) shall be included in all copies or substantial portions
- * of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
- * 

[PATCH] drm/vc4: hdmi: Always enable GCP with AVMUTE cleared

[Maxime Ripard]

From: Dom Cobley 

Issue is some displays go blank at the point of firmware to kms
handover.  Plugging/unplugging hdmi cable, power cycling display, or
switching standby off/on
typically resolve this case.

Finally managed to find a display that suffers from this, and track down
the issue.

The firmware uses AVMUTE in normal operation. It will set AVMUTE before
disabling hdmi clocks and phy. It will clear AVMUTE after clocks and phy
are set up for a new hdmi mode.

But with the hdmi handover from firmware to kms, AVMUTE will be set by
firmware.

kms driver typically has no GCP packet (except for deep colour modes).
The spec isn't clear on whether to consider the AVMUTE as continuing
indefinitely in the absense of a GCP packet, or to consider that state
to have ended.

Most displays behave as we want, but there are a number (from mutiple
manufacturers) which need to see AVMUTE cleared before displaying a
picture.

Lets just always enable GCP packet with AVMUTE cleared. That resolves
the issue on problematic displays.

>From HDMI 1.4 spec:

  A CD field of zero (Color Depth not indicated) shall be used whenever
  the Sink does not indicate support for Deep Color. This value may
  also be used in Deep Color mode to transmit a GCP indicating only
  non-Deep Color information (e.g. AVMUTE).

So use CD=0 where we were previously not enabling a GCP.

Link: 
https://forum.libreelec.tv/thread/24780-le-10-0-1-rpi4-no-picture-after-update-from-le-10-0-0
Signed-off-by: Dom Cobley 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 01c1de992384..ea22c9bf223a 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -97,6 +97,10 @@
 #define VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_SHIFT 8
 #define VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_MASK  VC4_MASK(15, 8)
 
+#define VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_0_MASK  VC4_MASK(7, 0)
+#define VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_0_SET_AVMUTEBIT(0)
+#define VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_0_CLEAR_AVMUTE  BIT(4)
+
 # define VC4_HD_M_SW_RST   BIT(2)
 # define VC4_HD_M_ENABLE   BIT(0)
 
@@ -1316,7 +1320,6 @@ static void vc5_hdmi_set_timings(struct vc4_hdmi 
*vc4_hdmi,
VC4_HDMI_VERTB_VBP));
unsigned long flags;
unsigned char gcp;
-   bool gcp_en;
u32 reg;
int idx;
 
@@ -1351,16 +1354,13 @@ static void vc5_hdmi_set_timings(struct vc4_hdmi 
*vc4_hdmi,
switch (vc4_state->output_bpc) {
case 12:
gcp = 6;
-   gcp_en = true;
break;
case 10:
gcp = 5;
-   gcp_en = true;
break;
case 8:
default:
-   gcp = 4;
-   gcp_en = false;
+   gcp = 0;
break;
}
 
@@ -1369,8 +1369,7 @@ static void vc5_hdmi_set_timings(struct vc4_hdmi 
*vc4_hdmi,
 * doesn't signal in GCP.
 */
if (vc4_state->output_format == VC4_HDMI_OUTPUT_YUV422) {
-   gcp = 4;
-   gcp_en = false;
+   gcp = 0;
}
 
reg = HDMI_READ(HDMI_DEEP_COLOR_CONFIG_1);
@@ -1383,11 +1382,12 @@ static void vc5_hdmi_set_timings(struct vc4_hdmi 
*vc4_hdmi,
reg = HDMI_READ(HDMI_GCP_WORD_1);
reg &= ~VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_MASK;
reg |= VC4_SET_FIELD(gcp, VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1);
+   reg &= ~VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_0_MASK;
+   reg |= VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_0_CLEAR_AVMUTE;
HDMI_WRITE(HDMI_GCP_WORD_1, reg);
 
reg = HDMI_READ(HDMI_GCP_CONFIG);
-   reg &= ~VC5_HDMI_GCP_CONFIG_GCP_ENABLE;
-   reg |= gcp_en ? VC5_HDMI_GCP_CONFIG_GCP_ENABLE : 0;
+   reg |= VC5_HDMI_GCP_CONFIG_GCP_ENABLE;
HDMI_WRITE(HDMI_GCP_CONFIG, reg);
 
reg = HDMI_READ(HDMI_MISC_CONTROL);
-- 
2.39.1

Re: linux-6.2-rc4+ hangs on poweroff/reboot: Bisected

[Chris Clayton]

Thanks Thorsten.

I did try to revert but it didnt revert cleanly and I don't have the
knowledge to fix it up.

The patch was part of a merge that included a number of related patches.
I'll try to revert the lot and report back.

Chris


On Fri, 27 Jan 2023, 11:20 Linux kernel regression tracking (Thorsten
Leemhuis),  wrote:

> Hi, this is your Linux kernel regression tracker. Top-posting for once,
> to make this easily accessible to everyone.
>
> @nouveau-maintainers, did anyone take a look at this? The report is
> already 8 days old and I don't see a single reply. Sure, we'll likely
> get a -rc8, but still it would be good to not fix this on the finish line.
>
> Chris, btw, did you try if you can revert the commit on top of latest
> mainline? And if so, does it fix the problem?
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
>
> #regzbot poke
>
> On 19.01.23 15:33, Linux kernel regression tracking (Thorsten Leemhuis)
> wrote:
> > [adding various lists and the two other nouveau maintainers to the list
> > of recipients]
>
> > On 18.01.23 21:59, Chris Clayton wrote:
> >> Hi.
> >>
> >> I build and installed the lastest development kernel earlier this week.
> I've found that when I try the laptop down (or
> >> reboot it), it hangs right at the end of closing the current session.
> The last line I see on  the screen when rebooting is:
> >>
> >>  sd 4:0:0:0: [sda] Synchronising SCSI cache
> >>
> >> when closing down I see one additional line:
> >>
> >>  sd 4:0:0:0 [sda]Stopping disk
> >>
> >> In both cases the machine then hangs and I have to hold down the power
> button fot a few seconds to switch it off.
> >>
> >> Linux 6.1 is OK but 6.2-rc1 hangs, so I bisected between this two and
> landed on:
> >>
> >>  # first bad commit: [0e44c21708761977dcbea9b846b51a6fb684907a]
> drm/nouveau/flcn: new code to load+boot simple HS FWs
> >> (VPR scrubber)
> >>
> >> I built and installed a kernel with
> f15cde64b66161bfa74fb58f4e5697d8265b802e (the parent of the bad commit)
> checked out
> >> and that shuts down and reboots fine. It the did the same with the bad
> commit checked out and that does indeed hang, so
> >> I'm confident the bisect outcome is OK.
> >>
> >> Kernels 6.1.6 and 5.15.88 are also OK.
> >>
> >> My system had dual GPUs - one intel and one NVidia. Related extracts
> from 'lscpi -v' is:
> >>
> >> 00:02.0 VGA compatible controller: Intel Corporation CometLake-H GT2
> [UHD Graphics] (rev 05) (prog-if 00 [VGA controller])
> >> Subsystem: CLEVO/KAPOK Computer CometLake-H GT2 [UHD Graphics]
> >>
> >> Flags: bus master, fast devsel, latency 0, IRQ 142
> >>
> >> Memory at c200 (64-bit, non-prefetchable) [size=16M]
> >>
> >> Memory at a000 (64-bit, prefetchable) [size=256M]
> >>
> >> I/O ports at 5000 [size=64]
> >>
> >> Expansion ROM at 000c [virtual] [disabled] [size=128K]
> >>
> >> Capabilities: [40] Vendor Specific Information: Len=0c 
> >>
> >> Capabilities: [70] Express Root Complex Integrated Endpoint,
> MSI 00
> >>
> >> Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit-
> >>
> >> Capabilities: [d0] Power Management version 2
> >>
> >> Kernel driver in use: i915
> >>
> >> Kernel modules: i915
> >>
> >>
> >> 01:00.0 VGA compatible controller: NVIDIA Corporation TU117M [GeForce
> GTX 1650 Ti Mobile] (rev a1) (prog-if 00 [VGA
> >> controller])
> >> Subsystem: CLEVO/KAPOK Computer TU117M [GeForce GTX 1650 Ti
> Mobile]
> >> Flags: bus master, fast devsel, latency 0, IRQ 141
> >> Memory at c400 (32-bit, non-prefetchable) [size=16M]
> >> Memory at b000 (64-bit, prefetchable) [size=256M]
> >> Memory at c000 (64-bit, prefetchable) [size=32M]
> >> I/O ports at 4000 [size=128]
> >> Expansion ROM at c300 [disabled] [size=512K]
> >> Capabilities: [60] Power Management version 3
> >> Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
> >> Capabilities: [78] Express Legacy Endpoint, MSI 00
> >> Kernel driver in use: nouveau
> >> Kernel modules: nouveau
> >>
> >> DRI_PRIME=1 is exported in one of my init scripts (yes, I am still
> using sysvinit).
> >>
> >> I've attached the bisect.log, but please let me know if I can provide
> any other diagnostics. Please cc me as I'm not
> >> subscribed.
> >
> > Thanks for the report. To be sure the issue doesn't fall through the
> > cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
> > tracking bot:
> >
> > #regzbot ^introduced e44c2170876197
> > #regzbot title drm: nouveau: hangs on poweroff/reboot
> > #regzbot ignore-activity
> >
> > This isn't a regression? This issue or a fix for it are 

Re: [PATCH] drm/mediatek: Remove dependency on GEM DMA helper

[Doug Anderson]

Hi,

On Thu, Jan 19, 2023 at 2:40 PM Rob Clark  wrote:
>
> From: Rob Clark 
>
> It appears that the dependency on the DMA helpers was only for
> drm_gem_dma_vm_ops.
>
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/mediatek/Kconfig   | 1 -
>  drivers/gpu/drm/mediatek/mtk_drm_gem.c | 7 ++-
>  2 files changed, 6 insertions(+), 2 deletions(-)

Drive-by comment: can you post a follow-up patch that also removes the
"#include " from "mtk_drm_gem.c", assuming
that still compiles? If it doesn't compile, that might be a bad sign
that we missed something. ;-)

-Doug

[PATCH] drm/vc4: Fix YUV plane handling when planes are in different buffers

[Maxime Ripard]

From: Dave Stevenson 

YUV images can either be presented as one allocation with offsets
for the different planes, or multiple allocations with 0 offsets.

The driver only ever calls drm_fb_[dma|cma]_get_gem_obj with plane
index 0, therefore any application using the second approach was
incorrectly rendered.

Correctly determine the address for each plane, removing the
assumption that the base address is the same for each.

Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.")
Signed-off-by: Dave Stevenson 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_plane.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index dee525bacd4b..97c84a3f5a46 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -438,7 +438,7 @@ static int vc4_plane_setup_clipping_and_scaling(struct 
drm_plane_state *state)
 {
struct vc4_plane_state *vc4_state = to_vc4_plane_state(state);
struct drm_framebuffer *fb = state->fb;
-   struct drm_gem_dma_object *bo = drm_fb_dma_get_gem_obj(fb, 0);
+   struct drm_gem_dma_object *bo;
int num_planes = fb->format->num_planes;
struct drm_crtc_state *crtc_state;
u32 h_subsample = fb->format->hsub;
@@ -457,8 +457,10 @@ static int vc4_plane_setup_clipping_and_scaling(struct 
drm_plane_state *state)
if (ret)
return ret;
 
-   for (i = 0; i < num_planes; i++)
+   for (i = 0; i < num_planes; i++) {
+   bo = drm_fb_dma_get_gem_obj(fb, i);
vc4_state->offsets[i] = bo->dma_addr + fb->offsets[i];
+   }
 
/*
 * We don't support subpixel source positioning for scaling,
-- 
2.39.1

Re: linux-6.2-rc4+ hangs on poweroff/reboot: Bisected

[Chris Clayton]

Hi Karol.

I sent the originsl report to Ben and LKML. Thorsten then added you, Lyude
Paul and the dri-devel and nouveau lists. So you should have received this
report on or about January 19.

Chris

On Fri, 27 Jan 2023, 11:35 Karol Herbst,  wrote:

> Where was the original email sent to anyway, because I don't have it at
> all.
>
> Anyhow, I suspect we want to fetch logs to see what's happening, but
> due to the nature of this bug it might get difficult.
>
> I'm checking out the laptops I have here if I can reproduce this
> issue, but I think all mine with Turing GPUs are fine.
>
> Maybe Ben has any idea what might be wrong with
> 0e44c21708761977dcbea9b846b51a6fb684907a or if that's an issue which
> is already fixed by not upstreamed patches as I think I remember Ben
> to talk about something like that recently.
>
> Karol
>
> On Fri, Jan 27, 2023 at 12:20 PM Linux kernel regression tracking
> (Thorsten Leemhuis)  wrote:
> >
> > Hi, this is your Linux kernel regression tracker. Top-posting for once,
> > to make this easily accessible to everyone.
> >
> > @nouveau-maintainers, did anyone take a look at this? The report is
> > already 8 days old and I don't see a single reply. Sure, we'll likely
> > get a -rc8, but still it would be good to not fix this on the finish
> line.
> >
> > Chris, btw, did you try if you can revert the commit on top of latest
> > mainline? And if so, does it fix the problem?
> >
> > Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> > --
> > Everything you wanna know about Linux kernel regression tracking:
> > https://linux-regtracking.leemhuis.info/about/#tldr
> > If I did something stupid, please tell me, as explained on that page.
> >
> > #regzbot poke
> >
> > On 19.01.23 15:33, Linux kernel regression tracking (Thorsten Leemhuis)
> > wrote:
> > > [adding various lists and the two other nouveau maintainers to the list
> > > of recipients]
> >
> > > On 18.01.23 21:59, Chris Clayton wrote:
> > >> Hi.
> > >>
> > >> I build and installed the lastest development kernel earlier this
> week. I've found that when I try the laptop down (or
> > >> reboot it), it hangs right at the end of closing the current session.
> The last line I see on  the screen when rebooting is:
> > >>
> > >>  sd 4:0:0:0: [sda] Synchronising SCSI cache
> > >>
> > >> when closing down I see one additional line:
> > >>
> > >>  sd 4:0:0:0 [sda]Stopping disk
> > >>
> > >> In both cases the machine then hangs and I have to hold down the
> power button fot a few seconds to switch it off.
> > >>
> > >> Linux 6.1 is OK but 6.2-rc1 hangs, so I bisected between this two and
> landed on:
> > >>
> > >>  # first bad commit: [0e44c21708761977dcbea9b846b51a6fb684907a]
> drm/nouveau/flcn: new code to load+boot simple HS FWs
> > >> (VPR scrubber)
> > >>
> > >> I built and installed a kernel with
> f15cde64b66161bfa74fb58f4e5697d8265b802e (the parent of the bad commit)
> checked out
> > >> and that shuts down and reboots fine. It the did the same with the
> bad commit checked out and that does indeed hang, so
> > >> I'm confident the bisect outcome is OK.
> > >>
> > >> Kernels 6.1.6 and 5.15.88 are also OK.
> > >>
> > >> My system had dual GPUs - one intel and one NVidia. Related extracts
> from 'lscpi -v' is:
> > >>
> > >> 00:02.0 VGA compatible controller: Intel Corporation CometLake-H GT2
> [UHD Graphics] (rev 05) (prog-if 00 [VGA controller])
> > >> Subsystem: CLEVO/KAPOK Computer CometLake-H GT2 [UHD Graphics]
> > >>
> > >> Flags: bus master, fast devsel, latency 0, IRQ 142
> > >>
> > >> Memory at c200 (64-bit, non-prefetchable) [size=16M]
> > >>
> > >> Memory at a000 (64-bit, prefetchable) [size=256M]
> > >>
> > >> I/O ports at 5000 [size=64]
> > >>
> > >> Expansion ROM at 000c [virtual] [disabled] [size=128K]
> > >>
> > >> Capabilities: [40] Vendor Specific Information: Len=0c 
> > >>
> > >> Capabilities: [70] Express Root Complex Integrated Endpoint,
> MSI 00
> > >>
> > >> Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit-
> > >>
> > >> Capabilities: [d0] Power Management version 2
> > >>
> > >> Kernel driver in use: i915
> > >>
> > >> Kernel modules: i915
> > >>
> > >>
> > >> 01:00.0 VGA compatible controller: NVIDIA Corporation TU117M [GeForce
> GTX 1650 Ti Mobile] (rev a1) (prog-if 00 [VGA
> > >> controller])
> > >> Subsystem: CLEVO/KAPOK Computer TU117M [GeForce GTX 1650 Ti
> Mobile]
> > >> Flags: bus master, fast devsel, latency 0, IRQ 141
> > >> Memory at c400 (32-bit, non-prefetchable) [size=16M]
> > >> Memory at b000 (64-bit, prefetchable) [size=256M]
> > >> Memory at c000 (64-bit, prefetchable) [size=32M]
> > >> I/O ports at 4000 [size=128]
> > >> Expansion ROM at c300 [disabled] [size=512K]
> > >> Capabilities: [60] Power Management version 3
> > >> Capabilities: [68] MSI: 

Re: [PATCH] drm/virtio: exbuf->fence_fd unmodified on interrupted wait

[Rob Clark]

On Fri, Jan 27, 2023 at 12:31 AM Ryan Neph  wrote:
>
> An interrupted dma_fence_wait() becomes an -ERESTARTSYS returned
> to userspace ioctl(DRM_IOCTL_VIRTGPU_EXECBUFFER) calls, prompting to
> retry the ioctl(), but the passed exbuf->fence_fd has been reset to -1,
> making the retry attempt fail at sync_file_get_fence().
>
> The uapi for DRM_IOCTL_VIRTGPU_EXECBUFFER is changed to retain the
> passed value for exbuf->fence_fd when returning ERESTARTSYS or EINTR.
>
> Fixes: 2cd7b6f08bc4 ("drm/virtio: add in/out fence support for explicit 
> synchronization")
> Signed-off-by: Ryan Neph 

Reviewed-by: Rob Clark 

> ---
>
>  drivers/gpu/drm/virtio/virtgpu_ioctl.c | 9 ++---
>  include/uapi/drm/virtgpu_drm.h | 3 +++
>  2 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c 
> b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> index 9f4a90493aea..ffce4e2a409a 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> @@ -132,6 +132,8 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device 
> *dev, void *data,
> uint64_t fence_ctx;
> uint32_t ring_idx;
>
> +   exbuf->fence_fd = -1;
> +
> fence_ctx = vgdev->fence_drv.context;
> ring_idx = 0;
>
> @@ -152,8 +154,6 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device 
> *dev, void *data,
> ring_idx = exbuf->ring_idx;
> }
>
> -   exbuf->fence_fd = -1;
> -
> virtio_gpu_create_context(dev, file);
> if (exbuf->flags & VIRTGPU_EXECBUF_FENCE_FD_IN) {
> struct dma_fence *in_fence;
> @@ -173,7 +173,7 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device 
> *dev, void *data,
>
> dma_fence_put(in_fence);
> if (ret)
> -   return ret;
> +   goto out_err;
> }
>
> if (exbuf->flags & VIRTGPU_EXECBUF_FENCE_FD_OUT) {
> @@ -259,6 +259,9 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device 
> *dev, void *data,
>
> if (out_fence_fd >= 0)
> put_unused_fd(out_fence_fd);
> +out_err:
> +   if (ret == -EINTR || ret == -ERESTARTSYS)
> +   exbuf->fence_fd = in_fence_fd;
>
> return ret;
>  }
> diff --git a/include/uapi/drm/virtgpu_drm.h b/include/uapi/drm/virtgpu_drm.h
> index 0512fde5e697..ac8d1eed12ab 100644
> --- a/include/uapi/drm/virtgpu_drm.h
> +++ b/include/uapi/drm/virtgpu_drm.h
> @@ -64,6 +64,9 @@ struct drm_virtgpu_map {
> __u32 pad;
>  };
>
> +/* For ioctl() returning ERESTARTSYS or EINTR, fence_fd is unmodified.
> + * For all other errors it is set to -1.
> + */
>  struct drm_virtgpu_execbuffer {
> __u32 flags;
> __u32 size;
> --
> 2.39.1.456.gfc5497dd1b-goog
>

[PATCH] drm/probe-helper: Cancel previous job before starting new one

[Maxime Ripard]

From: Dom Cobley 

Currently we schedule a call to output_poll_execute from
drm_kms_helper_poll_enable for 10s in future. Later we try to replace
that in drm_helper_probe_single_connector_modes with a 0s schedule with
delayed_event set.

But as there is already a job in the queue this fails, and the immediate
job we wanted with delayed_event set doesn't occur until 10s later.

And that call acts as if connector state has changed, reprobing modes.
This has a side effect of waking up a display that has been blanked.

Make sure we cancel the old job before submitting the immediate one.

Fixes: 162b6a57ac50 ("drm/probe-helper: don't lose hotplug event")
Signed-off-by: Dom Cobley 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_probe_helper.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 8127be134c39..db954adb446a 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -589,9 +589,11 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
 * disable itself again.
 */
dev->mode_config.delayed_event = true;
-   if (dev->mode_config.poll_enabled)
+   if (dev->mode_config.poll_enabled) {
+   
cancel_delayed_work_sync(>mode_config.output_poll_work);

schedule_delayed_work(>mode_config.output_poll_work,
  0);
+   }
}
 
/* Re-enable polling in case the global poll config changed. */
-- 
2.39.1

[PATCH] backlight: ktz8866: Convert to i2c's .probe_new()

[Uwe Kleine-König]

The probe function doesn't make use of the i2c_device_id * parameter so
it can be trivially converted.

Signed-off-by: Uwe Kleine-König 
---
Hello,

there is an ongoing effort to convert all drivers to .probe_new to
eventually drop .probe with the i2c_device_id parameter. This driver
currently sits in next so wasn't on my radar before.

My plan is to tackle that after the next merge window. So I ask you to
either apply this patch during the next merge window or accept that it
will go in via the i2c tree together with the patch that drops .probe().

Best regards
Uwe

 drivers/video/backlight/ktz8866.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/video/backlight/ktz8866.c 
b/drivers/video/backlight/ktz8866.c
index 97b723719e13..d38c13ad39c7 100644
--- a/drivers/video/backlight/ktz8866.c
+++ b/drivers/video/backlight/ktz8866.c
@@ -124,8 +124,7 @@ static void ktz8866_init(struct ktz8866 *ktz)
ktz8866_write(ktz, LCD_BIAS_CFG1, LCD_BIAS_EN);
 }
 
-static int ktz8866_probe(struct i2c_client *client,
-const struct i2c_device_id *id)
+static int ktz8866_probe(struct i2c_client *client)
 {
struct backlight_device *backlight_dev;
struct backlight_properties props;
@@ -197,7 +196,7 @@ static struct i2c_driver ktz8866_driver = {
.name = "ktz8866",
.of_match_table = ktz8866_match_table,
},
-   .probe = ktz8866_probe,
+   .probe_new = ktz8866_probe,
.remove = ktz8866_remove,
.id_table = ktz8866_ids,
 };

base-commit: 2241ab53cbb5cdb08a6b2d4688feb13971058f65
prerequisite-patch-id: 2e7d7db8c0a90b8cd1deb6bbc51ead4c89c89b62
-- 
2.39.0

Re: [RFC 10/12] cgroup/drm: Introduce weight based drm cgroup control

[Tvrtko Ursulin]

On 27/01/2023 14:11, Michal Koutný wrote:

On Fri, Jan 27, 2023 at 01:31:54PM +, Tvrtko Ursulin 
 wrote:

I think you missed the finish_suspend_scanning() part:

if (root_drmcs.suspended_period_us)
cancel_delayed_work_sync(_drmcs.scan_work);

So if scanning was in progress migration will wait until it finishes.


Indeed, I've missed that. Thank you!


Not claiming I did not miss something because I was totally new with cgroup
internals when I started working on this. So it is definitely useful to have
more eyes looking.


The custom with (especially v2, especially horizontal) migrations
is that they're treated leniently to avoid performance costs.

I'm afraid waiting for scan in can_attach() can propagate globally (via
cgroup_update_dfl_csses() and cgroup_attach_lock()) sometimes.


That something along those lines might be a concern was indeed worrying 
me when coming up with the scheme. Good inside knowledge hint, thank 
you. I will have a deeper look.



OTOH, unless I misunderstood, you need to cover explicit (not task but
resource, when sending client FD around) migration anyway?


Correct. So far that was handled outside the cgroup controller in the 
drm layer and any lock dependency propagation was hidden behind RCU.
But that will likely change once I try your suggestion of eliminating 
the struct pid based client tracking and so become relevant.



(I.e. my suggestion would be to mutualy exclude scanning and explicit
migration but not scanning and task migration in order to avoid possible
global propagation.)


Thanks, I will look into this all hopefully shortly. Perhaps what you 
suggest will come naturally with the removal of struct pid based tracking.


Regards,

Tvrtko

Re: [PATCH drm-next 05/14] drm/nouveau: new VM_BIND uapi interfaces

[Christian König]

Am 27.01.23 um 15:44 schrieb Danilo Krummrich:

[SNIP]


What you want is one component for tracking the VA allocations 
(drm_mm based) and a different component/interface for tracking the 
VA mappings (probably rb tree based).


That's what the GPUVA manager is doing. There are gpuva_regions 
which correspond to VA allocations and gpuvas which represent the 
mappings. Both are tracked separately (currently both with a 
separate drm_mm, though). However, the GPUVA manager needs to take 
regions into account when dealing with mappings to make sure the 
GPUVA manager doesn't propose drivers to merge over region 
boundaries. Speaking from userspace PoV, the kernel wouldn't merge 
mappings from different VKBuffer objects even if they're virtually 
and physically contiguous.


That are two completely different things and shouldn't be handled in 
a single component.


They are different things, but they're related in a way that for 
handling the mappings (in particular merging and sparse) the GPUVA 
manager needs to know the VA allocation (or region) boundaries.


I have the feeling there might be a misunderstanding. Userspace is in 
charge to actually allocate a portion of VA space and manage it. The 
GPUVA manager just needs to know about those VA space allocations and 
hence keeps track of them.


The GPUVA manager is not meant to be an allocator in the sense of 
finding and providing a hole for a given request.


Maybe the non-ideal choice of using drm_mm was implying something else.


Uff, well long story short that doesn't even remotely match the 
requirements. This way the GPUVA manager won't be usable for a whole 
bunch of use cases.


What we have are mappings which say X needs to point to Y with this and 
hw dependent flags.


The whole idea of having ranges is not going to fly. Neither with AMD 
GPUs and I strongly think not with Intels XA either.


We should probably talk about the design of the GPUVA manager once 
more when this should be applicable to all GPU drivers.


That's what I try to figure out with this RFC, how to make it 
appicable for all GPU drivers, so I'm happy to discuss this. :-)


Yeah, that was really good idea :) That proposal here is really far away 
from the actual requirements.


For sparse residency the kernel also needs to know the region 
boundaries to make sure that it keeps sparse mappings around.


What?


When userspace creates a new VKBuffer with the 
VK_BUFFER_CREATE_SPARSE_BINDING_BIT the kernel may need to create 
sparse mappings in order to ensure that using this buffer without any 
memory backed mappings doesn't fault the GPU.


Currently, the implementation does this the following way:

1. Userspace creates a new VKBuffer and hence allocates a portion of 
the VA space for it. It calls into the kernel indicating the new VA 
space region and the fact that the region is sparse.


2. The kernel picks up the region and stores it in the GPUVA manager, 
the driver creates the corresponding sparse mappings / page table 
entries.


3. Userspace might ask the driver to create a couple of memory backed 
mappings for this particular VA region. The GPUVA manager stores the 
mapping parameters, the driver creates the corresponding page table 
entries.


4. Userspace might ask to unmap all the memory backed mappings from 
this particular VA region. The GPUVA manager removes the mapping 
parameters, the driver cleans up the corresponding page table entries. 
However, the driver also needs to re-create the sparse mappings, since 
it's a sparse buffer, hence it needs to know the boundaries of the 
region it needs to create the sparse mappings in.


Again, this is not how things are working. First of all the kernel 
absolutely should *NOT* know about those regions.


What we have inside the kernel is the information what happens if an 
address X is accessed. On AMD HW this can be:


1. Route to the PCIe bus because the mapped BO is stored in system memory.
2. Route to the internal MC because the mapped BO is stored in local memory.
3. Route to other GPUs in the same hive.
4. Route to some doorbell to kick of other work.
...
x. Ignore write, return 0 on reads (this is what is used for sparse 
mappings).

x+1. Trigger a recoverable page fault. This is used for things like SVA.
x+2. Trigger a non-recoverable page fault. This is used for things like 
unmapped regions where access is illegal.


All this is plus some hw specific caching flags.

When Vulkan allocates a sparse VKBuffer what should happen is the following:

1. The Vulkan driver somehow figures out a VA region A..B for the 
buffer. This can be in userspace (libdrm_amdgpu) or kernel (drm_mm), but 
essentially is currently driver specific.


2. The kernel gets a request to map the VA range A..B as sparse, meaning 
that it updates the page tables from A..B with the sparse setting.


3. User space asks kernel to map a couple of memory backings at location 
A+1, A+10, A+15 etc


4. The VKBuffer is de-allocated, userspace 

Re: [PATCH v2] drm/mediatek: Clean dangling pointer on bind error path

[Chun-Kuang Hu]

Hi, Nicolas:

Nícolas F. R. A. Prado  於 2022年11月22日 週二 下午10:39寫道：
>
> mtk_drm_bind() can fail, in which case drm_dev_put() is called,
> destroying the drm_device object. However a pointer to it was still
> being held in the private object, and that pointer would be passed along
> to DRM in mtk_drm_sys_prepare() if a suspend were triggered at that
> point, resulting in a panic. Clean the pointer when destroying the
> object in the error path to prevent this from happening.

Applied to mediatek-drm-next [1], thanks.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next

Regards,
Chun-Kuang.

>
> Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
> Signed-off-by: Nícolas F. R. A. Prado 
>
> ---
>
> Changes in v2:
> - Added Fixes tag
>
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 39a42dc8fb85..a21ff1b3258c 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -514,6 +514,7 @@ static int mtk_drm_bind(struct device *dev)
>  err_deinit:
> mtk_drm_kms_deinit(drm);
>  err_free:
> +   private->drm = NULL;
> drm_dev_put(drm);
> return ret;
>  }
> --
> 2.38.1
>

RE: [PATCH] Revert "drm/display/dp_mst: Move all payload info into the atomic state"

[Limonciello, Mario]

[Public]



> -Original Message-
> From: Linux kernel regression tracking (Thorsten Leemhuis)
> 
> Sent: Friday, January 27, 2023 03:15
> To: Greg KH ; Limonciello, Mario
> 
> Cc: dri-devel@lists.freedesktop.org; sta...@vger.kernel.org;
> stanislav.lisovs...@intel.com; Zuo, Jerry ; amd-
> g...@lists.freedesktop.org; Lin, Wayne ; Guenter
> Roeck ; bske...@redhat.com
> Subject: Re: [PATCH] Revert "drm/display/dp_mst: Move all payload info into
> the atomic state"
> 
> On 27.01.23 08:39, Greg KH wrote:
> > On Fri, Jan 20, 2023 at 11:51:04AM -0600, Limonciello, Mario wrote:
> >> On 1/20/2023 11:46, Guenter Roeck wrote:
> >>> On Thu, Jan 12, 2023 at 04:50:44PM +0800, Wayne Lin wrote:
>  This reverts commit 4d07b0bc403403438d9cf88450506240c5faf92f.
> 
>  [Why]
>  Changes cause regression on amdgpu mst.
>  E.g.
>  In fill_dc_mst_payload_table_from_drm(), amdgpu expects to
> add/remove payload
>  one by one and call fill_dc_mst_payload_table_from_drm() to update
> the HW
>  maintained payload table. But previous change tries to go through all
> the
>  payloads in mst_state and update amdpug hw maintained table in once
> everytime
>  driver only tries to add/remove a specific payload stream only. The
> newly
>  design idea conflicts with the implementation in amdgpu nowadays.
> 
>  [How]
>  Revert this patch first. After addressing all regression problems caused
> by
>  this previous patch, will add it back and adjust it.
> >>>
> >>> Has there been any progress on this revert, or on fixing the underlying
> >>> problem ?
> >>>
> >>> Thanks,
> >>> Guenter
> >>
> >> Hi Guenter,
> >>
> >> Wayne is OOO for CNY, but let me update you.
> >>
> >> Harry has sent out this series which is a collection of proper fixes.
> >> https://patchwork.freedesktop.org/series/113125/
> >>
> >> Once that's reviewed and accepted, 4 of them are applicable for 6.1.
> >
> > Any hint on when those will be reviewed and accepted?  patchwork
> doesn't
> > show any activity on them, or at least I can't figure it out...
> 
> I didn't look closer (hence please correct me if I'm wrong), but the
> core changes afaics are in the DRM pull airlied send a few hours ago to
> Linus (note the "amdgpu […] DP MST fixes" line):
> 
> https://lore.kernel.org/all/CAPM%3D9tzuu4xnx6T5v7sKsK%2BA5HEaPOc1ie
> myznsyqzgztj%3d...@mail.gmail.com/

That's right.  There are 4 commits in that PR with the appropriate stable tags
that should fix the majority of the MST issues introduced in 6.1 by 
4d07b0bc40340
("drm/display/dp_mst: Move all payload info into the atomic state"):

  drm/amdgpu/display/mst: Fix mst_state->pbn_div and slot count assignments
  drm/amdgpu/display/mst: limit payload to be updated one by one
  drm/amdgpu/display/mst: update mst_mgr relevant variable when long HPD
  drm/display/dp_mst: Correct the kref of port.

There will be follow ups for any remaining corner cases.

> 
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.

RE: [PATCH Resend v11 05/15] drm/msm/dp: disable self_refresh_aware after entering psr

[Vinod Polimera]

> -Original Message-
> From: Dmitry Baryshkov 
> Sent: Tuesday, January 24, 2023 10:15 PM
> To: Vinod Polimera 
> Cc: Vinod Polimera (QUIC) ; dri-
> de...@lists.freedesktop.org; linux-arm-...@vger.kernel.org;
> freedr...@lists.freedesktop.org; devicet...@vger.kernel.org; Sankeerth
> Billakanti (QUIC) ; linux-
> ker...@vger.kernel.org; robdcl...@gmail.com; diand...@chromium.org;
> swb...@chromium.org; Kalyan Thota (QUIC) ;
> Kuogee Hsieh (QUIC) ; Vishnuvardhan
> Prodduturi (QUIC) ; Bjorn Andersson (QUIC)
> ; Abhinav Kumar (QUIC)
> 
> Subject: Re: [PATCH Resend v11 05/15] drm/msm/dp: disable
> self_refresh_aware after entering psr
> > 
> On Tue, 24 Jan 2023 at 17:10, Vinod Polimera 
> wrote:
> > > -Original Message-
> > > From: Dmitry Baryshkov 
> > > Sent: Tuesday, January 24, 2023 5:52 AM
> > > To: Vinod Polimera (QUIC) ; dri-
> > > de...@lists.freedesktop.org; linux-arm-...@vger.kernel.org;
> > > freedr...@lists.freedesktop.org; devicet...@vger.kernel.org
> > > Cc: Sankeerth Billakanti (QUIC) ; linux-
> > > ker...@vger.kernel.org; robdcl...@gmail.com; diand...@chromium.org;
> > > swb...@chromium.org; Kalyan Thota (QUIC)
> ;
> > > Kuogee Hsieh (QUIC) ; Vishnuvardhan
> > > Prodduturi (QUIC) ; Bjorn Andersson
> (QUIC)
> > > ; Abhinav Kumar (QUIC)
> > > 
> > > Subject: Re: [PATCH Resend v11 05/15] drm/msm/dp: disable
> > > self_refresh_aware after entering psr
> > >
> > >
> > > On 19/01/2023 16:26, Vinod Polimera wrote:
> > > > From: Sankeerth Billakanti 
> > > >
> > > > Updated frames get queued if self_refresh_aware is set when the
> > > > sink is in psr. To support bridge enable and avoid queuing of update
> > > > frames, reset the self_refresh_aware state after entering psr.
> > >
> > > I'm not convinced by this change. E.g. analogix code doesn't do this.
> > > Could you please clarify, why do you need to toggle the
> > > self_refresh_aware flag?
> > >
> > This was done to fix a bug reported by google. The use case is as follows:
> > CPU was running in a low frequency with debug build.
> > When self refresh was triggered by the library, due to system 
> > latency,
> the queued work was not scheduled.
> > There in another commit came and reinitialized the timer for the 
> > next
> PSR trigger.
> > This sequence happened multiple times  and we found there were
> multiple works which are stuck and yet to be run.
> 
> Where were workers stuck? Was it a busy loop around -EDEADLK /
> drm_modeset_backoff()? Also, what were ther ewma times for entry/exit
> avg times?
> 
It is not  an EDEADLK and return is successful.
Entry and exit times are proper but the work that is getting scheduled after 
timer expiry is happening very late.

> I'm asking because the issue that you are describing sounds like a
> generic one, not the driver-specific issue. And being generic it
> should be handled in a generic fascion, in drm_self_refresh_helper.c.
> 
> For example, I can imagine adding a variable to sr_data telling that
> the driver is in the process of transitioning to SR. Note: I did not
> perform a full research if it is a working solution or not. But from
> your description the driver really has to bail out early from
> drm_self_refresh_helper_entry_work().
> 
> > As PSR trigger is guarded by self_refresh_aware, we initialized the
> variable such that, if we are in PSR then until PSR exit, there cannot be any
> further PSR entry again.
> >
> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ref
> s/tags/v5.15.90/drivers/gpu/drm/drm_self_refresh_helper.c#105
> 
> Yes, and that's what triggered my attention. We are using a set of
> helpers, that depend on the self_refresh_aware being true. And
> suddenly under the hood we disable this flag. I'd say that I can not
> predict the effect this will have on the helpers library behaviour.
> 
> > This has solved few flicker issues during the stress testing.
> > > >
> > > > Signed-off-by: Sankeerth Billakanti 
> > > > Signed-off-by: Vinod Polimera 
> > > > ---
> > > >   drivers/gpu/drm/msm/dp/dp_drm.c | 27
> > > ++-
> > > >   1 file changed, 26 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c
> > > b/drivers/gpu/drm/msm/dp/dp_drm.c
> > > > index 029e08c..92d1a1b 100644
> > > > --- a/drivers/gpu/drm/msm/dp/dp_drm.c
> > > > +++ b/drivers/gpu/drm/msm/dp/dp_drm.c
> > > > @@ -134,6 +134,8 @@ static void edp_bridge_atomic_enable(struct
> > > drm_bridge *drm_bridge,
> > > >   struct drm_crtc_state *old_crtc_state;
> > > >   struct msm_dp_bridge *dp_bridge = to_dp_bridge(drm_bridge);
> > > >   struct msm_dp *dp = dp_bridge->dp_display;
> > > > + struct drm_connector *connector;
> > > > + struct drm_connector_state *conn_state = NULL;
> > > >
> > > >   /*
> > > >* Check the old state of the crtc to determine if the panel
> > > > @@ -150,10 +152,22 @@ static void edp_bridge_atomic_enable(struct
> > > drm_bridge 

[PATCH] drm/vc4: crtc: Increase setup cost in core clock calculation to handle extreme reduced blanking

[Maxime Ripard]

From: Dom Cobley 

The formula that determines the core clock requirement based on pixel
clock and blanking has been determined experimentally to minimise the
clock while supporting all modes we've seen.

A new reduced blanking mode (4kp60 at 533MHz rather than the standard
594MHz) has been seen that doesn't produce a high enough clock and
results in "flip_done timed out" error.

Increase the setup cost in the formula to make this work. The result is
a reduced blanking mode increases by up to 7MHz while leaving the
standard timing
mode untouched

Link: https://github.com/raspberrypi/linux/issues/4446
Fixes: 16e101051f32 ("drm/vc4: Increase the core clock based on HVS load")
Signed-off-by: Dom Cobley 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index cdc0559221f0..bef9d45ef1df 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -722,7 +722,7 @@ int vc4_crtc_atomic_check(struct drm_crtc *crtc,
struct vc4_encoder *vc4_encoder = to_vc4_encoder(encoder);
 
if (vc4_encoder->type == VC4_ENCODER_TYPE_HDMI0) {
-   vc4_state->hvs_load = max(mode->clock * mode->hdisplay 
/ mode->htotal + 1000,
+   vc4_state->hvs_load = max(mode->clock * mode->hdisplay 
/ mode->htotal + 8000,
  mode->clock * 9 / 10) * 1000;
} else {
vc4_state->hvs_load = mode->clock * 1000;
-- 
2.39.1

Re: [PATCH] drm/mediatek: mtk_drm_crtc: Add checks for devm_kcalloc

[Chun-Kuang Hu]

Hi, Ruanjinjie:

Applied to mediatek-drm-next [1], thanks.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next

Regards,
Chun-Kuang.

AngeloGioacchino Del Regno  於
2022年12月5日 週一 下午7:53寫道：
>
> Il 05/12/22 10:51, ruanjinjie ha scritto:
> > As the devm_kcalloc may return NULL, the return value needs to be checked
> > to avoid NULL poineter dereference.
> >
> > Fixes: 31c5558dae05 ("drm/mediatek: Refactor plane init")
> > Signed-off-by: ruanjinjie 
>
> Reviewed-by: AngeloGioacchino Del Regno 
> 
>

Re: [PATCH drm-next 05/14] drm/nouveau: new VM_BIND uapi interfaces

[Danilo Krummrich]

On 1/27/23 14:23, Christian König wrote:



Am 27.01.23 um 14:12 schrieb Danilo Krummrich:

On 1/27/23 08:55, Christian König wrote:

Am 27.01.23 um 02:26 schrieb Danilo Krummrich:

On 1/27/23 02:05, Matthew Brost wrote:

On Wed, Jan 18, 2023 at 07:12:47AM +0100, Danilo Krummrich wrote:

This commit provides the interfaces for the new UAPI motivated by the
Vulkan API. It allows user mode drivers (UMDs) to:

1) Initialize a GPU virtual address (VA) space via the new
    DRM_IOCTL_NOUVEAU_VM_INIT ioctl. UMDs can provide a kernel 
reserved

    VA area.

2) Bind and unbind GPU VA space mappings via the new
    DRM_IOCTL_NOUVEAU_VM_BIND ioctl.

3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC ioctl.

Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC support
asynchronous processing with DRM syncobjs as synchronization 
mechanism.


The default DRM_IOCTL_NOUVEAU_VM_BIND is synchronous processing,
DRM_IOCTL_NOUVEAU_EXEC supports asynchronous processing only.

Co-authored-by: Dave Airlie 
Signed-off-by: Danilo Krummrich 
---
  Documentation/gpu/driver-uapi.rst |   8 ++
  include/uapi/drm/nouveau_drm.h    | 216 
++

  2 files changed, 224 insertions(+)

diff --git a/Documentation/gpu/driver-uapi.rst 
b/Documentation/gpu/driver-uapi.rst

index 4411e6919a3d..9c7ca6e33a68 100644
--- a/Documentation/gpu/driver-uapi.rst
+++ b/Documentation/gpu/driver-uapi.rst
@@ -6,3 +6,11 @@ drm/i915 uAPI
  =
    .. kernel-doc:: include/uapi/drm/i915_drm.h
+
+drm/nouveau uAPI
+
+
+VM_BIND / EXEC uAPI
+---
+
+.. kernel-doc:: include/uapi/drm/nouveau_drm.h
diff --git a/include/uapi/drm/nouveau_drm.h 
b/include/uapi/drm/nouveau_drm.h

index 853a327433d3..f6e7d40201d4 100644
--- a/include/uapi/drm/nouveau_drm.h
+++ b/include/uapi/drm/nouveau_drm.h
@@ -126,6 +126,216 @@ struct drm_nouveau_gem_cpu_fini {
  __u32 handle;
  };
  +/**
+ * struct drm_nouveau_sync - sync object
+ *
+ * This structure serves as synchronization mechanism for 
(potentially)

+ * asynchronous operations such as EXEC or VM_BIND.
+ */
+struct drm_nouveau_sync {
+    /**
+ * @flags: the flags for a sync object
+ *
+ * The first 8 bits are used to determine the type of the 
sync object.

+ */
+    __u32 flags;
+#define DRM_NOUVEAU_SYNC_SYNCOBJ 0x0
+#define DRM_NOUVEAU_SYNC_TIMELINE_SYNCOBJ 0x1
+#define DRM_NOUVEAU_SYNC_TYPE_MASK 0xf
+    /**
+ * @handle: the handle of the sync object
+ */
+    __u32 handle;
+    /**
+ * @timeline_value:
+ *
+ * The timeline point of the sync object in case the syncobj 
is of

+ * type DRM_NOUVEAU_SYNC_TIMELINE_SYNCOBJ.
+ */
+    __u64 timeline_value;
+};
+
+/**
+ * struct drm_nouveau_vm_init - GPU VA space init structure
+ *
+ * Used to initialize the GPU's VA space for a user client, 
telling the kernel
+ * which portion of the VA space is managed by the UMD and kernel 
respectively.

+ */
+struct drm_nouveau_vm_init {
+    /**
+ * @unmanaged_addr: start address of the kernel managed VA 
space region

+ */
+    __u64 unmanaged_addr;
+    /**
+ * @unmanaged_size: size of the kernel managed VA space 
region in bytes

+ */
+    __u64 unmanaged_size;
+};
+
+/**
+ * struct drm_nouveau_vm_bind_op - VM_BIND operation
+ *
+ * This structure represents a single VM_BIND operation. UMDs 
should pass
+ * an array of this structure via struct drm_nouveau_vm_bind's 
_ptr field.

+ */
+struct drm_nouveau_vm_bind_op {
+    /**
+ * @op: the operation type
+ */
+    __u32 op;
+/**
+ * @DRM_NOUVEAU_VM_BIND_OP_ALLOC:
+ *
+ * The alloc operation is used to reserve a VA space region 
within the GPU's VA
+ * space. Optionally, the _NOUVEAU_VM_BIND_SPARSE flag can be 
passed to
+ * instruct the kernel to create sparse mappings for the given 
region.

+ */
+#define DRM_NOUVEAU_VM_BIND_OP_ALLOC 0x0


Do you really need this operation? We have no concept of this in Xe,
e.g. we can create a VM and the entire address space is managed 
exactly

the same.


The idea for alloc/free is to let UMDs allocate a portion of the VA 
space (which I call a region), basically the same thing Vulkan 
represents with a VKBuffer.


If that's mangled into the same component/interface then I can say 
from experience that this is a pretty bad idea. We have tried 
something similar with radeon and it turned out horrible.


What was the exact constellation in radeon and which problems did 
arise from it?




What you want is one component for tracking the VA allocations 
(drm_mm based) and a different component/interface for tracking the 
VA mappings (probably rb tree based).


That's what the GPUVA manager is doing. There are gpuva_regions which 
correspond to VA allocations and gpuvas which represent the mappings. 
Both are tracked separately (currently both with a separate drm_mm, 
though). However, the GPUVA manager needs to take regions into account 
when dealing with mappings to make sure the GPUVA manager doesn't 

Re: [PATCH] Revert "drm/display/dp_mst: Move all payload info into the atomic state"

[Hamza Mahfooz]

Hey Greg,

On 1/27/23 02:39, Greg KH wrote:

On Fri, Jan 20, 2023 at 11:51:04AM -0600, Limonciello, Mario wrote:

On 1/20/2023 11:46, Guenter Roeck wrote:

On Thu, Jan 12, 2023 at 04:50:44PM +0800, Wayne Lin wrote:

This reverts commit 4d07b0bc403403438d9cf88450506240c5faf92f.

[Why]
Changes cause regression on amdgpu mst.
E.g.
In fill_dc_mst_payload_table_from_drm(), amdgpu expects to add/remove payload
one by one and call fill_dc_mst_payload_table_from_drm() to update the HW
maintained payload table. But previous change tries to go through all the
payloads in mst_state and update amdpug hw maintained table in once everytime
driver only tries to add/remove a specific payload stream only. The newly
design idea conflicts with the implementation in amdgpu nowadays.

[How]
Revert this patch first. After addressing all regression problems caused by
this previous patch, will add it back and adjust it.


Has there been any progress on this revert, or on fixing the underlying
problem ?

Thanks,
Guenter


Hi Guenter,

Wayne is OOO for CNY, but let me update you.

Harry has sent out this series which is a collection of proper fixes.
https://patchwork.freedesktop.org/series/113125/

Once that's reviewed and accepted, 4 of them are applicable for 6.1.


Any hint on when those will be reviewed and accepted?  patchwork doesn't
show any activity on them, or at least I can't figure it out...


These patches have already made it into amd-staging-drm-next and as of
https://lore.kernel.org/amd-gfx/20230125220153.320248-1-alexander.deuc...@amd.com/
they should land in drm-next soon if they haven't already.



thanks,

greg k-h


--
Hamza

Re: [PATCH 13/14] drm/msm/a6xx: Add A619_holi speedbin support

[Konrad Dybcio]

On 27.01.2023 15:19, Dmitry Baryshkov wrote:
> On 26/01/2023 17:16, Konrad Dybcio wrote:
>> A619_holi is implemented on at least two SoCs: SM4350 (holi) and SM6375
>> (blair). This is what seems to be a first occurrence of this happening,
>> but it's easy to overcome by guarding the SoC-specific fuse values with
>> of_machine_is_compatible(). Do just that to enable frequency limiting
>> on these SoCs.
>>
>> Signed-off-by: Konrad Dybcio 
>> ---
>>   drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 31 +++
>>   1 file changed, 31 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
>> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
>> index 452ba32699b2..89990bec897f 100644
>> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
>> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
>> @@ -2091,6 +2091,34 @@ static u32 a618_get_speed_bin(u32 fuse)
>>   return UINT_MAX;
>>   }
>>   +static u32 a619_holi_get_speed_bin(u32 fuse)
>> +{
>> +    /*
>> + * There are (at least) two SoCs implementing A619_holi: SM4350 (holi)
>> + * and SM6375 (blair). Limit the fuse matching to the corresponding
>> + * SoC to prevent bogus frequency setting (as improbable as it may be,
>> + * given unexpected fuse values are.. unexpected! But still possible.)
>> + */
>> +
>> +    if (fuse == 0)
>> +    return 0;
>> +
>> +    if (of_machine_is_compatible("qcom,sm4350")) {
>> +    if (fuse == 138)
>> +    return 1;
>> +    else if (fuse == 92)
>> +    return 2;
>> +    } else if (of_machine_is_compatible("qcom,sm6375")) {
>> +    if (fuse == 190)
>> +    return 1;
>> +    else if (fuse == 177)
>> +    return 2;
>> +    } else
>> +    pr_warn("Unknown SoC implementing A619_holi!\n");
> 
> I think, we might be better to introduce "qcom,SoC-adreno" compat string 
> instead, ignore it in the bindings
I can hear Krzysztof hiring a hitman already..

and only care about it here. This might seem an overkill thinking from the 
single Adreno version. However this issue also affects other revisions.
> 
> For example, for the A618 there are at least three platforms which use the 
> same Adreno version: SC7180, SM7125 and SM7150. Only first one is supported 
> (thus the speed_bin function is simple). However according to the vendor dts 
> files all three platforms use different fuse values to specify the speed bin.
Or we may switch to simply matching SoCs based on platform
compatible, as it's really the SoC-specific and not GPU-specific.

Konrad> 
>> +
>> +    return UINT_MAX;
>> +}
>> +
>>   static u32 a619_get_speed_bin(u32 fuse)
>>   {
>>   if (fuse == 0)
>> @@ -2150,6 +2178,9 @@ static u32 fuse_to_supp_hw(struct device *dev, struct 
>> adreno_rev rev, u32 fuse)
>>   if (adreno_cmp_rev(ADRENO_REV(6, 1, 8, ANY_ID), rev))
>>   val = a618_get_speed_bin(fuse);
>>   +    else if (adreno_cmp_rev(ADRENO_REV(6, 1, 9, 1), rev))
>> +    val = a619_holi_get_speed_bin(fuse);
>> +
> 
> Are we sure that SM6350, the unholi A619 user, doesn't use patchid .1? (note 
> I do not know a thing about Adreno patch ids and its usage between different 
> platforms).
> 
>>   else if (adreno_cmp_rev(ADRENO_REV(6, 1, 9, ANY_ID), rev))
>>   val = a619_get_speed_bin(fuse);
>>   
> 

Re: [PATCH v3 04/10] drm/fbdev-generic: Initialize fb-helper structure in generic setup

[Thomas Zimmermann]

Hi

Am 25.01.23 um 22:03 schrieb Sam Ravnborg:

Hi Thomas,

On Wed, Jan 25, 2023 at 09:04:09PM +0100, Thomas Zimmermann wrote:

Initialize the fb-helper structure immediately after its allocation
in drm_fbdev_generic_setup(). That will make it easier to fill it with
driver-specific values, such as the preferred BPP.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
  drivers/gpu/drm/drm_fbdev_generic.c | 13 +
  1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_fbdev_generic.c 
b/drivers/gpu/drm/drm_fbdev_generic.c
index 135d58b8007b..63f66325a8a5 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -385,8 +385,6 @@ static int drm_fbdev_client_hotplug(struct drm_client_dev 
*client)
if (dev->fb_helper)
return drm_fb_helper_hotplug_event(dev->fb_helper);
  
-	drm_fb_helper_prepare(dev, fb_helper, _fb_helper_generic_funcs);

-
ret = drm_fb_helper_init(dev, fb_helper);
if (ret)
goto err;


 From the documentation:
The drm_fb_helper_prepare()
helper must be called first to initialize the minimum required to make
hotplug detection work.
...
To finish up the fbdev helper initialization, the
drm_fb_helper_init() function is called.

So this change do not follow the documentation as drm_fb_helper_init()
is now called before drm_fb_helper_prepare()


No, we now call drm_fb_helper_prepare() from within 
drm_fbdev_generic_setup(), right after allocating the fb_helper. 
drm_fb_helper_init() will only be called after the client received a 
hot-plug event.




I did not follow all the code - but my gut feeling is that the
documentation is right.


The docs are of low quality. The _prepare() helper is the actual init 
function and _init() only sets the fb_helper in the device instance.


Best regards
Thomas



Sam



@@ -456,12 +454,12 @@ void drm_fbdev_generic_setup(struct drm_device *dev,
fb_helper = kzalloc(sizeof(*fb_helper), GFP_KERNEL);
if (!fb_helper)
return;
+   drm_fb_helper_prepare(dev, fb_helper, _fb_helper_generic_funcs);
  
  	ret = drm_client_init(dev, _helper->client, "fbdev", _fbdev_client_funcs);

if (ret) {
-   kfree(fb_helper);
drm_err(dev, "Failed to register client: %d\n", ret);
-   return;
+   goto err_drm_client_init;
}
  
  	/*

@@ -484,5 +482,12 @@ void drm_fbdev_generic_setup(struct drm_device *dev,
drm_dbg_kms(dev, "client hotplug ret=%d\n", ret);
  
  	drm_client_register(_helper->client);

+
+   return;
+
+err_drm_client_init:
+   drm_fb_helper_unprepare(fb_helper);
+   kfree(fb_helper);
+   return;
  }
  EXPORT_SYMBOL(drm_fbdev_generic_setup);
--
2.39.0


--
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


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH 13/14] drm/msm/a6xx: Add A619_holi speedbin support

[Konrad Dybcio]

On 27.01.2023 15:19, Dmitry Baryshkov wrote:
> On 26/01/2023 17:16, Konrad Dybcio wrote:
>> A619_holi is implemented on at least two SoCs: SM4350 (holi) and SM6375
>> (blair). This is what seems to be a first occurrence of this happening,
>> but it's easy to overcome by guarding the SoC-specific fuse values with
>> of_machine_is_compatible(). Do just that to enable frequency limiting
>> on these SoCs.
>>
>> Signed-off-by: Konrad Dybcio 
>> ---
>>   drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 31 +++
>>   1 file changed, 31 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
>> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
>> index 452ba32699b2..89990bec897f 100644
>> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
>> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
>> @@ -2091,6 +2091,34 @@ static u32 a618_get_speed_bin(u32 fuse)
>>   return UINT_MAX;
>>   }
>>   +static u32 a619_holi_get_speed_bin(u32 fuse)
>> +{
>> +    /*
>> + * There are (at least) two SoCs implementing A619_holi: SM4350 (holi)
>> + * and SM6375 (blair). Limit the fuse matching to the corresponding
>> + * SoC to prevent bogus frequency setting (as improbable as it may be,
>> + * given unexpected fuse values are.. unexpected! But still possible.)
>> + */
>> +
>> +    if (fuse == 0)
>> +    return 0;
>> +
>> +    if (of_machine_is_compatible("qcom,sm4350")) {
>> +    if (fuse == 138)
>> +    return 1;
>> +    else if (fuse == 92)
>> +    return 2;
>> +    } else if (of_machine_is_compatible("qcom,sm6375")) {
>> +    if (fuse == 190)
>> +    return 1;
>> +    else if (fuse == 177)
>> +    return 2;
>> +    } else
>> +    pr_warn("Unknown SoC implementing A619_holi!\n");
> 
> I think, we might be better to introduce "qcom,SoC-adreno" compat string 
> instead, ignore it in the bindings and only care about it here. This might 
> seem an overkill thinking from the single Adreno version. However this issue 
> also affects other revisions.
> 
> For example, for the A618 there are at least three platforms which use the 
> same Adreno version: SC7180, SM7125 and SM7150. Only first one is supported 
> (thus the speed_bin function is simple). However according to the vendor dts 
> files all three platforms use different fuse values to specify the speed bin.
> 
>> +
>> +    return UINT_MAX;
>> +}
>> +
>>   static u32 a619_get_speed_bin(u32 fuse)
>>   {
>>   if (fuse == 0)
>> @@ -2150,6 +2178,9 @@ static u32 fuse_to_supp_hw(struct device *dev, struct 
>> adreno_rev rev, u32 fuse)
>>   if (adreno_cmp_rev(ADRENO_REV(6, 1, 8, ANY_ID), rev))
>>   val = a618_get_speed_bin(fuse);
>>   +    else if (adreno_cmp_rev(ADRENO_REV(6, 1, 9, 1), rev))
>> +    val = a619_holi_get_speed_bin(fuse);
>> +
> 
> Are we sure that SM6350, the unholi A619 user, doesn't use patchid .1? (note 
> I do not know a thing about Adreno patch ids and its usage between different 
> platforms).
Yes

Konrad
> 
>>   else if (adreno_cmp_rev(ADRENO_REV(6, 1, 9, ANY_ID), rev))
>>   val = a619_get_speed_bin(fuse);
>>   
> 

Re: [PATCH 13/14] drm/msm/a6xx: Add A619_holi speedbin support

[Dmitry Baryshkov]

On 26/01/2023 17:16, Konrad Dybcio wrote:

A619_holi is implemented on at least two SoCs: SM4350 (holi) and SM6375
(blair). This is what seems to be a first occurrence of this happening,
but it's easy to overcome by guarding the SoC-specific fuse values with
of_machine_is_compatible(). Do just that to enable frequency limiting
on these SoCs.

Signed-off-by: Konrad Dybcio 
---
  drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 31 +++
  1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 452ba32699b2..89990bec897f 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -2091,6 +2091,34 @@ static u32 a618_get_speed_bin(u32 fuse)
return UINT_MAX;
  }
  
+static u32 a619_holi_get_speed_bin(u32 fuse)

+{
+   /*
+* There are (at least) two SoCs implementing A619_holi: SM4350 (holi)
+* and SM6375 (blair). Limit the fuse matching to the corresponding
+* SoC to prevent bogus frequency setting (as improbable as it may be,
+* given unexpected fuse values are.. unexpected! But still possible.)
+*/
+
+   if (fuse == 0)
+   return 0;
+
+   if (of_machine_is_compatible("qcom,sm4350")) {
+   if (fuse == 138)
+   return 1;
+   else if (fuse == 92)
+   return 2;
+   } else if (of_machine_is_compatible("qcom,sm6375")) {
+   if (fuse == 190)
+   return 1;
+   else if (fuse == 177)
+   return 2;
+   } else
+   pr_warn("Unknown SoC implementing A619_holi!\n");


I think, we might be better to introduce "qcom,SoC-adreno" compat string 
instead, ignore it in the bindings and only care about it here. This 
might seem an overkill thinking from the single Adreno version. However 
this issue also affects other revisions.


For example, for the A618 there are at least three platforms which use 
the same Adreno version: SC7180, SM7125 and SM7150. Only first one is 
supported (thus the speed_bin function is simple). However according to 
the vendor dts files all three platforms use different fuse values to 
specify the speed bin.



+
+   return UINT_MAX;
+}
+
  static u32 a619_get_speed_bin(u32 fuse)
  {
if (fuse == 0)
@@ -2150,6 +2178,9 @@ static u32 fuse_to_supp_hw(struct device *dev, struct 
adreno_rev rev, u32 fuse)
if (adreno_cmp_rev(ADRENO_REV(6, 1, 8, ANY_ID), rev))
val = a618_get_speed_bin(fuse);
  
+	else if (adreno_cmp_rev(ADRENO_REV(6, 1, 9, 1), rev))

+   val = a619_holi_get_speed_bin(fuse);
+


Are we sure that SM6350, the unholi A619 user, doesn't use patchid .1? 
(note I do not know a thing about Adreno patch ids and its usage between 
different platforms).



else if (adreno_cmp_rev(ADRENO_REV(6, 1, 9, ANY_ID), rev))
val = a619_get_speed_bin(fuse);
  


--
With best wishes
Dmitry

Re: [PATCH v3 02/10] drm/client: Add hotplug_failed flag

[Thomas Zimmermann]

Hi

Am 25.01.23 um 21:57 schrieb Sam Ravnborg:

Hi Thomas,

On Wed, Jan 25, 2023 at 09:04:07PM +0100, Thomas Zimmermann wrote:

Signal failed hotplugging with a flag in struct drm_client_dev. If set,
the client helpers will not further try to set up the fbdev display.

This used to be signalled with a combination of cleared pointers in
struct drm_fb_helper,

I failed to find where we clear the pointers. What do I miss?


Those pointer fields, dev and funcs, where allocated with kzalloc(). The 
error path in drm_fbdev_client_hotplug() later reset them to NULL again 
if an error occured.


Best regards
Thomas


(I had assumed we would stop clearing the pointers after this change).

Sam

which prevents us from initializing these pointers

early after allocation.

The change also harmonizes behavior among DRM clients. Additional DRM
clients will now handle failed hotplugging like fbdev does.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
  drivers/gpu/drm/drm_client.c| 5 +
  drivers/gpu/drm/drm_fbdev_generic.c | 4 
  include/drm/drm_client.h| 8 
  3 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 09ac191c202d..009e7b10455c 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -208,8 +208,13 @@ void drm_client_dev_hotplug(struct drm_device *dev)
if (!client->funcs || !client->funcs->hotplug)
continue;
  
+		if (client->hotplug_failed)

+   continue;
+
ret = client->funcs->hotplug(client);
drm_dbg_kms(dev, "%s: ret=%d\n", client->name, ret);
+   if (ret)
+   client->hotplug_failed = true;
}
mutex_unlock(>clientlist_mutex);
  }
diff --git a/drivers/gpu/drm/drm_fbdev_generic.c 
b/drivers/gpu/drm/drm_fbdev_generic.c
index 3d455a2e3fb5..135d58b8007b 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -382,10 +382,6 @@ static int drm_fbdev_client_hotplug(struct drm_client_dev 
*client)
struct drm_device *dev = client->dev;
int ret;
  
-	/* Setup is not retried if it has failed */

-   if (!fb_helper->dev && fb_helper->funcs)
-   return 0;
-
if (dev->fb_helper)
return drm_fb_helper_hotplug_event(dev->fb_helper);
  
diff --git a/include/drm/drm_client.h b/include/drm/drm_client.h

index 4fc8018eddda..39482527a775 100644
--- a/include/drm/drm_client.h
+++ b/include/drm/drm_client.h
@@ -106,6 +106,14 @@ struct drm_client_dev {
 * @modesets: CRTC configurations
 */
struct drm_mode_set *modesets;
+
+   /**
+* @hotplug failed:
+*
+* Set by client hotplug helpers if the hotplugging failed
+* before. It is usually not tried again.
+*/
+   bool hotplug_failed;
  };
  
  int drm_client_init(struct drm_device *dev, struct drm_client_dev *client,

--
2.39.0


--
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


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v3 01/10] drm/client: Test for connectors before sending hotplug event

[Thomas Zimmermann]

Hi

Am 25.01.23 um 21:52 schrieb Sam Ravnborg:

Hi Thomas,

On Wed, Jan 25, 2023 at 09:04:06PM +0100, Thomas Zimmermann wrote:

Test for connectors in the client code and remove a similar test
from the generic fbdev emulation. Do nothing if the test fails.
Not having connectors indicates a driver bug.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
  drivers/gpu/drm/drm_client.c| 5 +
  drivers/gpu/drm/drm_fbdev_generic.c | 5 -
  2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 262ec64d4397..09ac191c202d 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -198,6 +198,11 @@ void drm_client_dev_hotplug(struct drm_device *dev)
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return;
  
+	if (!dev->mode_config.num_connector) {

+   drm_dbg_kms(dev, "No connectors found, will not send hotplug 
events!\n");
+   return;

This deserves a more visible logging - if a driver fails here it would
be good to spot it in the normal kernel log.
drm_info or drm_notice?


But is that really noteworthy? AFAIK, this situation can legally happen. 
So if it's expected, why should we print a message about it?


Best regards
Thomas



The original code had this on the debug level, but when moving the log
level could also be updated.

Sam


+   }
+
mutex_lock(>clientlist_mutex);
list_for_each_entry(client, >clientlist, list) {
if (!client->funcs || !client->funcs->hotplug)
diff --git a/drivers/gpu/drm/drm_fbdev_generic.c 
b/drivers/gpu/drm/drm_fbdev_generic.c
index 0a4c160e0e58..3d455a2e3fb5 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -389,11 +389,6 @@ static int drm_fbdev_client_hotplug(struct drm_client_dev 
*client)
if (dev->fb_helper)
return drm_fb_helper_hotplug_event(dev->fb_helper);
  
-	if (!dev->mode_config.num_connector) {

-   drm_dbg_kms(dev, "No connectors found, will not create 
framebuffer!\n");
-   return 0;
-   }
-
drm_fb_helper_prepare(dev, fb_helper, _fb_helper_generic_funcs);
  
  	ret = drm_fb_helper_init(dev, fb_helper);

--
2.39.0


--
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


OpenPGP_signature
Description: OpenPGP digital signature

Re: [RFC 10/12] cgroup/drm: Introduce weight based drm cgroup control

[Michal Koutný]

On Fri, Jan 27, 2023 at 01:31:54PM +, Tvrtko Ursulin 
 wrote:
> I think you missed the finish_suspend_scanning() part:
> 
>   if (root_drmcs.suspended_period_us)
>   cancel_delayed_work_sync(_drmcs.scan_work);
> 
> So if scanning was in progress migration will wait until it finishes.

Indeed, I've missed that. Thank you!

> Not claiming I did not miss something because I was totally new with cgroup
> internals when I started working on this. So it is definitely useful to have
> more eyes looking.

The custom with (especially v2, especially horizontal) migrations
is that they're treated leniently to avoid performance costs.

I'm afraid waiting for scan in can_attach() can propagate globally (via
cgroup_update_dfl_csses() and cgroup_attach_lock()) sometimes.

OTOH, unless I misunderstood, you need to cover explicit (not task but
resource, when sending client FD around) migration anyway?
(I.e. my suggestion would be to mutualy exclude scanning and explicit
migration but not scanning and task migration in order to avoid possible
global propagation.)

Thanks,
Michal


signature.asc
Description: Digital signature

Re: [PATCH] drm: override detected status for connectors which are forced on

[Maxime Ripard]

Hi Michael, all,

On Fri, Jan 20, 2023 at 10:03:48AM +0100, Michael Rodin wrote:
> Hi Maxime,
> 
> thank you for your feedback!
> On Thu, Dec 22, 2022 at 06:40:54PM +0100, Maxime Ripard wrote:
> > Hi,
> > 
> > On Thu, Dec 15, 2022 at 06:03:59PM +0100, Michael Rodin wrote:
> > > The detected status of a connector should be ignored when a connector is
> > > forced as hinted in the commit d50ba256b5f1 ("drm/kms: start
> > > adding command line interface using fb."). One negative side effect of
> > > not ignoring this is observed on the RCar3 SoCs which use the dw-hdmi
> > > driver. It continues executing drm_helper_hpd_irq_event even if its
> > > connector is forced to ON. As consequence drm_helper_hpd_irq_event calls
> > > "detect" so the connector status is updated to "disconnected":
> > > 
> > > [  420.201527] [drm:drm_helper_hpd_irq_event] [CONNECTOR:76:HDMI-A-1] 
> > > status updated from connected to disconnected
> > > 
> > > This status is corrected by drm_helper_probe_single_connector_modes 
> > > shortly
> > > after this because this function checks if a connector is forced:
> > > 
> > > [  420.218703] [drm:drm_helper_probe_single_connector_modes] 
> > > [CONNECTOR:76:HDMI-A-1] status updated from disconnected to connected
> > > 
> > > To avoid similar issues this commit adapts functions which call "detect"
> > > so they check additionally if a connector is forced and override the 
> > > status
> > > returned by "detect".
> > > 
> > > Fixes: 816da85a0990 ("drm: handle HPD and polled connectors separately")
> > > Signed-off-by: Michael Rodin 
> > 
> > As reported here, this breaks vc4, and probably i915:
> > https://lore.kernel.org/dri-devel/20221107123657.24vbgep3jqeklb2s@houat/
> > 
> > Maxime
> 
> My understanding from [1,2] was that the way to avoid such regressions is
> to make sure that the "detect" callbacks of connector drivers are always
> called even if a connector is forced. This is what I have implemented in my
> second patch where "detect" is called first and then the return value is
> adjusted based on the "force" status. If my understanding was wrong, I
> would very much appreciate if you could give me some hints for the
> implementation of an acceptable solution.

Ah, sorry, you're right.

I was confused since you didn't mention it was a new version, and didn't
provide a changelog, I just assumed you resent the same patch.

In the time between, we also got a report for the RaspberryPi that the
behaviour is also broken on CEC:

https://github.com/raspberrypi/linux/pull/5052

If we get back to the problem we're trying to solve, it means that if
nothing is provided on the command line, we should rely on the polling
or IRQ based detection that will call detect on a regular basis. The
current detect side effects (for HDMI) are that:

  * the CEC address will be invalidated if it's disconnected, and
set if it's connected.

  * if the scrambler was active, we re-enable the HDMI scrambler

If we want to force the connector to be disconnected, everything is
fine. If we want to force the connector on, then we should ignore the
CEC invalidation, but should keep enabling the scrambler.

And you want to avoid state transitions when the connector is forced,
which also makes sense.

I think we can get it to work by:

  - Merging your patch to call detect, but no matter the returned
status, if it's forced to a state by the command line or some other
mechanism, we return what was forced.

  - in the detect hook:

  * if connector->force is set to off, we just return
connector_status_disconnected.

  * if connector->force is set to on, and if:

+ the actual status is that the display is disconnected, we
  return but don't invalidate the CEC address.

+ the actual status is that the display is connected, we setup
  the scrambler again if needed, and set the CEC address.

So in addition to your patch, a skeleton detect hook would be something like:

static int detect(struct drm_connector *connector, bool force)
{
if (connector->force == DRM_FORCE_OFF)
return connector_status_disconnected;

status = /* whatever is needed to fetch the status from the hardware */;

if (status == connector_status_disconnected) {
if (connector->force == DRM_FORCE_ON)
return connector_status_connected;

cec_phys_addr_invalidate(vc4_hdmi->cec_adap);
}

edid = drm_get_edid(...);
cec_s_phys_addr_from_edid(..., edid);
reset_scrambler();

return status;
}

Does that make sense?
Maxime


signature.asc
Description: PGP signature

Re: [PATCH 3/7] drm/vmwgfx: Rename vmw_buffer_object to vmw_bo

[Thomas Zimmermann]

Am 26.01.23 um 18:38 schrieb Zack Rusin:

From: Zack Rusin 

The rest of the drivers which are using ttm have mostly standardized on
driver_prefix_bo as the name for subclasses of the TTM buffer object.
Make vmwgfx match the rest of the drivers and follow the same naming
semantics.

This is especially clear given that the name of the file in which the
object was defined is vmw_bo.c.

Signed-off-by: Zack Rusin 
---
  drivers/gpu/drm/vmwgfx/vmwgfx_bo.c   |  91 +
  drivers/gpu/drm/vmwgfx/vmwgfx_bo.h   | 191 +++
  drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c  |  10 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c   |   9 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_context.c  |  11 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c  |   9 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c  |   7 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_drv.h  | 182 ++
  drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c  |  53 +++--
  drivers/gpu/drm/vmwgfx/vmwgfx_fence.c|   2 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_gem.c  |  26 +--
  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  |  17 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_kms.h  |  12 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_mob.c  |   7 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c  |  18 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c   |  27 +--
  drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |  29 +--
  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c |  15 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_shader.c   |  15 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c |  13 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_streamoutput.c |   9 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_surface.c  |   9 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c   |   3 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_validation.c   |  30 +--
  drivers/gpu/drm/vmwgfx/vmwgfx_validation.h   |   6 +-
  25 files changed, 431 insertions(+), 370 deletions(-)
  create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_bo.h

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index 8aaeeecd2016..586e1f1e9e49 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -1,7 +1,7 @@
  // SPDX-License-Identifier: GPL-2.0 OR MIT
  /**
   *
- * Copyright © 2011-2018 VMware, Inc., Palo Alto, CA., USA
+ * Copyright © 2011-2023 VMware, Inc., Palo Alto, CA., USA
   * All Rights Reserved.
   *
   * Permission is hereby granted, free of charge, to any person obtaining a
@@ -26,55 +26,54 @@
   *
   **/
  
-#include 

-
+#include "vmwgfx_bo.h"
  #include "vmwgfx_drv.h"
-#include "ttm_object.h"
  
  
+#include 

+
  /**
- * vmw_buffer_object - Convert a struct ttm_buffer_object to a struct
- * vmw_buffer_object.
+ * vmw_bo - Convert a struct ttm_buffer_object to a struct vmw_bo.
   *
   * @bo: Pointer to the TTM buffer object.
- * Return: Pointer to the struct vmw_buffer_object embedding the
+ * Return: Pointer to the struct vmw_bo embedding the
   * TTM buffer object.
   */
-static struct vmw_buffer_object *
-vmw_buffer_object(struct ttm_buffer_object *bo)
+static struct vmw_bo *
+vmw_bo(struct ttm_buffer_object *bo)


We usually name these functions to_(): to_vmw_bo(). I'd also 
use the base GEM object as argument, as most DRM interfaces use GEM 
objects. This way you can upcast from ttm bos with


  vbo = to_vmw_bos(>base)

and use

  bo = >base

if you need the TTM bo.

Best regards
Thomas


  {
-   return container_of(bo, struct vmw_buffer_object, base);
+   return container_of(bo, struct vmw_bo, base);
  }
  
  /**

- * vmw_bo_bo_free - vmw buffer object destructor
+ * vmw_bo_free - vmw_bo destructor
   *
   * @bo: Pointer to the embedded struct ttm_buffer_object
   */
-static void vmw_bo_bo_free(struct ttm_buffer_object *bo)
+static void vmw_bo_free(struct ttm_buffer_object *bo)
  {
-   struct vmw_buffer_object *vmw_bo = vmw_buffer_object(bo);
+   struct vmw_bo *vbo = vmw_bo(bo);
  
-	WARN_ON(vmw_bo->dirty);

-   WARN_ON(!RB_EMPTY_ROOT(_bo->res_tree));
-   vmw_bo_unmap(vmw_bo);
+   WARN_ON(vbo->dirty);
+   WARN_ON(!RB_EMPTY_ROOT(>res_tree));
+   vmw_bo_unmap(vbo);
drm_gem_object_release(>base);
-   kfree(vmw_bo);
+   kfree(vbo);
  }
  
  /**

- * bo_is_vmw - check if the buffer object is a _buffer_object
+ * bo_is_vmw - check if the buffer object is a _bo
   * @bo: ttm buffer object to be checked
   *
   * Uses destroy function associated with the object to determine if this is
- * a _buffer_object.
+ * a _bo.
   *
   * Returns:
- * true if the object is of _buffer_object type, false if not.
+ * true if the object is of _bo type, false if not.
   */
  static bool bo_is_vmw(struct ttm_buffer_object *bo)
  {
-   return bo->destroy == _bo_bo_free;
+   return bo->destroy == _bo_free;
  }
  
  /**

@@ -88,7 +87,7 @@ static bool 

Re: [Intel-gfx] [PATCH] drm/i915: Avoid potential vm use-after-free

[Tvrtko Ursulin]

On 27/01/2023 13:10, Matthew Auld wrote:

On Mon, 23 Jan 2023 at 16:57, Tvrtko Ursulin
 wrote:



+ some more people based on e1a7ab4fca0c

On 19/01/2023 17:32, Rob Clark wrote:

From: Rob Clark 

Adding the vm to the vm_xa table makes it visible to userspace, which
could try to race with us to close the vm.  So we need to take our extra
reference before putting it in the table.

Signed-off-by: Rob Clark 
---
Note, you could list commit e1a7ab4fca0c ("drm/i915: Remove the vm open
count") as the "fixed" commit, but really the issue seems to go back
much further (with the fix needing some backporting in the process).


It would probably be rather essential to identify the correct Fixes: tag.

Since Thomas, Matt and Niranjana you were directly involved in the patch
which changed significantly how this works, perhaps there is something
still somewhat easily retrievable from your memory lanes to help with this?


Sorry for the delay. Fix looks good to me,
Reviewed-by: Matthew Auld 

Looking at the git history, the fixes tag I think needs to be:

Fixes: 9ec8795e7d91 ("drm/i915: Drop __rcu from gem_context->vm")
Cc:  # v5.16+


As discussed offline this looks correct to me too. Thanks for looking 
into it!


Since the CI was green I have now merged the patch. Thanks for the fix Rob!

Regards,

Tvrtko

P.S. Backport to kernels which do not contain e1a7ab4fca0c ("drm/i915: 
Remove the vm open count"), so 5.16 to 5.18, will require a slightly 
different patch as Matt has also mentioned offline.






Regards,

Tvrtko



   drivers/gpu/drm/i915/gem/i915_gem_context.c | 14 +++---
   1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 6250de9b9196..e4b78ab4773b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1861,11 +1861,19 @@ static int get_ppgtt(struct drm_i915_file_private 
*file_priv,
   vm = ctx->vm;
   GEM_BUG_ON(!vm);

+ /*
+  * Get a reference for the allocated handle.  Once the handle is
+  * visible in the vm_xa table, userspace could try to close it
+  * from under our feet, so we need to hold the extra reference
+  * first.
+  */
+ i915_vm_get(vm);
+
   err = xa_alloc(_priv->vm_xa, , vm, xa_limit_32b, GFP_KERNEL);
- if (err)
+ if (err) {
+ i915_vm_put(vm);
   return err;
-
- i915_vm_get(vm);
+ }

   GEM_BUG_ON(id == 0); /* reserved for invalid/unassigned ppgtt */
   args->value = id;

Re: [PATCH 1/7] drm/vmwgfx: Use the common gem mmap instead of the custom code

[Thomas Zimmermann]

Hi

Am 26.01.23 um 18:38 schrieb Zack Rusin:

From: Zack Rusin 

Before vmwgfx supported gem it needed to implement the entire mmap logic
explicitly. With GEM support that's not needed and the generic code
can be used by simply setting the vm_ops to vmwgfx specific ones on the
gem object itself.

Removes a lot of code from vmwgfx without any functional difference.


Yeah, I remember that these GEM helpers, and mmap in particular, were 
fairly inconsistent and confusing among drivers. After cleaning up 
everthing, it comes down to GEM helpers plus a few pointers in the GEM 
object funcs.




Signed-off-by: Zack Rusin 


Reviewed-by: Thomas Zimmermann 


---
  drivers/gpu/drm/vmwgfx/Makefile  |   2 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c  |   2 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_drv.h  |   6 --
  drivers/gpu/drm/vmwgfx/vmwgfx_gem.c  |   8 ++
  drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 110 ---
  5 files changed, 10 insertions(+), 118 deletions(-)
  delete mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c

diff --git a/drivers/gpu/drm/vmwgfx/Makefile b/drivers/gpu/drm/vmwgfx/Makefile
index 2a644f035597..e94479d9cd5b 100644
--- a/drivers/gpu/drm/vmwgfx/Makefile
+++ b/drivers/gpu/drm/vmwgfx/Makefile
@@ -1,7 +1,7 @@
  # SPDX-License-Identifier: GPL-2.0
  vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o vmwgfx_drv.o \
vmwgfx_ioctl.o vmwgfx_resource.o vmwgfx_ttm_buffer.o \
-   vmwgfx_cmd.o vmwgfx_irq.o vmwgfx_ldu.o vmwgfx_ttm_glue.o \
+   vmwgfx_cmd.o vmwgfx_irq.o vmwgfx_ldu.o \
vmwgfx_overlay.o vmwgfx_gmrid_manager.o vmwgfx_fence.o \
vmwgfx_bo.o vmwgfx_scrn.o vmwgfx_context.o \
vmwgfx_surface.o vmwgfx_prime.o vmwgfx_mob.o vmwgfx_shader.o \
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index bd02cb0e6837..e0c2e3748015 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -1566,7 +1566,7 @@ static const struct file_operations vmwgfx_driver_fops = {
.open = drm_open,
.release = drm_release,
.unlocked_ioctl = vmw_unlocked_ioctl,
-   .mmap = vmw_mmap,
+   .mmap = drm_gem_mmap,
.poll = drm_poll,
.read = drm_read,
  #if defined(CONFIG_COMPAT)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 5acbf5849b27..4dfa5044a9e7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -1053,12 +1053,6 @@ vmw_is_cursor_bypass3_enabled(const struct vmw_private 
*dev_priv)
return (vmw_fifo_caps(dev_priv) & SVGA_FIFO_CAP_CURSOR_BYPASS_3) != 0;
  }
  
-/**

- * TTM glue - vmwgfx_ttm_glue.c
- */
-
-extern int vmw_mmap(struct file *filp, struct vm_area_struct *vma);
-
  /**
   * TTM buffer object driver - vmwgfx_ttm_buffer.c
   */
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c
index ce609e7d758f..ba4ddd9f7a7e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c
@@ -103,6 +103,13 @@ static struct sg_table *vmw_gem_object_get_sg_table(struct 
drm_gem_object *obj)
return drm_prime_pages_to_sg(obj->dev, vmw_tt->dma_ttm.pages, 
vmw_tt->dma_ttm.num_pages);
  }
  
+static const struct vm_operations_struct vmw_vm_ops = {

+   .pfn_mkwrite = vmw_bo_vm_mkwrite,
+   .page_mkwrite = vmw_bo_vm_mkwrite,
+   .fault = vmw_bo_vm_fault,
+   .open = ttm_bo_vm_open,
+   .close = ttm_bo_vm_close,
+};
  
  static const struct drm_gem_object_funcs vmw_gem_object_funcs = {

.free = vmw_gem_object_free,
@@ -115,6 +122,7 @@ static const struct drm_gem_object_funcs 
vmw_gem_object_funcs = {
.vmap = drm_gem_ttm_vmap,
.vunmap = drm_gem_ttm_vunmap,
.mmap = drm_gem_ttm_mmap,
+   .vm_ops = _vm_ops,
  };
  
  /**

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
deleted file mode 100644
index 265f7c48d856..
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
+++ /dev/null
@@ -1,110 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0 OR MIT
-/**
- *
- * Copyright 2009-2011 VMware, Inc., Palo Alto, CA., USA
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the
- * "Software"), to deal in the Software without restriction, including
- * without limitation the rights to use, copy, modify, merge, publish,
- * distribute, sub license, and/or sell copies of the Software, and to
- * permit persons to whom the Software is furnished to do so, subject to
- * the following conditions:
- *
- * The above copyright notice and this permission notice (including the
- * next paragraph) shall be included in all copies or substantial portions
- * of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT 

Re: [PATCH 6/7] drm/vmwgfx: Abstract placement selection

[Thomas Zimmermann]

Hi

Am 26.01.23 um 18:38 schrieb Zack Rusin:

From: Zack Rusin 

Problem with explicit placement selection in vmwgfx is that by the time
the buffer object needs to be validated the information about which
placement was supposed to be used is lost. To workaround this the driver
had a bunch of state in various places e.g. as_mob or cpu_blit to
somehow convey the information on which placement was intended.

Fix is properly by allowing the buffer object to hold their preferred


'Fix it'


placement so it can be reused whenever needed. This makes the entire
validation pipeline a lot easier both to understand and maintain.

Signed-off-by: Zack Rusin 
---
  drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 156 +++--
  drivers/gpu/drm/vmwgfx/vmwgfx_bo.h|  26 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_context.c   |   9 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c   |  11 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c   |   3 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_drv.h   |   2 -
  drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c   |  36 ++-
  drivers/gpu/drm/vmwgfx/vmwgfx_gem.c   |   5 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   |  22 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_kms.h   |  21 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_resource.c  |  11 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_resource_priv.h |   3 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c  |  13 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_shader.c|  15 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_so.c|   4 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c  | 304 ++
  drivers/gpu/drm/vmwgfx/vmwgfx_streamoutput.c  |   3 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_surface.c   |   6 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c|  47 ---
  drivers/gpu/drm/vmwgfx/vmwgfx_va.c|   4 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_validation.c|  74 ++---
  drivers/gpu/drm/vmwgfx/vmwgfx_validation.h|   6 +-
  22 files changed, 325 insertions(+), 456 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index fa289e67143d..b94c32a59689 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -148,11 +148,17 @@ int vmw_bo_pin_in_vram_or_gmr(struct vmw_private 
*dev_priv,
goto out_unreserve;
}
  
-	ret = ttm_bo_validate(bo, _vram_gmr_placement, );

+   vmw_bo_placement_set(buf,
+vmw_bo_domain_gmr | vmw_bo_domain_vram,
+vmw_bo_domain_gmr);
+   ret = ttm_bo_validate(bo, >placement, );
if (likely(ret == 0) || ret == -ERESTARTSYS)
goto out_unreserve;
  
-	ret = ttm_bo_validate(bo, _vram_placement, );

+   vmw_bo_placement_set(buf,
+vmw_bo_domain_vram,
+vmw_bo_domain_vram);
+   ret = ttm_bo_validate(bo, >placement, );
  
  out_unreserve:

if (!ret)
@@ -203,17 +209,8 @@ int vmw_bo_pin_in_start_of_vram(struct vmw_private 
*dev_priv,
  {
struct ttm_operation_ctx ctx = {interruptible, false };
struct ttm_buffer_object *bo = >base;
-   struct ttm_placement placement;
-   struct ttm_place place;
int ret = 0;
  
-	place = vmw_vram_placement.placement[0];

-   place.lpfn = PFN_UP(bo->resource->size);
-   placement.num_placement = 1;
-   placement.placement = 
-   placement.num_busy_placement = 1;
-   placement.busy_placement = 
-
vmw_execbuf_release_pinned_bo(dev_priv);
ret = ttm_bo_reserve(bo, interruptible, false, NULL);
if (unlikely(ret != 0))
@@ -229,14 +226,21 @@ int vmw_bo_pin_in_start_of_vram(struct vmw_private 
*dev_priv,
bo->resource->start > 0 &&
buf->base.pin_count == 0) {
ctx.interruptible = false;
-   (void) ttm_bo_validate(bo, _sys_placement, );
+   vmw_bo_placement_set(buf,
+vmw_bo_domain_sys,
+vmw_bo_domain_sys);
+   (void) ttm_bo_validate(bo, >placement, );
}
  
+	vmw_bo_placement_set(buf,

+vmw_bo_domain_vram,
+vmw_bo_domain_vram);
+   buf->places[0].lpfn = PFN_UP(bo->resource->size);
if (buf->base.pin_count > 0)
-   ret = ttm_resource_compat(bo->resource, )
+   ret = ttm_resource_compat(bo->resource, >placement)
? 0 : -EINVAL;
else
-   ret = ttm_bo_validate(bo, , );
+   ret = ttm_bo_validate(bo, >placement, );
  
  	/* For some reason we didn't end up at the start of vram */

WARN_ON(ret == 0 && bo->resource->start != 0);
@@ -444,7 +448,7 @@ int vmw_bo_create_kernel(struct vmw_private *dev_priv, 
unsigned long size,
  }
  
  int vmw_bo_create(struct vmw_private *vmw,

- size_t size, struct ttm_placement *placement,
+ size_t size, 

Re: [RFC 10/12] cgroup/drm: Introduce weight based drm cgroup control

[Tvrtko Ursulin]

On 27/01/2023 13:01, Michal Koutný wrote:

On Thu, Jan 12, 2023 at 04:56:07PM +, Tvrtko Ursulin 
 wrote:

+static int drmcs_can_attach(struct cgroup_taskset *tset)
+{
+   int ret;
+
+   /*
+* As processes are getting moved between groups we need to ensure
+* both that the old group does not see a sudden downward jump in the
+* GPU utilisation, and that the new group does not see a sudden jump
+* up with all the GPU time clients belonging to the migrated process
+* have accumulated.
+*
+* To achieve that we suspend the scanner until the migration is
+* completed where the resume at the end ensures both groups start
+* observing GPU utilisation from a reset state.
+*/
+
+   ret = mutex_lock_interruptible(_mutex);
+   if (ret)
+   return ret;
+   start_suspend_scanning();
+   mutex_unlock(_mutex);
+
+   finish_suspend_scanning();


Here's scanning suspension, communicated via

root_drmcs.scanning_suspended = true;
root_drmcs.suspended_period_us = root_drmcs.period_us;
root_drmcs.period_us = 0;

but I don't see those used in scan_worker() and the scanning traversal
can apparently run concurrently with a task migration.


I think you missed the finish_suspend_scanning() part:

if (root_drmcs.suspended_period_us)
cancel_delayed_work_sync(_drmcs.scan_work);

So if scanning was in progress migration will wait until it finishes. 
And re-start only when migration is done (drmcs_attach), or it failed 
(drmcs_cancel_attach).


Not claiming I did not miss something because I was totally new with 
cgroup internals when I started working on this. So it is definitely 
useful to have more eyes looking.



[...]
+static bool
+__start_scanning(struct drm_cgroup_state *root, unsigned int period_us)
[...]
+   css_for_each_descendant_post(node, >css) {
[...]
+   active = drmcs_get_active_time_us(drmcs);
+   if (period_us && active > drmcs->prev_active_us)
+   drmcs->active_us += active - drmcs->prev_active_us;
+   drmcs->prev_active_us = active;


drmcs_get_active_time_us() could count a task's contribution here,
the task would migrate to a different drmcs,
and it'd be counted 2nd time.


Lets see.. __start_scanning() can be called from the worker, so max one 
instance at a time, no issue.


Then from resume scanning, so it is guaranteed worker is not running and 
can't restart since mutex guards the re-start.


Finally from drmcs_write_period_us() - yes there __start_scanning() can 
race with it being invoked by the worker - oops! However.. this is just 
a debugging aid as the cover letter explains. This file is not intended 
to be present in the final version, rather as per earlier discussion 
with Tejun the idea is to only have boot time option to control the 
functionality (enable/disable or period).


I will nevertheless try to fix this race up for the next posting to 
avoid further confusion!


Regards,

Tvrtko

Re: [PATCH drm-next 05/14] drm/nouveau: new VM_BIND uapi interfaces

[Christian König]

Am 27.01.23 um 14:12 schrieb Danilo Krummrich:

On 1/27/23 08:55, Christian König wrote:

Am 27.01.23 um 02:26 schrieb Danilo Krummrich:

On 1/27/23 02:05, Matthew Brost wrote:

On Wed, Jan 18, 2023 at 07:12:47AM +0100, Danilo Krummrich wrote:

This commit provides the interfaces for the new UAPI motivated by the
Vulkan API. It allows user mode drivers (UMDs) to:

1) Initialize a GPU virtual address (VA) space via the new
    DRM_IOCTL_NOUVEAU_VM_INIT ioctl. UMDs can provide a kernel 
reserved

    VA area.

2) Bind and unbind GPU VA space mappings via the new
    DRM_IOCTL_NOUVEAU_VM_BIND ioctl.

3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC ioctl.

Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC support
asynchronous processing with DRM syncobjs as synchronization 
mechanism.


The default DRM_IOCTL_NOUVEAU_VM_BIND is synchronous processing,
DRM_IOCTL_NOUVEAU_EXEC supports asynchronous processing only.

Co-authored-by: Dave Airlie 
Signed-off-by: Danilo Krummrich 
---
  Documentation/gpu/driver-uapi.rst |   8 ++
  include/uapi/drm/nouveau_drm.h    | 216 
++

  2 files changed, 224 insertions(+)

diff --git a/Documentation/gpu/driver-uapi.rst 
b/Documentation/gpu/driver-uapi.rst

index 4411e6919a3d..9c7ca6e33a68 100644
--- a/Documentation/gpu/driver-uapi.rst
+++ b/Documentation/gpu/driver-uapi.rst
@@ -6,3 +6,11 @@ drm/i915 uAPI
  =
    .. kernel-doc:: include/uapi/drm/i915_drm.h
+
+drm/nouveau uAPI
+
+
+VM_BIND / EXEC uAPI
+---
+
+.. kernel-doc:: include/uapi/drm/nouveau_drm.h
diff --git a/include/uapi/drm/nouveau_drm.h 
b/include/uapi/drm/nouveau_drm.h

index 853a327433d3..f6e7d40201d4 100644
--- a/include/uapi/drm/nouveau_drm.h
+++ b/include/uapi/drm/nouveau_drm.h
@@ -126,6 +126,216 @@ struct drm_nouveau_gem_cpu_fini {
  __u32 handle;
  };
  +/**
+ * struct drm_nouveau_sync - sync object
+ *
+ * This structure serves as synchronization mechanism for 
(potentially)

+ * asynchronous operations such as EXEC or VM_BIND.
+ */
+struct drm_nouveau_sync {
+    /**
+ * @flags: the flags for a sync object
+ *
+ * The first 8 bits are used to determine the type of the 
sync object.

+ */
+    __u32 flags;
+#define DRM_NOUVEAU_SYNC_SYNCOBJ 0x0
+#define DRM_NOUVEAU_SYNC_TIMELINE_SYNCOBJ 0x1
+#define DRM_NOUVEAU_SYNC_TYPE_MASK 0xf
+    /**
+ * @handle: the handle of the sync object
+ */
+    __u32 handle;
+    /**
+ * @timeline_value:
+ *
+ * The timeline point of the sync object in case the syncobj 
is of

+ * type DRM_NOUVEAU_SYNC_TIMELINE_SYNCOBJ.
+ */
+    __u64 timeline_value;
+};
+
+/**
+ * struct drm_nouveau_vm_init - GPU VA space init structure
+ *
+ * Used to initialize the GPU's VA space for a user client, 
telling the kernel
+ * which portion of the VA space is managed by the UMD and kernel 
respectively.

+ */
+struct drm_nouveau_vm_init {
+    /**
+ * @unmanaged_addr: start address of the kernel managed VA 
space region

+ */
+    __u64 unmanaged_addr;
+    /**
+ * @unmanaged_size: size of the kernel managed VA space 
region in bytes

+ */
+    __u64 unmanaged_size;
+};
+
+/**
+ * struct drm_nouveau_vm_bind_op - VM_BIND operation
+ *
+ * This structure represents a single VM_BIND operation. UMDs 
should pass
+ * an array of this structure via struct drm_nouveau_vm_bind's 
_ptr field.

+ */
+struct drm_nouveau_vm_bind_op {
+    /**
+ * @op: the operation type
+ */
+    __u32 op;
+/**
+ * @DRM_NOUVEAU_VM_BIND_OP_ALLOC:
+ *
+ * The alloc operation is used to reserve a VA space region 
within the GPU's VA
+ * space. Optionally, the _NOUVEAU_VM_BIND_SPARSE flag can be 
passed to
+ * instruct the kernel to create sparse mappings for the given 
region.

+ */
+#define DRM_NOUVEAU_VM_BIND_OP_ALLOC 0x0


Do you really need this operation? We have no concept of this in Xe,
e.g. we can create a VM and the entire address space is managed 
exactly

the same.


The idea for alloc/free is to let UMDs allocate a portion of the VA 
space (which I call a region), basically the same thing Vulkan 
represents with a VKBuffer.


If that's mangled into the same component/interface then I can say 
from experience that this is a pretty bad idea. We have tried 
something similar with radeon and it turned out horrible.


What was the exact constellation in radeon and which problems did 
arise from it?




What you want is one component for tracking the VA allocations 
(drm_mm based) and a different component/interface for tracking the 
VA mappings (probably rb tree based).


That's what the GPUVA manager is doing. There are gpuva_regions which 
correspond to VA allocations and gpuvas which represent the mappings. 
Both are tracked separately (currently both with a separate drm_mm, 
though). However, the GPUVA manager needs to take regions into account 
when dealing with mappings to make sure the GPUVA manager doesn't 
propose drivers to merge over region 

Re: [PATCH 5/7] drm/vmwgfx: Cleanup the vmw bo usage in the cursor paths

[Thomas Zimmermann]

Hi

Am 26.01.23 um 18:38 schrieb Zack Rusin:

From: Zack Rusin 

Base mapped count is useless because the ttm unmap functions handle
null maps just fine so completely remove all the code related to it.
Rename dummy to is_iomem because that's what it is even if we're not
activelly using it. Makes the code easier to read.

Signed-off-by: Zack Rusin 
---
  drivers/gpu/drm/vmwgfx/vmwgfx_bo.h  |  4 
  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 28 +---
  2 files changed, 9 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h
index db85609ec01c..4dcf37235cb0 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h
@@ -44,7 +44,6 @@ struct vmw_resource;
   * struct vmw_bo - TTM buffer object with vmwgfx additions
   * @base: The TTM buffer object
   * @res_tree: RB tree of resources using this buffer object as a backing MOB
- * @base_mapped_count: ttm BO mapping count; used by KMS atomic helpers.
   * @cpu_writers: Number of synccpu write grabs. Protected by reservation when
   * increased. May be decreased without reservation.
   * @dx_query_ctx: DX context if this buffer object is used as a DX query MOB
@@ -55,8 +54,6 @@ struct vmw_resource;
  struct vmw_bo {
struct ttm_buffer_object base;
struct rb_root res_tree;
-   /* For KMS atomic helpers: ttm bo mapping count */
-   atomic_t base_mapped_count;
  
  	atomic_t cpu_writers;

/* Not ref-counted.  Protected by binding_mutex */
@@ -67,7 +64,6 @@ struct vmw_bo {
struct vmw_bo_dirty *dirty;
  };
  
-

  int vmw_bo_create_kernel(struct vmw_private *dev_priv,
 unsigned long size,
 struct ttm_placement *placement,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 6780391c57ea..e83286e08837 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -153,9 +153,9 @@ static void vmw_cursor_update_mob(struct vmw_private 
*dev_priv,
SVGAGBCursorHeader *header;
SVGAGBAlphaCursorHeader *alpha_header;
const u32 image_size = width * height * sizeof(*image);
-   bool dummy;
+   bool is_iomem;


It seems those renames are obfuscating the patch. Maybe they can get 
their own commit?


Best regards
Thomas

  
-	header = ttm_kmap_obj_virtual(>cursor.map, );

+   header = ttm_kmap_obj_virtual(>cursor.map, _iomem);
alpha_header = >header.alphaHeader;
  
  	memset(header, 0, sizeof(*header));

@@ -185,13 +185,13 @@ static u32 vmw_du_cursor_mob_size(u32 w, u32 h)
   */
  static u32 *vmw_du_cursor_plane_acquire_image(struct vmw_plane_state *vps)
  {
-   bool dummy;
+   bool is_iomem;
if (vps->surf) {
if (vps->surf_mapped)
return vmw_bo_map_and_cache(vps->surf->res.backup);
return vps->surf->snooper.image;
} else if (vps->bo)
-   return ttm_kmap_obj_virtual(>bo->map, );
+   return ttm_kmap_obj_virtual(>bo->map, _iomem);
return NULL;
  }
  
@@ -364,7 +364,7 @@ void vmw_kms_cursor_snoop(struct vmw_surface *srf,

SVGA3dCopyBox *box;
unsigned box_count;
void *virtual;
-   bool dummy;
+   bool is_iomem;
struct vmw_dma_cmd {
SVGA3dCmdHeader header;
SVGA3dCmdSurfaceDMA dma;
@@ -424,7 +424,7 @@ void vmw_kms_cursor_snoop(struct vmw_surface *srf,
if (unlikely(ret != 0))
goto err_unreserve;
  
-	virtual = ttm_kmap_obj_virtual(, );

+   virtual = ttm_kmap_obj_virtual(, _iomem);
  
  	if (box->w == VMW_CURSOR_SNOOP_WIDTH && cmd->dma.guest.pitch == image_pitch) {

memcpy(srf->snooper.image, virtual,
@@ -658,19 +658,18 @@ vmw_du_cursor_plane_cleanup_fb(struct drm_plane *plane,
  {
struct vmw_cursor_plane *vcp = vmw_plane_to_vcp(plane);
struct vmw_plane_state *vps = vmw_plane_state_to_vps(old_state);
-   bool dummy;
+   bool is_iomem;
  
  	if (vps->surf_mapped) {

vmw_bo_unmap(vps->surf->res.backup);
vps->surf_mapped = false;
}
  
-	if (vps->bo && ttm_kmap_obj_virtual(>bo->map, )) {

+   if (vps->bo && ttm_kmap_obj_virtual(>bo->map, _iomem)) {
const int ret = ttm_bo_reserve(>bo->base, true, false, 
NULL);
  
  		if (likely(ret == 0)) {

-   if (atomic_read(>bo->base_mapped_count) == 0)
-   ttm_bo_kunmap(>bo->map);
+   ttm_bo_kunmap(>bo->map);
ttm_bo_unreserve(>bo->base);
}
}
@@ -744,9 +743,6 @@ vmw_du_cursor_plane_prepare_fb(struct drm_plane *plane,
  
  		ret = ttm_bo_kmap(>bo->base, 0, PFN_UP(size), >bo->map);
  
-		if (likely(ret == 0))

-   atomic_inc(>bo->base_mapped_count);
-
ttm_bo_unreserve(>bo->base);
  
  		if 

Re: [PATCH drm-next 05/14] drm/nouveau: new VM_BIND uapi interfaces

[Danilo Krummrich]

On 1/27/23 08:55, Christian König wrote:

Am 27.01.23 um 02:26 schrieb Danilo Krummrich:

On 1/27/23 02:05, Matthew Brost wrote:

On Wed, Jan 18, 2023 at 07:12:47AM +0100, Danilo Krummrich wrote:

This commit provides the interfaces for the new UAPI motivated by the
Vulkan API. It allows user mode drivers (UMDs) to:

1) Initialize a GPU virtual address (VA) space via the new
    DRM_IOCTL_NOUVEAU_VM_INIT ioctl. UMDs can provide a kernel reserved
    VA area.

2) Bind and unbind GPU VA space mappings via the new
    DRM_IOCTL_NOUVEAU_VM_BIND ioctl.

3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC ioctl.

Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC support
asynchronous processing with DRM syncobjs as synchronization mechanism.

The default DRM_IOCTL_NOUVEAU_VM_BIND is synchronous processing,
DRM_IOCTL_NOUVEAU_EXEC supports asynchronous processing only.

Co-authored-by: Dave Airlie 
Signed-off-by: Danilo Krummrich 
---
  Documentation/gpu/driver-uapi.rst |   8 ++
  include/uapi/drm/nouveau_drm.h    | 216 
++

  2 files changed, 224 insertions(+)

diff --git a/Documentation/gpu/driver-uapi.rst 
b/Documentation/gpu/driver-uapi.rst

index 4411e6919a3d..9c7ca6e33a68 100644
--- a/Documentation/gpu/driver-uapi.rst
+++ b/Documentation/gpu/driver-uapi.rst
@@ -6,3 +6,11 @@ drm/i915 uAPI
  =
    .. kernel-doc:: include/uapi/drm/i915_drm.h
+
+drm/nouveau uAPI
+
+
+VM_BIND / EXEC uAPI
+---
+
+.. kernel-doc:: include/uapi/drm/nouveau_drm.h
diff --git a/include/uapi/drm/nouveau_drm.h 
b/include/uapi/drm/nouveau_drm.h

index 853a327433d3..f6e7d40201d4 100644
--- a/include/uapi/drm/nouveau_drm.h
+++ b/include/uapi/drm/nouveau_drm.h
@@ -126,6 +126,216 @@ struct drm_nouveau_gem_cpu_fini {
  __u32 handle;
  };
  +/**
+ * struct drm_nouveau_sync - sync object
+ *
+ * This structure serves as synchronization mechanism for 
(potentially)

+ * asynchronous operations such as EXEC or VM_BIND.
+ */
+struct drm_nouveau_sync {
+    /**
+ * @flags: the flags for a sync object
+ *
+ * The first 8 bits are used to determine the type of the sync 
object.

+ */
+    __u32 flags;
+#define DRM_NOUVEAU_SYNC_SYNCOBJ 0x0
+#define DRM_NOUVEAU_SYNC_TIMELINE_SYNCOBJ 0x1
+#define DRM_NOUVEAU_SYNC_TYPE_MASK 0xf
+    /**
+ * @handle: the handle of the sync object
+ */
+    __u32 handle;
+    /**
+ * @timeline_value:
+ *
+ * The timeline point of the sync object in case the syncobj is of
+ * type DRM_NOUVEAU_SYNC_TIMELINE_SYNCOBJ.
+ */
+    __u64 timeline_value;
+};
+
+/**
+ * struct drm_nouveau_vm_init - GPU VA space init structure
+ *
+ * Used to initialize the GPU's VA space for a user client, telling 
the kernel
+ * which portion of the VA space is managed by the UMD and kernel 
respectively.

+ */
+struct drm_nouveau_vm_init {
+    /**
+ * @unmanaged_addr: start address of the kernel managed VA 
space region

+ */
+    __u64 unmanaged_addr;
+    /**
+ * @unmanaged_size: size of the kernel managed VA space region 
in bytes

+ */
+    __u64 unmanaged_size;
+};
+
+/**
+ * struct drm_nouveau_vm_bind_op - VM_BIND operation
+ *
+ * This structure represents a single VM_BIND operation. UMDs 
should pass
+ * an array of this structure via struct drm_nouveau_vm_bind's 
_ptr field.

+ */
+struct drm_nouveau_vm_bind_op {
+    /**
+ * @op: the operation type
+ */
+    __u32 op;
+/**
+ * @DRM_NOUVEAU_VM_BIND_OP_ALLOC:
+ *
+ * The alloc operation is used to reserve a VA space region within 
the GPU's VA
+ * space. Optionally, the _NOUVEAU_VM_BIND_SPARSE flag can be 
passed to

+ * instruct the kernel to create sparse mappings for the given region.
+ */
+#define DRM_NOUVEAU_VM_BIND_OP_ALLOC 0x0


Do you really need this operation? We have no concept of this in Xe,
e.g. we can create a VM and the entire address space is managed exactly
the same.


The idea for alloc/free is to let UMDs allocate a portion of the VA 
space (which I call a region), basically the same thing Vulkan 
represents with a VKBuffer.


If that's mangled into the same component/interface then I can say from 
experience that this is a pretty bad idea. We have tried something 
similar with radeon and it turned out horrible.


What was the exact constellation in radeon and which problems did arise 
from it?




What you want is one component for tracking the VA allocations (drm_mm 
based) and a different component/interface for tracking the VA mappings 
(probably rb tree based).


That's what the GPUVA manager is doing. There are gpuva_regions which 
correspond to VA allocations and gpuvas which represent the mappings. 
Both are tracked separately (currently both with a separate drm_mm, 
though). However, the GPUVA manager needs to take regions into account 
when dealing with mappings to make sure the GPUVA manager doesn't 
propose drivers to merge over region boundaries. Speaking from userspace 
PoV, the kernel wouldn't 

Re: [Intel-gfx] [PATCH] drm/i915: Avoid potential vm use-after-free

[Matthew Auld]

On Mon, 23 Jan 2023 at 16:57, Tvrtko Ursulin
 wrote:
>
>
> + some more people based on e1a7ab4fca0c
>
> On 19/01/2023 17:32, Rob Clark wrote:
> > From: Rob Clark 
> >
> > Adding the vm to the vm_xa table makes it visible to userspace, which
> > could try to race with us to close the vm.  So we need to take our extra
> > reference before putting it in the table.
> >
> > Signed-off-by: Rob Clark 
> > ---
> > Note, you could list commit e1a7ab4fca0c ("drm/i915: Remove the vm open
> > count") as the "fixed" commit, but really the issue seems to go back
> > much further (with the fix needing some backporting in the process).
>
> It would probably be rather essential to identify the correct Fixes: tag.
>
> Since Thomas, Matt and Niranjana you were directly involved in the patch
> which changed significantly how this works, perhaps there is something
> still somewhat easily retrievable from your memory lanes to help with this?

Sorry for the delay. Fix looks good to me,
Reviewed-by: Matthew Auld 

Looking at the git history, the fixes tag I think needs to be:

Fixes: 9ec8795e7d91 ("drm/i915: Drop __rcu from gem_context->vm")
Cc:  # v5.16+

>
> Regards,
>
> Tvrtko
>
> >
> >   drivers/gpu/drm/i915/gem/i915_gem_context.c | 14 +++---
> >   1 file changed, 11 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index 6250de9b9196..e4b78ab4773b 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -1861,11 +1861,19 @@ static int get_ppgtt(struct drm_i915_file_private 
> > *file_priv,
> >   vm = ctx->vm;
> >   GEM_BUG_ON(!vm);
> >
> > + /*
> > +  * Get a reference for the allocated handle.  Once the handle is
> > +  * visible in the vm_xa table, userspace could try to close it
> > +  * from under our feet, so we need to hold the extra reference
> > +  * first.
> > +  */
> > + i915_vm_get(vm);
> > +
> >   err = xa_alloc(_priv->vm_xa, , vm, xa_limit_32b, GFP_KERNEL);
> > - if (err)
> > + if (err) {
> > + i915_vm_put(vm);
> >   return err;
> > -
> > - i915_vm_get(vm);
> > + }
> >
> >   GEM_BUG_ON(id == 0); /* reserved for invalid/unassigned ppgtt */
> >   args->value = id;

Re: [RFC 10/12] cgroup/drm: Introduce weight based drm cgroup control

[Michal Koutný]

On Thu, Jan 12, 2023 at 04:56:07PM +, Tvrtko Ursulin 
 wrote:
> +static int drmcs_can_attach(struct cgroup_taskset *tset)
> +{
> + int ret;
> +
> + /*
> +  * As processes are getting moved between groups we need to ensure
> +  * both that the old group does not see a sudden downward jump in the
> +  * GPU utilisation, and that the new group does not see a sudden jump
> +  * up with all the GPU time clients belonging to the migrated process
> +  * have accumulated.
> +  *
> +  * To achieve that we suspend the scanner until the migration is
> +  * completed where the resume at the end ensures both groups start
> +  * observing GPU utilisation from a reset state.
> +  */
> +
> + ret = mutex_lock_interruptible(_mutex);
> + if (ret)
> + return ret;
> + start_suspend_scanning();
> + mutex_unlock(_mutex);
> +
> + finish_suspend_scanning();

Here's scanning suspension, communicated via 

root_drmcs.scanning_suspended = true;
root_drmcs.suspended_period_us = root_drmcs.period_us;
root_drmcs.period_us = 0;

but I don't see those used in scan_worker() and the scanning traversal
can apparently run concurrently with a task migration.

> [...]
> +static bool
> +__start_scanning(struct drm_cgroup_state *root, unsigned int period_us)
> [...]
> + css_for_each_descendant_post(node, >css) {
> [...]
> + active = drmcs_get_active_time_us(drmcs);
> + if (period_us && active > drmcs->prev_active_us)
> + drmcs->active_us += active - drmcs->prev_active_us;
> + drmcs->prev_active_us = active;

drmcs_get_active_time_us() could count a task's contribution here,
the task would migrate to a different drmcs,
and it'd be counted 2nd time.




signature.asc
Description: Digital signature

Re: [RFC v3 00/12] DRM scheduling cgroup controller

[Michal Koutný]

On Fri, Jan 27, 2023 at 11:40:58AM +, Tvrtko Ursulin 
 wrote:
> The main point is, should someone prove me wrong and come up a smarter way
> at some point in the future, then "drm.weight" as an ABI remains compatible
> and the improvement can happen completely under the hood. In the mean time
> users get external control, and _some_ ability to improve the user
> experience with the scenarios such as I described yesterday.

I'm on board now.

(I've done a mental switch of likening this rather to existing IO
control (higher variance of quanta size, worse preemption, limited
effect) than CPU control.)


> Cgroup tree hierarchy modifications being the reason for not converging can
> also happen, but I thought I can hand wave that as not a realistic scenario.
> Perhaps I am not imaginative enough?

My suggestion: simply skip offlined drmcgs instead of restarting whole
iteration. (A respawning cgroup-wrapped job or intentionally adverse
respawner could in my imagination cause that.)

> Under or over-accounting for migrating tasks I don't think can happen since
> I am explicitly handling that.

I'll reply to the patch for better context...

Regards,
Michal


signature.asc
Description: Digital signature

Re: [PATCH v2 01/16] of: device: make of_device_uevent_modalias() take a const device *

[Greg Kroah-Hartman]

On Wed, Jan 11, 2023 at 08:54:04AM -0600, Rob Herring wrote:
> On Wed, Jan 11, 2023 at 5:30 AM Greg Kroah-Hartman
>  wrote:
> >
> > of_device_uevent_modalias() does not modify the device pointer passed to
> > it, so mark it constant.  In order to properly do this, a number of
> > busses need to have a modalias function added as they were attempting to
> > just point to of_device_uevent_modalias instead of their bus-specific
> > modalias function.  This is fine except if the prototype for a bus and
> > device type modalias function diverges and then problems could happen.  To
> > prevent all of that, just wrap the call to of_device_uevent_modalias()
> > directly for each bus and device type individually.
> 
> Why not just put the wrapper function in the DT code instead of making
> 4 copies of it?

Ok, I looked at doing this today, but in the end, making "4" copies of
this is simpler overall.  To do it your way would require a "const"
version of the function be added to the core, and then convert these 4
busses to use that, and then when the real function is converted to be
const, move all of these functions back over to use that again.

Lots of churn, and then in the end, we still have the mismatch of a
the same function callback being used in two different types of
callbacks (one a bus, one a class).  This way we separate them to make
things much more obvious and self-contained.

So I'll keep this as-is for now, thanks.

greg k-h

Re: [PATCH v12 00/18] drm: Add Samsung MIPI DSIM bridge

[Marek Vasut]

On 1/27/23 12:04, Jagan Teki wrote:

On Fri, Jan 27, 2023 at 4:26 PM Rasmus Villemoes
 wrote:


On 27/01/2023 11.39, Jagan Teki wrote:

On Fri, Jan 27, 2023 at 4:03 PM Rasmus Villemoes
 wrote:


Hi Jagan and others

I'm trying to test this series on our imx8mp-based boards, which has the
mipi-dsi connected to a ti,sn65dsi86 bridge (in turn connected to a
full-size DP-connector). But I don't know how to add the proper nodes to
imx8mp.dtsi. My current, obviously incomplete, attempt is


Please use this repo - https://github.com/openedev/kernel/tree/imx8mm-dsi-v12


Thanks, but that's exactly what I'm doing, and I don't see any
modification of imx8mp.dtsi in that branch. I'm basically looking for
help to do the equivalent of

   88775338cd58 - arm64: dts: imx8mm: Add MIPI DSI pipeline
   f964f67dd6ee - arm64: dts: imx8mm: Add eLCDIF node support

for imx8mp in order to test those patches on our boards (we have two
variants).


Marek, any help here, thanks.


Try attached patch.From f7e85ef14c52e84e495ab85fd07263e5b909bf7f Mon Sep 17 00:00:00 2001
From: Marek Vasut 
Date: Sun, 27 Feb 2022 02:20:05 +0100
Subject: [PATCH] arm64: dts: imx8mp: Add display pipeline components
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Add DSIM, DSIM PHY, LCDIF1 and mediamix blk_ctl nodes for iMX8MP.
The blk_ctl is required to enable LCDIF clock and DSIM clock, and
handle DSIM resets.

Upstream-Status: Pending
Signed-off-by: Marek Vasut 
Cc: Abel Vesa 
Cc: Dong Aisheng 
Cc: Fabio Estevam 
Cc: Guido Günther 
Cc: Lucas Stach 
Cc: NXP Linux Team 
Cc: Rob Herring 
Cc: Shawn Guo 
---
 arch/arm64/boot/dts/freescale/imx8mp.dtsi | 144 +-
 1 file changed, 139 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index bb916a0948a8f..aef39d62b47d7 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -533,6 +533,7 @@ pgc {
 	pgc_mipi_phy1: power-domain@0 {
 		#power-domain-cells = <0>;
 		reg = ;
+		power-domains = <_mediamix>;
 	};
 
 	pgc_pcie_phy: power-domain@1 {
@@ -587,6 +588,7 @@ pgc_mediamix: power-domain@10 {
 	pgc_mipi_phy2: power-domain@16 {
 		#power-domain-cells = <0>;
 		reg = ;
+		power-domains = <_mediamix>;
 	};
 
 	pgc_hsiomix: power-domains@17 {
@@ -1082,7 +1084,7 @@ aips4: bus@32c0 {
 
 			media_blk_ctrl: blk-ctrl@32ec {
 compatible = "fsl,imx8mp-media-blk-ctrl",
-	 "syscon";
+	 "simple-bus", "syscon";
 reg = <0x32ec 0x1>;
 power-domains = <_mediamix>,
 		<_mipi_phy1>,
@@ -1120,14 +1122,146 @@ media_blk_ctrl: blk-ctrl@32ec {
 	 < IMX8MP_CLK_MEDIA_MIPI_PHY1_REF_ROOT>;
 clock-names = "apb", "axi", "cam1", "cam2",
 	  "disp1", "disp2", "isp", "phy";
+assigned-clocks = < IMX8MP_CLK_MEDIA_DISP1_PIX>,
+		  < IMX8MP_CLK_MEDIA_DISP2_PIX>,
+		  < IMX8MP_VIDEO_PLL1_OUT>;
+assigned-clock-parents = < IMX8MP_VIDEO_PLL1_OUT>,
+			 < IMX8MP_VIDEO_PLL1_OUT>;
+assigned-clock-rates = <0>, <0>, <59400>;
+
+#power-domain-cells = <1>;
 
-assigned-clocks = < IMX8MP_CLK_MEDIA_AXI>,
+lvds_ldb: lvds-ldb {
+	#address-cells = <0>;
+	#size-cells = <0>;
+	compatible = "fsl,imx8mp-ldb";
+	clocks = < IMX8MP_CLK_MEDIA_LDB>;
+	clock-names = "ldb";
+	assigned-clocks = < IMX8MP_CLK_MEDIA_LDB>;
+	assigned-clock-parents = < IMX8MP_VIDEO_PLL1_OUT>;
+
+	ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		port@0 {
+			reg = <0>;
+
+			ldb_from_lcdif2: endpoint {
+remote-endpoint = <_to_ldb>;
+			};
+		};
+
+		/* LVDS single-link or dual-link */
+		port@1 {
+			reg = <1>;
+
+			ldb_lvds_ch0: endpoint {
+			};
+		};
+
+		port@2 {
+			reg = <2>;
+
+			ldb_lvds_ch1: endpoint {
+			};
+		};
+	};
+};
+			};
+
+			mipi_dsi: mipi_dsi@32e6 {
+#address-cells = <0>;
+#size-cells = <0>;
+compatible = "fsl,imx8mp-mipi-dsim";
+reg = <0x32e6 0x400>;
+clocks = < IMX8MP_CLK_MEDIA_APB>,
+	 < IMX8MP_CLK_MEDIA_MIPI_PHY1_REF>;
+clock-names = "bus_clk", "sclk_mipi";
+assigned-clocks = < IMX8MP_CLK_MEDIA_APB>,
+		  < IMX8MP_CLK_MEDIA_MIPI_PHY1_REF>;
+assigned-clock-parents = < IMX8MP_SYS_PLL1_266M>,
+			 < IMX8MP_CLK_24M>;
+assigned-clock-rates = <26600>, <2400>;
+samsung,pll-clock-frequency = <2400>;
+interrupts = ;
+power-domains = <_blk_ctrl IMX8MP_MEDIABLK_PD_MIPI_DSI_1>;
+status = "disabled";
+ports {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	port@0 {
+		reg = <0>;
+
+		dsim_from_lcdif1: endpoint {
+			remote-endpoint = <_to_dsim>;
+		};
+	};
+};
+			};
+
+			lcdif1: display-controller@32e8 {
+#address-cells = <0>;
+#size-cells = <0>;
+compatible = 

Re: [PATCH] drm/nouveau/mmu: fix Use after Free bug in nvkm_vmm_node_split

[Takashi Iwai]

On Tue, 03 Jan 2023 15:07:55 +0100,
Takashi Iwai wrote:
> 
> On Fri, 30 Dec 2022 08:27:58 +0100,
> Zheng Wang wrote:
> > 
> > Here is a function call chain.
> > nvkm_vmm_pfn_map->nvkm_vmm_pfn_split_merge->nvkm_vmm_node_split
> > If nvkm_vma_tail return NULL in nvkm_vmm_node_split, it will
> > finally invoke nvkm_vmm_node_merge->nvkm_vmm_node_delete, which
> > will free the vma. However, nvkm_vmm_pfn_map didn't notice that.
> > It goes into next label and UAF happens.
> > 
> > Fix it by returning the return-value of nvkm_vmm_node_merge
> > instead of NULL.
> > 
> > Signed-off-by: Zheng Wang 
> 
> FWIW, CVE-2023-0030 has been assigned to this bug.
> It's a question whether it really deserves as a security issue, but a
> bug is a bug...
> 
> Ben, could you review this please?

A gentle ping as reminder.  The bug is still present.


thanks,

Takashi

> 
> 
> thanks,
> 
> Takashi
> 
> > ---
> >  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c 
> > b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
> > index ae793f400ba1..84d6fc87b2e8 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
> > @@ -937,8 +937,8 @@ nvkm_vmm_node_split(struct nvkm_vmm *vmm,
> > if (vma->size != size) {
> > struct nvkm_vma *tmp;
> > if (!(tmp = nvkm_vma_tail(vma, vma->size - size))) {
> > -   nvkm_vmm_node_merge(vmm, prev, vma, NULL, vma->size);
> > -   return NULL;
> > +   tmp = nvkm_vmm_node_merge(vmm, prev, vma, NULL, 
> > vma->size);
> > +   return tmp;
> > }
> > tmp->part = true;
> > nvkm_vmm_node_insert(vmm, tmp);
> > -- 
> > 2.25.1
> > 

Re: [RFC v3 00/12] DRM scheduling cgroup controller

[Tvrtko Ursulin]

On 27/01/2023 10:04, Michal Koutný wrote:

On Thu, Jan 26, 2023 at 05:57:24PM +, Tvrtko Ursulin 
 wrote:

So even if the RFC shows just a simple i915 implementation, the controller
itself shouldn't prevent a smarter approach (via exposed ABI).


scan/query + over budget notification is IMO limited in guarantees.


It is yes, I tried to stress out that it is not a hard guarantee in any 
shape and form and that the "quality" of adhering to the allocated 
budget will depend on individual hw and sw capabilities.


But it is what I believe is the best approach given a) how different in 
scheduling capability GPU drivers are and b) the very fact there isn't a 
central scheduling entity as opposed to the CPU side of things.


It is just no possible to do a hard guarantee system. GPUs do not 
preempt as nicely and easily as the CPUs do. And the frequency of 
context switches varies widely from too fast to "never", so again, 
charging would have several problems to overcome which would make the 
whole setup IMHO pointless.


And not only that some GPUs do not preempt nicely, but some even can't 
do any of this, period. Even if we stay within the lineage of hardware 
supported by only i915, we have three distinct categories: 1) can't do 
any of this, 2a) can do fine grained priority based scheduling with 
reasonable preemption capability, 2b) ditto but without reasonable 
preemption capability, and 3) like 2a) and 2b) but with the scheduler in 
the firmware and currently supporting coarse priority based scheduling.


Shall I also mention that a single cgroup can contain multiple GPU 
clients, all using different GPUs with a different mix of the above 
listed challenges?


The main point is, should someone prove me wrong and come up a smarter 
way at some point in the future, then "drm.weight" as an ABI remains 
compatible and the improvement can happen completely under the hood. In 
the mean time users get external control, and _some_ ability to improve 
the user experience with the scenarios such as I described yesterday.



[...]
Yes agreed, and to re-stress out, the ABI as proposed does not preclude
changing from scanning to charging or whatever. The idea was for it to be
compatible in concept with the CPU controller and also avoid baking in the
controlling method to individual drivers.
[...]


But I submit to your point of rather not exposing this via cgroup API
for possible future refinements.


Ack.


Secondly, doing this in userspace would require the ability to get some sort
of an atomic snapshot of the whole tree hierarchy to account for changes in
layout of the tree and task migrations. Or some retry logic with some added
ABI fields to enable it.


Note, that the proposed implementation is succeptible to miscount due to
concurrent tree modifications and task migrations too (scanning may not
converge under frequent cgroup layout modifications, and migrating tasks
may be summed 0 or >1 times). While in-kernel implementation may assure
the snapshot view, it'd come at cost. (Read: since the mechanism isn't
precise anyway, I don't suggest a fully synchronized scanning.)


The part that scanning may not converge in my _current implementation_ 
is true. For instance if clients would be constantly coming and going, 
for that I took a shortcut of not bothering to accumulate usage on 
process/client exit, and I just wait for a stable two periods to look at 
the current state. I reckon this is possibly okay for the real world.


Cgroup tree hierarchy modifications being the reason for not converging 
can also happen, but I thought I can hand wave that as not a realistic 
scenario. Perhaps I am not imaginative enough?


Under or over-accounting for migrating tasks I don't think can happen 
since I am explicitly handling that.


Regards,

Tvrtko

Re: linux-6.2-rc4+ hangs on poweroff/reboot: Bisected

[Karol Herbst]

Where was the original email sent to anyway, because I don't have it at all.

Anyhow, I suspect we want to fetch logs to see what's happening, but
due to the nature of this bug it might get difficult.

I'm checking out the laptops I have here if I can reproduce this
issue, but I think all mine with Turing GPUs are fine.

Maybe Ben has any idea what might be wrong with
0e44c21708761977dcbea9b846b51a6fb684907a or if that's an issue which
is already fixed by not upstreamed patches as I think I remember Ben
to talk about something like that recently.

Karol

On Fri, Jan 27, 2023 at 12:20 PM Linux kernel regression tracking
(Thorsten Leemhuis)  wrote:
>
> Hi, this is your Linux kernel regression tracker. Top-posting for once,
> to make this easily accessible to everyone.
>
> @nouveau-maintainers, did anyone take a look at this? The report is
> already 8 days old and I don't see a single reply. Sure, we'll likely
> get a -rc8, but still it would be good to not fix this on the finish line.
>
> Chris, btw, did you try if you can revert the commit on top of latest
> mainline? And if so, does it fix the problem?
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
>
> #regzbot poke
>
> On 19.01.23 15:33, Linux kernel regression tracking (Thorsten Leemhuis)
> wrote:
> > [adding various lists and the two other nouveau maintainers to the list
> > of recipients]
>
> > On 18.01.23 21:59, Chris Clayton wrote:
> >> Hi.
> >>
> >> I build and installed the lastest development kernel earlier this week. 
> >> I've found that when I try the laptop down (or
> >> reboot it), it hangs right at the end of closing the current session. The 
> >> last line I see on  the screen when rebooting is:
> >>
> >>  sd 4:0:0:0: [sda] Synchronising SCSI cache
> >>
> >> when closing down I see one additional line:
> >>
> >>  sd 4:0:0:0 [sda]Stopping disk
> >>
> >> In both cases the machine then hangs and I have to hold down the power 
> >> button fot a few seconds to switch it off.
> >>
> >> Linux 6.1 is OK but 6.2-rc1 hangs, so I bisected between this two and 
> >> landed on:
> >>
> >>  # first bad commit: [0e44c21708761977dcbea9b846b51a6fb684907a] 
> >> drm/nouveau/flcn: new code to load+boot simple HS FWs
> >> (VPR scrubber)
> >>
> >> I built and installed a kernel with 
> >> f15cde64b66161bfa74fb58f4e5697d8265b802e (the parent of the bad commit) 
> >> checked out
> >> and that shuts down and reboots fine. It the did the same with the bad 
> >> commit checked out and that does indeed hang, so
> >> I'm confident the bisect outcome is OK.
> >>
> >> Kernels 6.1.6 and 5.15.88 are also OK.
> >>
> >> My system had dual GPUs - one intel and one NVidia. Related extracts from 
> >> 'lscpi -v' is:
> >>
> >> 00:02.0 VGA compatible controller: Intel Corporation CometLake-H GT2 [UHD 
> >> Graphics] (rev 05) (prog-if 00 [VGA controller])
> >> Subsystem: CLEVO/KAPOK Computer CometLake-H GT2 [UHD Graphics]
> >>
> >> Flags: bus master, fast devsel, latency 0, IRQ 142
> >>
> >> Memory at c200 (64-bit, non-prefetchable) [size=16M]
> >>
> >> Memory at a000 (64-bit, prefetchable) [size=256M]
> >>
> >> I/O ports at 5000 [size=64]
> >>
> >> Expansion ROM at 000c [virtual] [disabled] [size=128K]
> >>
> >> Capabilities: [40] Vendor Specific Information: Len=0c 
> >>
> >> Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
> >>
> >> Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit-
> >>
> >> Capabilities: [d0] Power Management version 2
> >>
> >> Kernel driver in use: i915
> >>
> >> Kernel modules: i915
> >>
> >>
> >> 01:00.0 VGA compatible controller: NVIDIA Corporation TU117M [GeForce GTX 
> >> 1650 Ti Mobile] (rev a1) (prog-if 00 [VGA
> >> controller])
> >> Subsystem: CLEVO/KAPOK Computer TU117M [GeForce GTX 1650 Ti Mobile]
> >> Flags: bus master, fast devsel, latency 0, IRQ 141
> >> Memory at c400 (32-bit, non-prefetchable) [size=16M]
> >> Memory at b000 (64-bit, prefetchable) [size=256M]
> >> Memory at c000 (64-bit, prefetchable) [size=32M]
> >> I/O ports at 4000 [size=128]
> >> Expansion ROM at c300 [disabled] [size=512K]
> >> Capabilities: [60] Power Management version 3
> >> Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
> >> Capabilities: [78] Express Legacy Endpoint, MSI 00
> >> Kernel driver in use: nouveau
> >> Kernel modules: nouveau
> >>
> >> DRI_PRIME=1 is exported in one of my init scripts (yes, I am still using 
> >> sysvinit).
> >>
> >> I've attached the bisect.log, but please let me know if I can provide any 
> >> other diagnostics. Please cc me as I'm not
> >> 

Re: [PATCH 3/3] drm/msm/disp/dpu1: reserve the resources on topology change

[Dmitry Baryshkov]

On Fri, 27 Jan 2023 at 12:15, Kalyan Thota  wrote:
>
> Some features like ctm can be enabled dynamically. Release and reserve
> the dpu resources whenever a topology change occurs such that
> required hw blocks are allocated appropriately.
>
> Signed-off-by: Kalyan Thota 
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h|  1 +
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 41 
> ++---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h |  4 ++-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c |  2 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c  |  4 ---
>  5 files changed, 42 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> index 539b68b..89afe04 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> @@ -225,6 +225,7 @@ struct dpu_crtc_state {
>
> enum dpu_crtc_crc_source crc_source;
> int crc_frame_skip_count;
> +   struct msm_display_topology topology;
>  };
>
>  #define to_dpu_crtc_state(x) \
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 8d76cb3..db417f5 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -217,6 +217,18 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
> 15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
>  };
>
> +static void dpu_encoder_virt_atomic_mode_set(struct drm_encoder *drm_enc,
> +struct drm_crtc_state 
> *crtc_state,
> +struct drm_connector_state 
> *conn_state);
> +
> +static bool _dpu_enc_is_topology_changed(struct drm_crtc_state *crtc_state,
> +   struct msm_display_topology topology)
> +{
> +   struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc_state);
> +
> +   return !!memcmp(>topology,
> +   , sizeof(struct msm_display_topology));
> +}
>
>  bool dpu_encoder_is_widebus_enabled(const struct drm_encoder *drm_enc)
>  {
> @@ -650,12 +662,16 @@ static int dpu_encoder_virt_atomic_check(
>  * Release and Allocate resources on every modeset
>  * Dont allocate when active is false.
>  */
> -   if (drm_atomic_crtc_needs_modeset(crtc_state)) {
> +   if (drm_atomic_crtc_needs_modeset(crtc_state) ||
> +   _dpu_enc_is_topology_changed(crtc_state, topology)) {
> dpu_rm_release(global_state, drm_enc);
>
> -   if (!crtc_state->active_changed || crtc_state->active)
> +   if (crtc_state->enable) {
> ret = dpu_rm_reserve(_kms->rm, 
> global_state,
> drm_enc, crtc_state, 
> topology);
> +   if (!ret)
> +   dpu_enc->topology = topology;
> +   }
> }
> }
>
> @@ -1089,7 +1105,7 @@ static void dpu_encoder_virt_atomic_mode_set(struct 
> drm_encoder *drm_enc,
> }
>
> cstate->num_mixers = num_lm;
> -
> +   cstate->topology = dpu_enc->topology;

There is one part of the story that I do not quite like here. The crtc
state now gets the encoder-level information (regarding the num_intf,
num_enc, etc).
Just to clarify, I find it particularly bad that we have to actively
poke into the crtc state from the dpu_encoder.c. I hope to get to it
at some point, most probably while reworking the encoder code to
support  using a single CTL for all the operations.

> dpu_enc->connector = conn_state->connector;
>
> for (i = 0; i < dpu_enc->num_phys_encs; i++) {
> @@ -2076,11 +2092,14 @@ void dpu_encoder_helper_phys_cleanup(struct 
> dpu_encoder_phys *phys_enc)
> ctl->ops.clear_pending_flush(ctl);
>  }
>
> -void dpu_encoder_prepare_commit(struct drm_encoder *drm_enc)
> +void dpu_encoder_prepare_commit(struct drm_encoder *drm_enc,
> +   struct drm_crtc_state *crtc_state)
>  {
> struct dpu_encoder_virt *dpu_enc;
> struct dpu_encoder_phys *phys;
> int i;
> +   struct list_head *connector_list;
> +   struct drm_connector *conn = NULL, *conn_iter;
>
> if (!drm_enc) {
> DPU_ERROR("invalid encoder\n");
> @@ -2088,6 +2107,20 @@ void dpu_encoder_prepare_commit(struct drm_encoder 
> *drm_enc)
> }
> dpu_enc = to_dpu_encoder_virt(drm_enc);
>
> +   connector_list = _enc->dev->mode_config.connector_list;
> +   list_for_each_entry(conn_iter, connector_list, head)
> +   if (conn_iter->state->best_encoder == drm_enc)
> +   conn = conn_iter;

I don't think we can poke at conn_iter->state here.

> +
> +   /*
> +* In case of modeset, DRM kernel will trigger a atomic_mode_set
> +* call