Re: [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

[Marek Olšák]

We already don't have accurate BO fences in some cases. Instead, BOs can
have fences which are equal to the last seen command buffer for each queue.
It's practically the same as if the kernel had no visibility into command
submissions and just added a fence into all queues when it needed to wait
for idle. That's already one alternative to BO fences that would work
today. The only BOs that need accurate BO fences are shared buffers, and
those use cases can be converted to explicit fences.

Removing memory management from all command buffer submission logic would
be one of the benefits that is quite appealing.

You don't need to depend on apps for budgeting and placement determination.
You can sort buffers according to driver usage, e.g. scratch/spill buffers,
shader IO rings, MSAA images, other images, and buffers. Alternatively, you
can have just internal buffers vs app buffers. Then you assign VRAM from
left to right until you reach the quota. This is optional, so this part can
be ignored.

>> - A GPU hang signals all fences. Other deadlocks will be handled like
GPU hangs.
>
>What do you mean by "all"?  All fences that were supposed to be
>signaled by the hung context?

Yes, that's one of the possibilities. Any GPU hang followed by a GPU reset
can clear VRAM, so all processes should recreate their contexts and
reinitialize resources. A deadlock caused by userspace could be handled
similarly.

I don't know how timeline fences would work across processes and how
resilient they would be to segfaults.

Marek

On Mon, Apr 19, 2021 at 11:48 AM Jason Ekstrand 
wrote:

> Not going to comment on everything on the first pass...
>
> On Mon, Apr 19, 2021 at 5:48 AM Marek Olšák  wrote:
> >
> > Hi,
> >
> > This is our initial proposal for explicit fences everywhere and new
> memory management that doesn't use BO fences. It's a redesign of how Linux
> graphics drivers work, and it can coexist with what we have now.
> >
> >
> > 1. Introduction
> > (skip this if you are already sold on explicit fences)
> >
> > The current Linux graphics architecture was initially designed for GPUs
> with only one graphics queue where everything was executed in the
> submission order and per-BO fences were used for memory management and
> CPU-GPU synchronization, not GPU-GPU synchronization. Later, multiple
> queues were added on top, which required the introduction of implicit
> GPU-GPU synchronization between queues of different processes using per-BO
> fences. Recently, even parallel execution within one queue was enabled
> where a command buffer starts draws and compute shaders, but doesn't wait
> for them, enabling parallelism between back-to-back command buffers.
> Modesetting also uses per-BO fences for scheduling flips. Our GPU scheduler
> was created to enable all those use cases, and it's the only reason why the
> scheduler exists.
> >
> > The GPU scheduler, implicit synchronization, BO-fence-based memory
> management, and the tracking of per-BO fences increase CPU overhead and
> latency, and reduce parallelism. There is a desire to replace all of them
> with something much simpler. Below is how we could do it.
> >
> >
> > 2. Explicit synchronization for window systems and modesetting
> >
> > The producer is an application and the consumer is a compositor or a
> modesetting driver.
> >
> > 2.1. The Present request
> >
> > As part of the Present request, the producer will pass 2 fences (sync
> objects) to the consumer alongside the presented DMABUF BO:
> > - The submit fence: Initially unsignalled, it will be signalled when the
> producer has finished drawing into the presented buffer.
> > - The return fence: Initially unsignalled, it will be signalled when the
> consumer has finished using the presented buffer.
>
> I'm not sure syncobj is what we want.  In the Intel world we're trying
> to go even further to something we're calling "userspace fences" which
> are a timeline implemented as a single 64-bit value in some
> CPU-mappable BO.  The client writes a higher value into the BO to
> signal the timeline.  The kernel then provides some helpers for
> waiting on them reliably and without spinning.  I don't expect
> everyone to support these right away but, If we're going to re-plumb
> userspace for explicit synchronization, I'd like to make sure we take
> this into account so we only have to do it once.
>
>
> > Deadlock mitigation to recover from segfaults:
> > - The kernel knows which process is obliged to signal which fence. This
> information is part of the Present request and supplied by userspace.
>
> This isn't clear to me.  Yes, if we're using anything dma-fence based
> like syncobj, this is true.  But it doesn't seem totally true as a
> general statement.
>
>
> > - If the producer crashes, the kernel signals the submit fence, so that
> the consumer can make forward progress.
> > - If the consumer crashes, the kernel signals the return fence, so that
> the producer can reclaim the buffer.
> > - A GPU hang signals all 

[Bug 212729] New: amdgpu: WARN_ON drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:119 set_reg_field_values.constprop.0+0xbe/0xe0

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=212729

Bug ID: 212729
   Summary: amdgpu: WARN_ON
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:1
19 set_reg_field_values.constprop.0+0xbe/0xe0
   Product: Drivers
   Version: 2.5
Kernel Version: 5.11.14-200.fc33.x86_64
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: b...@kernel.crashing.org
Regression: No

Created attachment 296437
  --> https://bugzilla.kernel.org/attachment.cgi?id=296437=edit
Full kernel log

On Fedora 33, I recently started getting these (I haven't had a chance to
bisect). Note the error that happens shortly before the WARN_ON as it might be
relevant.

This seem to go along with the screen occasionally not coming back from
blanking when the machine is left idle. Sometimes unplugging/replugging the DP
connector works, sometimes it doesn't. I *think* it's related but I'm not 100%
certain.

The GPU is a 6800XT.

[4.361992] [drm] Initialized amdgpu 3.40.0 20150101 for :0d:00.0 on
minor 0
[4.668196] [drm] REG_WAIT timeout 1us * 10 tries -
mpc2_assert_idle_mpcc line:480
[4.800700] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts:
(null). Quota mode: none.
[4.844273] [ cut here ]
[4.844274] WARNING: CPU: 7 PID: 504 at
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:119
set_reg_field_values.constprop.0+0xbe/0xe0 [amdgpu]
[4.844400] Modules linked in: amdgpu drm_ttm_helper ttm iommu_v2 gpu_sched
drm_kms_helper cec crct10dif_pclmul crc32_pclmul crc32c_intel drm
ghash_clmulni_intel igb ccp nvme r8169 nvme_core dca i2c_algo_bit wmi
pinctrl_amd fuse
[4.844410] CPU: 7 PID: 504 Comm: plymouthd Not tainted
5.11.14-200.fc33.x86_64 #1
[4.844412] Hardware name: System manufacturer System Product Name/ROG STRIX
X570-E GAMING, BIOS 3603 03/19/2021
[4.844413] RIP: 0010:set_reg_field_values.constprop.0+0xbe/0xe0 [amdgpu]
[4.844525] Code: 50 08 49 89 51 08 8b 08 48 8d 42 08 49 89 41 08 44 8b 02
48 8d 50 08 0f b6 c9 49 89 51 08 8b 00 45 85 c0 75 b5 0f 0b eb b1 c3 <0f> 0b e9
4d ff ff ff 49 8b 51 08 eb d1 49 8b 41 08 eb d6 66 66 2e
[4.844526] RSP: 0018:c0af00d377a0 EFLAGS: 00010246
[4.844528] RAX:  RBX: a078d4de RCX:

[4.844528] RDX:  RSI: 0001 RDI:
c0af00d377a8
[4.844529] RBP: c0af00d37820 R08: 0001 R09:
c0af00d377b0
[4.844530] R10:  R11: 39e8 R12:
0005
[4.844531] R13: a078d80e1740 R14: 3ae0 R15:
a078d9bc01e8
[4.844532] FS:  7fbf4f575f40() GS:a07fcebc()
knlGS:
[4.844533] CS:  0010 DS:  ES:  CR0: 80050033
[4.844534] CR2: 7fd50a00d000 CR3: 000110d6c000 CR4:
00350ee0
[4.844535] Call Trace:
[4.844537]  generic_reg_update_ex+0x5a/0x1c0 [amdgpu]
[4.844646]  ? dcn20_enable_plane+0x77/0x1e0 [amdgpu]
[4.844769]  dcn20_program_front_end_for_ctx+0x997/0xb20 [amdgpu]
[4.844888]  ? optc3_lock+0x9d/0xb0 [amdgpu]
[4.845004]  dc_commit_state+0x49a/0xa30 [amdgpu]
[4.845117]  ? drm_calc_timestamping_constants+0x195/0x1f0 [drm]
[4.845135]  amdgpu_dm_atomic_commit_tail+0x585/0x2600 [amdgpu]
[4.845253]  ? amdgpu_vm_bo_invalidate+0x83/0x1a0 [amdgpu]
[4.845345]  ? amdgpu_bo_move_notify+0x41/0xe0 [amdgpu]
[4.845434]  ? amdgpu_bo_move+0x2d1/0x6d0 [amdgpu]
[4.845522]  ? ttm_bo_handle_move_mem+0x90/0x180 [ttm]
[4.845526]  ? ttm_bo_validate+0x11b/0x150 [ttm]
[4.845529]  ? dm_plane_helper_prepare_fb+0x18c/0x220 [amdgpu]
[4.845644]  ? _cond_resched+0x16/0x40
[4.845647]  ? _cond_resched+0x16/0x40
[4.845648]  ? __wait_for_common+0x2b/0x140
[4.845650]  commit_tail+0x94/0x130 [drm_kms_helper]
[4.845661]  drm_atomic_helper_commit+0x113/0x140 [drm_kms_helper]
[4.845669]  drm_atomic_helper_set_config+0x70/0xb0 [drm_kms_helper]
[4.845678]  drm_mode_setcrtc+0x1d3/0x6f0 [drm]
[4.845695]  ? avc_has_extended_perms+0x18d/0x3e0
[4.845698]  ? drm_mode_getcrtc+0x180/0x180 [drm]
[4.845712]  drm_ioctl_kernel+0x86/0xd0 [drm]
[4.845730]  drm_ioctl+0x20f/0x3a0 [drm]
[4.845745]  ? drm_mode_getcrtc+0x180/0x180 [drm]
[4.845760]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[4.845848]  __x64_sys_ioctl+0x83/0xb0
[4.845850]  do_syscall_64+0x33/0x40
[4.845853]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[4.845855] RIP: 0033:0x7fbf4f8315db
[4.845856] Code: 89 d8 49 8d 3c 1c 48 f7 d8 49 39 c4 72 b5 e8 1c ff ff ff
85 c0 78 ba 4c 89 e0 5b 5d 41 5c c3 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 8b 0d 6d b8 0c 00 f7 d8 64 89 01 48
[ 

Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match

[Dominique MARTINET]

Arnd Bergmann wrote on Mon, Apr 19, 2021 at 02:16:36PM +0200:
> In some cases, you can use the device_link infrastructure to deal
> with dependencies between devices. Not sure if this would help
> in your case, but have a look at device_link_add() etc in drivers/base/core.c

I'll need to actually try to convince myself but if creating the link
forces driver registration then it should be workable.

> > In this particular case the problem is that since 7d981405d0fd ("soc:
> > imx8m: change to use platform driver") the soc probe tries to use the
> > nvmem driver for ocotp fuses for imx8m devices, which isn't ready yet.
> > So soc loading gets pushed back to the end of the list because it gets
> > defered and other drivers relying on soc_device_match get confused
> > because they wrongly think a device doesn't match a quirk when it
> > actually does.
> >
> > If there is a way to ensure the nvmem driver gets loaded before the soc,
> > that would also solve the problem nicely, and avoid the need to mess
> > with all the ~50 drivers which use it.
> >
> > Is there a way to control in what order drivers get loaded? Something in
> > the dtb perhaps?
> 
> For built-in drivers, load order depends on the initcall level and
> link order (how things are lined listed in the Makefile hierarchy).
> 
> For loadable modules, this is up to user space in the end.
> 
> Which of the drivers in this scenario are loadable modules?

All the drivers involved in my case are built-in (nvmem, soc and final
soc_device_match consumer e.g. caam_jr that crashes the kernel if soc is
not identified properly).

I frankly don't like the idea of moving nvmem/ above soc/ in
drivers/Makefile as a "solution" to this (especially as there is one
that seems to care about what soc they run on...), so I'll have a look
at links first, hopefully that will work out.


Thanks,
-- 
Dominique
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/msm/dsi: fix msm_dsi_phy_get_clk_provider return code

[abhinavk]

On 2021-04-11 17:01, Dmitry Baryshkov wrote:

msm_dsi_phy_get_clk_provider() always returns two provided clocks, so
return 0 instead of returning incorrect -EINVAL error code.

Fixes: 5d13459650b3 ("drm/msm/dsi: push provided clocks handling into
a generic code")
Signed-off-by: Dmitry Baryshkov 

Reviewed-by: Abhinav Kumar 

---
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index f0a2ddf96a4b..ff7f2ec42030 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -843,7 +843,7 @@ int msm_dsi_phy_get_clk_provider(struct msm_dsi_phy 
*phy,

if (pixel_clk_provider)
 		*pixel_clk_provider = 
phy->provided_clocks->hws[DSI_PIXEL_PLL_CLK]->clk;


-   return -EINVAL;
+   return 0;
 }

 void msm_dsi_phy_pll_save_state(struct msm_dsi_phy *phy)

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/msm/dsi: dsi_phy_28nm_8960: fix uninitialized variable access

[abhinavk]

On 2021-04-09 18:19, Dmitry Baryshkov wrote:

The parent_name initialization was lost in refactoring, restore it now.

Fixes: 5d13459650b3 ("drm/msm/dsi: push provided clocks handling into
a generic code")
Reported-by: kernel test robot 
Signed-off-by: Dmitry Baryshkov 

Reviewed-by: Abhinav Kumar 

---
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c
index 582b1428f971..86e40a0d41a3 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c
@@ -405,6 +405,10 @@ static int pll_28nm_register(struct dsi_pll_28nm
*pll_28nm, struct clk_hw **prov
if (!vco_name)
return -ENOMEM;

+   parent_name = devm_kzalloc(dev, 32, GFP_KERNEL);
+   if (!parent_name)
+   return -ENOMEM;
+
clk_name = devm_kzalloc(dev, 32, GFP_KERNEL);
if (!clk_name)
return -ENOMEM;

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 03/20] drm/dp: Move i2c init to drm_dp_aux_init, add __must_check and fini

[Ville Syrjälä]

On Mon, Apr 19, 2021 at 06:55:05PM -0400, Lyude Paul wrote:
> When moving around drm_dp_aux_register() calls, it turned out we
> accidentally managed to cause issues with the Tegra driver due to the fact
> the Tegra driver would attempt to retrieve a reference to the AUX channel's
> i2c adapter - which wouldn't be initialized until drm_dp_aux_register() is
> called.
> 
> This doesn't actually make a whole ton of sense, as it's not unexpected for
> a driver to need to be able to use an AUX adapter before it's been
> registered. Likewise-it's not unexpected for a driver to try using the i2c
> adapter for said AUX channel before it's been registered as well. In fact,
> the current documentation for drm_dp_aux_init() even seems to imply that
> drm_dp_aux_init() is supposed to be handling i2c adapter creation for this
> precise reason - not drm_dp_aux_register().
> 
> Since the i2c adapter doesn't need to be linked to the DRM device in any
> way, we can just fix this problem by moving i2c adapter creation out of
> drm_dp_aux_register() and into drm_dp_aux_init(). Additionally, since this
> means that drm_dp_aux_init() can fail we go ahead and add a __must_check
> attribute to it so that drivers don't ignore its return status on failures.
> And finally, we add a drm_dp_aux_fini() and hook it up in all DRM drivers
> across the kernel to take care of cleaning up the i2c adapter once it's no
> longer needed.
> 
> This should also fix the regressions noted in the Tegra driver.

The init vs. register split is intentional. Registering the thing
and allowing userspace access to it before the rest of the driver
is ready isn't particularly great. For a while now we've tried to
move towards an architecture where the driver is fully initialzied
before anything gets exposed to userspace.

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 20/20] drm/dp_mst: Convert drm_dp_mst_topology.c to drm_err()/drm_dbg*()

[Lyude Paul]

And finally, convert all of the code in drm_dp_mst_topology.c over to using
drm_err() and drm_dbg*(). Note that this refactor would have been a lot
more complicated to have tried writing a coccinelle script for, so this
whole thing was done by hand.

v2:
* Fix line-wrapping in drm_dp_mst_atomic_check_mstb_bw_limit()

Signed-off-by: Lyude Paul 
Cc: Robert Foss 
Reviewed-by: Robert Foss 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 368 +-
 1 file changed, 187 insertions(+), 181 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 9bac5bd050ab..5539a91b4031 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -286,7 +286,8 @@ static void drm_dp_encode_sideband_msg_hdr(struct 
drm_dp_sideband_msg_hdr *hdr,
*len = idx;
 }
 
-static bool drm_dp_decode_sideband_msg_hdr(struct drm_dp_sideband_msg_hdr *hdr,
+static bool drm_dp_decode_sideband_msg_hdr(const struct 
drm_dp_mst_topology_mgr *mgr,
+  struct drm_dp_sideband_msg_hdr *hdr,
   u8 *buf, int buflen, u8 *hdrlen)
 {
u8 crc4;
@@ -303,7 +304,7 @@ static bool drm_dp_decode_sideband_msg_hdr(struct 
drm_dp_sideband_msg_hdr *hdr,
crc4 = drm_dp_msg_header_crc4(buf, (len * 2) - 1);
 
if ((crc4 & 0xf) != (buf[len - 1] & 0xf)) {
-   DRM_DEBUG_KMS("crc4 mismatch 0x%x 0x%x\n", crc4, buf[len - 1]);
+   drm_dbg_kms(mgr->dev, "crc4 mismatch 0x%x 0x%x\n", crc4, 
buf[len - 1]);
return false;
}
 
@@ -789,7 +790,8 @@ static bool drm_dp_sideband_append_payload(struct 
drm_dp_sideband_msg_rx *msg,
return true;
 }
 
-static bool drm_dp_sideband_parse_link_address(struct drm_dp_sideband_msg_rx 
*raw,
+static bool drm_dp_sideband_parse_link_address(const struct 
drm_dp_mst_topology_mgr *mgr,
+  struct drm_dp_sideband_msg_rx 
*raw,
   struct 
drm_dp_sideband_msg_reply_body *repmsg)
 {
int idx = 1;
@@ -1014,7 +1016,8 @@ drm_dp_sideband_parse_query_stream_enc_status(
return true;
 }
 
-static bool drm_dp_sideband_parse_reply(struct drm_dp_sideband_msg_rx *raw,
+static bool drm_dp_sideband_parse_reply(const struct drm_dp_mst_topology_mgr 
*mgr,
+   struct drm_dp_sideband_msg_rx *raw,
struct drm_dp_sideband_msg_reply_body 
*msg)
 {
memset(msg, 0, sizeof(*msg));
@@ -1030,7 +1033,7 @@ static bool drm_dp_sideband_parse_reply(struct 
drm_dp_sideband_msg_rx *raw,
 
switch (msg->req_type) {
case DP_LINK_ADDRESS:
-   return drm_dp_sideband_parse_link_address(raw, msg);
+   return drm_dp_sideband_parse_link_address(mgr, raw, msg);
case DP_QUERY_PAYLOAD:
return drm_dp_sideband_parse_query_payload_ack(raw, msg);
case DP_REMOTE_DPCD_READ:
@@ -1053,14 +1056,16 @@ static bool drm_dp_sideband_parse_reply(struct 
drm_dp_sideband_msg_rx *raw,
case DP_QUERY_STREAM_ENC_STATUS:
return drm_dp_sideband_parse_query_stream_enc_status(raw, msg);
default:
-   DRM_ERROR("Got unknown reply 0x%02x (%s)\n", msg->req_type,
- drm_dp_mst_req_type_str(msg->req_type));
+   drm_err(mgr->dev, "Got unknown reply 0x%02x (%s)\n",
+   msg->req_type, drm_dp_mst_req_type_str(msg->req_type));
return false;
}
 }
 
-static bool drm_dp_sideband_parse_connection_status_notify(struct 
drm_dp_sideband_msg_rx *raw,
-  struct 
drm_dp_sideband_msg_req_body *msg)
+static bool
+drm_dp_sideband_parse_connection_status_notify(const struct 
drm_dp_mst_topology_mgr *mgr,
+  struct drm_dp_sideband_msg_rx 
*raw,
+  struct 
drm_dp_sideband_msg_req_body *msg)
 {
int idx = 1;
 
@@ -1082,12 +1087,14 @@ static bool 
drm_dp_sideband_parse_connection_status_notify(struct drm_dp_sideban
idx++;
return true;
 fail_len:
-   DRM_DEBUG_KMS("connection status reply parse length fail %d %d\n", idx, 
raw->curlen);
+   drm_dbg_kms(mgr->dev, "connection status reply parse length fail %d 
%d\n",
+   idx, raw->curlen);
return false;
 }
 
-static bool drm_dp_sideband_parse_resource_status_notify(struct 
drm_dp_sideband_msg_rx *raw,
-  struct 
drm_dp_sideband_msg_req_body *msg)
+static bool drm_dp_sideband_parse_resource_status_notify(const struct 
drm_dp_mst_topology_mgr *mgr,
+struct 
drm_dp_sideband_msg_rx *raw,
+struct 

[PATCH v3 19/20] drm/dp_dual_mode: Convert drm_dp_dual_mode_helper.c to using drm_err/drm_dbg_kms()

[Lyude Paul]

Next step in the conversion, move everything in drm_dp_dual_mode_helper.c
over to using drm_err() and drm_dbg_kms(). This was done using the
following cocci script:

  @@
  expression list expr;
  @@

  (
  - DRM_DEBUG_KMS(expr);
  + drm_dbg_kms(dev, expr);
  |
  - DRM_ERROR(expr);
  + drm_err(dev, expr);
  )

And correcting the indentation of the resulting code by hand.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/drm_dp_dual_mode_helper.c | 45 +++
 1 file changed, 21 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index dbf9b1fdec63..9faf49354cab 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
@@ -202,8 +203,8 @@ enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(const 
struct drm_device *dev,
 */
ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_HDMI_ID,
hdmi_id, sizeof(hdmi_id));
-   DRM_DEBUG_KMS("DP dual mode HDMI ID: %*pE (err %zd)\n",
- ret ? 0 : (int)sizeof(hdmi_id), hdmi_id, ret);
+   drm_dbg_kms(dev, "DP dual mode HDMI ID: %*pE (err %zd)\n",
+   ret ? 0 : (int)sizeof(hdmi_id), hdmi_id, ret);
if (ret)
return DRM_DP_DUAL_MODE_UNKNOWN;
 
@@ -221,8 +222,7 @@ enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(const 
struct drm_device *dev,
 */
ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_ADAPTOR_ID,
_id, sizeof(adaptor_id));
-   DRM_DEBUG_KMS("DP dual mode adaptor ID: %02x (err %zd)\n",
- adaptor_id, ret);
+   drm_dbg_kms(dev, "DP dual mode adaptor ID: %02x (err %zd)\n", 
adaptor_id, ret);
if (ret == 0) {
if (is_lspcon_adaptor(hdmi_id, adaptor_id))
return DRM_DP_DUAL_MODE_LSPCON;
@@ -238,8 +238,7 @@ enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(const 
struct drm_device *dev,
 * that we may have misdetected the type.
 */
if (!is_type1_adaptor(adaptor_id) && adaptor_id != hdmi_id[0])
-   DRM_ERROR("Unexpected DP dual mode adaptor ID %02x\n",
- adaptor_id);
+   drm_err(dev, "Unexpected DP dual mode adaptor ID 
%02x\n", adaptor_id);
 
}
 
@@ -286,7 +285,7 @@ int drm_dp_dual_mode_max_tmds_clock(const struct drm_device 
*dev, enum drm_dp_du
ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_MAX_TMDS_CLOCK,
_tmds_clock, sizeof(max_tmds_clock));
if (ret || max_tmds_clock == 0x00 || max_tmds_clock == 0xff) {
-   DRM_DEBUG_KMS("Failed to query max TMDS clock\n");
+   drm_dbg_kms(dev, "Failed to query max TMDS clock\n");
return 165000;
}
 
@@ -326,7 +325,7 @@ int drm_dp_dual_mode_get_tmds_output(const struct 
drm_device *dev,
ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_TMDS_OEN,
_oen, sizeof(tmds_oen));
if (ret) {
-   DRM_DEBUG_KMS("Failed to query state of TMDS output buffers\n");
+   drm_dbg_kms(dev, "Failed to query state of TMDS output 
buffers\n");
return ret;
}
 
@@ -372,18 +371,17 @@ int drm_dp_dual_mode_set_tmds_output(const struct 
drm_device *dev, enum drm_dp_d
ret = drm_dp_dual_mode_write(adapter, DP_DUAL_MODE_TMDS_OEN,
 _oen, sizeof(tmds_oen));
if (ret) {
-   DRM_DEBUG_KMS("Failed to %s TMDS output buffers (%d 
attempts)\n",
- enable ? "enable" : "disable",
- retry + 1);
+   drm_dbg_kms(dev, "Failed to %s TMDS output buffers (%d 
attempts)\n",
+   enable ? "enable" : "disable", retry + 1);
return ret;
}
 
ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_TMDS_OEN,
, sizeof(tmp));
if (ret) {
-   DRM_DEBUG_KMS("I2C read failed during TMDS output 
buffer %s (%d attempts)\n",
- enable ? "enabling" : "disabling",
- retry + 1);
+   drm_dbg_kms(dev,
+   "I2C read failed during TMDS output buffer 
%s (%d attempts)\n",
+   enable ? "enabling" : "disabling", retry + 
1);
return ret;
}
 
@@ -391,8 +389,8 @@ int drm_dp_dual_mode_set_tmds_output(const struct 
drm_device *dev, enum drm_dp_d
return 0;
}
 
-   

[PATCH v3 16/20] drm/dp_mst: Pass drm_dp_mst_topology_mgr to drm_dp_get_vc_payload_bw()

[Lyude Paul]

Since this is one of the few functions in drm_dp_mst_topology.c that
doesn't have any way of getting access to a drm_device, let's pass the
drm_dp_mst_topology_mgr down to this function so that it can use
drm_dbg_kms().

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/drm_dp_mst_topology.c   | 7 +--
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 ++-
 include/drm/drm_dp_mst_helper.h | 3 ++-
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 276f7f054d62..9bac5bd050ab 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3638,6 +3638,7 @@ static int drm_dp_send_up_ack_reply(struct 
drm_dp_mst_topology_mgr *mgr,
 
 /**
  * drm_dp_get_vc_payload_bw - get the VC payload BW for an MST link
+ * @mgr: The _dp_mst_topology_mgr to use
  * @link_rate: link rate in 10kbits/s units
  * @link_lane_count: lane count
  *
@@ -3646,7 +3647,8 @@ static int drm_dp_send_up_ack_reply(struct 
drm_dp_mst_topology_mgr *mgr,
  * convert the number of PBNs required for a given stream to the number of
  * timeslots this stream requires in each MTP.
  */
-int drm_dp_get_vc_payload_bw(int link_rate, int link_lane_count)
+int drm_dp_get_vc_payload_bw(const struct drm_dp_mst_topology_mgr *mgr,
+int link_rate, int link_lane_count)
 {
if (link_rate == 0 || link_lane_count == 0)
DRM_DEBUG_KMS("invalid link rate/lane count: (%d / %d)\n",
@@ -3711,7 +3713,8 @@ int drm_dp_mst_topology_mgr_set_mst(struct 
drm_dp_mst_topology_mgr *mgr, bool ms
goto out_unlock;
}
 
-   mgr->pbn_div = 
drm_dp_get_vc_payload_bw(drm_dp_bw_code_to_link_rate(mgr->dpcd[1]),
+   mgr->pbn_div = drm_dp_get_vc_payload_bw(mgr,
+   
drm_dp_bw_code_to_link_rate(mgr->dpcd[1]),
mgr->dpcd[2] & 
DP_MAX_LANE_COUNT_MASK);
if (mgr->pbn_div == 0) {
ret = -EINVAL;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 180f97cd74cb..eb04b3cefda2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -70,7 +70,8 @@ static int intel_dp_mst_compute_link_config(struct 
intel_encoder *encoder,
slots = drm_dp_atomic_find_vcpi_slots(state, _dp->mst_mgr,
  connector->port,
  crtc_state->pbn,
- 
drm_dp_get_vc_payload_bw(crtc_state->port_clock,
+ 
drm_dp_get_vc_payload_bw(_dp->mst_mgr,
+  
crtc_state->port_clock,
   
crtc_state->lane_count));
if (slots == -EDEADLK)
return slots;
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index bd1c39907b92..20dc705642bd 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -783,7 +783,8 @@ drm_dp_mst_detect_port(struct drm_connector *connector,
 
 struct edid *drm_dp_mst_get_edid(struct drm_connector *connector, struct 
drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port);
 
-int drm_dp_get_vc_payload_bw(int link_rate, int link_lane_count);
+int drm_dp_get_vc_payload_bw(const struct drm_dp_mst_topology_mgr *mgr,
+int link_rate, int link_lane_count);
 
 int drm_dp_calc_pbn_mode(int clock, int bpp, bool dsc);
 
-- 
2.30.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 18/20] drm/dp: Convert drm_dp_helper.c to using drm_err/drm_dbg_*()

[Lyude Paul]

Now that we've added a back-pointer to drm_device to drm_dp_aux, made
drm_dp_aux available to any functions in drm_dp_helper.c which need to
print to the kernel log, and ensured all of our logging uses a consistent
format, let's do the final step of the conversion and actually move
everything over to using drm_err() and drm_dbg_*().

This was done by using the following cocci script:

  @@
  expression list expr;
  @@

  (
  - DRM_DEBUG_KMS(expr);
  + drm_dbg_kms(aux->drm_dev, expr);
  |
  - DRM_DEBUG_DP(expr);
  + drm_dbg_dp(aux->drm_dev, expr);
  |
  - DRM_DEBUG_ATOMIC(expr);
  + drm_dbg_atomic(aux->drm_dev, expr);
  |
  - DRM_DEBUG_KMS_RATELIMITED(expr);
  + drm_dbg_kms_ratelimited(aux->drm_dev, expr);
  |
  - DRM_ERROR(expr);
  + drm_err(aux->drm_dev, expr);
  )

Followed by correcting the resulting line-wrapping in the results by hand.

v2:
* Fix indenting in drm_dp_dump_access

Signed-off-by: Lyude Paul 
Cc: Robert Foss 
Reviewed-by: Robert Foss 
---
 drivers/gpu/drm/drm_dp_helper.c | 121 
 1 file changed, 59 insertions(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 6dc1ccd4880b..75563987ab8c 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -139,8 +139,8 @@ void drm_dp_link_train_clock_recovery_delay(const struct 
drm_dp_aux *aux,
 DP_TRAINING_AUX_RD_MASK;
 
if (rd_interval > 4)
-   DRM_DEBUG_KMS("%s: AUX interval %lu, out of range (max 4)\n",
- aux->name, rd_interval);
+   drm_dbg_kms(aux->drm_dev, "%s: AUX interval %lu, out of range 
(max 4)\n",
+   aux->name, rd_interval);
 
if (rd_interval == 0 || dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
rd_interval = 100;
@@ -155,8 +155,8 @@ static void __drm_dp_link_train_channel_eq_delay(const 
struct drm_dp_aux *aux,
 unsigned long rd_interval)
 {
if (rd_interval > 4)
-   DRM_DEBUG_KMS("%s: AUX interval %lu, out of range (max 4)\n",
- aux->name, rd_interval);
+   drm_dbg_kms(aux->drm_dev, "%s: AUX interval %lu, out of range 
(max 4)\n",
+   aux->name, rd_interval);
 
if (rd_interval == 0)
rd_interval = 400;
@@ -220,11 +220,11 @@ drm_dp_dump_access(const struct drm_dp_aux *aux,
const char *arrow = request == DP_AUX_NATIVE_READ ? "->" : "<-";
 
if (ret > 0)
-   DRM_DEBUG_DP("%s: 0x%05x AUX %s (ret=%3d) %*ph\n",
-aux->name, offset, arrow, ret, min(ret, 20), 
buffer);
+   drm_dbg_dp(aux->drm_dev, "%s: 0x%05x AUX %s (ret=%3d) %*ph\n",
+  aux->name, offset, arrow, ret, min(ret, 20), buffer);
else
-   DRM_DEBUG_DP("%s: 0x%05x AUX %s (ret=%3d)\n",
-aux->name, offset, arrow, ret);
+   drm_dbg_dp(aux->drm_dev, "%s: 0x%05x AUX %s (ret=%3d)\n",
+  aux->name, offset, arrow, ret);
 }
 
 /**
@@ -287,8 +287,8 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
request,
err = ret;
}
 
-   DRM_DEBUG_KMS("%s: Too many retries, giving up. First error: %d\n",
- aux->name, err);
+   drm_dbg_kms(aux->drm_dev, "%s: Too many retries, giving up. First 
error: %d\n",
+   aux->name, err);
ret = err;
 
 unlock:
@@ -524,44 +524,44 @@ bool drm_dp_send_real_edid_checksum(struct drm_dp_aux 
*aux,
 
if (drm_dp_dpcd_read(aux, DP_DEVICE_SERVICE_IRQ_VECTOR,
 _test_req, 1) < 1) {
-   DRM_ERROR("%s: DPCD failed read at register 0x%x\n",
- aux->name, DP_DEVICE_SERVICE_IRQ_VECTOR);
+   drm_err(aux->drm_dev, "%s: DPCD failed read at register 0x%x\n",
+   aux->name, DP_DEVICE_SERVICE_IRQ_VECTOR);
return false;
}
auto_test_req &= DP_AUTOMATED_TEST_REQUEST;
 
if (drm_dp_dpcd_read(aux, DP_TEST_REQUEST, _edid_read, 1) < 1) {
-   DRM_ERROR("%s: DPCD failed read at register 0x%x\n",
- aux->name, DP_TEST_REQUEST);
+   drm_err(aux->drm_dev, "%s: DPCD failed read at register 0x%x\n",
+   aux->name, DP_TEST_REQUEST);
return false;
}
link_edid_read &= DP_TEST_LINK_EDID_READ;
 
if (!auto_test_req || !link_edid_read) {
-   DRM_DEBUG_KMS("%s: Source DUT does not support 
TEST_EDID_READ\n",
- aux->name);
+   drm_dbg_kms(aux->drm_dev, "%s: Source DUT does not support 
TEST_EDID_READ\n",
+   aux->name);
return false;
}
 
if (drm_dp_dpcd_write(aux, DP_DEVICE_SERVICE_IRQ_VECTOR,

[PATCH v3 17/20] drm/print: Handle potentially NULL drm_devices in drm_dbg_*

[Lyude Paul]

While this shouldn't really be something that happens all that often, since
we're going to be using the drm_dbg_* log helpers in DRM helpers it's
technically possible that a driver could use an AUX adapter before it's
been associated with it's respective drm_device. While drivers should take
care to avoid this, there's likely going to be situations where it's
difficult to workaround. And since other logging helpers in the kernel tend
to be OK with NULL pointers (for instance, passing a NULL pointer to a "%s"
argument for a printk-like function in the kernel doesn't break anything),
we should do the same for ours.

Signed-off-by: Lyude Paul 
---
 include/drm/drm_print.h | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index a3c58c941bdc..9b66be54dd16 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -443,25 +443,25 @@ void drm_dev_dbg(const struct device *dev, enum 
drm_debug_category category,
 
 
 #define drm_dbg_core(drm, fmt, ...)\
-   drm_dev_dbg((drm)->dev, DRM_UT_CORE, fmt, ##__VA_ARGS__)
+   drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_CORE, fmt, ##__VA_ARGS__)
 #define drm_dbg(drm, fmt, ...) \
-   drm_dev_dbg((drm)->dev, DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
+   drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRIVER, fmt, 
##__VA_ARGS__)
 #define drm_dbg_kms(drm, fmt, ...) \
-   drm_dev_dbg((drm)->dev, DRM_UT_KMS, fmt, ##__VA_ARGS__)
+   drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_KMS, fmt, ##__VA_ARGS__)
 #define drm_dbg_prime(drm, fmt, ...)   \
-   drm_dev_dbg((drm)->dev, DRM_UT_PRIME, fmt, ##__VA_ARGS__)
+   drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_PRIME, fmt, ##__VA_ARGS__)
 #define drm_dbg_atomic(drm, fmt, ...)  \
-   drm_dev_dbg((drm)->dev, DRM_UT_ATOMIC, fmt, ##__VA_ARGS__)
+   drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_ATOMIC, fmt, 
##__VA_ARGS__)
 #define drm_dbg_vbl(drm, fmt, ...) \
-   drm_dev_dbg((drm)->dev, DRM_UT_VBL, fmt, ##__VA_ARGS__)
+   drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_VBL, fmt, ##__VA_ARGS__)
 #define drm_dbg_state(drm, fmt, ...)   \
-   drm_dev_dbg((drm)->dev, DRM_UT_STATE, fmt, ##__VA_ARGS__)
+   drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_STATE, fmt, ##__VA_ARGS__)
 #define drm_dbg_lease(drm, fmt, ...)   \
-   drm_dev_dbg((drm)->dev, DRM_UT_LEASE, fmt, ##__VA_ARGS__)
+   drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_LEASE, fmt, ##__VA_ARGS__)
 #define drm_dbg_dp(drm, fmt, ...)  \
-   drm_dev_dbg((drm)->dev, DRM_UT_DP, fmt, ##__VA_ARGS__)
+   drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DP, fmt, ##__VA_ARGS__)
 #define drm_dbg_drmres(drm, fmt, ...)  \
-   drm_dev_dbg((drm)->dev, DRM_UT_DRMRES, fmt, ##__VA_ARGS__)
+   drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRMRES, fmt, 
##__VA_ARGS__)
 
 
 /*
-- 
2.30.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 11/20] drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_detect()

[Lyude Paul]

Since we're about to be using drm_dbg_*() throughout the DP helpers, we'll
need to be able to access the DRM device in the dual mode DP helpers as
well. Note however that since drm_dp_dual_mode_detect() can be called with
DDC adapters that aren't part of a drm_dp_aux struct, we need to pass down
the drm_device to these functions instead of using drm_dp_aux.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/drm_dp_dual_mode_helper.c   | 4 +++-
 drivers/gpu/drm/i915/display/intel_hdmi.c   | 2 +-
 drivers/gpu/drm/i915/display/intel_lspcon.c | 5 +++--
 include/drm/drm_dp_dual_mode_helper.h   | 4 +++-
 4 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index 1c9ea9f7fdaf..9ee75c568c37 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -165,6 +165,7 @@ static bool is_lspcon_adaptor(const char 
hdmi_id[DP_DUAL_MODE_HDMI_ID_LEN],
 
 /**
  * drm_dp_dual_mode_detect - Identify the DP dual mode adaptor
+ * @dev: _device to use
  * @adapter: I2C adapter for the DDC bus
  *
  * Attempt to identify the type of the DP dual mode adaptor used.
@@ -178,7 +179,8 @@ static bool is_lspcon_adaptor(const char 
hdmi_id[DP_DUAL_MODE_HDMI_ID_LEN],
  * Returns:
  * The type of the DP dual mode adaptor used
  */
-enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(struct i2c_adapter *adapter)
+enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(const struct drm_device 
*dev,
+  struct i2c_adapter *adapter)
 {
char hdmi_id[DP_DUAL_MODE_HDMI_ID_LEN] = {};
uint8_t adaptor_id = 0x00;
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 47a8f0a1c5e2..08fb98dac169 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2224,7 +2224,7 @@ intel_hdmi_dp_dual_mode_detect(struct drm_connector 
*connector, bool has_edid)
enum port port = hdmi_to_dig_port(hdmi)->base.port;
struct i2c_adapter *adapter =
intel_gmbus_get_adapter(dev_priv, hdmi->ddc_bus);
-   enum drm_dp_dual_mode_type type = drm_dp_dual_mode_detect(adapter);
+   enum drm_dp_dual_mode_type type = 
drm_dp_dual_mode_detect(_priv->drm, adapter);
 
/*
 * Type 1 DVI adaptors are not required to implement any
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index e4ff533e3a69..ca25044e7d1b 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -221,7 +221,8 @@ static bool lspcon_probe(struct intel_lspcon *lspcon)
 {
int retry;
enum drm_dp_dual_mode_type adaptor_type;
-   struct i2c_adapter *adapter = _to_intel_dp(lspcon)->aux.ddc;
+   struct intel_dp *intel_dp = lspcon_to_intel_dp(lspcon);
+   struct i2c_adapter *adapter = _dp->aux.ddc;
enum drm_lspcon_mode expected_mode;
 
expected_mode = lspcon_wake_native_aux_ch(lspcon) ?
@@ -232,7 +233,7 @@ static bool lspcon_probe(struct intel_lspcon *lspcon)
if (retry)
usleep_range(500, 1000);
 
-   adaptor_type = drm_dp_dual_mode_detect(adapter);
+   adaptor_type = drm_dp_dual_mode_detect(intel_dp->aux.drm_dev, 
adapter);
if (adaptor_type == DRM_DP_DUAL_MODE_LSPCON)
break;
}
diff --git a/include/drm/drm_dp_dual_mode_helper.h 
b/include/drm/drm_dp_dual_mode_helper.h
index 4c42db81fcb4..23ce849152f3 100644
--- a/include/drm/drm_dp_dual_mode_helper.h
+++ b/include/drm/drm_dp_dual_mode_helper.h
@@ -62,6 +62,7 @@
 #define DP_DUAL_MODE_LSPCON_CURRENT_MODE   0x41
 #define  DP_DUAL_MODE_LSPCON_MODE_PCON 0x1
 
+struct drm_device;
 struct i2c_adapter;
 
 ssize_t drm_dp_dual_mode_read(struct i2c_adapter *adapter,
@@ -103,7 +104,8 @@ enum drm_dp_dual_mode_type {
DRM_DP_DUAL_MODE_LSPCON,
 };
 
-enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(struct i2c_adapter 
*adapter);
+enum drm_dp_dual_mode_type
+drm_dp_dual_mode_detect(const struct drm_device *dev, struct i2c_adapter 
*adapter);
 int drm_dp_dual_mode_max_tmds_clock(enum drm_dp_dual_mode_type type,
struct i2c_adapter *adapter);
 int drm_dp_dual_mode_get_tmds_output(enum drm_dp_dual_mode_type type,
-- 
2.30.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 15/20] drm/dp_dual_mode: Pass drm_device to drm_lspcon_(get|set)_mode()

[Lyude Paul]

So that we can start using drm_dbg_*() throughout the DRM DP helpers.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/drm_dp_dual_mode_helper.c   |  8 +---
 drivers/gpu/drm/i915/display/intel_lspcon.c | 12 +++-
 include/drm/drm_dp_dual_mode_helper.h   |  4 ++--
 3 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index c9c2952bcad2..dbf9b1fdec63 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -430,6 +430,7 @@ EXPORT_SYMBOL(drm_dp_get_dual_mode_type_name);
 /**
  * drm_lspcon_get_mode: Get LSPCON's current mode of operation by
  * reading offset (0x80, 0x41)
+ * @dev: _device to use
  * @adapter: I2C-over-aux adapter
  * @mode: current lspcon mode of operation output variable
  *
@@ -437,7 +438,7 @@ EXPORT_SYMBOL(drm_dp_get_dual_mode_type_name);
  * 0 on success, sets the current_mode value to appropriate mode
  * -error on failure
  */
-int drm_lspcon_get_mode(struct i2c_adapter *adapter,
+int drm_lspcon_get_mode(const struct drm_device *dev, struct i2c_adapter 
*adapter,
enum drm_lspcon_mode *mode)
 {
u8 data;
@@ -477,13 +478,14 @@ EXPORT_SYMBOL(drm_lspcon_get_mode);
 /**
  * drm_lspcon_set_mode: Change LSPCON's mode of operation by
  * writing offset (0x80, 0x40)
+ * @dev: _device to use
  * @adapter: I2C-over-aux adapter
  * @mode: required mode of operation
  *
  * Returns:
  * 0 on success, -error on failure/timeout
  */
-int drm_lspcon_set_mode(struct i2c_adapter *adapter,
+int drm_lspcon_set_mode(const struct drm_device *dev, struct i2c_adapter 
*adapter,
enum drm_lspcon_mode mode)
 {
u8 data = 0;
@@ -508,7 +510,7 @@ int drm_lspcon_set_mode(struct i2c_adapter *adapter,
 * so wait and retry until time out or done.
 */
do {
-   ret = drm_lspcon_get_mode(adapter, _mode);
+   ret = drm_lspcon_get_mode(dev, adapter, _mode);
if (ret) {
DRM_ERROR("can't confirm LSPCON mode change\n");
return ret;
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index ca25044e7d1b..ec0048024746 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -139,10 +139,11 @@ void lspcon_detect_hdr_capability(struct intel_lspcon 
*lspcon)
 
 static enum drm_lspcon_mode lspcon_get_current_mode(struct intel_lspcon 
*lspcon)
 {
+   struct intel_dp *intel_dp = lspcon_to_intel_dp(lspcon);
enum drm_lspcon_mode current_mode;
-   struct i2c_adapter *adapter = _to_intel_dp(lspcon)->aux.ddc;
+   struct i2c_adapter *adapter = _dp->aux.ddc;
 
-   if (drm_lspcon_get_mode(adapter, _mode)) {
+   if (drm_lspcon_get_mode(intel_dp->aux.drm_dev, adapter, _mode)) 
{
DRM_DEBUG_KMS("Error reading LSPCON mode\n");
return DRM_LSPCON_MODE_INVALID;
}
@@ -175,11 +176,12 @@ static enum drm_lspcon_mode lspcon_wait_mode(struct 
intel_lspcon *lspcon,
 static int lspcon_change_mode(struct intel_lspcon *lspcon,
  enum drm_lspcon_mode mode)
 {
+   struct intel_dp *intel_dp = lspcon_to_intel_dp(lspcon);
int err;
enum drm_lspcon_mode current_mode;
-   struct i2c_adapter *adapter = _to_intel_dp(lspcon)->aux.ddc;
+   struct i2c_adapter *adapter = _dp->aux.ddc;
 
-   err = drm_lspcon_get_mode(adapter, _mode);
+   err = drm_lspcon_get_mode(intel_dp->aux.drm_dev, adapter, 
_mode);
if (err) {
DRM_ERROR("Error reading LSPCON mode\n");
return err;
@@ -190,7 +192,7 @@ static int lspcon_change_mode(struct intel_lspcon *lspcon,
return 0;
}
 
-   err = drm_lspcon_set_mode(adapter, mode);
+   err = drm_lspcon_set_mode(intel_dp->aux.drm_dev, adapter, mode);
if (err < 0) {
DRM_ERROR("LSPCON mode change failed\n");
return err;
diff --git a/include/drm/drm_dp_dual_mode_helper.h 
b/include/drm/drm_dp_dual_mode_helper.h
index 01eec9ff5962..7ee482265087 100644
--- a/include/drm/drm_dp_dual_mode_helper.h
+++ b/include/drm/drm_dp_dual_mode_helper.h
@@ -114,8 +114,8 @@ int drm_dp_dual_mode_set_tmds_output(const struct 
drm_device *dev, enum drm_dp_d
 struct i2c_adapter *adapter, bool enable);
 const char *drm_dp_get_dual_mode_type_name(enum drm_dp_dual_mode_type type);
 
-int drm_lspcon_get_mode(struct i2c_adapter *adapter,
+int drm_lspcon_get_mode(const struct drm_device *dev, struct i2c_adapter 
*adapter,
enum drm_lspcon_mode *current_mode);
-int drm_lspcon_set_mode(struct i2c_adapter *adapter,
+int drm_lspcon_set_mode(const struct drm_device *dev, struct i2c_adapter 
*adapter,
enum drm_lspcon_mode reqd_mode);
 

[PATCH v3 13/20] drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_max_tmds_clock()

[Lyude Paul]

Another function we need to pass drm_device down to in order to start using
drm_dbg_*().

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/drm_dp_dual_mode_helper.c | 3 ++-
 drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
 include/drm/drm_dp_dual_mode_helper.h | 2 +-
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index a63d7de85309..4a26b3e1f78f 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -252,6 +252,7 @@ EXPORT_SYMBOL(drm_dp_dual_mode_detect);
 
 /**
  * drm_dp_dual_mode_max_tmds_clock - Max TMDS clock for DP dual mode adaptor
+ * @dev: _device to use
  * @type: DP dual mode adaptor type
  * @adapter: I2C adapter for the DDC bus
  *
@@ -265,7 +266,7 @@ EXPORT_SYMBOL(drm_dp_dual_mode_detect);
  * Returns:
  * Maximum supported TMDS clock rate for the DP dual mode adaptor in kHz.
  */
-int drm_dp_dual_mode_max_tmds_clock(enum drm_dp_dual_mode_type type,
+int drm_dp_dual_mode_max_tmds_clock(const struct drm_device *dev, enum 
drm_dp_dual_mode_type type,
struct i2c_adapter *adapter)
 {
uint8_t max_tmds_clock;
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index fc3e7a9396b5..46de56af33db 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2256,7 +2256,7 @@ intel_hdmi_dp_dual_mode_detect(struct drm_connector 
*connector, bool has_edid)
 
hdmi->dp_dual_mode.type = type;
hdmi->dp_dual_mode.max_tmds_clock =
-   drm_dp_dual_mode_max_tmds_clock(type, adapter);
+   drm_dp_dual_mode_max_tmds_clock(_priv->drm, type, adapter);
 
drm_dbg_kms(_priv->drm,
"DP dual mode adaptor (%s) detected (max TMDS clock: %d 
kHz)\n",
diff --git a/include/drm/drm_dp_dual_mode_helper.h 
b/include/drm/drm_dp_dual_mode_helper.h
index 8cb0dcd98a99..aabf9c951380 100644
--- a/include/drm/drm_dp_dual_mode_helper.h
+++ b/include/drm/drm_dp_dual_mode_helper.h
@@ -106,7 +106,7 @@ enum drm_dp_dual_mode_type {
 
 enum drm_dp_dual_mode_type
 drm_dp_dual_mode_detect(const struct drm_device *dev, struct i2c_adapter 
*adapter);
-int drm_dp_dual_mode_max_tmds_clock(enum drm_dp_dual_mode_type type,
+int drm_dp_dual_mode_max_tmds_clock(const struct drm_device *dev, enum 
drm_dp_dual_mode_type type,
struct i2c_adapter *adapter);
 int drm_dp_dual_mode_get_tmds_output(enum drm_dp_dual_mode_type type,
 struct i2c_adapter *adapter, bool 
*enabled);
-- 
2.30.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 12/20] drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_set_tmds_output()

[Lyude Paul]

Another function that we'll need to pass a drm_device (and not drm_dp_aux)
down to so that we can move over to using drm_dbg_*().

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/drm_dp_dual_mode_helper.c | 3 ++-
 drivers/gpu/drm/i915/display/intel_hdmi.c | 3 +--
 include/drm/drm_dp_dual_mode_helper.h | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index 9ee75c568c37..a63d7de85309 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -336,6 +336,7 @@ EXPORT_SYMBOL(drm_dp_dual_mode_get_tmds_output);
 
 /**
  * drm_dp_dual_mode_set_tmds_output - Enable/disable TMDS output buffers in 
the DP dual mode adaptor
+ * @dev: _device to use
  * @type: DP dual mode adaptor type
  * @adapter: I2C adapter for the DDC bus
  * @enable: enable (as opposed to disable) the TMDS output buffers
@@ -349,7 +350,7 @@ EXPORT_SYMBOL(drm_dp_dual_mode_get_tmds_output);
  * Returns:
  * 0 on success, negative error code on failure
  */
-int drm_dp_dual_mode_set_tmds_output(enum drm_dp_dual_mode_type type,
+int drm_dp_dual_mode_set_tmds_output(const struct drm_device *dev, enum 
drm_dp_dual_mode_type type,
 struct i2c_adapter *adapter, bool enable)
 {
uint8_t tmds_oen = enable ? 0 : DP_DUAL_MODE_TMDS_DISABLE;
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 08fb98dac169..fc3e7a9396b5 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -1251,8 +1251,7 @@ void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi 
*hdmi, bool enable)
drm_dbg_kms(_priv->drm, "%s DP dual mode adaptor TMDS output\n",
enable ? "Enabling" : "Disabling");
 
-   drm_dp_dual_mode_set_tmds_output(hdmi->dp_dual_mode.type,
-adapter, enable);
+   drm_dp_dual_mode_set_tmds_output(_priv->drm, 
hdmi->dp_dual_mode.type, adapter, enable);
 }
 
 static int intel_hdmi_hdcp_read(struct intel_digital_port *dig_port,
diff --git a/include/drm/drm_dp_dual_mode_helper.h 
b/include/drm/drm_dp_dual_mode_helper.h
index 23ce849152f3..8cb0dcd98a99 100644
--- a/include/drm/drm_dp_dual_mode_helper.h
+++ b/include/drm/drm_dp_dual_mode_helper.h
@@ -110,7 +110,7 @@ int drm_dp_dual_mode_max_tmds_clock(enum 
drm_dp_dual_mode_type type,
struct i2c_adapter *adapter);
 int drm_dp_dual_mode_get_tmds_output(enum drm_dp_dual_mode_type type,
 struct i2c_adapter *adapter, bool 
*enabled);
-int drm_dp_dual_mode_set_tmds_output(enum drm_dp_dual_mode_type type,
+int drm_dp_dual_mode_set_tmds_output(const struct drm_device *dev, enum 
drm_dp_dual_mode_type type,
 struct i2c_adapter *adapter, bool enable);
 const char *drm_dp_get_dual_mode_type_name(enum drm_dp_dual_mode_type type);
 
-- 
2.30.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 10/20] drm/dp: Always print aux channel name in logs

[Lyude Paul]

Since we're about to convert everything in drm_dp_helper.c over to using
drm_dbg_*(), let's also make our logging more consistent in drm_dp_helper.c
while we're at it to ensure that we always print the name of the AUX
channel in question.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/drm_dp_helper.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index eaafc676aa0c..6dc1ccd4880b 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -139,8 +139,8 @@ void drm_dp_link_train_clock_recovery_delay(const struct 
drm_dp_aux *aux,
 DP_TRAINING_AUX_RD_MASK;
 
if (rd_interval > 4)
-   DRM_DEBUG_KMS("AUX interval %lu, out of range (max 4)\n",
- rd_interval);
+   DRM_DEBUG_KMS("%s: AUX interval %lu, out of range (max 4)\n",
+ aux->name, rd_interval);
 
if (rd_interval == 0 || dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
rd_interval = 100;
@@ -155,8 +155,8 @@ static void __drm_dp_link_train_channel_eq_delay(const 
struct drm_dp_aux *aux,
 unsigned long rd_interval)
 {
if (rd_interval > 4)
-   DRM_DEBUG_KMS("AUX interval %lu, out of range (max 4)\n",
- rd_interval);
+   DRM_DEBUG_KMS("%s: AUX interval %lu, out of range (max 4)\n",
+ aux->name, rd_interval);
 
if (rd_interval == 0)
rd_interval = 400;
@@ -2819,7 +2819,7 @@ int drm_dp_pcon_frl_enable(struct drm_dp_aux *aux)
if (ret < 0)
return ret;
if (!(buf & DP_PCON_ENABLE_SOURCE_CTL_MODE)) {
-   DRM_DEBUG_KMS("PCON in Autonomous mode, can't enable FRL\n");
+   DRM_DEBUG_KMS("%s: PCON in Autonomous mode, can't enable 
FRL\n", aux->name);
return -EINVAL;
}
buf |= DP_PCON_ENABLE_HDMI_LINK;
@@ -2914,7 +2914,8 @@ void drm_dp_pcon_hdmi_frl_link_error_count(struct 
drm_dp_aux *aux,
num_error = 0;
}
 
-   DRM_ERROR("More than %d errors since the last read for lane 
%d", num_error, i);
+   DRM_ERROR("%s: More than %d errors since the last read for lane 
%d",
+ aux->name, num_error, i);
}
 }
 EXPORT_SYMBOL(drm_dp_pcon_hdmi_frl_link_error_count);
-- 
2.30.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 14/20] drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_get_tmds_output()

[Lyude Paul]

Another function to pass drm_device * down to so we can start using the
drm_dbg_*() in the DRM DP helpers.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/drm_dp_dual_mode_helper.c | 5 +++--
 include/drm/drm_dp_dual_mode_helper.h | 2 +-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index 4a26b3e1f78f..c9c2952bcad2 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -296,6 +296,7 @@ EXPORT_SYMBOL(drm_dp_dual_mode_max_tmds_clock);
 
 /**
  * drm_dp_dual_mode_get_tmds_output - Get the state of the TMDS output buffers 
in the DP dual mode adaptor
+ * @dev: _device to use
  * @type: DP dual mode adaptor type
  * @adapter: I2C adapter for the DDC bus
  * @enabled: current state of the TMDS output buffers
@@ -310,8 +311,8 @@ EXPORT_SYMBOL(drm_dp_dual_mode_max_tmds_clock);
  * Returns:
  * 0 on success, negative error code on failure
  */
-int drm_dp_dual_mode_get_tmds_output(enum drm_dp_dual_mode_type type,
-struct i2c_adapter *adapter,
+int drm_dp_dual_mode_get_tmds_output(const struct drm_device *dev,
+enum drm_dp_dual_mode_type type, struct 
i2c_adapter *adapter,
 bool *enabled)
 {
uint8_t tmds_oen;
diff --git a/include/drm/drm_dp_dual_mode_helper.h 
b/include/drm/drm_dp_dual_mode_helper.h
index aabf9c951380..01eec9ff5962 100644
--- a/include/drm/drm_dp_dual_mode_helper.h
+++ b/include/drm/drm_dp_dual_mode_helper.h
@@ -108,7 +108,7 @@ enum drm_dp_dual_mode_type
 drm_dp_dual_mode_detect(const struct drm_device *dev, struct i2c_adapter 
*adapter);
 int drm_dp_dual_mode_max_tmds_clock(const struct drm_device *dev, enum 
drm_dp_dual_mode_type type,
struct i2c_adapter *adapter);
-int drm_dp_dual_mode_get_tmds_output(enum drm_dp_dual_mode_type type,
+int drm_dp_dual_mode_get_tmds_output(const struct drm_device *dev, enum 
drm_dp_dual_mode_type type,
 struct i2c_adapter *adapter, bool 
*enabled);
 int drm_dp_dual_mode_set_tmds_output(const struct drm_device *dev, enum 
drm_dp_dual_mode_type type,
 struct i2c_adapter *adapter, bool enable);
-- 
2.30.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 09/20] drm/dp: Pass drm_dp_aux to drm_dp*_link_train_channel_eq_delay()

[Lyude Paul]

So that we can start using drm_dbg_*() for
drm_dp_link_train_channel_eq_delay() and
drm_dp_lttpr_link_train_channel_eq_delay().

Signed-off-by: Lyude Paul 
Reviewed-by: Laurent Pinchart 
---
 drivers/gpu/drm/amd/amdgpu/atombios_dp.c   |  2 +-
 drivers/gpu/drm/drm_dp_helper.c| 14 +-
 .../gpu/drm/i915/display/intel_dp_link_training.c  |  4 ++--
 drivers/gpu/drm/msm/dp/dp_ctrl.c   |  4 ++--
 drivers/gpu/drm/msm/edp/edp_ctrl.c |  4 ++--
 drivers/gpu/drm/radeon/atombios_dp.c   |  2 +-
 drivers/gpu/drm/xlnx/zynqmp_dp.c   |  2 +-
 include/drm/drm_dp_helper.h|  6 --
 8 files changed, 22 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c 
b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
index b0eaeb6afd29..9f0acee0a271 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
@@ -682,7 +682,7 @@ amdgpu_atombios_dp_link_train_ce(struct 
amdgpu_atombios_dp_link_train_info *dp_i
dp_info->tries = 0;
channel_eq = false;
while (1) {
-   drm_dp_link_train_channel_eq_delay(dp_info->dpcd);
+   drm_dp_link_train_channel_eq_delay(dp_info->aux, dp_info->dpcd);
 
if (drm_dp_dpcd_read_link_status(dp_info->aux,
 dp_info->link_status) <= 0) {
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 3a3c4cfb9ac6..eaafc676aa0c 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -151,7 +151,8 @@ void drm_dp_link_train_clock_recovery_delay(const struct 
drm_dp_aux *aux,
 }
 EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
 
-static void __drm_dp_link_train_channel_eq_delay(unsigned long rd_interval)
+static void __drm_dp_link_train_channel_eq_delay(const struct drm_dp_aux *aux,
+unsigned long rd_interval)
 {
if (rd_interval > 4)
DRM_DEBUG_KMS("AUX interval %lu, out of range (max 4)\n",
@@ -165,9 +166,11 @@ static void __drm_dp_link_train_channel_eq_delay(unsigned 
long rd_interval)
usleep_range(rd_interval, rd_interval * 2);
 }
 
-void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+void drm_dp_link_train_channel_eq_delay(const struct drm_dp_aux *aux,
+   const u8 dpcd[DP_RECEIVER_CAP_SIZE])
 {
-   __drm_dp_link_train_channel_eq_delay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
+   __drm_dp_link_train_channel_eq_delay(aux,
+dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
 DP_TRAINING_AUX_RD_MASK);
 }
 EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
@@ -183,13 +186,14 @@ static u8 dp_lttpr_phy_cap(const u8 
phy_cap[DP_LTTPR_PHY_CAP_SIZE], int r)
return phy_cap[r - DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1];
 }
 
-void drm_dp_lttpr_link_train_channel_eq_delay(const u8 
phy_cap[DP_LTTPR_PHY_CAP_SIZE])
+void drm_dp_lttpr_link_train_channel_eq_delay(const struct drm_dp_aux *aux,
+ const u8 
phy_cap[DP_LTTPR_PHY_CAP_SIZE])
 {
u8 interval = dp_lttpr_phy_cap(phy_cap,
   
DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1) &
  DP_TRAINING_AUX_RD_MASK;
 
-   __drm_dp_link_train_channel_eq_delay(interval);
+   __drm_dp_link_train_channel_eq_delay(aux, interval);
 }
 EXPORT_SYMBOL(drm_dp_lttpr_link_train_channel_eq_delay);
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 198ddb3c173a..6bf6f1ec13ed 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -665,11 +665,11 @@ intel_dp_link_training_channel_equalization_delay(struct 
intel_dp *intel_dp,
  enum drm_dp_phy dp_phy)
 {
if (dp_phy == DP_PHY_DPRX) {
-   drm_dp_link_train_channel_eq_delay(intel_dp->dpcd);
+   drm_dp_link_train_channel_eq_delay(_dp->aux, 
intel_dp->dpcd);
} else {
const u8 *phy_caps = intel_dp_lttpr_phy_caps(intel_dp, dp_phy);
 
-   drm_dp_lttpr_link_train_channel_eq_delay(phy_caps);
+   drm_dp_lttpr_link_train_channel_eq_delay(_dp->aux, 
phy_caps);
}
 }
 
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 264a9eae87d3..2cebd17a7289 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1184,7 +1184,7 @@ static int dp_ctrl_link_lane_down_shift(struct 
dp_ctrl_private *ctrl)
 static void dp_ctrl_clear_training_pattern(struct dp_ctrl_private *ctrl)
 {
dp_ctrl_train_pattern_set(ctrl, DP_TRAINING_PATTERN_DISABLE);

[PATCH v3 08/20] drm/dp: Pass drm_dp_aux to drm_dp_link_train_clock_recovery_delay()

[Lyude Paul]

So that we can start using drm_dbg_*() in
drm_dp_link_train_clock_recovery_delay().

Signed-off-by: Lyude Paul 
Reviewed-by: Laurent Pinchart 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/amd/amdgpu/atombios_dp.c  | 2 +-
 drivers/gpu/drm/drm_dp_helper.c   | 3 ++-
 drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2 +-
 drivers/gpu/drm/msm/dp/dp_ctrl.c  | 2 +-
 drivers/gpu/drm/msm/edp/edp_ctrl.c| 2 +-
 drivers/gpu/drm/radeon/atombios_dp.c  | 2 +-
 drivers/gpu/drm/xlnx/zynqmp_dp.c  | 2 +-
 include/drm/drm_dp_helper.h   | 4 +++-
 8 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c 
b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
index 14a097322238..b0eaeb6afd29 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
@@ -617,7 +617,7 @@ amdgpu_atombios_dp_link_train_cr(struct 
amdgpu_atombios_dp_link_train_info *dp_i
dp_info->tries = 0;
voltage = 0xff;
while (1) {
-   drm_dp_link_train_clock_recovery_delay(dp_info->dpcd);
+   drm_dp_link_train_clock_recovery_delay(dp_info->aux, 
dp_info->dpcd);
 
if (drm_dp_dpcd_read_link_status(dp_info->aux,
 dp_info->link_status) <= 0) {
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index b197fdac2334..3a3c4cfb9ac6 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -132,7 +132,8 @@ u8 drm_dp_get_adjust_request_post_cursor(const u8 
link_status[DP_LINK_STATUS_SIZ
 }
 EXPORT_SYMBOL(drm_dp_get_adjust_request_post_cursor);
 
-void drm_dp_link_train_clock_recovery_delay(const u8 
dpcd[DP_RECEIVER_CAP_SIZE])
+void drm_dp_link_train_clock_recovery_delay(const struct drm_dp_aux *aux,
+   const u8 dpcd[DP_RECEIVER_CAP_SIZE])
 {
unsigned long rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
 DP_TRAINING_AUX_RD_MASK;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 591ddc4b876c..198ddb3c173a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -513,7 +513,7 @@ static void 
intel_dp_link_training_clock_recovery_delay(struct intel_dp *intel_d
enum drm_dp_phy dp_phy)
 {
if (dp_phy == DP_PHY_DPRX)
-   drm_dp_link_train_clock_recovery_delay(intel_dp->dpcd);
+   drm_dp_link_train_clock_recovery_delay(_dp->aux, 
intel_dp->dpcd);
else
drm_dp_lttpr_link_train_clock_recovery_delay();
 }
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 1390f3547fde..264a9eae87d3 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1103,7 +1103,7 @@ static int dp_ctrl_link_train_1(struct dp_ctrl_private 
*ctrl,
tries = 0;
old_v_level = ctrl->link->phy_params.v_level;
for (tries = 0; tries < maximum_retries; tries++) {
-   drm_dp_link_train_clock_recovery_delay(ctrl->panel->dpcd);
+   drm_dp_link_train_clock_recovery_delay(ctrl->aux, 
ctrl->panel->dpcd);
 
ret = dp_ctrl_read_link_status(ctrl, link_status);
if (ret)
diff --git a/drivers/gpu/drm/msm/edp/edp_ctrl.c 
b/drivers/gpu/drm/msm/edp/edp_ctrl.c
index 57af3d8b6699..6501598448b4 100644
--- a/drivers/gpu/drm/msm/edp/edp_ctrl.c
+++ b/drivers/gpu/drm/msm/edp/edp_ctrl.c
@@ -608,7 +608,7 @@ static int edp_start_link_train_1(struct edp_ctrl *ctrl)
tries = 0;
old_v_level = ctrl->v_level;
while (1) {
-   drm_dp_link_train_clock_recovery_delay(ctrl->dpcd);
+   drm_dp_link_train_clock_recovery_delay(ctrl->drm_aux, 
ctrl->dpcd);
 
rlen = drm_dp_dpcd_read_link_status(ctrl->drm_aux, link_status);
if (rlen < DP_LINK_STATUS_SIZE) {
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index c50c504bad50..299b9d8da376 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -680,7 +680,7 @@ static int radeon_dp_link_train_cr(struct 
radeon_dp_link_train_info *dp_info)
dp_info->tries = 0;
voltage = 0xff;
while (1) {
-   drm_dp_link_train_clock_recovery_delay(dp_info->dpcd);
+   drm_dp_link_train_clock_recovery_delay(dp_info->aux, 
dp_info->dpcd);
 
if (drm_dp_dpcd_read_link_status(dp_info->aux,
 dp_info->link_status) <= 0) {
diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c b/drivers/gpu/drm/xlnx/zynqmp_dp.c

[PATCH v3 07/20] drm/dp: Clarify DP AUX registration time

[Lyude Paul]

The docs we had for drm_dp_aux_init() and drm_dp_aux_register() were mostly
correct, except for the fact that they made the assumption that all AUX
devices were grandchildren of their respective DRM devices. This is the
case for most normal GPUs, but is almost never the case with SoCs and
display bridges. So, let's fix this documentation to clarify when the right
time to use drm_dp_aux_init() or drm_dp_aux_register() is.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/drm_dp_helper.c | 57 +
 1 file changed, 37 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index b34105c41867..b197fdac2334 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1728,13 +1728,21 @@ EXPORT_SYMBOL(drm_dp_remote_aux_init);
  * drm_dp_aux_init() - minimally initialise an aux channel
  * @aux: DisplayPort AUX channel
  *
- * If you need to use the drm_dp_aux's i2c adapter prior to registering it
- * with the outside world, call drm_dp_aux_init() first. You must still
- * call drm_dp_aux_register() once the connector has been registered to
- * allow userspace access to the auxiliary DP channel. Once the AUX channel is
- * no longer being used and has been unregistered with
- * drm_dp_aux_unregister(), the driver must clean up any resources it's
- * allocated with drm_dp_aux_fini().
+ * If you need to use the drm_dp_aux's i2c adapter prior to registering it with
+ * the outside world, call drm_dp_aux_init() first. For drivers which are
+ * grandparents to their AUX adapters (e.g. the AUX adapter is parented by a
+ * _connector), you must still call drm_dp_aux_register() once the 
connector
+ * has been registered to allow userspace access to the auxiliary DP channel.
+ * Likewise, for such drivers you should also assign _dp_aux.drm_dev as
+ * early as possible so that the _device that corresponds to the AUX 
adapter
+ * may be mentioned in debugging output from the DRM DP helpers.
+ *
+ * For devices which use a separate platform device for their AUX adapters, 
this
+ * may be called as early as required by the driver.
+ *
+ * Once the AUX channel is no longer being used and has been unregistered with
+ * drm_dp_aux_unregister(), the driver must clean up any resources its 
allocated with
+ * drm_dp_aux_fini().
  *
  * Returns:
  * %0 on success, negative error code on failure
@@ -1794,19 +1802,28 @@ EXPORT_SYMBOL(drm_dp_aux_fini);
  * drm_dp_aux_register() - register aux channel
  * @aux: DisplayPort AUX channel
  *
- * Automatically calls drm_dp_aux_init() if this hasn't been done yet. The
- * driver must make sure to call drm_dp_aux_unregister() to unregister the
- * device, and drm_dp_aux_fini() to cleanup the device after it's been
- * unregistered.
- *
- * This should only be called when the underlying  drm_connector is
- * initialized already. Therefore the best place to call this is from
- * _connector_funcs.late_register. Not that drivers which don't follow this
- * will Oops when CONFIG_DRM_DP_AUX_CHARDEV is enabled.
- *
- * Drivers which need to use the aux channel before that point (e.g. at driver
- * load time, before drm_dev_register() has been called) need to call
- * drm_dp_aux_init().
+ * Automatically calls drm_dp_aux_init() if this hasn't been done yet. This
+ * should only be called once the parent of @aux, _dp_aux.dev, is
+ * initialized. For devices which are grandparents of their AUX channels,
+ * _dp_aux.dev will typically be the _connector  which
+ * corresponds to @aux. For these devices, it's advised to call
+ * drm_dp_aux_register() in _connector_funcs.late_register, and likewise to
+ * call drm_dp_aux_unregister() in _connector_funcs.early_unregister.
+ * Functions which don't follow this will likely Oops when
+ * %CONFIG_DRM_DP_AUX_CHARDEV is enabled.
+ *
+ * For devices where the AUX channel is a device that exists independently of
+ * the _device that uses it, such as SoCs and bridge devices, it is
+ * recommended to call drm_dp_aux_register() after a _device has been
+ * assigned to _dp_aux.drm_dev, and likewise to call
+ * drm_dp_aux_unregister() once the _device should no longer be associated
+ * with the AUX channel (e.g. on bridge detach). Additionally, the driver must
+ * call drm_dp_aux_fini() on @aux once it's been unregistered and is no longer
+ * in use.
+ *
+ * Drivers which need to use the aux channel before either of the two points
+ * mentioned above need to call drm_dp_aux_init() in order to use the AUX
+ * channel before registration.
  *
  * Returns 0 on success or a negative error code on failure.
  */
-- 
2.30.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 06/20] drm/dp: Add backpointer to drm_device in drm_dp_aux

[Lyude Paul]

This is something that we've wanted for a while now: the ability to
actually look up the respective drm_device for a given drm_dp_aux struct.
This will also allow us to transition over to using the drm_dbg_*() helpers
for debug message printing, as we'll finally have a drm_device to reference
for doing so.

Note that there is one limitation with this - because some DP AUX adapters
exist as platform devices which are initialized independently of their
respective DRM devices, one cannot rely on drm_dp_aux->drm_dev to always be
non-NULL until drm_dp_aux_register() has been called. We make sure to point
this out in the documentation for struct drm_dp_aux.

v3:
* Add WARN_ON_ONCE() to drm_dp_aux_register() if drm_dev isn't filled out

Signed-off-by: Lyude Paul 
Acked-by: Thierry Reding 
---
 drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 7 ---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c  | 1 +
 drivers/gpu/drm/bridge/analogix/analogix-anx6345.c   | 1 +
 drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c   | 1 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c   | 1 +
 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c  | 1 +
 drivers/gpu/drm/bridge/tc358767.c| 1 +
 drivers/gpu/drm/bridge/ti-sn65dsi86.c| 1 +
 drivers/gpu/drm/drm_dp_aux_dev.c | 6 ++
 drivers/gpu/drm/drm_dp_helper.c  | 2 ++
 drivers/gpu/drm/drm_dp_mst_topology.c| 1 +
 drivers/gpu/drm/i915/display/intel_dp_aux.c  | 1 +
 drivers/gpu/drm/msm/edp/edp.h| 3 +--
 drivers/gpu/drm/msm/edp/edp_aux.c| 5 +++--
 drivers/gpu/drm/msm/edp/edp_ctrl.c   | 2 +-
 drivers/gpu/drm/nouveau/nouveau_connector.c  | 1 +
 drivers/gpu/drm/radeon/atombios_dp.c | 1 +
 drivers/gpu/drm/tegra/dpaux.c| 1 +
 drivers/gpu/drm/xlnx/zynqmp_dp.c | 1 +
 include/drm/drm_dp_helper.h  | 9 -
 20 files changed, 38 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c 
b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
index 54c209ab8c9f..14a097322238 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
@@ -190,11 +190,12 @@ int amdgpu_atombios_dp_aux_init(struct amdgpu_connector 
*amdgpu_connector)
 
amdgpu_connector->ddc_bus->rec.hpd = amdgpu_connector->hpd.hpd;
amdgpu_connector->ddc_bus->aux.transfer = 
amdgpu_atombios_dp_aux_transfer;
+   amdgpu_connector->ddc_bus->aux.drm_dev = amdgpu_connector->base.dev;
+
ret = drm_dp_aux_init(_connector->ddc_bus->aux);
-   if (ret)
-   return ret;
+   if (!ret)
+   amdgpu_connector->ddc_bus->has_aux = true;
 
-   amdgpu_connector->ddc_bus->has_aux = true;
return ret;
 }
 
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 51fbbf3ef59b..a98bd3b521b2 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -438,6 +438,7 @@ int amdgpu_dm_initialize_dp_connector(struct 
amdgpu_display_manager *dm,
 
dm_aux->aux.transfer = dm_dp_aux_transfer;
dm_aux->ddc_service = aconnector->dc_link->ddc;
+   dm_aux->aux.drm_dev = dm->ddev;
 
ret = drm_dp_aux_init(_aux->aux);
if (ret)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c 
b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
index c105dcb79c37..f4e6a53f3821 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
@@ -537,6 +537,7 @@ static int anx6345_bridge_attach(struct drm_bridge *bridge,
/* Register aux channel */
anx6345->aux.name = "DP-AUX";
anx6345->aux.dev = >client->dev;
+   anx6345->aux.drm_dev = bridge->dev;
anx6345->aux.transfer = anx6345_aux_transfer;
 
err = drm_dp_aux_register(>aux);
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c 
b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
index 0778458e81be..7bd28c077181 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
@@ -905,6 +905,7 @@ static int anx78xx_bridge_attach(struct drm_bridge *bridge,
/* Register aux channel */
anx78xx->aux.name = "DP-AUX";
anx78xx->aux.dev = >client->dev;
+   anx78xx->aux.drm_dev = bridge->dev;
anx78xx->aux.transfer = anx78xx_aux_transfer;
 
err = drm_dp_aux_register(>aux);
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index f82e193d32ae..17359bb7a82d 100644
--- 

[PATCH v3 05/20] drm/nouveau/kms/nv50-: Move AUX adapter reg to connector late register/early unregister

[Lyude Paul]

Since AUX adapters on nouveau have their respective DRM connectors as
parents, we need to make sure that we register then after their connectors.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/nouveau_connector.c | 25 -
 1 file changed, 20 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index e5a93fab856e..56eaa29b34d6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -401,7 +401,6 @@ nouveau_connector_destroy(struct drm_connector *connector)
drm_connector_cleanup(connector);
if (nv_connector->aux.transfer) {
drm_dp_cec_unregister_connector(_connector->aux);
-   drm_dp_aux_unregister(_connector->aux);
drm_dp_aux_fini(_connector->aux);
kfree(nv_connector->aux.name);
}
@@ -906,13 +905,29 @@ nouveau_connector_late_register(struct drm_connector 
*connector)
int ret;
 
ret = nouveau_backlight_init(connector);
+   if (ret)
+   return ret;
 
+   if (connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
+   connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
+   ret = drm_dp_aux_register(_connector(connector)->aux);
+   if (ret)
+   goto backlight_fini;
+   }
+
+   return 0;
+backlight_fini:
+   nouveau_backlight_fini(connector);
return ret;
 }
 
 static void
 nouveau_connector_early_unregister(struct drm_connector *connector)
 {
+   if (connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
+   connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort)
+   drm_dp_aux_unregister(_connector(connector)->aux);
+
nouveau_backlight_fini(connector);
 }
 
@@ -1344,14 +1359,14 @@ nouveau_connector_create(struct drm_device *dev,
snprintf(aux_name, sizeof(aux_name), "sor-%04x-%04x",
 dcbe->hasht, dcbe->hashm);
nv_connector->aux.name = kstrdup(aux_name, GFP_KERNEL);
-   ret = drm_dp_aux_register(_connector->aux);
+   ret = drm_dp_aux_init(_connector->aux);
if (ret) {
-   NV_ERROR(drm, "failed to register aux channel\n");
+   NV_ERROR(drm, "Failed to init AUX adapter for 
sor-%04x-%04x: %d\n",
+dcbe->hasht, dcbe->hashm, ret);
kfree(nv_connector);
return ERR_PTR(ret);
}
-   funcs = _connector_funcs;
-   break;
+   fallthrough;
default:
funcs = _connector_funcs;
break;
-- 
2.30.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 04/20] drm/bridge/cdns-mhdp8546: Register DP aux channel with userspace

[Lyude Paul]

Just adds some missing calls to
drm_dp_aux_register()/drm_dp_aux_unregister() for when we attach/detach the
bridge.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c 
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index c5e2bc75b226..518e9a441c21 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -1719,10 +1719,14 @@ static int cdns_mhdp_attach(struct drm_bridge *bridge,
 
dev_dbg(mhdp->dev, "%s\n", __func__);
 
+   ret = drm_dp_aux_register(>aux);
+   if (ret < 0)
+   return ret;
+
if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
ret = cdns_mhdp_connector_init(mhdp);
if (ret)
-   return ret;
+   goto aux_unregister;
}
 
spin_lock(>start_lock);
@@ -1738,6 +1742,9 @@ static int cdns_mhdp_attach(struct drm_bridge *bridge,
   mhdp->regs + CDNS_APB_INT_MASK);
 
return 0;
+aux_unregister:
+   drm_dp_aux_unregister(>aux);
+   return ret;
 }
 
 static void cdns_mhdp_configure_video(struct cdns_mhdp_device *mhdp,
@@ -2082,6 +2089,8 @@ static void cdns_mhdp_detach(struct drm_bridge *bridge)
 
dev_dbg(mhdp->dev, "%s\n", __func__);
 
+   drm_dp_aux_unregister(>aux);
+
spin_lock(>start_lock);
 
mhdp->bridge_attached = false;
-- 
2.30.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 03/20] drm/dp: Move i2c init to drm_dp_aux_init, add __must_check and fini

[Lyude Paul]

When moving around drm_dp_aux_register() calls, it turned out we
accidentally managed to cause issues with the Tegra driver due to the fact
the Tegra driver would attempt to retrieve a reference to the AUX channel's
i2c adapter - which wouldn't be initialized until drm_dp_aux_register() is
called.

This doesn't actually make a whole ton of sense, as it's not unexpected for
a driver to need to be able to use an AUX adapter before it's been
registered. Likewise-it's not unexpected for a driver to try using the i2c
adapter for said AUX channel before it's been registered as well. In fact,
the current documentation for drm_dp_aux_init() even seems to imply that
drm_dp_aux_init() is supposed to be handling i2c adapter creation for this
precise reason - not drm_dp_aux_register().

Since the i2c adapter doesn't need to be linked to the DRM device in any
way, we can just fix this problem by moving i2c adapter creation out of
drm_dp_aux_register() and into drm_dp_aux_init(). Additionally, since this
means that drm_dp_aux_init() can fail we go ahead and add a __must_check
attribute to it so that drivers don't ignore its return status on failures.
And finally, we add a drm_dp_aux_fini() and hook it up in all DRM drivers
across the kernel to take care of cleaning up the i2c adapter once it's no
longer needed.

This should also fix the regressions noted in the Tegra driver.

Signed-off-by: Lyude Paul 
Fixes: 39c17ae60ea9 ("drm/tegra: Don't register DP AUX channels before 
connectors")
Cc: Thierry Reding 
Cc: Thierry Reding 
---
 .../gpu/drm/amd/amdgpu/amdgpu_connectors.c|  7 +-
 drivers/gpu/drm/amd/amdgpu/atombios_dp.c  | 10 ++-
 drivers/gpu/drm/amd/amdgpu/atombios_dp.h  |  2 +-
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  6 +-
 .../drm/bridge/analogix/analogix-anx6345.c|  2 +
 .../drm/bridge/analogix/analogix-anx78xx.c|  2 +
 .../drm/bridge/analogix/analogix_dp_core.c|  1 +
 .../drm/bridge/cadence/cdns-mhdp8546-core.c   | 14 ++-
 drivers/gpu/drm/bridge/tc358767.c |  5 +-
 drivers/gpu/drm/bridge/ti-sn65dsi86.c | 16 ++--
 drivers/gpu/drm/drm_dp_helper.c   | 88 ++-
 drivers/gpu/drm/i915/display/intel_dp_aux.c   | 10 ++-
 drivers/gpu/drm/i915/display/intel_dp_aux.h   |  2 +-
 drivers/gpu/drm/msm/dp/dp_aux.c   |  1 +
 drivers/gpu/drm/msm/edp/edp_aux.c |  1 +
 drivers/gpu/drm/nouveau/nouveau_connector.c   |  1 +
 drivers/gpu/drm/radeon/radeon_connectors.c|  1 +
 drivers/gpu/drm/tegra/dpaux.c | 14 ++-
 drivers/gpu/drm/xlnx/zynqmp_dp.c  |  1 +
 include/drm/drm_dp_helper.h   |  3 +-
 20 files changed, 140 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index b9c11c2b2885..23b2134a651b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -1963,8 +1963,11 @@ amdgpu_connector_add(struct amdgpu_device *adev,
 
connector->display_info.subpixel_order = subpixel_order;
 
-   if (has_aux)
-   amdgpu_atombios_dp_aux_init(amdgpu_connector);
+   if (has_aux) {
+   int ret = amdgpu_atombios_dp_aux_init(amdgpu_connector);
+   if (ret)
+   goto failed;
+   }
 
if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
connector_type == DRM_MODE_CONNECTOR_eDP) {
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c 
b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
index a3ba9ca11e98..54c209ab8c9f 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
@@ -184,12 +184,18 @@ amdgpu_atombios_dp_aux_transfer(struct drm_dp_aux *aux, 
struct drm_dp_aux_msg *m
return ret;
 }
 
-void amdgpu_atombios_dp_aux_init(struct amdgpu_connector *amdgpu_connector)
+int amdgpu_atombios_dp_aux_init(struct amdgpu_connector *amdgpu_connector)
 {
+   int ret;
+
amdgpu_connector->ddc_bus->rec.hpd = amdgpu_connector->hpd.hpd;
amdgpu_connector->ddc_bus->aux.transfer = 
amdgpu_atombios_dp_aux_transfer;
-   drm_dp_aux_init(_connector->ddc_bus->aux);
+   ret = drm_dp_aux_init(_connector->ddc_bus->aux);
+   if (ret)
+   return ret;
+
amdgpu_connector->ddc_bus->has_aux = true;
+   return ret;
 }
 
 /* general DP utility functions */
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.h 
b/drivers/gpu/drm/amd/amdgpu/atombios_dp.h
index f59d85eaddf0..6b65cbf009fd 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.h
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.h
@@ -24,7 +24,7 @@
 #ifndef __ATOMBIOS_DP_H__
 #define __ATOMBIOS_DP_H__
 
-void amdgpu_atombios_dp_aux_init(struct amdgpu_connector *amdgpu_connector);
+int amdgpu_atombios_dp_aux_init(struct amdgpu_connector *amdgpu_connector);
 u8 amdgpu_atombios_dp_get_sinktype(struct amdgpu_connector *amdgpu_connector);
 int 

[PATCH v3 02/20] drm/dp: Add __no_check to drm_dp_aux_register()

[Lyude Paul]

Since we're about to make it so that drm_dp_aux_init() can fail (and thus -
should have it's return value checked) - we should require that callers of
drm_dp_aux_register() also check it's return value since drm_dp_aux_init()
can be called from there.

Signed-off-by: Lyude Paul 
---
 include/drm/drm_dp_helper.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 1e85c2021f2f..e44b0ee7b85e 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -2010,7 +2010,7 @@ bool drm_dp_lttpr_pre_emphasis_level_3_supported(const u8 
caps[DP_LTTPR_PHY_CAP_
 
 void drm_dp_remote_aux_init(struct drm_dp_aux *aux);
 void drm_dp_aux_init(struct drm_dp_aux *aux);
-int drm_dp_aux_register(struct drm_dp_aux *aux);
+__must_check int drm_dp_aux_register(struct drm_dp_aux *aux);
 void drm_dp_aux_unregister(struct drm_dp_aux *aux);
 
 int drm_dp_start_crc(struct drm_dp_aux *aux, struct drm_crtc *crtc);
-- 
2.30.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 01/20] drm/amdgpu: Add error handling to amdgpu_dm_initialize_dp_connector()

[Lyude Paul]

While working on moving i2c device registration into drm_dp_aux_init() - I
realized that in order to do so we need to make sure that drivers calling
drm_dp_aux_init() handle any errors it could possibly return. In the
process of doing that, I noticed that the majority of AMD's code for DP
connector creation doesn't attempt to do any real error handling.

So, let's fix this and also cleanup amdgpu_dm_initialize_dp_connector()
while we're at it. This way we can handle the error codes from
drm_dp_aux_init().

Signed-off-by: Lyude Paul 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +++-
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   | 44 +++
 .../display/amdgpu_dm/amdgpu_dm_mst_types.h   |  6 +--
 3 files changed, 45 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index a0c8c41e4e57..fc5d315bbb05 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7608,10 +7608,9 @@ static int amdgpu_dm_connector_init(struct 
amdgpu_display_manager *dm,
 
aconnector->i2c = i2c;
res = i2c_add_adapter(>base);
-
if (res) {
DRM_ERROR("Failed to register hw i2c %d\n", link->link_index);
-   goto out_free;
+   goto fail_free;
}
 
connector_type = to_drm_connector_type(link->connector_signal);
@@ -7625,8 +7624,7 @@ static int amdgpu_dm_connector_init(struct 
amdgpu_display_manager *dm,
 
if (res) {
DRM_ERROR("connector_init failed\n");
-   aconnector->connector_id = -1;
-   goto out_free;
+   goto fail_id;
}
 
drm_connector_helper_add(
@@ -7643,15 +7641,22 @@ static int amdgpu_dm_connector_init(struct 
amdgpu_display_manager *dm,
drm_connector_attach_encoder(
>base, >base);
 
-   if (connector_type == DRM_MODE_CONNECTOR_DisplayPort
-   || connector_type == DRM_MODE_CONNECTOR_eDP)
-   amdgpu_dm_initialize_dp_connector(dm, aconnector, 
link->link_index);
-
-out_free:
-   if (res) {
-   kfree(i2c);
-   aconnector->i2c = NULL;
+   if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
+   connector_type == DRM_MODE_CONNECTOR_eDP) {
+   res = amdgpu_dm_initialize_dp_connector(dm, aconnector, 
link->link_index);
+   if (res)
+   goto fail_cleanup;
}
+
+   return 0;
+fail_cleanup:
+   drm_connector_cleanup(>base);
+fail_id:
+   aconnector->connector_id = -1;
+fail_free:
+   kfree(i2c);
+   aconnector->i2c = NULL;
+
return res;
 }
 
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 73cdb9fe981a..3dee9cce9c9e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -425,33 +425,39 @@ static const struct drm_dp_mst_topology_cbs dm_mst_cbs = {
.add_connector = dm_dp_add_mst_connector,
 };
 
-void amdgpu_dm_initialize_dp_connector(struct amdgpu_display_manager *dm,
-  struct amdgpu_dm_connector *aconnector,
-  int link_index)
+int amdgpu_dm_initialize_dp_connector(struct amdgpu_display_manager *dm,
+ struct amdgpu_dm_connector *aconnector,
+ int link_index)
 {
-   aconnector->dm_dp_aux.aux.name =
-   kasprintf(GFP_KERNEL, "AMDGPU DM aux hw bus %d",
- link_index);
-   aconnector->dm_dp_aux.aux.transfer = dm_dp_aux_transfer;
-   aconnector->dm_dp_aux.ddc_service = aconnector->dc_link->ddc;
+   struct amdgpu_dm_dp_aux *dm_aux = >dm_dp_aux;
+   int ret;
 
-   drm_dp_aux_init(>dm_dp_aux.aux);
-   drm_dp_cec_register_connector(>dm_dp_aux.aux,
- >base);
+   dm_aux->aux.name = kasprintf(GFP_KERNEL, "AMDGPU DM aux hw bus %d", 
link_index);
+   if (!dm_aux->aux.name)
+   return -ENOMEM;
+
+   dm_aux->aux.transfer = dm_dp_aux_transfer;
+   dm_aux->ddc_service = aconnector->dc_link->ddc;
+
+   drm_dp_aux_init(_aux->aux);
+   drm_dp_cec_register_connector(_aux->aux, >base);
 
if (aconnector->base.connector_type == DRM_MODE_CONNECTOR_eDP)
-   return;
+   return 0;
 
aconnector->mst_mgr.cbs = _mst_cbs;
-   drm_dp_mst_topology_mgr_init(
-   >mst_mgr,
-   adev_to_drm(dm->adev),
-   >dm_dp_aux.aux,
-   16,
-   4,
-   aconnector->connector_id);
+   ret = drm_dp_mst_topology_mgr_init(>mst_mgr, 
adev_to_drm(dm->adev),
+  

[PATCH v3 00/20] drm: Use new DRM printk funcs (like drm_dbg_*()) in DP helpers

[Lyude Paul]

Since it's been asked quite a few times on some of the various DP
related patch series I've submitted to use the new DRM printk helpers,
and it technically wasn't really trivial to do this before due to the
lack of a consistent way to find a drm_device for an AUX channel, this
patch series aims to address this. In this series we:

* (NEW!) Move i2c adapter setup into drm_dp_aux_init() and add
  drm_dp_aux_fini()
* Clean-up potentially erroneous usages of drm_dp_aux_init() and
  drm_dp_aux_register() so that actual AUX registration doesn't happen
  until we have an associated DRM device
* Clean-up any obvious errors in drivers we find along the way
* Add a backpointer to the respective drm_device for an AUX channel in
  drm_dp_aux.drm_dev, and hook it up in every driver with an AUX channel
  across the tree
* Add a new ratelimited print helper we'll need for converting the DP
  helpers over to using the new DRM printk helpers
* Fix any inconsistencies with logging in drm_dp_helper.c so we always
  have the aux channel name printed
* Prepare the various DP helpers so they can find the correct drm_device
  to use for logging
* And finally, convert all of the DP helpers over to using drm_dbg_*()
  and drm_err().

Lyude Paul (20):
  drm/amdgpu: Add error handling to amdgpu_dm_initialize_dp_connector()
  drm/dp: Add __no_check to drm_dp_aux_register()
  drm/dp: Move i2c init to drm_dp_aux_init, add __must_check and fini
  drm/bridge/cdns-mhdp8546: Register DP aux channel with userspace
  drm/nouveau/kms/nv50-: Move AUX adapter reg to connector late
register/early unregister
  drm/dp: Add backpointer to drm_device in drm_dp_aux
  drm/dp: Clarify DP AUX registration time
  drm/dp: Pass drm_dp_aux to drm_dp_link_train_clock_recovery_delay()
  drm/dp: Pass drm_dp_aux to drm_dp*_link_train_channel_eq_delay()
  drm/dp: Always print aux channel name in logs
  drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_detect()
  drm/dp_dual_mode: Pass drm_device to
drm_dp_dual_mode_set_tmds_output()
  drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_max_tmds_clock()
  drm/dp_dual_mode: Pass drm_device to
drm_dp_dual_mode_get_tmds_output()
  drm/dp_dual_mode: Pass drm_device to drm_lspcon_(get|set)_mode()
  drm/dp_mst: Pass drm_dp_mst_topology_mgr to drm_dp_get_vc_payload_bw()
  drm/print: Handle potentially NULL drm_devices in drm_dbg_*
  drm/dp: Convert drm_dp_helper.c to using drm_err/drm_dbg_*()
  drm/dp_dual_mode: Convert drm_dp_dual_mode_helper.c to using
drm_err/drm_dbg_kms()
  drm/dp_mst: Convert drm_dp_mst_topology.c to drm_err()/drm_dbg*()

 .../gpu/drm/amd/amdgpu/amdgpu_connectors.c|   7 +-
 drivers/gpu/drm/amd/amdgpu/atombios_dp.c  |  17 +-
 drivers/gpu/drm/amd/amdgpu/atombios_dp.h  |   2 +-
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  29 +-
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  49 ++-
 .../display/amdgpu_dm/amdgpu_dm_mst_types.h   |   6 +-
 .../drm/bridge/analogix/analogix-anx6345.c|   3 +
 .../drm/bridge/analogix/analogix-anx78xx.c|   3 +
 .../drm/bridge/analogix/analogix_dp_core.c|   2 +
 .../drm/bridge/cadence/cdns-mhdp8546-core.c   |  26 +-
 drivers/gpu/drm/bridge/tc358767.c |   6 +-
 drivers/gpu/drm/bridge/ti-sn65dsi86.c |  17 +-
 drivers/gpu/drm/drm_dp_aux_dev.c  |   6 +
 drivers/gpu/drm/drm_dp_dual_mode_helper.c |  68 ++--
 drivers/gpu/drm/drm_dp_helper.c   | 260 +++-
 drivers/gpu/drm/drm_dp_mst_topology.c | 376 +-
 drivers/gpu/drm/i915/display/intel_dp_aux.c   |  11 +-
 drivers/gpu/drm/i915/display/intel_dp_aux.h   |   2 +-
 .../drm/i915/display/intel_dp_link_training.c |   6 +-
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |   3 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c |   7 +-
 drivers/gpu/drm/i915/display/intel_lspcon.c   |  17 +-
 drivers/gpu/drm/msm/dp/dp_aux.c   |   1 +
 drivers/gpu/drm/msm/dp/dp_ctrl.c  |   6 +-
 drivers/gpu/drm/msm/edp/edp.h |   3 +-
 drivers/gpu/drm/msm/edp/edp_aux.c |   6 +-
 drivers/gpu/drm/msm/edp/edp_ctrl.c|   8 +-
 drivers/gpu/drm/nouveau/nouveau_connector.c   |  27 +-
 drivers/gpu/drm/radeon/atombios_dp.c  |   5 +-
 drivers/gpu/drm/radeon/radeon_connectors.c|   1 +
 drivers/gpu/drm/tegra/dpaux.c |  15 +-
 drivers/gpu/drm/xlnx/zynqmp_dp.c  |   6 +-
 include/drm/drm_dp_dual_mode_helper.h |  14 +-
 include/drm/drm_dp_helper.h   |  24 +-
 include/drm/drm_dp_mst_helper.h   |   3 +-
 include/drm/drm_print.h   |  20 +-
 36 files changed, 631 insertions(+), 431 deletions(-)

-- 
2.30.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] dma-buf: Add DmaBufTotal counter in meminfo

[Michal Hocko]

On Mon 19-04-21 17:44:13, Christian König wrote:
> Am 19.04.21 um 17:19 schrieb peter.enderb...@sony.com:
> > On 4/19/21 5:00 PM, Michal Hocko wrote:
> > > On Mon 19-04-21 12:41:58, peter.enderb...@sony.com wrote:
> > > > On 4/19/21 2:16 PM, Michal Hocko wrote:
> > > > > On Sat 17-04-21 12:40:32, Peter Enderborg wrote:
> > > > > > This adds a total used dma-buf memory. Details
> > > > > > can be found in debugfs, however it is not for everyone
> > > > > > and not always available. dma-buf are indirect allocated by
> > > > > > userspace. So with this value we can monitor and detect
> > > > > > userspace applications that have problems.
> > > > > The changelog would benefit from more background on why this is 
> > > > > needed,
> > > > > and who is the primary consumer of that value.
> > > > > 
> > > > > I cannot really comment on the dma-buf internals but I have two 
> > > > > remarks.
> > > > > Documentation/filesystems/proc.rst needs an update with the counter
> > > > > explanation and secondly is this information useful for OOM situations
> > > > > analysis? If yes then show_mem should dump the value as well.
> > > > > 
> > > > >  From the implementation point of view, is there any reason why this
> > > > > hasn't used the existing global_node_page_state infrastructure?
> > > > I fix doc in next version.  Im not sure what you expect the commit 
> > > > message to include.
> > > As I've said. Usual justification covers answers to following questions
> > >   - Why do we need it?
> > >   - Why the existing data is insuficient?
> > >   - Who is supposed to use the data and for what?
> > > 
> > > I can see an answer for the first two questions (because this can be a
> > > lot of memory and the existing infrastructure is not production suitable
> > > - debugfs). But the changelog doesn't really explain who is going to use
> > > the new data. Is this a monitoring to raise an early alarm when the
> > > value grows? Is this for debugging misbehaving drivers? How is it
> > > valuable for those?
> > > 
> > > > The function of the meminfo is: (From 
> > > > Documentation/filesystems/proc.rst)
> > > > 
> > > > "Provides information about distribution and utilization of memory."
> > > True. Yet we do not export any random counters, do we?
> > > 
> > > > Im not the designed of dma-buf, I think  global_node_page_state as a 
> > > > kernel
> > > > internal.
> > > It provides a node specific and optimized counters. Is this a good fit
> > > with your new counter? Or the NUMA locality is of no importance?
> > Sounds good to me, if Christian Koenig think it is good, I will use that.
> > It is only virtio in drivers that use the global_node_page_state if
> > that matters.
> 
> DMA-buf are not NUMA aware at all. On which node the pages are allocated
> (and if we use pages at all and not internal device memory) is up to the
> exporter and importer.

The question is not whether it is NUMA aware but whether it is useful to
know per-numa data for the purpose the counter is supposed to serve.
-- 
Michal Hocko
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] dma-buf: Add DmaBufTotal counter in meminfo

[Michal Hocko]

On Mon 19-04-21 12:41:58, peter.enderb...@sony.com wrote:
> On 4/19/21 2:16 PM, Michal Hocko wrote:
> > On Sat 17-04-21 12:40:32, Peter Enderborg wrote:
> >> This adds a total used dma-buf memory. Details
> >> can be found in debugfs, however it is not for everyone
> >> and not always available. dma-buf are indirect allocated by
> >> userspace. So with this value we can monitor and detect
> >> userspace applications that have problems.
> > The changelog would benefit from more background on why this is needed,
> > and who is the primary consumer of that value.
> >
> > I cannot really comment on the dma-buf internals but I have two remarks.
> > Documentation/filesystems/proc.rst needs an update with the counter
> > explanation and secondly is this information useful for OOM situations
> > analysis? If yes then show_mem should dump the value as well.
> >
> > From the implementation point of view, is there any reason why this
> > hasn't used the existing global_node_page_state infrastructure?
> 
> I fix doc in next version.  Im not sure what you expect the commit message to 
> include.

As I've said. Usual justification covers answers to following questions
- Why do we need it?
- Why the existing data is insuficient?
- Who is supposed to use the data and for what?

I can see an answer for the first two questions (because this can be a
lot of memory and the existing infrastructure is not production suitable
- debugfs). But the changelog doesn't really explain who is going to use
the new data. Is this a monitoring to raise an early alarm when the
value grows? Is this for debugging misbehaving drivers? How is it
valuable for those?

> The function of the meminfo is: (From Documentation/filesystems/proc.rst)
> 
> "Provides information about distribution and utilization of memory."

True. Yet we do not export any random counters, do we?

> Im not the designed of dma-buf, I think  global_node_page_state as a kernel
> internal.

It provides a node specific and optimized counters. Is this a good fit
with your new counter? Or the NUMA locality is of no importance?

> dma-buf is a device driver that provides a function so I might be
> on the outside. However I also see that it might be relevant for a OOM.
> It is memory that can be freed by killing userspace processes.
> 
> The show_mem thing. Should it be a separate patch?

This is up to you but if you want to expose the counter then send it in
one series.

-- 
Michal Hocko
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm/vmwgfx fixes for 5.12-rc8

[Daniel Vetter]

On Sun, Apr 18, 2021 at 1:03 AM Dave Airlie  wrote:
>
> Hi Zack,
>
> Please make sure to always cc dri-devel and/or Daniel on these so if
> I'm away they don't get lost, but also so that they make it into
> patchwork for processing.
>
> If you have a chance can you resend it, I'll see if we can process
> this out of band and get it to Linus before release.

Or use drm-misc-fixes train, usually it leaves on schedul :-)
-Daniel

>
> Dave.
>
> On Thu, 15 Apr 2021 at 07:14, Zack Rusin  wrote:
> >
> > The following changes since commit d434405aaab7d0ebc516b68a8fc4100922d7f5ef:
> >
> >Linux 5.12-rc7 (2021-04-11 15:16:13 -0700)
> >
> > are available in the Git repository at:
> >
> >g...@gitlab.freedesktop.org:zack/vmwgfx.git tags/vmwgfx-fixes-2021-04-14
> >
> > for you to fetch changes up to 2ef4fb92363c44e8a6f93fd0877b6a7dee6f874d:
> >
> >drm/vmwgfx: Make sure bo's are unpinned before putting them back 
> > (2021-04-14 16:41:31 -0400)
> >
> > 
> > vmwgfx fixes for regressions in 5.12
> >
> > Here's a set of 3 patches fixing ugly regressions
> > in the vmwgfx driver. We broke lock initialization
> > code and ended up using spinlocks before initialization
> > breaking lockdep.
> > Also there was a bit of a fallout from drm changes
> > which made the core validate that unreferenced buffers
> > have been unpinned. vmwgfx pinning code predates a lot
> > of the core drm and wasn't written to account for those
> > semantics. Fortunately changes required to fix it
> > are not too intrusive.
> > The changes have been validated by our internal ci.
> >
> > Signed-off-by: Zack Rusin 
> >
> > 
> > Zack Rusin (3):
> >drm/vmwgfx: Make sure we unpin no longer needed buffers
> >drm/vmwgfx: Fix the lockdep breakage
> >drm/vmwgfx: Make sure bo's are unpinned before putting them back
> >
> >   drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c |  4 
> >   drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 17 -
> >   drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |  5 +
> >   drivers/gpu/drm/vmwgfx/vmwgfx_mob.c | 14 ++
> >   4 files changed, 27 insertions(+), 13 deletions(-)



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] drm/bridge/sii8620: fix dependency on extcon

[Randy Dunlap]

On 4/19/21 10:10 AM, Randy Dunlap wrote:
> On 4/19/21 2:01 AM, Robert Foss wrote:
>> The DRM_SIL_SII8620 kconfig has a weak `imply` dependency
>> on EXTCON, which causes issues when sii8620 is built
>> as a builtin and EXTCON is built as a module.
>>
>> The symptoms are 'undefined reference' errors caused
>> by the symbols in EXTCON not being available
>> to the sii8620 driver.
>>
>> Fixes: 688838442147 ("drm/bridge/sii8620: use micro-USB cable detection 
>> logic to detect MHL")
>> Signed-off-by: Robert Foss 
>> Reported-by: kernel test robot 
>> ---
>>
>> LKP reported issue:
>> https://lore.kernel.org/lkml/202104040604.sste2cxf-...@intel.com/
>>
>>
>> Changes since v1:
>>  - Fix typo on comment
>>
>> Changes since v2:
>>  - Randy: Changed from `depends` to `select` 
> 
> I don't know why my name is on that. I didn't
> suggest any change -- I just reported that v2
> had a problem.
> 
> 
>>
>>
>>  drivers/gpu/drm/bridge/Kconfig | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>> index 22a467abd3e9..70402da5cc70 100644
>> --- a/drivers/gpu/drm/bridge/Kconfig
>> +++ b/drivers/gpu/drm/bridge/Kconfig
>> @@ -169,7 +169,7 @@ config DRM_SIL_SII8620
>>  tristate "Silicon Image SII8620 HDMI/MHL bridge"
>>  depends on OF
>>  select DRM_KMS_HELPER
>> -imply EXTCON
>> +select EXTCON
>>  depends on RC_CORE || !RC_CORE
>>  help
>>Silicon Image SII8620 HDMI/MHL bridge chip driver.
> 
> 
> Thanks. Works For Me.
> 
> Acked-by: Randy Dunlap  # build-tested

Actually I can upgrade that to:

Reviewed-by: Randy Dunlap 


ta.
-- 
~Randy

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] drm/bridge/sii8620: fix dependency on extcon

[Robert Foss]

On Mon, Apr 19, 2021, 19:11 Randy Dunlap  wrote:

> On 4/19/21 2:01 AM, Robert Foss wrote:
> > The DRM_SIL_SII8620 kconfig has a weak `imply` dependency
> > on EXTCON, which causes issues when sii8620 is built
> > as a builtin and EXTCON is built as a module.
> >
> > The symptoms are 'undefined reference' errors caused
> > by the symbols in EXTCON not being available
> > to the sii8620 driver.
> >
> > Fixes: 688838442147 ("drm/bridge/sii8620: use micro-USB cable detection
> logic to detect MHL")
> > Signed-off-by: Robert Foss 
> > Reported-by: kernel test robot 
> > ---
> >
> > LKP reported issue:
> > https://lore.kernel.org/lkml/202104040604.sste2cxf-...@intel.com/
> >
> >
> > Changes since v1:
> >  - Fix typo on comment
> >
> > Changes since v2:
> >  - Randy: Changed from `depends` to `select`
>
> I don't know why my name is on that. I didn't
> suggest any change -- I just reported that v2
> had a problem.
>

Credit where credit is due :)


>
> >
> >
> >  drivers/gpu/drm/bridge/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/Kconfig
> b/drivers/gpu/drm/bridge/Kconfig
> > index 22a467abd3e9..70402da5cc70 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -169,7 +169,7 @@ config DRM_SIL_SII8620
> >   tristate "Silicon Image SII8620 HDMI/MHL bridge"
> >   depends on OF
> >   select DRM_KMS_HELPER
> > - imply EXTCON
> > + select EXTCON
> >   depends on RC_CORE || !RC_CORE
> >   help
> > Silicon Image SII8620 HDMI/MHL bridge chip driver.
>
>
> Thanks. Works For Me.
>
> Acked-by: Randy Dunlap  # build-tested
>
> --
> ~Randy
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] drm/bridge/sii8620: fix dependency on extcon

[Randy Dunlap]

On 4/19/21 2:01 AM, Robert Foss wrote:
> The DRM_SIL_SII8620 kconfig has a weak `imply` dependency
> on EXTCON, which causes issues when sii8620 is built
> as a builtin and EXTCON is built as a module.
> 
> The symptoms are 'undefined reference' errors caused
> by the symbols in EXTCON not being available
> to the sii8620 driver.
> 
> Fixes: 688838442147 ("drm/bridge/sii8620: use micro-USB cable detection logic 
> to detect MHL")
> Signed-off-by: Robert Foss 
> Reported-by: kernel test robot 
> ---
> 
> LKP reported issue:
> https://lore.kernel.org/lkml/202104040604.sste2cxf-...@intel.com/
> 
> 
> Changes since v1:
>  - Fix typo on comment
> 
> Changes since v2:
>  - Randy: Changed from `depends` to `select` 

I don't know why my name is on that. I didn't
suggest any change -- I just reported that v2
had a problem.


> 
> 
>  drivers/gpu/drm/bridge/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 22a467abd3e9..70402da5cc70 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -169,7 +169,7 @@ config DRM_SIL_SII8620
>   tristate "Silicon Image SII8620 HDMI/MHL bridge"
>   depends on OF
>   select DRM_KMS_HELPER
> - imply EXTCON
> + select EXTCON
>   depends on RC_CORE || !RC_CORE
>   help
> Silicon Image SII8620 HDMI/MHL bridge chip driver.


Thanks. Works For Me.

Acked-by: Randy Dunlap  # build-tested

-- 
~Randy

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4] drm/doc/rfc: i915 DG1 uAPI

[Matthew Auld]

Add an entry for the new uAPI needed for DG1. Also add the overall
upstream plan, including some notes for the TTM conversion.

v2(Daniel):
  - include the overall upstreaming plan
  - add a note for mmap, there are differences here for TTM vs i915
  - bunch of other suggestions from Daniel
v3:
 (Daniel)
  - add a note for set/get caching stuff
  - add some more docs for existing query and extensions stuff
  - add an actual code example for regions query
  - bunch of other stuff
 (Jason)
  - uAPI change(!):
- try a simpler design with the placements extension
- rather than have a generic setparam which can cover multiple
  use cases, have each extension be responsible for one thing
  only
v4:
 (Daniel)
  - add some more notes for ttm conversion
  - bunch of other stuff
 (Jason)
  - uAPI change(!):
- drop all the extra rsvd members for the region_query and
  region_info, just keep the bare minimum needed for padding

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Thomas Hellström 
Cc: Daniele Ceraolo Spurio 
Cc: Lionel Landwerlin 
Cc: Jon Bloomfield 
Cc: Jordan Justen 
Cc: Daniel Vetter 
Cc: Kenneth Graunke 
Cc: Jason Ekstrand 
Cc: Dave Airlie 
Cc: dri-devel@lists.freedesktop.org
Cc: mesa-...@lists.freedesktop.org
Acked-by: Daniel Vetter 
---
 Documentation/gpu/rfc/i915_gem_lmem.h   | 212 
 Documentation/gpu/rfc/i915_gem_lmem.rst | 130 +++
 Documentation/gpu/rfc/index.rst |   4 +
 3 files changed, 346 insertions(+)
 create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.h
 create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.rst

diff --git a/Documentation/gpu/rfc/i915_gem_lmem.h 
b/Documentation/gpu/rfc/i915_gem_lmem.h
new file mode 100644
index ..7ed59b6202d5
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_gem_lmem.h
@@ -0,0 +1,212 @@
+/**
+ * enum drm_i915_gem_memory_class - Supported memory classes
+ */
+enum drm_i915_gem_memory_class {
+   /** @I915_MEMORY_CLASS_SYSTEM: System memory */
+   I915_MEMORY_CLASS_SYSTEM = 0,
+   /** @I915_MEMORY_CLASS_DEVICE: Device local-memory */
+   I915_MEMORY_CLASS_DEVICE,
+};
+
+/**
+ * struct drm_i915_gem_memory_class_instance - Identify particular memory 
region
+ */
+struct drm_i915_gem_memory_class_instance {
+   /** @memory_class: See enum drm_i915_gem_memory_class */
+   __u16 memory_class;
+
+   /** @memory_instance: Which instance */
+   __u16 memory_instance;
+};
+
+/**
+ * struct drm_i915_memory_region_info - Describes one region as known to the
+ * driver.
+ *
+ * Note that we reserve some stuff here for potential future work. As an 
example
+ * we might want expose the capabilities(see @caps) for a given region, which
+ * could include things like if the region is CPU mappable/accessible, what are
+ * the supported mapping types etc.
+ *
+ * Note this is using both struct drm_i915_query_item and struct 
drm_i915_query.
+ * For this new query we are adding the new query id 
DRM_I915_QUERY_MEMORY_REGIONS
+ * at _i915_query_item.query_id.
+ */
+struct drm_i915_memory_region_info {
+   /** @region: The class:instance pair encoding */
+   struct drm_i915_gem_memory_class_instance region;
+
+   /** @pad: MBZ */
+   __u32 pad;
+
+   /** @caps: MBZ */
+   __u64 caps;
+
+   /** @probed_size: Memory probed by the driver (-1 = unknown) */
+   __u64 probed_size;
+
+   /** @unallocated_size: Estimate of memory remaining (-1 = unknown) */
+   __u64 unallocated_size;
+};
+
+/**
+ * struct drm_i915_query_memory_regions
+ *
+ * The region info query enumerates all regions known to the driver by filling
+ * in an array of struct drm_i915_memory_region_info structures.
+ *
+ * Example for getting the list of supported regions:
+ *
+ * .. code-block:: C
+ *
+ * struct drm_i915_query_memory_regions *info;
+ * struct drm_i915_query_item item = {
+ * .query_id = DRM_I915_QUERY_MEMORY_REGIONS;
+ * };
+ * struct drm_i915_query query = {
+ * .num_items = 1,
+ * .items_ptr = (uintptr_t),
+ * };
+ * int err, i;
+ *
+ * // First query the size of the blob we need, this needs to be large
+ * // enough to hold our array of regions. The kernel will fill out the
+ * // item.length for us, which is the number of bytes we need.
+ * err = ioctl(fd, DRM_IOCTL_I915_QUERY, );
+ * if (err) ...
+ *
+ * info = calloc(1, item.length);
+ * // Now that we allocated the required number of bytes, we call the ioctl
+ * // again, this time with the data_ptr pointing to our newly allocated
+ * // blob, which the kernel can then populate with the all the region 
info.
+ * item.data_ptr = (uintptr_t),
+ *
+ * err = ioctl(fd, DRM_IOCTL_I915_QUERY, );
+ * if (err) ...
+ *
+ * // We can now access each region in the array
+ * for (i = 0; i < info->num_regions; i++) {
+ * struct 

Re: [Nouveau] [PATCH] drm/nouveau: fix an error code in nouveau_backlight_init()

[Pierre Moreau]

I can not remember why the original code did return 0 rather than an error, but
-ENOMEM seems indeed way more fitting.

Reviewed-by: Pierre Moreau 

On 2021-04-14 — 08:58, Dan Carpenter wrote:
> If nouveau_get_backlight_name() fails then this should return -ENOMEM
> but currently it returns success.
> 
> Fixes: db1a0ae21461 ("drm/nouveau/bl: Assign different names to interfaces")
> Signed-off-by: Dan Carpenter 
> ---
> This is from static analysis.  In the original commit db1a0ae21461
> ("drm/nouveau/bl: Assign different names to interfaces") then returning
> zero seemed to be a very deliberate choice.  I do think it was wrong
> though and -ENOMEM is the currect return.
> 
>  drivers/gpu/drm/nouveau/nouveau_backlight.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> index 72f35a2babcb..3786b1c85182 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> @@ -274,6 +274,7 @@ nouveau_backlight_init(struct drm_connector *connector)
>  
>   if (!nouveau_get_backlight_name(backlight_name, bl)) {
>   NV_ERROR(drm, "Failed to retrieve a unique name for the 
> backlight interface\n");
> + ret = -ENOMEM;
>   goto fail_alloc;
>   }
>  
> -- 
> 2.30.2
> 
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] dt-bindings: Add E Ink to vendor bindings

[Alistair Francis]

Add the E Ink Corporation to the vendor bindings.

Signed-off-by: Alistair Francis 
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml 
b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 996f4de2fff5..6c9323dc9b78 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -329,6 +329,8 @@ patternProperties:
 description: eGalax_eMPIA Technology Inc
   "^einfochips,.*":
 description: Einfochips
+  "^eink,.*":
+description: E Ink Corporation
   "^elan,.*":
 description: Elan Microelectronic Corp.
   "^element14,.*":
-- 
2.31.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/panel: Add support for E Ink VB3300-KCA

[Alistair Francis]

Add support for the 10.3" E Ink panel described at:
https://www.eink.com/product.html?type=productdetail=7

Signed-off-by: Alistair Francis 
---
 drivers/gpu/drm/panel/panel-simple.c | 29 
 1 file changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 4e2dad314c79..f1f6fd2517f6 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1964,6 +1964,32 @@ static const struct panel_desc edt_etm0700g0bdh6 = {
.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
 };
 
+static const struct display_timing eink_vb3300_kca_timing = {
+   .pixelclock = { 4000, 4000, 4000 },
+   .hactive = { 334, 334, 334 },
+   .hfront_porch = { 1, 1, 1 },
+   .hback_porch = { 1, 1, 1 },
+   .hsync_len = { 1, 1, 1 },
+   .vactive = { 1405, 1405, 1405 },
+   .vfront_porch = { 1, 1, 1 },
+   .vback_porch = { 1, 1, 1 },
+   .vsync_len = { 1, 1, 1 },
+   .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
+DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE,
+};
+
+static const struct panel_desc eink_vb3300_kca = {
+   .modes = _etm0700g0dh6_mode,
+   .num_modes = 1,
+   .bpc = 6,
+   .size = {
+   .width = 157,
+   .height = 209,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+   .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
+};
+
 static const struct display_timing evervision_vgg804821_timing = {
.pixelclock = { 2760, 3330, 5000 },
.hactive = { 800, 800, 800 },
@@ -4232,6 +4258,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "edt,etm0700g0dh6",
.data = _etm0700g0dh6,
+   }, {
+   .compatible = "eink,vb3300-kca",
+   .data = _vb3300_kca,
}, {
.compatible = "edt,etm0700g0bdh6",
.data = _etm0700g0bdh6,
-- 
2.31.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: remove special handling for non GEM drivers

[Nirmoy]

Tested-by: Nirmoy Das 

On 4/19/21 11:28 AM, Christian König wrote:

vmwgfx is the only driver actually using this. Move the handling into
the driver instead.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/ttm/ttm_bo.c   | 11 ---
  drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 10 ++
  include/drm/ttm/ttm_bo_api.h   | 19 ---
  3 files changed, 10 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 80831df0ef61..38183e227116 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -460,8 +460,6 @@ static void ttm_bo_release(struct kref *kref)
  
  	atomic_dec(_glob.bo_count);

dma_fence_put(bo->moving);
-   if (!ttm_bo_uses_embedded_gem_object(bo))
-   dma_resv_fini(>base._resv);
bo->destroy(bo);
  }
  
@@ -1056,15 +1054,6 @@ int ttm_bo_init_reserved(struct ttm_device *bdev,

} else {
bo->base.resv = >base._resv;
}
-   if (!ttm_bo_uses_embedded_gem_object(bo)) {
-   /*
-* bo.base is not initialized, so we have to setup the
-* struct elements we want use regardless.
-*/
-   bo->base.size = size;
-   dma_resv_init(>base._resv);
-   drm_vma_node_reset(>base.vma_node);
-   }
atomic_inc(_glob.bo_count);
  
  	/*

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index 50e529a01677..587314d57991 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -460,6 +460,7 @@ void vmw_bo_bo_free(struct ttm_buffer_object *bo)
WARN_ON(vmw_bo->dirty);
WARN_ON(!RB_EMPTY_ROOT(_bo->res_tree));
vmw_bo_unmap(vmw_bo);
+   dma_resv_fini(>base._resv);
kfree(vmw_bo);
  }
  
@@ -512,6 +513,11 @@ int vmw_bo_create_kernel(struct vmw_private *dev_priv, unsigned long size,

if (unlikely(ret))
goto error_free;
  
+

+   bo->base.size = size;
+   dma_resv_init(>base._resv);
+   drm_vma_node_reset(>base.vma_node);
+
ret = ttm_bo_init_reserved(_priv->bdev, bo, size,
   ttm_bo_type_device, placement, 0,
   , NULL, NULL, NULL);
@@ -570,6 +576,10 @@ int vmw_bo_init(struct vmw_private *dev_priv,
if (unlikely(ret))
return ret;
  
+	vmw_bo->base.base.size = size;

+   dma_resv_init(_bo->base.base._resv);
+   drm_vma_node_reset(_bo->base.base.vma_node);
+
ret = ttm_bo_init_reserved(bdev, _bo->base, size,
   ttm_bo_type_device, placement,
   0, , NULL, NULL, bo_free);
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 3587f660e8f4..e88da481a976 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -562,25 +562,6 @@ ssize_t ttm_bo_io(struct ttm_device *bdev, struct file 
*filp,
  int ttm_bo_swapout(struct ttm_buffer_object *bo, struct ttm_operation_ctx 
*ctx,
   gfp_t gfp_flags);
  
-/**

- * ttm_bo_uses_embedded_gem_object - check if the given bo uses the
- * embedded drm_gem_object.
- *
- * Most ttm drivers are using gem too, so the embedded
- * ttm_buffer_object.base will be initialized by the driver (before
- * calling ttm_bo_init).  It is also possible to use ttm without gem
- * though (vmwgfx does that).
- *
- * This helper will figure whenever a given ttm bo is a gem object too
- * or not.
- *
- * @bo: The bo to check.
- */
-static inline bool ttm_bo_uses_embedded_gem_object(struct ttm_buffer_object 
*bo)
-{
-   return bo->base.dev != NULL;
-}
-
  /**
   * ttm_bo_pin - Pin the buffer object.
   * @bo: The buffer object to pin

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] dma-buf: Add DmaBufTotal counter in meminfo

[Christian König]

Am 19.04.21 um 18:11 schrieb Michal Hocko:

On Mon 19-04-21 17:44:13, Christian König wrote:

Am 19.04.21 um 17:19 schrieb peter.enderb...@sony.com:

On 4/19/21 5:00 PM, Michal Hocko wrote:

On Mon 19-04-21 12:41:58, peter.enderb...@sony.com wrote:

On 4/19/21 2:16 PM, Michal Hocko wrote:

On Sat 17-04-21 12:40:32, Peter Enderborg wrote:

This adds a total used dma-buf memory. Details
can be found in debugfs, however it is not for everyone
and not always available. dma-buf are indirect allocated by
userspace. So with this value we can monitor and detect
userspace applications that have problems.

The changelog would benefit from more background on why this is needed,
and who is the primary consumer of that value.

I cannot really comment on the dma-buf internals but I have two remarks.
Documentation/filesystems/proc.rst needs an update with the counter
explanation and secondly is this information useful for OOM situations
analysis? If yes then show_mem should dump the value as well.

  From the implementation point of view, is there any reason why this
hasn't used the existing global_node_page_state infrastructure?

I fix doc in next version.  Im not sure what you expect the commit message to 
include.

As I've said. Usual justification covers answers to following questions
- Why do we need it?
- Why the existing data is insuficient?
- Who is supposed to use the data and for what?

I can see an answer for the first two questions (because this can be a
lot of memory and the existing infrastructure is not production suitable
- debugfs). But the changelog doesn't really explain who is going to use
the new data. Is this a monitoring to raise an early alarm when the
value grows? Is this for debugging misbehaving drivers? How is it
valuable for those?


The function of the meminfo is: (From Documentation/filesystems/proc.rst)

"Provides information about distribution and utilization of memory."

True. Yet we do not export any random counters, do we?


Im not the designed of dma-buf, I think  global_node_page_state as a kernel
internal.

It provides a node specific and optimized counters. Is this a good fit
with your new counter? Or the NUMA locality is of no importance?

Sounds good to me, if Christian Koenig think it is good, I will use that.
It is only virtio in drivers that use the global_node_page_state if
that matters.

DMA-buf are not NUMA aware at all. On which node the pages are allocated
(and if we use pages at all and not internal device memory) is up to the
exporter and importer.

The question is not whether it is NUMA aware but whether it is useful to
know per-numa data for the purpose the counter is supposed to serve.


No, not at all. The pages of a single DMA-buf could even be from 
different NUMA nodes if the exporting driver decides that this is 
somehow useful.


Christian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] dma-buf: Add DmaBufTotal counter in meminfo

[Michal Hocko]

On Sat 17-04-21 12:40:32, Peter Enderborg wrote:
> This adds a total used dma-buf memory. Details
> can be found in debugfs, however it is not for everyone
> and not always available. dma-buf are indirect allocated by
> userspace. So with this value we can monitor and detect
> userspace applications that have problems.

The changelog would benefit from more background on why this is needed,
and who is the primary consumer of that value.

I cannot really comment on the dma-buf internals but I have two remarks.
Documentation/filesystems/proc.rst needs an update with the counter
explanation and secondly is this information useful for OOM situations
analysis? If yes then show_mem should dump the value as well.

>From the implementation point of view, is there any reason why this
hasn't used the existing global_node_page_state infrastructure?
-- 
Michal Hocko
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] dma-buf: Add DmaBufTotal counter in meminfo

[Peter.Enderborg]

On 4/19/21 5:00 PM, Michal Hocko wrote:
> On Mon 19-04-21 12:41:58, peter.enderb...@sony.com wrote:
>> On 4/19/21 2:16 PM, Michal Hocko wrote:
>>> On Sat 17-04-21 12:40:32, Peter Enderborg wrote:
 This adds a total used dma-buf memory. Details
 can be found in debugfs, however it is not for everyone
 and not always available. dma-buf are indirect allocated by
 userspace. So with this value we can monitor and detect
 userspace applications that have problems.
>>> The changelog would benefit from more background on why this is needed,
>>> and who is the primary consumer of that value.
>>>
>>> I cannot really comment on the dma-buf internals but I have two remarks.
>>> Documentation/filesystems/proc.rst needs an update with the counter
>>> explanation and secondly is this information useful for OOM situations
>>> analysis? If yes then show_mem should dump the value as well.
>>>
>>> From the implementation point of view, is there any reason why this
>>> hasn't used the existing global_node_page_state infrastructure?
>> I fix doc in next version.  Im not sure what you expect the commit message 
>> to include.
> As I've said. Usual justification covers answers to following questions
>   - Why do we need it?
>   - Why the existing data is insuficient?
>   - Who is supposed to use the data and for what?
>
> I can see an answer for the first two questions (because this can be a
> lot of memory and the existing infrastructure is not production suitable
> - debugfs). But the changelog doesn't really explain who is going to use
> the new data. Is this a monitoring to raise an early alarm when the
> value grows? Is this for debugging misbehaving drivers? How is it
> valuable for those?
>
>> The function of the meminfo is: (From Documentation/filesystems/proc.rst)
>>
>> "Provides information about distribution and utilization of memory."
> True. Yet we do not export any random counters, do we?
>
>> Im not the designed of dma-buf, I think  global_node_page_state as a kernel
>> internal.
> It provides a node specific and optimized counters. Is this a good fit
> with your new counter? Or the NUMA locality is of no importance?

Sounds good to me, if Christian Koenig think it is good, I will use that.
It is only virtio in drivers that use the global_node_page_state if
that matters.


>
>> dma-buf is a device driver that provides a function so I might be
>> on the outside. However I also see that it might be relevant for a OOM.
>> It is memory that can be freed by killing userspace processes.
>>
>> The show_mem thing. Should it be a separate patch?
> This is up to you but if you want to expose the counter then send it in
> one series.
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

[Jason Ekstrand]

Not going to comment on everything on the first pass...

On Mon, Apr 19, 2021 at 5:48 AM Marek Olšák  wrote:
>
> Hi,
>
> This is our initial proposal for explicit fences everywhere and new memory 
> management that doesn't use BO fences. It's a redesign of how Linux graphics 
> drivers work, and it can coexist with what we have now.
>
>
> 1. Introduction
> (skip this if you are already sold on explicit fences)
>
> The current Linux graphics architecture was initially designed for GPUs with 
> only one graphics queue where everything was executed in the submission order 
> and per-BO fences were used for memory management and CPU-GPU 
> synchronization, not GPU-GPU synchronization. Later, multiple queues were 
> added on top, which required the introduction of implicit GPU-GPU 
> synchronization between queues of different processes using per-BO fences. 
> Recently, even parallel execution within one queue was enabled where a 
> command buffer starts draws and compute shaders, but doesn't wait for them, 
> enabling parallelism between back-to-back command buffers. Modesetting also 
> uses per-BO fences for scheduling flips. Our GPU scheduler was created to 
> enable all those use cases, and it's the only reason why the scheduler exists.
>
> The GPU scheduler, implicit synchronization, BO-fence-based memory 
> management, and the tracking of per-BO fences increase CPU overhead and 
> latency, and reduce parallelism. There is a desire to replace all of them 
> with something much simpler. Below is how we could do it.
>
>
> 2. Explicit synchronization for window systems and modesetting
>
> The producer is an application and the consumer is a compositor or a 
> modesetting driver.
>
> 2.1. The Present request
>
> As part of the Present request, the producer will pass 2 fences (sync 
> objects) to the consumer alongside the presented DMABUF BO:
> - The submit fence: Initially unsignalled, it will be signalled when the 
> producer has finished drawing into the presented buffer.
> - The return fence: Initially unsignalled, it will be signalled when the 
> consumer has finished using the presented buffer.

I'm not sure syncobj is what we want.  In the Intel world we're trying
to go even further to something we're calling "userspace fences" which
are a timeline implemented as a single 64-bit value in some
CPU-mappable BO.  The client writes a higher value into the BO to
signal the timeline.  The kernel then provides some helpers for
waiting on them reliably and without spinning.  I don't expect
everyone to support these right away but, If we're going to re-plumb
userspace for explicit synchronization, I'd like to make sure we take
this into account so we only have to do it once.


> Deadlock mitigation to recover from segfaults:
> - The kernel knows which process is obliged to signal which fence. This 
> information is part of the Present request and supplied by userspace.

This isn't clear to me.  Yes, if we're using anything dma-fence based
like syncobj, this is true.  But it doesn't seem totally true as a
general statement.


> - If the producer crashes, the kernel signals the submit fence, so that the 
> consumer can make forward progress.
> - If the consumer crashes, the kernel signals the return fence, so that the 
> producer can reclaim the buffer.
> - A GPU hang signals all fences. Other deadlocks will be handled like GPU 
> hangs.

What do you mean by "all"?  All fences that were supposed to be
signaled by the hung context?


>
> Other window system requests can follow the same idea.
>
> Merged fences where one fence object contains multiple fences will be 
> supported. A merged fence is signalled only when its fences are signalled. 
> The consumer will have the option to redefine the unsignalled return fence to 
> a merged fence.
>
> 2.2. Modesetting
>
> Since a modesetting driver can also be the consumer, the present ioctl will 
> contain a submit fence and a return fence too. One small problem with this is 
> that userspace can hang the modesetting driver, but in theory, any later 
> present ioctl can override the previous one, so the unsignalled presentation 
> is never used.
>
>
> 3. New memory management
>
> The per-BO fences will be removed and the kernel will not know which buffers 
> are busy. This will reduce CPU overhead and latency. The kernel will not need 
> per-BO fences with explicit synchronization, so we just need to remove their 
> last user: buffer evictions. It also resolves the current OOM deadlock.

Is this even really possible?  I'm no kernel MM expert (trying to
learn some) but my understanding is that the use of per-BO dma-fence
runs deep.  I would like to stop using it for implicit synchronization
to be sure, but I'm not sure I believe the claim that we can get rid
of it entirely.  Happy to see someone try, though.


> 3.1. Evictions
>
> If the kernel wants to move a buffer, it will have to wait for everything to 
> go idle, halt all userspace command submissions, move the 

Re: [PATCH v4] dma-buf: Add DmaBufTotal counter in meminfo

[Christian König]

Am 19.04.21 um 17:19 schrieb peter.enderb...@sony.com:

On 4/19/21 5:00 PM, Michal Hocko wrote:

On Mon 19-04-21 12:41:58, peter.enderb...@sony.com wrote:

On 4/19/21 2:16 PM, Michal Hocko wrote:

On Sat 17-04-21 12:40:32, Peter Enderborg wrote:

This adds a total used dma-buf memory. Details
can be found in debugfs, however it is not for everyone
and not always available. dma-buf are indirect allocated by
userspace. So with this value we can monitor and detect
userspace applications that have problems.

The changelog would benefit from more background on why this is needed,
and who is the primary consumer of that value.

I cannot really comment on the dma-buf internals but I have two remarks.
Documentation/filesystems/proc.rst needs an update with the counter
explanation and secondly is this information useful for OOM situations
analysis? If yes then show_mem should dump the value as well.

 From the implementation point of view, is there any reason why this
hasn't used the existing global_node_page_state infrastructure?

I fix doc in next version.  Im not sure what you expect the commit message to 
include.

As I've said. Usual justification covers answers to following questions
- Why do we need it?
- Why the existing data is insuficient?
- Who is supposed to use the data and for what?

I can see an answer for the first two questions (because this can be a
lot of memory and the existing infrastructure is not production suitable
- debugfs). But the changelog doesn't really explain who is going to use
the new data. Is this a monitoring to raise an early alarm when the
value grows? Is this for debugging misbehaving drivers? How is it
valuable for those?


The function of the meminfo is: (From Documentation/filesystems/proc.rst)

"Provides information about distribution and utilization of memory."

True. Yet we do not export any random counters, do we?


Im not the designed of dma-buf, I think  global_node_page_state as a kernel
internal.

It provides a node specific and optimized counters. Is this a good fit
with your new counter? Or the NUMA locality is of no importance?

Sounds good to me, if Christian Koenig think it is good, I will use that.
It is only virtio in drivers that use the global_node_page_state if
that matters.


DMA-buf are not NUMA aware at all. On which node the pages are allocated 
(and if we use pages at all and not internal device memory) is up to the 
exporter and importer.


Christian.





dma-buf is a device driver that provides a function so I might be
on the outside. However I also see that it might be relevant for a OOM.
It is memory that can be freed by killing userspace processes.

The show_mem thing. Should it be a separate patch?

This is up to you but if you want to expose the counter then send it in
one series.



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 15/27] drm/bridge: ti-sn65dsi86: Break GPIO and MIPI-to-eDP bridge into sub-drivers

[Doug Anderson]

Hi,

On Fri, Apr 16, 2021 at 7:32 PM kernel test robot  wrote:
>
> Hi Douglas,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on next-20210416]
> [cannot apply to wsa/i2c/for-next robh/for-next linus/master v5.12-rc7 
> v5.12-rc6 v5.12-rc5 v5.12-rc7]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
>
> url:
> https://github.com/0day-ci/linux/commits/Douglas-Anderson/drm-Fix-EDID-reading-on-ti-sn65dsi86-solve-some-chicken-and-egg-problems/20210417-064243
> base:18250b538735142307082e4e99e3ae5c12d44013
> config: x86_64-randconfig-a002-20210416 (attached as .config)
> compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 
> f549176ad976caa3e19edd036df9a7e12770af7c)
> reproduce (this is a W=1 build):
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # install x86_64 cross compiling tool for clang build
> # apt-get install binutils-x86-64-linux-gnu
> # 
> https://github.com/0day-ci/linux/commit/a870b6e38fac3e5453e4b74fdfe6eb05c8be7ea7
> git remote add linux-review https://github.com/0day-ci/linux
> git fetch --no-tags linux-review 
> Douglas-Anderson/drm-Fix-EDID-reading-on-ti-sn65dsi86-solve-some-chicken-and-egg-problems/20210417-064243
> git checkout a870b6e38fac3e5453e4b74fdfe6eb05c8be7ea7
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
> ARCH=x86_64
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 
>
> All errors (new ones prefixed by >>):
>
> >> drivers/gpu/drm/bridge/ti-sn65dsi86.c:1308:1: error: redefinition of 
> >> '__inittest'
>module_auxiliary_driver(ti_sn_bridge_driver);
>^
>include/linux/auxiliary_bus.h:71:2: note: expanded from macro 
> 'module_auxiliary_driver'
>module_driver(__auxiliary_driver, auxiliary_driver_register, 
> auxiliary_driver_unregister)
>^
>include/linux/device/driver.h:262:3: note: expanded from macro 
> 'module_driver'
>} \
>  ^
>include/linux/module.h:130:42: note: expanded from macro '\
>module_init'
>static inline initcall_t __maybe_unused __inittest(void)   
>  \
>^
>drivers/gpu/drm/bridge/ti-sn65dsi86.c:1190:1: note: previous definition is 
> here
>module_auxiliary_driver(ti_sn_gpio_driver);
>^
>include/linux/auxiliary_bus.h:71:2: note: expanded from macro 
> 'module_auxiliary_driver'
>module_driver(__auxiliary_driver, auxiliary_driver_register, 
> auxiliary_driver_unregister)
>^
>include/linux/device/driver.h:262:3: note: expanded from macro 
> 'module_driver'
>} \
>  ^
>include/linux/module.h:130:42: note: expanded from macro '\
>module_init'
>static inline initcall_t __maybe_unused __inittest(void)   
>  \

Ah, my mistake in individually using these in the same module:

module_auxiliary_driver(ti_sn_gpio_driver);
module_auxiliary_driver(ti_sn_bridge_driver);
module_auxiliary_driver(ti_sn_aux_driver);
module_i2c_driver(ti_sn65dsi86_driver);

What I had worked fine because I wasn't building as a module. I've
fixed this to have a manual init mechanism that will look something
like this at the end of the series:

---

static int __init ti_sn65dsi86_init(void)
{
int ret;

ret = i2c_add_driver(_sn65dsi86_driver);
if (ret)
return ret;

ret = ti_sn_gpio_register();
if (ret)
goto err_main_was_registered;

ret = auxiliary_driver_register(_sn_aux_driver);
if (ret)
goto err_gpio_was_registered;

ret = auxiliary_driver_register(_sn_bridge_driver);
if (ret)
goto err_aux_was_registered;

return 0;

err_aux_was_registered:
auxiliary_driver_unregister(_sn_aux_driver);
err_gpio_was_registered:
ti_sn_gpio_unregister();
err_main_was_registered:
i2c_del_driver(_sn65dsi86_driver);

return ret;
}
module_init(ti_sn65dsi86_init);

static void __exit ti_sn65dsi86_exit(void)
{
auxiliary_driver_unregister(_sn_bridge_driver);
auxiliary_driver_unregister(_sn_aux_driver);
ti_sn_gpio_unregister();
i2c_del_driver(_sn65dsi86_driver);
}
module_exit(ti_sn65dsi86_exit);

---

With that I can compile as a module and everything works fine with
this builtin. I'll plan to spin a v5 with that fix but I'll wait a
little bit to see if I get any feedback. If I happen to get drm-misc
commit access or can convince someone, I'll try to get the early
patches in the series landed so v5 isn't so giant.

NOTE: on my system sn65dsi86 doesn't actually work currently when
running as a module. That's a pre-existing problem and not one

Re: [PATCH v3 4/4] drm/doc/rfc: i915 DG1 uAPI

[Jason Ekstrand]

On Mon, Apr 19, 2021 at 7:02 AM Matthew Auld  wrote:
>
> On 16/04/2021 17:38, Jason Ekstrand wrote:
> > On Thu, Apr 15, 2021 at 11:04 AM Matthew Auld  
> > wrote:
> >>
> >> Add an entry for the new uAPI needed for DG1.
> >>
> >> v2(Daniel):
> >>- include the overall upstreaming plan
> >>- add a note for mmap, there are differences here for TTM vs i915
> >>- bunch of other suggestions from Daniel
> >> v3:
> >>   (Daniel)
> >>- add a note for set/get caching stuff
> >>- add some more docs for existing query and extensions stuff
> >>- add an actual code example for regions query
> >>- bunch of other stuff
> >>   (Jason)
> >>- uAPI change(!):
> >>  - try a simpler design with the placements extension
> >>  - rather than have a generic setparam which can cover multiple
> >>use cases, have each extension be responsible for one thing
> >>only
> >>
> >> Signed-off-by: Matthew Auld 
> >> Cc: Joonas Lahtinen 
> >> Cc: Jordan Justen 
> >> Cc: Daniel Vetter 
> >> Cc: Kenneth Graunke 
> >> Cc: Jason Ekstrand 
> >> Cc: Dave Airlie 
> >> Cc: dri-devel@lists.freedesktop.org
> >> Cc: mesa-...@lists.freedesktop.org
> >> ---
> >>   Documentation/gpu/rfc/i915_gem_lmem.h   | 255 
> >>   Documentation/gpu/rfc/i915_gem_lmem.rst | 139 +
> >>   Documentation/gpu/rfc/index.rst |   4 +
> >>   3 files changed, 398 insertions(+)
> >>   create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.h
> >>   create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.rst
> >>
> >> diff --git a/Documentation/gpu/rfc/i915_gem_lmem.h 
> >> b/Documentation/gpu/rfc/i915_gem_lmem.h
> >> new file mode 100644
> >> index ..2a82a452e9f2
> >> --- /dev/null
> >> +++ b/Documentation/gpu/rfc/i915_gem_lmem.h
> >> @@ -0,0 +1,255 @@
> >> +/*
> >> + * Note that drm_i915_query_item and drm_i915_query are existing bits of 
> >> uAPI.
> >> + * For the regions query we are just adding a new query id, so no actual 
> >> new
> >> + * ioctl or anything, but including it here for reference.
> >> + */
> >> +struct drm_i915_query_item {
> >> +#define DRM_I915_QUERY_MEMORY_REGIONS   0xdeadbeaf
> >> +   
> >> +__u64 query_id;
> >> +
> >> +/*
> >> + * When set to zero by userspace, this is filled with the size of 
> >> the
> >> + * data to be written at the data_ptr pointer. The kernel sets 
> >> this
> >> + * value to a negative value to signal an error on a particular 
> >> query
> >> + * item.
> >> + */
> >> +__s32 length;
> >> +
> >> +__u32 flags;
> >> +/*
> >> + * Data will be written at the location pointed by data_ptr when 
> >> the
> >> + * value of length matches the length of the data to be written 
> >> by the
> >> + * kernel.
> >> + */
> >> +__u64 data_ptr;
> >> +};
> >> +
> >> +struct drm_i915_query {
> >> +__u32 num_items;
> >> +/*
> >> + * Unused for now. Must be cleared to zero.
> >> + */
> >> +__u32 flags;
> >> +/*
> >> + * This points to an array of num_items drm_i915_query_item 
> >> structures.
> >> + */
> >> +__u64 items_ptr;
> >> +};
> >> +
> >> +#define DRM_IOCTL_I915_QUERY   DRM_IOWR(DRM_COMMAND_BASE + 
> >> DRM_I915_QUERY, struct drm_i915_query)
> >> +
> >> +/**
> >> + * enum drm_i915_gem_memory_class
> >> + */
> >> +enum drm_i915_gem_memory_class {
> >> +   /** @I915_MEMORY_CLASS_SYSTEM: system memory */
> >> +   I915_MEMORY_CLASS_SYSTEM = 0,
> >> +   /** @I915_MEMORY_CLASS_DEVICE: device local-memory */
> >> +   I915_MEMORY_CLASS_DEVICE,
> >> +};
> >> +
> >> +/**
> >> + * struct drm_i915_gem_memory_class_instance
> >> + */
> >> +struct drm_i915_gem_memory_class_instance {
> >> +   /** @memory_class: see enum drm_i915_gem_memory_class */
> >> +   __u16 memory_class;
> >> +
> >> +   /** @memory_instance: which instance */
> >> +   __u16 memory_instance;
> >> +};
> >> +
> >> +/**
> >> + * struct drm_i915_memory_region_info
> >> + *
> >> + * Describes one region as known to the driver.
> >> + *
> >> + * Note that we reserve quite a lot of stuff here for potential future 
> >> work. As
> >> + * an example we might want expose the capabilities(see caps) for a given
> >> + * region, which could include things like if the region is CPU
> >> + * mappable/accessible etc.
> >
> > I get caps but I'm seriously at a loss as to what the rest of this
> > would be used for.  Why are caps and flags both there and separate?
> > Flags are typically something you set, not query.  Also, what's with
> > rsvd1 at the end?  This smells of substantial over-building to me.
> >
> > I thought to myself, "maybe I'm missing a future use-case" so I looked
> > at the internal tree and none of this is being used there either.
> > This indicates to me that either I'm missing something and there's
> > code somewhere I don't know about 

[PATCH v2 2/2] drm/amd/amdgpu/amdgpu_drv.c: Replace drm_modeset_*_all with DRM_MODESET_LOCK_ALL_*

[Fabio M. De Francesco]

Replace the deprecated API with new helpers, according to the TODO list
of the DRM subsystem. The new API has been introduced with commit
b7ea04d299c7: DRM_MODESET_LOCK_ALL_BEGIN() simplifies grabbing all modeset
locks using a local context and has the advantage of reducing boilerplate.

Signed-off-by: Fabio M. De Francesco 
---

Changes from v1: Added further information to the commit message.

 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 671ec1002230..0e9b7a180ee7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1438,8 +1438,10 @@ static int amdgpu_pmops_runtime_idle(struct device *dev)
 
if (amdgpu_device_has_dc_support(adev)) {
struct drm_crtc *crtc;
+   struct drm_modeset_acquire_ctx ctx;
+   int ret_lock;
 
-   drm_modeset_lock_all(drm_dev);
+   DRM_MODESET_LOCK_ALL_BEGIN(drm_dev, ctx, 0, ret_lock);
 
drm_for_each_crtc(crtc, drm_dev) {
if (crtc->state->active) {
@@ -1448,7 +1450,7 @@ static int amdgpu_pmops_runtime_idle(struct device *dev)
}
}
 
-   drm_modeset_unlock_all(drm_dev);
+   DRM_MODESET_LOCK_ALL_END(drm_dev, ctx, ret_lock);
 
} else {
struct drm_connector *list_connector;
-- 
2.31.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/2] drm/amd/amdgpu/amdgpu_device.c: Replace drm_modeset_*_all with DRM_MODESET_LOCK_ALL_*

[Fabio M. De Francesco]

Replace the deprecated API with new helpers, according to the TODO list
of the DRM subsystem. The new API has been introduced with commit
b7ea04d299c7: DRM_MODESET_LOCK_ALL_BEGIN() simplifies grabbing all modeset
locks using a local context and has the advantage of reducing boilerplate.

Signed-off-by: Fabio M. De Francesco 
---

Changes from v1: Added further information in the commit message.

 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 6447cd6ca5a8..e1a71579f8e6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -32,6 +32,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -3694,14 +3695,17 @@ int amdgpu_device_suspend(struct drm_device *dev, bool 
fbcon)
 
if (!amdgpu_device_has_dc_support(adev)) {
/* turn off display hw */
-   drm_modeset_lock_all(dev);
+   struct drm_modeset_acquire_ctx ctx;
+   int ret;
+
+   DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
drm_connector_list_iter_begin(dev, );
drm_for_each_connector_iter(connector, )
drm_helper_connector_dpms(connector,
  DRM_MODE_DPMS_OFF);
drm_connector_list_iter_end();
-   drm_modeset_unlock_all(dev);
-   /* unpin the front buffers and cursors */
+   DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
+   /* unpin the front buffers and cursors */
list_for_each_entry(crtc, >mode_config.crtc_list, head) {
struct amdgpu_crtc *amdgpu_crtc = to_amdgpu_crtc(crtc);
struct drm_framebuffer *fb = crtc->primary->fb;
@@ -3830,19 +3834,21 @@ int amdgpu_device_resume(struct drm_device *dev, bool 
fbcon)
/* blat the mode back in */
if (fbcon) {
if (!amdgpu_device_has_dc_support(adev)) {
+   struct drm_modeset_acquire_ctx ctx;
+   int ret;
+
/* pre DCE11 */
drm_helper_resume_force_mode(dev);
 
/* turn on display hw */
-   drm_modeset_lock_all(dev);
+   DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
 
drm_connector_list_iter_begin(dev, );
drm_for_each_connector_iter(connector, )
drm_helper_connector_dpms(connector,
  DRM_MODE_DPMS_ON);
drm_connector_list_iter_end();
-
-   drm_modeset_unlock_all(dev);
+   DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
}
amdgpu_fbdev_set_suspend(adev, 0);
}
-- 
2.31.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/2] Replace drm_modeset_*_all with DRM_MODESET_LOCK_ALL_*

[Fabio M. De Francesco]

Replace the deprecated API with new helpers, according to the TODO list
of the DRM subsystem. The new API has been introduced with commit 
b7ea04d299c7: DRM_MODESET_LOCK_ALL_BEGIN() simplifies grabbing all modeset 
locks using a local context. This has the advantage of reducing boilerplate.

Changes from v1: Added further information to the commit message.

Fabio M. De Francesco (2):
  drm/amd/amdgpu/amdgpu_device.c: Replace drm_modeset_*_all with
DRM_MODESET_LOCK_ALL_*
  drm/amd/amdgpu/amdgpu_drv.c: Replace drm_modeset_*_all with
DRM_MODESET_LOCK_ALL_*

 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 18 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  6 --
 2 files changed, 16 insertions(+), 8 deletions(-)

-- 
2.31.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 11/19] drm/i915: Update the helper to set correct mapping

[Tvrtko Ursulin]

On 19/04/2021 15:37, Matthew Auld wrote:

On 19/04/2021 15:07, Tvrtko Ursulin wrote:


On 19/04/2021 12:30, Matthew Auld wrote:

On 15/04/2021 12:05, Tvrtko Ursulin wrote:


On 15/04/2021 10:23, Matthew Auld wrote:

On Thu, 15 Apr 2021 at 09:21, Tvrtko Ursulin
 wrote:



On 14/04/2021 17:20, Matthew Auld wrote:

On Wed, 14 Apr 2021 at 16:22, Tvrtko Ursulin
 wrote:



On 12/04/2021 10:05, Matthew Auld wrote:
From: Venkata Sandeep Dhanalakota 



Determine the possible coherent map type based on object location,
and if target has llc or if user requires an always coherent
mapping.

Cc: Matthew Auld 
Cc: CQ Tang 
Suggested-by: Michal Wajdeczko 
Signed-off-by: Venkata Sandeep Dhanalakota 


---
    drivers/gpu/drm/i915/gt/intel_engine_cs.c    |  3 ++-
    drivers/gpu/drm/i915/gt/intel_engine_pm.c    |  2 +-
    drivers/gpu/drm/i915/gt/intel_lrc.c  |  4 +++-
    drivers/gpu/drm/i915/gt/intel_ring.c |  9 ++---
    drivers/gpu/drm/i915/gt/selftest_context.c   |  3 ++-
    drivers/gpu/drm/i915/gt/selftest_hangcheck.c |  4 ++--
    drivers/gpu/drm/i915/gt/selftest_lrc.c   |  4 +++-
    drivers/gpu/drm/i915/gt/uc/intel_guc.c   |  4 +++-
    drivers/gpu/drm/i915/gt/uc/intel_huc.c   |  4 +++-
    drivers/gpu/drm/i915/i915_drv.h  | 11 +--
    drivers/gpu/drm/i915/selftests/igt_spinner.c |  4 ++--
    11 files changed, 36 insertions(+), 16 deletions(-)

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

index efe935f80c1a..b79568d370f5 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -664,7 +664,8 @@ static int init_status_page(struct 
intel_engine_cs *engine)

    if (ret)
    goto err;

- vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
+ vaddr = i915_gem_object_pin_map(obj,
+ i915_coherent_map_type(engine->i915, obj, true));
    if (IS_ERR(vaddr)) {
    ret = PTR_ERR(vaddr);
    goto err_unpin;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c 
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c

index 7c9af86fdb1e..47f4397095e5 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -23,7 +23,7 @@ static void dbg_poison_ce(struct 
intel_context *ce)


    if (ce->state) {
    struct drm_i915_gem_object *obj = ce->state->obj;
- int type = i915_coherent_map_type(ce->engine->i915);
+ int type = 
i915_coherent_map_type(ce->engine->i915, obj, true);

    void *map;

    if (!i915_gem_object_trylock(obj))
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c

index e86897cde984..aafe2a4df496 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -903,7 +903,9 @@ lrc_pre_pin(struct intel_context *ce,
    GEM_BUG_ON(!i915_vma_is_pinned(ce->state));

    *vaddr = i915_gem_object_pin_map(ce->state->obj,
- i915_coherent_map_type(ce->engine->i915) |
+ i915_coherent_map_type(ce->engine->i915,
+ ce->state->obj,
+ false) |
 I915_MAP_OVERRIDE);

    return PTR_ERR_OR_ZERO(*vaddr);
diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c 
b/drivers/gpu/drm/i915/gt/intel_ring.c

index aee0a77c77e0..3cf6c7e68108 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring.c
@@ -53,9 +53,12 @@ int intel_ring_pin(struct intel_ring *ring, 
struct i915_gem_ww_ctx *ww)


    if (i915_vma_is_map_and_fenceable(vma))
    addr = (void __force *)i915_vma_pin_iomap(vma);
- else
- addr = i915_gem_object_pin_map(vma->obj,
- i915_coherent_map_type(vma->vm->i915));
+ else {
+ int type = i915_coherent_map_type(vma->vm->i915, 
vma->obj, false);

+
+ addr = i915_gem_object_pin_map(vma->obj, type);
+ }
+
    if (IS_ERR(addr)) {
    ret = PTR_ERR(addr);
    goto err_ring;
diff --git a/drivers/gpu/drm/i915/gt/selftest_context.c 
b/drivers/gpu/drm/i915/gt/selftest_context.c

index b9bdd1d23243..26685b927169 100644
--- a/drivers/gpu/drm/i915/gt/selftest_context.c
+++ b/drivers/gpu/drm/i915/gt/selftest_context.c
@@ -88,7 +88,8 @@ static int __live_context_size(struct 
intel_engine_cs *engine)

    goto err;

    vaddr = i915_gem_object_pin_map_unlocked(ce->state->obj,
- i915_coherent_map_type(engine->i915));
+ i915_coherent_map_type(engine->i915,
+ ce->state->obj, false));
    if (IS_ERR(vaddr)) {
    err = PTR_ERR(vaddr);
    intel_context_unpin(ce);
diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c 
b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c

index 746985971c3a..5b63d4df8c93 100644
--- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
@@ -69,7 +69,7 @@ static int hang_init(struct hang *h, struct 

Re: [Outreachy kernel] [PATCH 1/2] drm/amd/amdgpu/amdgpu_device.c: Replace drm_modeset_*_all with DRM_MODESET_LOCK_ALL_*

[Julia Lawall]

On Mon, 19 Apr 2021, Fabio M. De Francesco wrote:

> On Monday, April 19, 2021 3:08:51 PM CEST Julia Lawall wrote:
> > On Mon, 19 Apr 2021, Fabio M. De Francesco wrote:
> > > Replace the deprecated API with new helpers, according to the TODO list
> > > of the DRM subsystem.
> >
> > The commit message will perhaps not be very meaningful one year from now.
> > You could say for example DRM_MODESET_LOCK_ALL_BEGIN was introduced in
> > commit XXX (there is a proper format for referring to other commits) for
> > what purpose.  And then say that you are making the replacement.
> >
> > Actually, I'm a little surprised to see something that looks like a
> > function call be replaced by something that looks like a macro.  Maybe it
> > was a macro all along, and this is just making that more clear.  In any
> > case, if I were to look at this commit, I would appreciate a little more
> > context information.
> >
> > julia
> >
> I have made that message in line with an old commit (9bcaa3fe58ab) that had
> been taken by D. Vetter (the DRM maintainer). That message didn't explain more
> than referring to the TODO list. I try to stick with each subsystem's
> conventions.
>
> However, I agree with you: referring to a TODO list, which some day  will
> surely change, is not the best means to provide context information.
>
> From that macro documentation 
> (https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#c.DRM_MODESET_LOCK_ALL_BEGIN):
>
> "DRM_MODESET_LOCK_ALL_BEGIN  simplifies grabbing all modeset locks using a
> local context. This has the advantage of reducing boilerplate, [...]".
> (Please, note that I haven't copied the last part of the paragraph because it
> talks about checking the return value but I think it's useless because the
> only possible return value is 0).
>
> If more context information is needed, I would add the above-mentioned note to
> my commit message and submit a v2 patch.
>
> Is it the right way to solve the issue that you pointed out?

It seems find to include the information you propose.

thanks,
julia

>
> Thanks in advance,
>
> Fabio
> >
> > > Signed-off-by: Fabio M. De Francesco 
> > > ---
> > >
> > >  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 18 --
> > >  1 file changed, 12 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index
> > > 6447cd6ca5a8..e1a71579f8e6 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > @@ -32,6 +32,7 @@
> > >
> > >  #include 
> > >
> > >  #include 
> > >
> > > +#include 
> > >
> > >  #include 
> > >  #include 
> > >  #include 
> > >
> > > @@ -3694,14 +3695,17 @@ int amdgpu_device_suspend(struct drm_device *dev,
> > > bool fbcon)>
> > >   if (!amdgpu_device_has_dc_support(adev)) {
> > >
> > >   /* turn off display hw */
> > >
> > > - drm_modeset_lock_all(dev);
> > > + struct drm_modeset_acquire_ctx ctx;
> > > + int ret;
> > > +
> > > + DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
> > >
> > >   drm_connector_list_iter_begin(dev, );
> > >   drm_for_each_connector_iter(connector, )
> > >
> > >   drm_helper_connector_dpms(connector,
> > >
> > >
> DRM_MODE_DPMS_OFF);
> > >
> > >   drm_connector_list_iter_end();
> > >
> > > - drm_modeset_unlock_all(dev);
> > > - /* unpin the front buffers and cursors */
> > > + DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
> > > + /* unpin the front buffers and cursors */
> > >
> > >   list_for_each_entry(crtc, >mode_config.crtc_list,
> head) {
> > >
> > >   struct amdgpu_crtc *amdgpu_crtc =
> to_amdgpu_crtc(crtc);
> > >   struct drm_framebuffer *fb = crtc->primary-
> >fb;
> > >
> > > @@ -3830,19 +3834,21 @@ int amdgpu_device_resume(struct drm_device *dev,
> > > bool fbcon)>
> > >   /* blat the mode back in */
> > >   if (fbcon) {
> > >
> > >   if (!amdgpu_device_has_dc_support(adev)) {
> > >
> > > + struct drm_modeset_acquire_ctx ctx;
> > > + int ret;
> > > +
> > >
> > >   /* pre DCE11 */
> > >   drm_helper_resume_force_mode(dev);
> > >
> > >   /* turn on display hw */
> > >
> > > - drm_modeset_lock_all(dev);
> > > + DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0,
> ret);
> > >
> > >   drm_connector_list_iter_begin(dev, );
> > >   drm_for_each_connector_iter(connector,
> )
> > >
> > >
> drm_helper_connector_dpms(connector,
> > >
> > >
> DRM_MODE_DPMS_ON);
> > >
> > >   drm_connector_list_iter_end();
> > >
> > > -
> > > - drm_modeset_unlock_all(dev);
> > > + DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
> > >
> > >   }
> > >   amdgpu_fbdev_set_suspend(adev, 0);
> > >
> > >   }
> > >
> > > --
> 

Re: [Intel-gfx] [PATCH 11/19] drm/i915: Update the helper to set correct mapping

[Matthew Auld]

On 19/04/2021 15:07, Tvrtko Ursulin wrote:


On 19/04/2021 12:30, Matthew Auld wrote:

On 15/04/2021 12:05, Tvrtko Ursulin wrote:


On 15/04/2021 10:23, Matthew Auld wrote:

On Thu, 15 Apr 2021 at 09:21, Tvrtko Ursulin
 wrote:



On 14/04/2021 17:20, Matthew Auld wrote:

On Wed, 14 Apr 2021 at 16:22, Tvrtko Ursulin
 wrote:



On 12/04/2021 10:05, Matthew Auld wrote:

From: Venkata Sandeep Dhanalakota 

Determine the possible coherent map type based on object location,
and if target has llc or if user requires an always coherent
mapping.

Cc: Matthew Auld 
Cc: CQ Tang 
Suggested-by: Michal Wajdeczko 
Signed-off-by: Venkata Sandeep Dhanalakota 


---
    drivers/gpu/drm/i915/gt/intel_engine_cs.c    |  3 ++-
    drivers/gpu/drm/i915/gt/intel_engine_pm.c    |  2 +-
    drivers/gpu/drm/i915/gt/intel_lrc.c  |  4 +++-
    drivers/gpu/drm/i915/gt/intel_ring.c |  9 ++---
    drivers/gpu/drm/i915/gt/selftest_context.c   |  3 ++-
    drivers/gpu/drm/i915/gt/selftest_hangcheck.c |  4 ++--
    drivers/gpu/drm/i915/gt/selftest_lrc.c   |  4 +++-
    drivers/gpu/drm/i915/gt/uc/intel_guc.c   |  4 +++-
    drivers/gpu/drm/i915/gt/uc/intel_huc.c   |  4 +++-
    drivers/gpu/drm/i915/i915_drv.h  | 11 +--
    drivers/gpu/drm/i915/selftests/igt_spinner.c |  4 ++--
    11 files changed, 36 insertions(+), 16 deletions(-)

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

index efe935f80c1a..b79568d370f5 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -664,7 +664,8 @@ static int init_status_page(struct 
intel_engine_cs *engine)

    if (ret)
    goto err;

- vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
+ vaddr = i915_gem_object_pin_map(obj,
+ i915_coherent_map_type(engine->i915, obj, true));
    if (IS_ERR(vaddr)) {
    ret = PTR_ERR(vaddr);
    goto err_unpin;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c 
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c

index 7c9af86fdb1e..47f4397095e5 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -23,7 +23,7 @@ static void dbg_poison_ce(struct intel_context 
*ce)


    if (ce->state) {
    struct drm_i915_gem_object *obj = ce->state->obj;
- int type = i915_coherent_map_type(ce->engine->i915);
+ int type = 
i915_coherent_map_type(ce->engine->i915, obj, true);

    void *map;

    if (!i915_gem_object_trylock(obj))
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c

index e86897cde984..aafe2a4df496 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -903,7 +903,9 @@ lrc_pre_pin(struct intel_context *ce,
    GEM_BUG_ON(!i915_vma_is_pinned(ce->state));

    *vaddr = i915_gem_object_pin_map(ce->state->obj,
- i915_coherent_map_type(ce->engine->i915) |
+ i915_coherent_map_type(ce->engine->i915,
+ ce->state->obj,
+ false) |
 I915_MAP_OVERRIDE);

    return PTR_ERR_OR_ZERO(*vaddr);
diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c 
b/drivers/gpu/drm/i915/gt/intel_ring.c

index aee0a77c77e0..3cf6c7e68108 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring.c
@@ -53,9 +53,12 @@ int intel_ring_pin(struct intel_ring *ring, 
struct i915_gem_ww_ctx *ww)


    if (i915_vma_is_map_and_fenceable(vma))
    addr = (void __force *)i915_vma_pin_iomap(vma);
- else
- addr = i915_gem_object_pin_map(vma->obj,
- i915_coherent_map_type(vma->vm->i915));
+ else {
+ int type = i915_coherent_map_type(vma->vm->i915, 
vma->obj, false);

+
+ addr = i915_gem_object_pin_map(vma->obj, type);
+ }
+
    if (IS_ERR(addr)) {
    ret = PTR_ERR(addr);
    goto err_ring;
diff --git a/drivers/gpu/drm/i915/gt/selftest_context.c 
b/drivers/gpu/drm/i915/gt/selftest_context.c

index b9bdd1d23243..26685b927169 100644
--- a/drivers/gpu/drm/i915/gt/selftest_context.c
+++ b/drivers/gpu/drm/i915/gt/selftest_context.c
@@ -88,7 +88,8 @@ static int __live_context_size(struct 
intel_engine_cs *engine)

    goto err;

    vaddr = i915_gem_object_pin_map_unlocked(ce->state->obj,
- i915_coherent_map_type(engine->i915));
+ i915_coherent_map_type(engine->i915,
+ ce->state->obj, false));
    if (IS_ERR(vaddr)) {
    err = PTR_ERR(vaddr);
    intel_context_unpin(ce);
diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c 
b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c

index 746985971c3a..5b63d4df8c93 100644
--- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
@@ -69,7 +69,7 @@ static int hang_init(struct hang *h, struct 
intel_gt *gt)

    h->seqno = 

Re: [Intel-gfx] [PATCH 12/19] drm/i915/lmem: Bypass aperture when lmem is available

[Tvrtko Ursulin]

On 16/04/2021 15:25, Matthew Auld wrote:

On 14/04/2021 16:33, Tvrtko Ursulin wrote:


On 12/04/2021 10:05, Matthew Auld wrote:

From: Anusha Srivatsa 

In the scenario where local memory is available, we have
rely on CPU access via lmem directly instead of aperture.

v2:
gmch is only relevant for much older hw, therefore we can drop the
has_aperture check since it should always be present on such platforms.
(Chris)

Cc: Ville Syrjälä 
Cc: Dhinakaran Pandiyan 
Cc: Maarten Lankhorst 
Cc: Chris P Wilson 
Cc: Daniel Vetter 
Cc: Joonas Lahtinen 
Cc: Daniele Ceraolo Spurio 
Cc: CQ Tang 
Signed-off-by: Anusha Srivatsa 
---
  drivers/gpu/drm/i915/display/intel_fbdev.c | 22 +++---
  drivers/gpu/drm/i915/gem/i915_gem_lmem.c   | 15 +++
  drivers/gpu/drm/i915/gem/i915_gem_lmem.h   |  5 +
  drivers/gpu/drm/i915/i915_vma.c    | 19 +--
  4 files changed, 48 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c

index 2b37959da747..4af40229f5ec 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -139,14 +139,22 @@ static int intelfb_alloc(struct drm_fb_helper 
*helper,

  size = mode_cmd.pitches[0] * mode_cmd.height;
  size = PAGE_ALIGN(size);
-    /* If the FB is too big, just don't use it since fbdev is not very
- * important and we should probably use that space with FBC or 
other

- * features. */
  obj = ERR_PTR(-ENODEV);
-    if (size * 2 < dev_priv->stolen_usable_size)
-    obj = i915_gem_object_create_stolen(dev_priv, size);
-    if (IS_ERR(obj))
-    obj = i915_gem_object_create_shmem(dev_priv, size);
+    if (HAS_LMEM(dev_priv)) {
+    obj = i915_gem_object_create_lmem(dev_priv, size,
+  I915_BO_ALLOC_CONTIGUOUS);


Has to be contiguous? Question for display experts I guess.

[Comes back later.] Ah for iomap? Put a comment to that effect perhaps?


I don't think it has to be, since we could in theory just use pin_map() 
underneath, which can already deal with non-contiguous chunks of lmem, 
although that might bring in ww locking. I think for now just add a 
comment and mark this as XXX, and potentially revisit as follow up?


Sure.

Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 03/19] drm/i915: Create stolen memory region from local memory

[Tvrtko Ursulin]

On 16/04/2021 16:04, Matthew Auld wrote:

On 14/04/2021 16:01, Tvrtko Ursulin wrote:


On 12/04/2021 10:05, Matthew Auld wrote:

From: CQ Tang 

Add "REGION_STOLEN" device info to dg1, create stolen memory
region from upper portion of local device memory, starting
from DSMBASE.

v2:
 - s/drm_info/drm_dbg; userspace likely doesn't care about stolen.
 - mem->type is only setup after the region probe, so setting the 
name
   as stolen-local or stolen-system based on this value won't 
work. Split

   system vs local stolen setup to fix this.
 - kill all the region->devmem/is_devmem stuff. We already 
differentiate

   the different types of stolen so such things shouldn't be needed
   anymore.

Signed-off-by: CQ Tang 
Signed-off-by: Matthew Auld 
---
  drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 99 +++---
  drivers/gpu/drm/i915/gem/i915_gem_stolen.h |  3 +
  drivers/gpu/drm/i915/i915_pci.c    |  2 +-
  drivers/gpu/drm/i915/i915_reg.h    |  1 +
  drivers/gpu/drm/i915/intel_memory_region.c |  6 ++
  drivers/gpu/drm/i915/intel_memory_region.h |  5 +-
  6 files changed, 102 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c

index b0597de206de..56dd58bef5ee 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -10,6 +10,7 @@
  #include 
  #include 
+#include "gem/i915_gem_lmem.h"
  #include "gem/i915_gem_region.h"
  #include "i915_drv.h"
  #include "i915_gem_stolen.h"
@@ -121,6 +122,14 @@ static int i915_adjust_stolen(struct 
drm_i915_private *i915,

  }
  }
+    /*
+ * With device local memory, we don't need to check the address 
range,
+ * this is device memory physical address, could overlap with 
system

+ * memory.
+ */
+    if (HAS_LMEM(i915))
+    return 0;
+
  /*
   * Verify that nothing else uses this physical address. Stolen
   * memory should be reserved by the BIOS and hidden from the
@@ -374,8 +383,9 @@ static void icl_get_stolen_reserved(struct 
drm_i915_private *i915,

  }
  }
-static int i915_gem_init_stolen(struct drm_i915_private *i915)
+static int i915_gem_init_stolen(struct intel_memory_region *mem)
  {
+    struct drm_i915_private *i915 = mem->i915;
  struct intel_uncore *uncore = >uncore;
  resource_size_t reserved_base, stolen_top;
  resource_size_t reserved_total, reserved_size;
@@ -396,10 +406,10 @@ static int i915_gem_init_stolen(struct 
drm_i915_private *i915)

  return 0;
  }
-    if (resource_size(_graphics_stolen_res) == 0)
+    if (resource_size(>region) == 0)
  return 0;
-    i915->dsm = intel_graphics_stolen_res;
+    i915->dsm = mem->region;
  if (i915_adjust_stolen(i915, >dsm))
  return 0;
@@ -684,23 +694,36 @@ static int _i915_gem_object_stolen_init(struct 
intel_memory_region *mem,

  return ret;
  }
+struct intel_memory_region *i915_stolen_region(struct 
drm_i915_private *i915)

+{
+    if (HAS_LMEM(i915))
+    return i915->mm.regions[INTEL_REGION_STOLEN_LMEM];
+
+    return i915->mm.regions[INTEL_REGION_STOLEN_SMEM];
+}


Could be a bikeshedding comment only - especially since I think this 
path gets very little used at runtime so it is most likely pointless 
to fiddle with it, but it just strikes me a bit not fully elegant to do:


i915_gem_object_create_stolen
  -> i915_gem_object_create_region
 -> i915_stolen_region

And end up in here, when alternative could be at driver init:

i915->stolen_region_id = HAS_LMEM() ? ... : ...;

i915_gem_object_create_stolen
  -> 
i915_gem_object_create_region(i915->mm.regions[i915->stolen_region_id]);


Or pointer to region. Would avoid having to export i915_stolen_region 
as well.


Or is i915->dsm already the right thing? Because..


I guess we could just have an i915->stolen_region short-cut or something?


i915->dsm is not it? Where does i915_gem_init_stolen exists for 
local-stolen then? At the "resource_size(>region) == 0" check?







+
  struct drm_i915_gem_object *
  i915_gem_object_create_stolen(struct drm_i915_private *i915,
    resource_size_t size)
  {
-    return 
i915_gem_object_create_region(i915->mm.regions[INTEL_REGION_STOLEN_SMEM], 


+    return i915_gem_object_create_region(i915_stolen_region(i915),
   size, I915_BO_ALLOC_CONTIGUOUS);
  }
  static int init_stolen(struct intel_memory_region *mem)
  {
-    intel_memory_region_set_name(mem, "stolen");
+    if (HAS_LMEM(mem->i915)) {
+    if (!io_mapping_init_wc(>iomap,
+    mem->io_start,
+    resource_size(>region)))
+    return -EIO;
+    }
  /*
   * Initialise stolen early so that we may reserve preallocated
   * objects for the BIOS to KMS transition.
   */
-    return i915_gem_init_stolen(mem->i915);
+    return i915_gem_init_stolen(mem);


... I find the mem region 

Re: [Intel-gfx] [PATCH 11/19] drm/i915: Update the helper to set correct mapping

[Tvrtko Ursulin]

On 19/04/2021 12:30, Matthew Auld wrote:

On 15/04/2021 12:05, Tvrtko Ursulin wrote:


On 15/04/2021 10:23, Matthew Auld wrote:

On Thu, 15 Apr 2021 at 09:21, Tvrtko Ursulin
 wrote:



On 14/04/2021 17:20, Matthew Auld wrote:

On Wed, 14 Apr 2021 at 16:22, Tvrtko Ursulin
 wrote:



On 12/04/2021 10:05, Matthew Auld wrote:

From: Venkata Sandeep Dhanalakota 

Determine the possible coherent map type based on object location,
and if target has llc or if user requires an always coherent
mapping.

Cc: Matthew Auld 
Cc: CQ Tang 
Suggested-by: Michal Wajdeczko 
Signed-off-by: Venkata Sandeep Dhanalakota 


---
    drivers/gpu/drm/i915/gt/intel_engine_cs.c    |  3 ++-
    drivers/gpu/drm/i915/gt/intel_engine_pm.c    |  2 +-
    drivers/gpu/drm/i915/gt/intel_lrc.c  |  4 +++-
    drivers/gpu/drm/i915/gt/intel_ring.c |  9 ++---
    drivers/gpu/drm/i915/gt/selftest_context.c   |  3 ++-
    drivers/gpu/drm/i915/gt/selftest_hangcheck.c |  4 ++--
    drivers/gpu/drm/i915/gt/selftest_lrc.c   |  4 +++-
    drivers/gpu/drm/i915/gt/uc/intel_guc.c   |  4 +++-
    drivers/gpu/drm/i915/gt/uc/intel_huc.c   |  4 +++-
    drivers/gpu/drm/i915/i915_drv.h  | 11 +--
    drivers/gpu/drm/i915/selftests/igt_spinner.c |  4 ++--
    11 files changed, 36 insertions(+), 16 deletions(-)

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

index efe935f80c1a..b79568d370f5 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -664,7 +664,8 @@ static int init_status_page(struct 
intel_engine_cs *engine)

    if (ret)
    goto err;

- vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
+ vaddr = i915_gem_object_pin_map(obj,
+ i915_coherent_map_type(engine->i915, obj, true));
    if (IS_ERR(vaddr)) {
    ret = PTR_ERR(vaddr);
    goto err_unpin;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c 
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c

index 7c9af86fdb1e..47f4397095e5 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -23,7 +23,7 @@ static void dbg_poison_ce(struct intel_context 
*ce)


    if (ce->state) {
    struct drm_i915_gem_object *obj = ce->state->obj;
- int type = i915_coherent_map_type(ce->engine->i915);
+ int type = i915_coherent_map_type(ce->engine->i915, 
obj, true);

    void *map;

    if (!i915_gem_object_trylock(obj))
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c

index e86897cde984..aafe2a4df496 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -903,7 +903,9 @@ lrc_pre_pin(struct intel_context *ce,
    GEM_BUG_ON(!i915_vma_is_pinned(ce->state));

    *vaddr = i915_gem_object_pin_map(ce->state->obj,
- i915_coherent_map_type(ce->engine->i915) |
+ i915_coherent_map_type(ce->engine->i915,
+ ce->state->obj,
+ false) |
 I915_MAP_OVERRIDE);

    return PTR_ERR_OR_ZERO(*vaddr);
diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c 
b/drivers/gpu/drm/i915/gt/intel_ring.c

index aee0a77c77e0..3cf6c7e68108 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring.c
@@ -53,9 +53,12 @@ int intel_ring_pin(struct intel_ring *ring, 
struct i915_gem_ww_ctx *ww)


    if (i915_vma_is_map_and_fenceable(vma))
    addr = (void __force *)i915_vma_pin_iomap(vma);
- else
- addr = i915_gem_object_pin_map(vma->obj,
- i915_coherent_map_type(vma->vm->i915));
+ else {
+ int type = i915_coherent_map_type(vma->vm->i915, 
vma->obj, false);

+
+ addr = i915_gem_object_pin_map(vma->obj, type);
+ }
+
    if (IS_ERR(addr)) {
    ret = PTR_ERR(addr);
    goto err_ring;
diff --git a/drivers/gpu/drm/i915/gt/selftest_context.c 
b/drivers/gpu/drm/i915/gt/selftest_context.c

index b9bdd1d23243..26685b927169 100644
--- a/drivers/gpu/drm/i915/gt/selftest_context.c
+++ b/drivers/gpu/drm/i915/gt/selftest_context.c
@@ -88,7 +88,8 @@ static int __live_context_size(struct 
intel_engine_cs *engine)

    goto err;

    vaddr = i915_gem_object_pin_map_unlocked(ce->state->obj,
- i915_coherent_map_type(engine->i915));
+ i915_coherent_map_type(engine->i915,
+ ce->state->obj, false));
    if (IS_ERR(vaddr)) {
    err = PTR_ERR(vaddr);
    intel_context_unpin(ce);
diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c 
b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c

index 746985971c3a..5b63d4df8c93 100644
--- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
@@ -69,7 +69,7 @@ static int hang_init(struct hang *h, struct 
intel_gt *gt)

    h->seqno = memset(vaddr, 0xff, PAGE_SIZE);

    vaddr = 

Re: [Outreachy kernel] [PATCH 1/2] drm/amd/amdgpu/amdgpu_device.c: Replace drm_modeset_*_all with DRM_MODESET_LOCK_ALL_*

[Fabio M. De Francesco]

On Monday, April 19, 2021 3:08:51 PM CEST Julia Lawall wrote:
> On Mon, 19 Apr 2021, Fabio M. De Francesco wrote:
> > Replace the deprecated API with new helpers, according to the TODO list
> > of the DRM subsystem.
> 
> The commit message will perhaps not be very meaningful one year from now.
> You could say for example DRM_MODESET_LOCK_ALL_BEGIN was introduced in
> commit XXX (there is a proper format for referring to other commits) for
> what purpose.  And then say that you are making the replacement.
> 
> Actually, I'm a little surprised to see something that looks like a
> function call be replaced by something that looks like a macro.  Maybe it
> was a macro all along, and this is just making that more clear.  In any
> case, if I were to look at this commit, I would appreciate a little more
> context information.
> 
> julia
>
I have made that message in line with an old commit (9bcaa3fe58ab) that had 
been taken by D. Vetter (the DRM maintainer). That message didn't explain more 
than referring to the TODO list. I try to stick with each subsystem's  
conventions.

However, I agree with you: referring to a TODO list, which some day  will 
surely change, is not the best means to provide context information.

>From that macro documentation 
>(https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#c.DRM_MODESET_LOCK_ALL_BEGIN):

"DRM_MODESET_LOCK_ALL_BEGIN  simplifies grabbing all modeset locks using a 
local context. This has the advantage of reducing boilerplate, [...]". 
(Please, note that I haven't copied the last part of the paragraph because it 
talks about checking the return value but I think it's useless because the 
only possible return value is 0).

If more context information is needed, I would add the above-mentioned note to 
my commit message and submit a v2 patch.

Is it the right way to solve the issue that you pointed out?

Thanks in advance,

Fabio
> 
> > Signed-off-by: Fabio M. De Francesco 
> > ---
> > 
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 18 --
> >  1 file changed, 12 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index
> > 6447cd6ca5a8..e1a71579f8e6 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > @@ -32,6 +32,7 @@
> > 
> >  #include 
> >  
> >  #include 
> > 
> > +#include 
> > 
> >  #include 
> >  #include 
> >  #include 
> > 
> > @@ -3694,14 +3695,17 @@ int amdgpu_device_suspend(struct drm_device *dev,
> > bool fbcon)> 
> > if (!amdgpu_device_has_dc_support(adev)) {
> > 
> > /* turn off display hw */
> > 
> > -   drm_modeset_lock_all(dev);
> > +   struct drm_modeset_acquire_ctx ctx;
> > +   int ret;
> > +
> > +   DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
> > 
> > drm_connector_list_iter_begin(dev, );
> > drm_for_each_connector_iter(connector, )
> > 
> > drm_helper_connector_dpms(connector,
> > 
> >   
DRM_MODE_DPMS_OFF);
> > 
> > drm_connector_list_iter_end();
> > 
> > -   drm_modeset_unlock_all(dev);
> > -   /* unpin the front buffers and cursors */
> > +   DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
> > +   /* unpin the front buffers and cursors */
> > 
> > list_for_each_entry(crtc, >mode_config.crtc_list, 
head) {
> > 
> > struct amdgpu_crtc *amdgpu_crtc = 
to_amdgpu_crtc(crtc);
> > struct drm_framebuffer *fb = crtc->primary-
>fb;
> > 
> > @@ -3830,19 +3834,21 @@ int amdgpu_device_resume(struct drm_device *dev,
> > bool fbcon)> 
> > /* blat the mode back in */
> > if (fbcon) {
> > 
> > if (!amdgpu_device_has_dc_support(adev)) {
> > 
> > +   struct drm_modeset_acquire_ctx ctx;
> > +   int ret;
> > +
> > 
> > /* pre DCE11 */
> > drm_helper_resume_force_mode(dev);
> > 
> > /* turn on display hw */
> > 
> > -   drm_modeset_lock_all(dev);
> > +   DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, 
ret);
> > 
> > drm_connector_list_iter_begin(dev, );
> > drm_for_each_connector_iter(connector, 
)
> > 
> > 
drm_helper_connector_dpms(connector,
> > 
> >   
DRM_MODE_DPMS_ON);
> > 
> > drm_connector_list_iter_end();
> > 
> > -
> > -   drm_modeset_unlock_all(dev);
> > +   DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
> > 
> > }
> > amdgpu_fbdev_set_suspend(adev, 0);
> > 
> > }
> > 
> > 

Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match

[Guenter Roeck]

On 4/18/21 9:27 PM, Alice Guo (OSS) wrote:
> From: Alice Guo 
> 
> Update all the code that use soc_device_match because add support for
> soc_device_match returning -EPROBE_DEFER.
> 
> Signed-off-by: Alice Guo 
> ---
[ ... ]
>  drivers/watchdog/renesas_wdt.c|  2 +-
>  48 files changed, 131 insertions(+), 52 deletions(-)
> 
[ ... ]
> diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c
> index 5791198960e6..fdc534dc4024 100644
> --- a/drivers/watchdog/renesas_wdt.c
> +++ b/drivers/watchdog/renesas_wdt.c
> @@ -197,7 +197,7 @@ static bool rwdt_blacklisted(struct device *dev)
>   const struct soc_device_attribute *attr;
>  
>   attr = soc_device_match(rwdt_quirks_match);
> - if (attr && setup_max_cpus > (uintptr_t)attr->data) {
> + if (!IS_ERR(attr) && attr && setup_max_cpus > (uintptr_t)attr->data) {

This is wrong. We can not make the decision below without having access
to attr. The function may wrongly return false if soc_device_match()
returns an error.

Guenter

>   dev_info(dev, "Watchdog blacklisted on %s %s\n", attr->soc_id,
>attr->revision);
>   return true;
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: remove special handling for non GEM drivers

[Huang Rui]

On Mon, Apr 19, 2021 at 05:28:53PM +0800, Christian König wrote:
> vmwgfx is the only driver actually using this. Move the handling into
> the driver instead.
> 
> Signed-off-by: Christian König 

Acked-by: Huang Rui 

> ---
>  drivers/gpu/drm/ttm/ttm_bo.c   | 11 ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 10 ++
>  include/drm/ttm/ttm_bo_api.h   | 19 ---
>  3 files changed, 10 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 80831df0ef61..38183e227116 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -460,8 +460,6 @@ static void ttm_bo_release(struct kref *kref)
>  
>   atomic_dec(_glob.bo_count);
>   dma_fence_put(bo->moving);
> - if (!ttm_bo_uses_embedded_gem_object(bo))
> - dma_resv_fini(>base._resv);
>   bo->destroy(bo);
>  }
>  
> @@ -1056,15 +1054,6 @@ int ttm_bo_init_reserved(struct ttm_device *bdev,
>   } else {
>   bo->base.resv = >base._resv;
>   }
> - if (!ttm_bo_uses_embedded_gem_object(bo)) {
> - /*
> -  * bo.base is not initialized, so we have to setup the
> -  * struct elements we want use regardless.
> -  */
> - bo->base.size = size;
> - dma_resv_init(>base._resv);
> - drm_vma_node_reset(>base.vma_node);
> - }
>   atomic_inc(_glob.bo_count);
>  
>   /*
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> index 50e529a01677..587314d57991 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> @@ -460,6 +460,7 @@ void vmw_bo_bo_free(struct ttm_buffer_object *bo)
>   WARN_ON(vmw_bo->dirty);
>   WARN_ON(!RB_EMPTY_ROOT(_bo->res_tree));
>   vmw_bo_unmap(vmw_bo);
> + dma_resv_fini(>base._resv);
>   kfree(vmw_bo);
>  }
>  
> @@ -512,6 +513,11 @@ int vmw_bo_create_kernel(struct vmw_private *dev_priv, 
> unsigned long size,
>   if (unlikely(ret))
>   goto error_free;
>  
> +
> + bo->base.size = size;
> + dma_resv_init(>base._resv);
> + drm_vma_node_reset(>base.vma_node);
> +
>   ret = ttm_bo_init_reserved(_priv->bdev, bo, size,
>  ttm_bo_type_device, placement, 0,
>  , NULL, NULL, NULL);
> @@ -570,6 +576,10 @@ int vmw_bo_init(struct vmw_private *dev_priv,
>   if (unlikely(ret))
>   return ret;
>  
> + vmw_bo->base.base.size = size;
> + dma_resv_init(_bo->base.base._resv);
> + drm_vma_node_reset(_bo->base.base.vma_node);
> +
>   ret = ttm_bo_init_reserved(bdev, _bo->base, size,
>  ttm_bo_type_device, placement,
>  0, , NULL, NULL, bo_free);
> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> index 3587f660e8f4..e88da481a976 100644
> --- a/include/drm/ttm/ttm_bo_api.h
> +++ b/include/drm/ttm/ttm_bo_api.h
> @@ -562,25 +562,6 @@ ssize_t ttm_bo_io(struct ttm_device *bdev, struct file 
> *filp,
>  int ttm_bo_swapout(struct ttm_buffer_object *bo, struct ttm_operation_ctx 
> *ctx,
>  gfp_t gfp_flags);
>  
> -/**
> - * ttm_bo_uses_embedded_gem_object - check if the given bo uses the
> - * embedded drm_gem_object.
> - *
> - * Most ttm drivers are using gem too, so the embedded
> - * ttm_buffer_object.base will be initialized by the driver (before
> - * calling ttm_bo_init).  It is also possible to use ttm without gem
> - * though (vmwgfx does that).
> - *
> - * This helper will figure whenever a given ttm bo is a gem object too
> - * or not.
> - *
> - * @bo: The bo to check.
> - */
> -static inline bool ttm_bo_uses_embedded_gem_object(struct ttm_buffer_object 
> *bo)
> -{
> - return bo->base.dev != NULL;
> -}
> -
>  /**
>   * ttm_bo_pin - Pin the buffer object.
>   * @bo: The buffer object to pin
> -- 
> 2.25.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5.11 068/122] drm/vmwgfx: Make sure we unpin no longer needed buffers

[Greg Kroah-Hartman]

From: Zack Rusin 

commit ab4d9913632b1e5ffcf3365783e98718b3c83c7f upstream.

We were not correctly unpinning no longer needed buffers. In particular
vmw_buffer_object, which is internally often pinned on creation wasn't
unpinned on destruction and none of the internal MOB buffers were
unpinned before being put back. Technically this existed for a
long time but commit 57fcd550eb15 ("drm/ttm: Warn on pinning without
holding a reference") introduced a WARN_ON which was filling up the
kernel logs rather quickly.

Quite frankly internal usage of vmw_buffer_object and in general
pinning needs to be refactored in vmwgfx but for now this makes
it work.

Signed-off-by: Zack Rusin 
Reviewed-by: Martin Krastev 
Reviewed-by: Roland Scheidegger 
Fixes: 57fcd550eb15 ("drm/ttm: Warn on pinning without holding a reference")
Link: https://patchwork.freedesktop.org/patch/414984/?series=86052=1
Cc: Huang Rui 
Cc: Christian König 
Cc: Daniel Vetter 
Cc: Christian Koenig 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |2 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_mob.c |4 
 2 files changed, 6 insertions(+)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -1554,6 +1554,8 @@ static inline void vmw_bo_unreference(st
 
*buf = NULL;
if (tmp_buf != NULL) {
+   if (tmp_buf->base.pin_count > 0)
+   ttm_bo_unpin(_buf->base);
ttm_bo_put(_buf->base);
}
 }
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
@@ -277,6 +277,7 @@ out_no_setup:
 >otables[i]);
}
 
+   ttm_bo_unpin(batch->otable_bo);
ttm_bo_put(batch->otable_bo);
batch->otable_bo = NULL;
return ret;
@@ -342,6 +343,7 @@ static void vmw_otable_batch_takedown(st
vmw_bo_fence_single(bo, NULL);
ttm_bo_unreserve(bo);
 
+   ttm_bo_unpin(batch->otable_bo);
ttm_bo_put(batch->otable_bo);
batch->otable_bo = NULL;
 }
@@ -528,6 +530,7 @@ static void vmw_mob_pt_setup(struct vmw_
 void vmw_mob_destroy(struct vmw_mob *mob)
 {
if (mob->pt_bo) {
+   ttm_bo_unpin(mob->pt_bo);
ttm_bo_put(mob->pt_bo);
mob->pt_bo = NULL;
}
@@ -643,6 +646,7 @@ int vmw_mob_bind(struct vmw_private *dev
 out_no_cmd_space:
vmw_fifo_resource_dec(dev_priv);
if (pt_set_up) {
+   ttm_bo_unpin(mob->pt_bo);
ttm_bo_put(mob->pt_bo);
mob->pt_bo = NULL;
}


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Outreachy kernel] [PATCH 1/2] drm/amd/amdgpu/amdgpu_device.c: Replace drm_modeset_*_all with DRM_MODESET_LOCK_ALL_*

[Julia Lawall]

On Mon, 19 Apr 2021, Fabio M. De Francesco wrote:

> Replace the deprecated API with new helpers, according to the TODO list
> of the DRM subsystem.

The commit message will perhaps not be very meaningful one year from now.
You could say for example DRM_MODESET_LOCK_ALL_BEGIN was introduced in
commit XXX (there is a proper format for referring to other commits) for
what purpose.  And then say that you are making the replacement.

Actually, I'm a little surprised to see something that looks like a
function call be replaced by something that looks like a macro.  Maybe it
was a macro all along, and this is just making that more clear.  In any
case, if I were to look at this commit, I would appreciate a little more
context information.

julia

>
> Signed-off-by: Fabio M. De Francesco 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 6447cd6ca5a8..e1a71579f8e6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -32,6 +32,7 @@
>  #include 
>
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -3694,14 +3695,17 @@ int amdgpu_device_suspend(struct drm_device *dev, 
> bool fbcon)
>
>   if (!amdgpu_device_has_dc_support(adev)) {
>   /* turn off display hw */
> - drm_modeset_lock_all(dev);
> + struct drm_modeset_acquire_ctx ctx;
> + int ret;
> +
> + DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
>   drm_connector_list_iter_begin(dev, );
>   drm_for_each_connector_iter(connector, )
>   drm_helper_connector_dpms(connector,
> DRM_MODE_DPMS_OFF);
>   drm_connector_list_iter_end();
> - drm_modeset_unlock_all(dev);
> - /* unpin the front buffers and cursors */
> + DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
> + /* unpin the front buffers and cursors */
>   list_for_each_entry(crtc, >mode_config.crtc_list, head) {
>   struct amdgpu_crtc *amdgpu_crtc = to_amdgpu_crtc(crtc);
>   struct drm_framebuffer *fb = crtc->primary->fb;
> @@ -3830,19 +3834,21 @@ int amdgpu_device_resume(struct drm_device *dev, bool 
> fbcon)
>   /* blat the mode back in */
>   if (fbcon) {
>   if (!amdgpu_device_has_dc_support(adev)) {
> + struct drm_modeset_acquire_ctx ctx;
> + int ret;
> +
>   /* pre DCE11 */
>   drm_helper_resume_force_mode(dev);
>
>   /* turn on display hw */
> - drm_modeset_lock_all(dev);
> + DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
>
>   drm_connector_list_iter_begin(dev, );
>   drm_for_each_connector_iter(connector, )
>   drm_helper_connector_dpms(connector,
> DRM_MODE_DPMS_ON);
>   drm_connector_list_iter_end();
> -
> - drm_modeset_unlock_all(dev);
> + DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
>   }
>   amdgpu_fbdev_set_suspend(adev, 0);
>   }
> --
> 2.31.1
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20210419122059.738-2-fmdefrancesco%40gmail.com.
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] dma-buf: Add DmaBufTotal counter in meminfo

[Peter.Enderborg]

On 4/19/21 2:16 PM, Michal Hocko wrote:
> On Sat 17-04-21 12:40:32, Peter Enderborg wrote:
>> This adds a total used dma-buf memory. Details
>> can be found in debugfs, however it is not for everyone
>> and not always available. dma-buf are indirect allocated by
>> userspace. So with this value we can monitor and detect
>> userspace applications that have problems.
> The changelog would benefit from more background on why this is needed,
> and who is the primary consumer of that value.
>
> I cannot really comment on the dma-buf internals but I have two remarks.
> Documentation/filesystems/proc.rst needs an update with the counter
> explanation and secondly is this information useful for OOM situations
> analysis? If yes then show_mem should dump the value as well.
>
> From the implementation point of view, is there any reason why this
> hasn't used the existing global_node_page_state infrastructure?

I fix doc in next version.  Im not sure what you expect the commit message to 
include.

The function of the meminfo is: (From Documentation/filesystems/proc.rst)

"Provides information about distribution and utilization of memory."

Im not the designed of dma-buf, I think  global_node_page_state as a kernel
internal. dma-buf is a device driver that provides a function so I might be
on the outside. However I also see that it might be relevant for a OOM.
It is memory that can be freed by killing userspace processes.

The show_mem thing. Should it be a separate patch?




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/amd/amdgpu/amdgpu_drv.c: Replace drm_modeset_*_all with DRM_MODESET_LOCK_ALL_*

[Fabio M. De Francesco]

Replace the deprecated API with new helpers, according to the TODO list
of the DRM subsystem.

Signed-off-by: Fabio M. De Francesco 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 671ec1002230..0e9b7a180ee7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1438,8 +1438,10 @@ static int amdgpu_pmops_runtime_idle(struct device *dev)
 
if (amdgpu_device_has_dc_support(adev)) {
struct drm_crtc *crtc;
+   struct drm_modeset_acquire_ctx ctx;
+   int ret_lock;
 
-   drm_modeset_lock_all(drm_dev);
+   DRM_MODESET_LOCK_ALL_BEGIN(drm_dev, ctx, 0, ret_lock);
 
drm_for_each_crtc(crtc, drm_dev) {
if (crtc->state->active) {
@@ -1448,7 +1450,7 @@ static int amdgpu_pmops_runtime_idle(struct device *dev)
}
}
 
-   drm_modeset_unlock_all(drm_dev);
+   DRM_MODESET_LOCK_ALL_END(drm_dev, ctx, ret_lock);
 
} else {
struct drm_connector *list_connector;
-- 
2.31.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/amd/amdgpu/amdgpu_device.c: Replace drm_modeset_*_all with DRM_MODESET_LOCK_ALL_*

[Fabio M. De Francesco]

Replace the deprecated API with new helpers, according to the TODO list
of the DRM subsystem.

Signed-off-by: Fabio M. De Francesco 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 6447cd6ca5a8..e1a71579f8e6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -32,6 +32,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -3694,14 +3695,17 @@ int amdgpu_device_suspend(struct drm_device *dev, bool 
fbcon)
 
if (!amdgpu_device_has_dc_support(adev)) {
/* turn off display hw */
-   drm_modeset_lock_all(dev);
+   struct drm_modeset_acquire_ctx ctx;
+   int ret;
+
+   DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
drm_connector_list_iter_begin(dev, );
drm_for_each_connector_iter(connector, )
drm_helper_connector_dpms(connector,
  DRM_MODE_DPMS_OFF);
drm_connector_list_iter_end();
-   drm_modeset_unlock_all(dev);
-   /* unpin the front buffers and cursors */
+   DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
+   /* unpin the front buffers and cursors */
list_for_each_entry(crtc, >mode_config.crtc_list, head) {
struct amdgpu_crtc *amdgpu_crtc = to_amdgpu_crtc(crtc);
struct drm_framebuffer *fb = crtc->primary->fb;
@@ -3830,19 +3834,21 @@ int amdgpu_device_resume(struct drm_device *dev, bool 
fbcon)
/* blat the mode back in */
if (fbcon) {
if (!amdgpu_device_has_dc_support(adev)) {
+   struct drm_modeset_acquire_ctx ctx;
+   int ret;
+
/* pre DCE11 */
drm_helper_resume_force_mode(dev);
 
/* turn on display hw */
-   drm_modeset_lock_all(dev);
+   DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
 
drm_connector_list_iter_begin(dev, );
drm_for_each_connector_iter(connector, )
drm_helper_connector_dpms(connector,
  DRM_MODE_DPMS_ON);
drm_connector_list_iter_end();
-
-   drm_modeset_unlock_all(dev);
+   DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
}
amdgpu_fbdev_set_suspend(adev, 0);
}
-- 
2.31.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/2] drm/amd/amdgpu: Replace drm_modeset_*_all with DRM_MODESET_LOCK_ALL_*

[Fabio M. De Francesco]

According to the TODO list of the DRM subsystem, replace the deprecated
drm_modeset_*_all() with DRM_MODESET_LOCK_ALL_*().

Fabio M. De Francesco (2):
  drm/amd/amdgpu/amdgpu_device.c: Replace drm_modeset_*_all with
DRM_MODESET_LOCK_ALL_*
  drm/amd/amdgpu/amdgpu_drv.c: Replace drm_modeset_*_all with
DRM_MODESET_LOCK_ALL_*

 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 18 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  6 --
 2 files changed, 16 insertions(+), 8 deletions(-)

-- 
2.31.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match

[Arnd Bergmann]

On Mon, Apr 19, 2021 at 11:33 AM Dominique MARTINET
 wrote:
> Geert Uytterhoeven wrote on Mon, Apr 19, 2021 at 11:03:24AM +0200:
>
> > soc_device_match() should only be used as a last resort, to identify
> > systems that cannot be identified otherwise.  Typically this is used for
> > quirks, which should only be enabled on a very specific subset of
> > systems.  IMHO such systems should make sure soc_device_match()
> > is available early, by registering their SoC device early.
>
> I definitely agree there, my suggestion to defer was only because I know
> of no other way to influence the ordering of drivers loading reliably
> and gave up on soc being init'd early.

In some cases, you can use the device_link infrastructure to deal
with dependencies between devices. Not sure if this would help
in your case, but have a look at device_link_add() etc in drivers/base/core.c

> In this particular case the problem is that since 7d981405d0fd ("soc:
> imx8m: change to use platform driver") the soc probe tries to use the
> nvmem driver for ocotp fuses for imx8m devices, which isn't ready yet.
> So soc loading gets pushed back to the end of the list because it gets
> defered and other drivers relying on soc_device_match get confused
> because they wrongly think a device doesn't match a quirk when it
> actually does.
>
> If there is a way to ensure the nvmem driver gets loaded before the soc,
> that would also solve the problem nicely, and avoid the need to mess
> with all the ~50 drivers which use it.
>
> Is there a way to control in what order drivers get loaded? Something in
> the dtb perhaps?

For built-in drivers, load order depends on the initcall level and
link order (how things are lined listed in the Makefile hierarchy).

For loadable modules, this is up to user space in the end.

Which of the drivers in this scenario are loadable modules?

Arnd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Split render/display SoCs, Mesa's renderonly, and Wayland dmabuf hints

[Simon Ser]

Hi all,

I'm working on a Wayland extension [1] that, among other things, allows
compositors to advertise the preferred device to be used by Wayland
clients.

In general, compositors will send a render node. However, in the case
of split render/display SoCs, things get a little bit complicated.

The Wayland compositor will find the display-only DRM device (usually
at /dev/dri/card0). This DRM device will have a DRM primary node, but
no DRM render node.

The Wayland compositor will create a GBM device from this display-only
device, then create an EGL display. Under the hood, Mesa's kmsro will
kick in and magically open a render node from a different device.

However the compositor has no knowledge of this, and has no way to
discover the render node opened by kmsro.

This is an issue because the compositor has no render node to send to
Wayland clients. The compositor is forced to send a primary node to
clients. Clients will need to open the primary node and rely on Mesa's
renderonly to once again magically open the render node under the hood.

In general clients cannot be expected to be able to open primary nodes.
This happens to work on systemd distributions because udev sets a
special uaccess tag on the primary node that makes logind grant
permissions to users physically logged in on a VT.

This will fall apart on non-logind systems and on systems where no user
is physically logged in. Additionally, it may be desirable to deny
access to primary nodes in sandboxes.

So I believe the best way forward would be for the compositor to send
the render node to clients. This could prevent clients to allocate
buffers suitable for scan-out, but that can be fixed with some kind of
buffer constraints negotiation, like we presented at XDC 2020 [2].

There are a few solutions:

1. Require compositors to discover the render device by trying to import
   a buffer. For each available render device, the compositor would
   allocate a buffer, export it as a DMA-BUF, import it to the
   display-only device, then try to drmModeAddFB.
2. Allow compositors to query the render device magically opened by
   kmsro. This could be done either via EGL_EXT_device_drm, or via a
   new EGL extension.
3. Allow compositors to query the kernel drivers to know which devices
   are compatible with each other. Some uAPI to query a compatible
   display device from a render-only device, or vice-versa, has been
   suggested in the past.

(1) has a number of limitations and gotchas. It requires allocating
real buffers, this has a rather big cost for something done at
compositor initialization time. It requires to select a buffer format
and modifier compatible with both devices, so it can't be isolated in
a simple function (and e.g. shared between all compositors in libdrm).
Some drivers will allow to drmModeAddFB buffers that can't be scanned
out, and will only reject the buffer at atomic commit time.

(2) wouldn't work with non-EGL APIs such as Vulkan. Eric Anholt seemed
pretty opposed to this idea, but I didn't fully understood why.

I don't know how feasible (3) is. The kernel drivers must be able to
decide whether buffers coming from another driver can be scanned out,
but how early can they give an answer? Can they give an answer solely
based on a DRM node, and not a DMA-BUF?

Feedback is welcome. Do you agree with the premise that compositors
need access to the render node? Do you have any other potential solution
in mind? Which solution would you prefer?

Thanks,

Simon

[1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/8
[2]: https://xdc2020.x.org/event/9/contributions/634/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 4/4] drm/doc/rfc: i915 DG1 uAPI

[Matthew Auld]

On 16/04/2021 17:38, Jason Ekstrand wrote:

On Thu, Apr 15, 2021 at 11:04 AM Matthew Auld  wrote:


Add an entry for the new uAPI needed for DG1.

v2(Daniel):
   - include the overall upstreaming plan
   - add a note for mmap, there are differences here for TTM vs i915
   - bunch of other suggestions from Daniel
v3:
  (Daniel)
   - add a note for set/get caching stuff
   - add some more docs for existing query and extensions stuff
   - add an actual code example for regions query
   - bunch of other stuff
  (Jason)
   - uAPI change(!):
 - try a simpler design with the placements extension
 - rather than have a generic setparam which can cover multiple
   use cases, have each extension be responsible for one thing
   only

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Jordan Justen 
Cc: Daniel Vetter 
Cc: Kenneth Graunke 
Cc: Jason Ekstrand 
Cc: Dave Airlie 
Cc: dri-devel@lists.freedesktop.org
Cc: mesa-...@lists.freedesktop.org
---
  Documentation/gpu/rfc/i915_gem_lmem.h   | 255 
  Documentation/gpu/rfc/i915_gem_lmem.rst | 139 +
  Documentation/gpu/rfc/index.rst |   4 +
  3 files changed, 398 insertions(+)
  create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.h
  create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.rst

diff --git a/Documentation/gpu/rfc/i915_gem_lmem.h 
b/Documentation/gpu/rfc/i915_gem_lmem.h
new file mode 100644
index ..2a82a452e9f2
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_gem_lmem.h
@@ -0,0 +1,255 @@
+/*
+ * Note that drm_i915_query_item and drm_i915_query are existing bits of uAPI.
+ * For the regions query we are just adding a new query id, so no actual new
+ * ioctl or anything, but including it here for reference.
+ */
+struct drm_i915_query_item {
+#define DRM_I915_QUERY_MEMORY_REGIONS   0xdeadbeaf
+   
+__u64 query_id;
+
+/*
+ * When set to zero by userspace, this is filled with the size of the
+ * data to be written at the data_ptr pointer. The kernel sets this
+ * value to a negative value to signal an error on a particular query
+ * item.
+ */
+__s32 length;
+
+__u32 flags;
+/*
+ * Data will be written at the location pointed by data_ptr when the
+ * value of length matches the length of the data to be written by the
+ * kernel.
+ */
+__u64 data_ptr;
+};
+
+struct drm_i915_query {
+__u32 num_items;
+/*
+ * Unused for now. Must be cleared to zero.
+ */
+__u32 flags;
+/*
+ * This points to an array of num_items drm_i915_query_item structures.
+ */
+__u64 items_ptr;
+};
+
+#define DRM_IOCTL_I915_QUERY   DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_QUERY, 
struct drm_i915_query)
+
+/**
+ * enum drm_i915_gem_memory_class
+ */
+enum drm_i915_gem_memory_class {
+   /** @I915_MEMORY_CLASS_SYSTEM: system memory */
+   I915_MEMORY_CLASS_SYSTEM = 0,
+   /** @I915_MEMORY_CLASS_DEVICE: device local-memory */
+   I915_MEMORY_CLASS_DEVICE,
+};
+
+/**
+ * struct drm_i915_gem_memory_class_instance
+ */
+struct drm_i915_gem_memory_class_instance {
+   /** @memory_class: see enum drm_i915_gem_memory_class */
+   __u16 memory_class;
+
+   /** @memory_instance: which instance */
+   __u16 memory_instance;
+};
+
+/**
+ * struct drm_i915_memory_region_info
+ *
+ * Describes one region as known to the driver.
+ *
+ * Note that we reserve quite a lot of stuff here for potential future work. As
+ * an example we might want expose the capabilities(see caps) for a given
+ * region, which could include things like if the region is CPU
+ * mappable/accessible etc.


I get caps but I'm seriously at a loss as to what the rest of this
would be used for.  Why are caps and flags both there and separate?
Flags are typically something you set, not query.  Also, what's with
rsvd1 at the end?  This smells of substantial over-building to me.

I thought to myself, "maybe I'm missing a future use-case" so I looked
at the internal tree and none of this is being used there either.
This indicates to me that either I'm missing something and there's
code somewhere I don't know about or, with three years of building on
internal branches, we still haven't proven that any of this is needed.
If it's the latter, which I strongly suspect, maybe we should drop the
unnecessary bits and only add them back in if and when we have proof
that they're useful.


Do you mean just drop caps/flags here, but keep/inflate rsvd0/rsvd1, 
which is less opinionated about future unknowns? If so, makes sense to me.




To be clear, I don't mind the query API as such and the class/instance
stuff seems fine and I really like being able to get the sizes
directly.  What concerns me is all this extra future-proofing that we
have zero proof is actually useful.  In my experience, when you build
out like this without so much as a 

Re: [Nouveau] [PATCH 13/40] drm/nouveau/dispnv50/disp: Include header containing our prototypes

[Karol Herbst]

Reviewed-by: Karol Herbst 

On Fri, Apr 16, 2021 at 4:38 PM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/nouveau/dispnv50/disp.c:2599:1: warning: no previous 
> prototype for ‘nv50_display_create’ [-Wmissing-prototypes]
>
> Cc: Ben Skeggs 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Lee Jones 
> ---
>  drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 351f954989530..4905ed584ff48 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -68,6 +68,8 @@
>
>  #include 
>
> +#include "nv50_display.h"
> +
>  
> /**
>   * EVO channel
>   
> */
> --
> 2.27.0
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 14/40] drm/nouveau/nouveau_ioc32: File headers are not good candidates for kernel-doc

[Karol Herbst]

Reviewed-by: Karol Herbst 

On Fri, Apr 16, 2021 at 4:38 PM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/nouveau/nouveau_ioc32.c:2: warning: Cannot understand  * 
> file mga_ioc32.c
>
> Cc: Ben Skeggs 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Lee Jones 
> ---
>  drivers/gpu/drm/nouveau/nouveau_ioc32.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_ioc32.c 
> b/drivers/gpu/drm/nouveau/nouveau_ioc32.c
> index adf01ca9e035d..8ddf9b2325a42 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_ioc32.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_ioc32.c
> @@ -1,4 +1,4 @@
> -/**
> +/*
>   * \file mga_ioc32.c
>   *
>   * 32-bit ioctl compatibility routines for the MGA DRM.
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH 16/40] drm/nouveau/nouveau_ioc32: Demote kernel-doc abuse to standard comment block

[Karol Herbst]

Reviewed-by: Karol Herbst 

On Fri, Apr 16, 2021 at 4:38 PM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/nouveau/nouveau_ioc32.c:52: warning: Function parameter or 
> member 'filp' not described in 'nouveau_compat_ioctl'
>  drivers/gpu/drm/nouveau/nouveau_ioc32.c:52: warning: Function parameter or 
> member 'cmd' not described in 'nouveau_compat_ioctl'
>  drivers/gpu/drm/nouveau/nouveau_ioc32.c:52: warning: Function parameter or 
> member 'arg' not described in 'nouveau_compat_ioctl'
>
> Cc: Ben Skeggs 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Lee Jones 
> ---
>  drivers/gpu/drm/nouveau/nouveau_ioc32.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_ioc32.c 
> b/drivers/gpu/drm/nouveau/nouveau_ioc32.c
> index 8ddf9b2325a42..2af3615c5205c 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_ioc32.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_ioc32.c
> @@ -38,7 +38,7 @@
>
>  #include "nouveau_ioctl.h"
>
> -/**
> +/*
>   * Called whenever a 32-bit process running under a 64-bit kernel
>   * performs an ioctl on /dev/dri/card.
>   *
> --
> 2.27.0
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
>

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH 15/40] drm/nouveau/nouveau_svm: Remove unused variable 'ret' from void function

[Karol Herbst]

On Fri, Apr 16, 2021 at 4:38 PM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/nouveau/nouveau_svm.c: In function ‘nouveau_pfns_map’:
>  drivers/gpu/drm/nouveau/nouveau_svm.c:810:6: warning: variable ‘ret’ set but 
> not used [-Wunused-but-set-variable]
>
> Cc: Ben Skeggs 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Lee Jones 
> ---
>  drivers/gpu/drm/nouveau/nouveau_svm.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c 
> b/drivers/gpu/drm/nouveau/nouveau_svm.c
> index 1c3f890377d2c..26af6ee915368 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_svm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
> @@ -811,7 +811,6 @@ nouveau_pfns_map(struct nouveau_svmm *svmm, struct 
> mm_struct *mm,
>  unsigned long addr, u64 *pfns, unsigned long npages)
>  {
> struct nouveau_pfnmap_args *args = nouveau_pfns_to_args(pfns);
> -   int ret;
>
> args->p.addr = addr;
> args->p.size = npages << PAGE_SHIFT;
> @@ -819,8 +818,8 @@ nouveau_pfns_map(struct nouveau_svmm *svmm, struct 
> mm_struct *mm,
> mutex_lock(>mutex);
>
> svmm->vmm->vmm.object.client->super = true;
> -   ret = nvif_object_ioctl(>vmm->vmm.object, args, sizeof(*args) +
> -   npages * sizeof(args->p.phys[0]), NULL);
> +   nvif_object_ioctl(>vmm->vmm.object, args, sizeof(*args) +
> + npages * sizeof(args->p.phys[0]), NULL);

yeah mhh.. I think this one is actually fine, but it might make sense
to still report something back, although in userspace we still don't
care as the CL API doesn't return any error.

> svmm->vmm->vmm.object.client->super = false;
>
> mutex_unlock(>mutex);
> --
> 2.27.0
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH 12/40] drm/nouveau/nv50_display: Remove superfluous prototype for local static functions

[Karol Herbst]

Reviewed-by: Karol Herbst 

On Fri, Apr 16, 2021 at 4:38 PM Lee Jones  wrote:
>
> Fixes the following build error:
>
>  drivers/gpu/drm/nouveau/dispnv50/disp.c:2530:1: error: conflicting types for 
> ‘nv50_display_fini’
>  In file included from drivers/gpu/drm/nouveau/dispnv50/disp.c:71:
>  drivers/gpu/drm/nouveau/nv50_display.h:36:6: note: previous declaration of 
> ‘nv50_display_fini’ was her
>  In file included from drivers/gpu/drm/nouveau/dispnv50/disp.c:71:
>  drivers/gpu/drm/nouveau/nv50_display.h:35:6: note: previous declaration of 
> ‘nv50_display_init’ was here
>  drivers/gpu/drm/nouveau/dispnv50/disp.c:2581:1: error: static declaration of 
> ‘nv50_display_destroy’ follows non-static declaration
>  In file included from drivers/gpu/drm/nouveau/dispnv50/disp.c:71:
>  drivers/gpu/drm/nouveau/nv50_display.h:34:6: note: previous declaration of 
> ‘nv50_display_destroy’ was here
>
> Cc: Ben Skeggs 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Lee Jones 
> ---
>  drivers/gpu/drm/nouveau/nv50_display.h | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nv50_display.h 
> b/drivers/gpu/drm/nouveau/nv50_display.h
> index fbd3b15583bc8..2421401d12636 100644
> --- a/drivers/gpu/drm/nouveau/nv50_display.h
> +++ b/drivers/gpu/drm/nouveau/nv50_display.h
> @@ -31,7 +31,4 @@
>  #include "nouveau_reg.h"
>
>  int  nv50_display_create(struct drm_device *);
> -void nv50_display_destroy(struct drm_device *);
> -int  nv50_display_init(struct drm_device *);
> -void nv50_display_fini(struct drm_device *);
>  #endif /* __NV50_DISPLAY_H__ */
> --
> 2.27.0
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH 11/40] drm/nouveau/dispnv50/headc57d: Make local function 'headc57d_olut' static

[Karol Herbst]

Reviewed-by: Karol Herbst 

On Fri, Apr 16, 2021 at 4:38 PM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/nouveau/dispnv50/headc57d.c:173:1: warning: no previous 
> prototype for ‘headc57d_olut’ [-Wmissing-prototypes]
>
> Cc: Ben Skeggs 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Lyude Paul 
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Lee Jones 
> ---
>  drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c 
> b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
> index fd51527b56b83..bdcfd240d61c8 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
> @@ -169,7 +169,7 @@ headc57d_olut_load(struct drm_color_lut *in, int size, 
> void __iomem *mem)
> writew(readw(mem - 4), mem + 4);
>  }
>
> -bool
> +static bool
>  headc57d_olut(struct nv50_head *head, struct nv50_head_atom *asyh, int size)
>  {
> if (size != 0 && size != 256 && size != 1024)
> --
> 2.27.0
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH 10/40] drm/nouveau/dispnv50/disp: Remove unused variable 'ret' from function returning void

[Karol Herbst]

On Fri, Apr 16, 2021 at 4:38 PM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/nouveau/dispnv50/disp.c: In function ‘nv50_mstm_cleanup’:
>  drivers/gpu/drm/nouveau/dispnv50/disp.c:1357:6: warning: variable ‘ret’ set 
> but not used [-Wunused-but-set-variable]
>

same comment here: we should really check if it's better to handle the
error and report it back that something failed or so..

> Cc: Ben Skeggs 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Lee Jones 
> ---
>  drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 4801aafd9552b..351f954989530 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -1386,12 +1386,11 @@ nv50_mstm_cleanup(struct nv50_mstm *mstm)
>  {
> struct nouveau_drm *drm = nouveau_drm(mstm->outp->base.base.dev);
> struct drm_encoder *encoder;
> -   int ret;
>
> NV_ATOMIC(drm, "%s: mstm cleanup\n", mstm->outp->base.base.name);
> -   ret = drm_dp_check_act_status(>mgr);
> +   drm_dp_check_act_status(>mgr);
>
> -   ret = drm_dp_update_payload_part2(>mgr);
> +   drm_dp_update_payload_part2(>mgr);
>
> drm_for_each_encoder(encoder, mstm->outp->base.base.dev) {
> if (encoder->encoder_type == DRM_MODE_ENCODER_DPMST) {
> --
> 2.27.0
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 09/40] drm/nouveau/dispnv04/crtc: Demote non-conforming kernel-doc headers

[Karol Herbst]

Reviewed-by: Karol Herbst 

On Fri, Apr 16, 2021 at 4:38 PM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c:462: warning: Function parameter or 
> member 'crtc' not described in 'nv_crtc_mode_set_regs'
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c:462: warning: Function parameter or 
> member 'mode' not described in 'nv_crtc_mode_set_regs'
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or 
> member 'crtc' not described in 'nv_crtc_mode_set'
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or 
> member 'mode' not described in 'nv_crtc_mode_set'
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or 
> member 'adjusted_mode' not described in 'nv_crtc_mode_set'
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or 
> member 'x' not described in 'nv_crtc_mode_set'
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or 
> member 'y' not described in 'nv_crtc_mode_set'
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or 
> member 'old_fb' not described in 'nv_crtc_mode_set'
>
> Cc: Ben Skeggs 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Lee Jones 
> ---
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c 
> b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> index f9e962fd94d0d..f9a276ea5a9e0 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> @@ -449,7 +449,7 @@ nv_crtc_mode_set_vga(struct drm_crtc *crtc, struct 
> drm_display_mode *mode)
> regp->Attribute[NV_CIO_AR_CSEL_INDEX] = 0x00;
>  }
>
> -/**
> +/*
>   * Sets up registers for the given mode/adjusted_mode pair.
>   *
>   * The clocks, CRTCs and outputs attached to this CRTC must be off.
> @@ -625,7 +625,7 @@ nv_crtc_swap_fbs(struct drm_crtc *crtc, struct 
> drm_framebuffer *old_fb)
> return ret;
>  }
>
> -/**
> +/*
>   * Sets up registers for the given mode/adjusted_mode pair.
>   *
>   * The clocks, CRTCs and outputs attached to this CRTC must be off.
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH 07/40] drm/nouveau/nouveau_bo: Remove unused variables 'dev'

[Karol Herbst]

Reviewed-by: Karol Herbst 

On Fri, Apr 16, 2021 at 4:37 PM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/nouveau/nouveau_bo.c: In function ‘nouveau_ttm_tt_populate’:
>  drivers/gpu/drm/nouveau/nouveau_bo.c:1228:17: warning: variable ‘dev’ set 
> but not used [-Wunused-but-set-variable]
>  drivers/gpu/drm/nouveau/nouveau_bo.c: In function 
> ‘nouveau_ttm_tt_unpopulate’:
>  drivers/gpu/drm/nouveau/nouveau_bo.c:1252:17: warning: variable ‘dev’ set 
> but not used [-Wunused-but-set-variable]
>
> Cc: Ben Skeggs 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Sumit Semwal 
> Cc: "Christian König" 
> Cc: Jeremy Kolb 
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Signed-off-by: Lee Jones 
> ---
>  drivers/gpu/drm/nouveau/nouveau_bo.c | 4 
>  1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 3e09df0472ce4..37b3d2c10f5c5 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -1255,7 +1255,6 @@ nouveau_ttm_tt_populate(struct ttm_device *bdev,
>  {
> struct ttm_tt *ttm_dma = (void *)ttm;
> struct nouveau_drm *drm;
> -   struct device *dev;
> bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
>
> if (ttm_tt_is_populated(ttm))
> @@ -1268,7 +1267,6 @@ nouveau_ttm_tt_populate(struct ttm_device *bdev,
> }
>
> drm = nouveau_bdev(bdev);
> -   dev = drm->dev->dev;
>
> return ttm_pool_alloc(>ttm.bdev.pool, ttm, ctx);
>  }
> @@ -1278,14 +1276,12 @@ nouveau_ttm_tt_unpopulate(struct ttm_device *bdev,
>   struct ttm_tt *ttm)
>  {
> struct nouveau_drm *drm;
> -   struct device *dev;
> bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
>
> if (slave)
> return;
>
> drm = nouveau_bdev(bdev);
> -   dev = drm->dev->dev;
>
> return ttm_pool_free(>ttm.bdev.pool, ttm);
>  }
> --
> 2.27.0
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH 05/40] drm/nouveau/nvkm/subdev/volt/gk20a: Demote non-conformant kernel-doc headers

[Karol Herbst]

Reviewed-by: Karol Herbst 

On Fri, Apr 16, 2021 at 4:37 PM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:53: warning: Function 
> parameter or member 'speedo' not described in 'gk20a_volt_get_cvb_voltage'
>  drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:53: warning: Function 
> parameter or member 's_scale' not described in 'gk20a_volt_get_cvb_voltage'
>  drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:53: warning: Function 
> parameter or member 'coef' not described in 'gk20a_volt_get_cvb_voltage'
>  drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:69: warning: Function 
> parameter or member 'speedo' not described in 'gk20a_volt_get_cvb_t_voltage'
>  drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:69: warning: Function 
> parameter or member 'temp' not described in 'gk20a_volt_get_cvb_t_voltage'
>  drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:69: warning: Function 
> parameter or member 's_scale' not described in 'gk20a_volt_get_cvb_t_voltage'
>  drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:69: warning: Function 
> parameter or member 't_scale' not described in 'gk20a_volt_get_cvb_t_voltage'
>  drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:69: warning: Function 
> parameter or member 'coef' not described in 'gk20a_volt_get_cvb_t_voltage'
>
> Cc: Ben Skeggs 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Lee Jones 
> ---
>  drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c
> index 8c2faa9645111..ccac88da88648 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c
> @@ -45,7 +45,7 @@ static const struct cvb_coef gk20a_cvb_coef[] = {
> /* 852 */ { 1608418, -21643, -269, 0,763,  -48},
>  };
>
> -/**
> +/*
>   * cvb_mv = ((c2 * speedo / s_scale + c1) * speedo / s_scale + c0)
>   */
>  static inline int
> @@ -58,7 +58,7 @@ gk20a_volt_get_cvb_voltage(int speedo, int s_scale, const 
> struct cvb_coef *coef)
> return mv;
>  }
>
> -/**
> +/*
>   * cvb_t_mv =
>   * ((c2 * speedo / s_scale + c1) * speedo / s_scale + c0) +
>   * ((c3 * speedo / s_scale + c4 + c5 * T / t_scale) * T / t_scale)
> --
> 2.27.0
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
>

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH 06/40] drm/nouveau/nvkm/engine/gr/gf100: Demote non-conformant kernel-doc header

[Karol Herbst]

Reviewed-by: Karol Herbst 

On Fri, Apr 16, 2021 at 4:37 PM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:992: warning: Function 
> parameter or member 'gr' not described in 'gf100_gr_wait_idle'
>
> Cc: Ben Skeggs 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Lee Jones 
> ---
>  drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c 
> b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c
> index 397ff4fe9df89..69e6008f99196 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c
> @@ -982,7 +982,7 @@ gf100_gr_zbc_init(struct gf100_gr *gr)
> }
>  }
>
> -/**
> +/*
>   * Wait until GR goes idle. GR is considered idle if it is disabled by the
>   * MC (0x200) register, or GR is not busy and a context switch is not in
>   * progress.
> --
> 2.27.0
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
>

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH 02/40] drm/nouveau/dispnv50/disp: Remove unused variable 'ret'

[Karol Herbst]

On Fri, Apr 16, 2021 at 4:37 PM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/nouveau/dispnv50/disp.c:1381:6: warning: variable ‘ret’ set 
> but not used [-Wunused-but-set-variable]
>

not a big fan of just ignoring return codes, I'd rather see it handled
somehow, unless somebody knowing more about the details here says it's
okay.

> Cc: Ben Skeggs 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Lee Jones 
> ---
>  drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 1c9c0cdf85dbc..4801aafd9552b 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -1410,10 +1410,9 @@ nv50_mstm_prepare(struct nv50_mstm *mstm)
>  {
> struct nouveau_drm *drm = nouveau_drm(mstm->outp->base.base.dev);
> struct drm_encoder *encoder;
> -   int ret;
>
> NV_ATOMIC(drm, "%s: mstm prepare\n", mstm->outp->base.base.name);
> -   ret = drm_dp_update_payload_part1(>mgr);
> +   drm_dp_update_payload_part1(>mgr);
>
> drm_for_each_encoder(encoder, mstm->outp->base.base.dev) {
> if (encoder->encoder_type == DRM_MODE_ENCODER_DPMST) {
> --
> 2.27.0
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH 01/40] drm/nouveau/nvkm/subdev/bios/init: Demote obvious abuse of kernel-doc

[Karol Herbst]

Reviewed-by: Karol Herbst 

On Fri, Apr 16, 2021 at 4:37 PM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:584: warning: Function 
> parameter or member 'init' not described in 'init_reserved'
>  drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:611: warning: Function 
> parameter or member 'init' not described in 'init_done'
>  drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:622: warning: Function 
> parameter or member 'init' not described in 'init_io_restrict_prog'
>  drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:659: warning: Function 
> parameter or member 'init' not described in 'init_repeat'
>  drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:685: warning: Function 
> parameter or member 'init' not described in 'init_io_restrict_pll'
>  drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:725: warning: Function 
> parameter or member 'init' not described in 'init_end_repeat'
>
> NB: Trimmed for brevity (lots of these!)
>
> Cc: Ben Skeggs 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Lee Jones 
> ---
>  .../gpu/drm/nouveau/nvkm/subdev/bios/init.c   | 204 ++
>  1 file changed, 68 insertions(+), 136 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
> index 9de74f41dcd2a..5a91dc4e5c8ec 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
> @@ -575,9 +575,8 @@ init_tmds_reg(struct nvbios_init *init, u8 tmds)
>   * init opcode handlers
>   
> */
>
> -/**
> +/*
>   * init_reserved - stub for various unknown/unused single-byte opcodes
> - *
>   */
>  static void
>  init_reserved(struct nvbios_init *init)
> @@ -602,9 +601,8 @@ init_reserved(struct nvbios_init *init)
> init->offset += length;
>  }
>
> -/**
> +/*
>   * INIT_DONE - opcode 0x71
> - *
>   */
>  static void
>  init_done(struct nvbios_init *init)
> @@ -613,9 +611,8 @@ init_done(struct nvbios_init *init)
> init->offset = 0x;
>  }
>
> -/**
> +/*
>   * INIT_IO_RESTRICT_PROG - opcode 0x32
> - *
>   */
>  static void
>  init_io_restrict_prog(struct nvbios_init *init)
> @@ -650,9 +647,8 @@ init_io_restrict_prog(struct nvbios_init *init)
> trace("}]\n");
>  }
>
> -/**
> +/*
>   * INIT_REPEAT - opcode 0x33
> - *
>   */
>  static void
>  init_repeat(struct nvbios_init *init)
> @@ -676,9 +672,8 @@ init_repeat(struct nvbios_init *init)
> init->repeat = repeat;
>  }
>
> -/**
> +/*
>   * INIT_IO_RESTRICT_PLL - opcode 0x34
> - *
>   */
>  static void
>  init_io_restrict_pll(struct nvbios_init *init)
> @@ -716,9 +711,8 @@ init_io_restrict_pll(struct nvbios_init *init)
> trace("}]\n");
>  }
>
> -/**
> +/*
>   * INIT_END_REPEAT - opcode 0x36
> - *
>   */
>  static void
>  init_end_repeat(struct nvbios_init *init)
> @@ -732,9 +726,8 @@ init_end_repeat(struct nvbios_init *init)
> }
>  }
>
> -/**
> +/*
>   * INIT_COPY - opcode 0x37
> - *
>   */
>  static void
>  init_copy(struct nvbios_init *init)
> @@ -759,9 +752,8 @@ init_copy(struct nvbios_init *init)
> init_wrvgai(init, port, index, data);
>  }
>
> -/**
> +/*
>   * INIT_NOT - opcode 0x38
> - *
>   */
>  static void
>  init_not(struct nvbios_init *init)
> @@ -771,9 +763,8 @@ init_not(struct nvbios_init *init)
> init_exec_inv(init);
>  }
>
> -/**
> +/*
>   * INIT_IO_FLAG_CONDITION - opcode 0x39
> - *
>   */
>  static void
>  init_io_flag_condition(struct nvbios_init *init)
> @@ -788,9 +779,8 @@ init_io_flag_condition(struct nvbios_init *init)
> init_exec_set(init, false);
>  }
>
> -/**
> +/*
>   * INIT_GENERIC_CONDITION - opcode 0x3a
> - *
>   */
>  static void
>  init_generic_condition(struct nvbios_init *init)
> @@ -840,9 +830,8 @@ init_generic_condition(struct nvbios_init *init)
> }
>  }
>
> -/**
> +/*
>   * INIT_IO_MASK_OR - opcode 0x3b
> - *
>   */
>  static void
>  init_io_mask_or(struct nvbios_init *init)
> @@ -859,9 +848,8 @@ init_io_mask_or(struct nvbios_init *init)
> init_wrvgai(init, 0x03d4, index, data &= ~(1 << or));
>  }
>
> -/**
> +/*
>   * INIT_IO_OR - opcode 0x3c
> - *
>   */
>  static void
>  init_io_or(struct nvbios_init *init)
> @@ -878,9 +866,8 @@ init_io_or(struct nvbios_init *init)
> init_wrvgai(init, 0x03d4, index, data | (1 << or));
>  }
>
> -/**
> +/*
>   * INIT_ANDN_REG - opcode 0x47
> - *
>   */
>  static void
>  init_andn_reg(struct nvbios_init *init)
> @@ -895,9 +882,8 @@ init_andn_reg(struct nvbios_init *init)
> init_mask(init, reg, mask, 0);
>  }
>
> -/**
> +/*
>   * INIT_OR_REG - opcode 0x48
> - *
>   */
>  static void
>  init_or_reg(struct nvbios_init *init)
> @@ -912,9 +898,8 @@ init_or_reg(struct nvbios_init *init)
> init_mask(init, reg, 0, mask);
>  }
>
> -/**
> +/*
> 

Re: [Intel-gfx] [PATCH 11/19] drm/i915: Update the helper to set correct mapping

[Matthew Auld]

On 15/04/2021 12:05, Tvrtko Ursulin wrote:


On 15/04/2021 10:23, Matthew Auld wrote:

On Thu, 15 Apr 2021 at 09:21, Tvrtko Ursulin
 wrote:



On 14/04/2021 17:20, Matthew Auld wrote:

On Wed, 14 Apr 2021 at 16:22, Tvrtko Ursulin
 wrote:



On 12/04/2021 10:05, Matthew Auld wrote:

From: Venkata Sandeep Dhanalakota 

Determine the possible coherent map type based on object location,
and if target has llc or if user requires an always coherent
mapping.

Cc: Matthew Auld 
Cc: CQ Tang 
Suggested-by: Michal Wajdeczko 
Signed-off-by: Venkata Sandeep Dhanalakota 


---
    drivers/gpu/drm/i915/gt/intel_engine_cs.c    |  3 ++-
    drivers/gpu/drm/i915/gt/intel_engine_pm.c    |  2 +-
    drivers/gpu/drm/i915/gt/intel_lrc.c  |  4 +++-
    drivers/gpu/drm/i915/gt/intel_ring.c |  9 ++---
    drivers/gpu/drm/i915/gt/selftest_context.c   |  3 ++-
    drivers/gpu/drm/i915/gt/selftest_hangcheck.c |  4 ++--
    drivers/gpu/drm/i915/gt/selftest_lrc.c   |  4 +++-
    drivers/gpu/drm/i915/gt/uc/intel_guc.c   |  4 +++-
    drivers/gpu/drm/i915/gt/uc/intel_huc.c   |  4 +++-
    drivers/gpu/drm/i915/i915_drv.h  | 11 +--
    drivers/gpu/drm/i915/selftests/igt_spinner.c |  4 ++--
    11 files changed, 36 insertions(+), 16 deletions(-)

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

index efe935f80c1a..b79568d370f5 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -664,7 +664,8 @@ static int init_status_page(struct 
intel_engine_cs *engine)

    if (ret)
    goto err;

- vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
+ vaddr = i915_gem_object_pin_map(obj,
+ 
i915_coherent_map_type(engine->i915, obj, true));

    if (IS_ERR(vaddr)) {
    ret = PTR_ERR(vaddr);
    goto err_unpin;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c 
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c

index 7c9af86fdb1e..47f4397095e5 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -23,7 +23,7 @@ static void dbg_poison_ce(struct intel_context *ce)

    if (ce->state) {
    struct drm_i915_gem_object *obj = ce->state->obj;
- int type = i915_coherent_map_type(ce->engine->i915);
+ int type = i915_coherent_map_type(ce->engine->i915, 
obj, true);

    void *map;

    if (!i915_gem_object_trylock(obj))
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c

index e86897cde984..aafe2a4df496 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -903,7 +903,9 @@ lrc_pre_pin(struct intel_context *ce,
    GEM_BUG_ON(!i915_vma_is_pinned(ce->state));

    *vaddr = i915_gem_object_pin_map(ce->state->obj,
-  
i915_coherent_map_type(ce->engine->i915) |
+  
i915_coherent_map_type(ce->engine->i915,
+ 
ce->state->obj,
+ 
false) |

 I915_MAP_OVERRIDE);

    return PTR_ERR_OR_ZERO(*vaddr);
diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c 
b/drivers/gpu/drm/i915/gt/intel_ring.c

index aee0a77c77e0..3cf6c7e68108 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring.c
@@ -53,9 +53,12 @@ int intel_ring_pin(struct intel_ring *ring, 
struct i915_gem_ww_ctx *ww)


    if (i915_vma_is_map_and_fenceable(vma))
    addr = (void __force *)i915_vma_pin_iomap(vma);
- else
- addr = i915_gem_object_pin_map(vma->obj,
-
i915_coherent_map_type(vma->vm->i915));

+ else {
+ int type = i915_coherent_map_type(vma->vm->i915, 
vma->obj, false);

+
+ addr = i915_gem_object_pin_map(vma->obj, type);
+ }
+
    if (IS_ERR(addr)) {
    ret = PTR_ERR(addr);
    goto err_ring;
diff --git a/drivers/gpu/drm/i915/gt/selftest_context.c 
b/drivers/gpu/drm/i915/gt/selftest_context.c

index b9bdd1d23243..26685b927169 100644
--- a/drivers/gpu/drm/i915/gt/selftest_context.c
+++ b/drivers/gpu/drm/i915/gt/selftest_context.c
@@ -88,7 +88,8 @@ static int __live_context_size(struct 
intel_engine_cs *engine)

    goto err;

    vaddr = i915_gem_object_pin_map_unlocked(ce->state->obj,
-  
i915_coherent_map_type(engine->i915));
+  
i915_coherent_map_type(engine->i915,
+ 
ce->state->obj, false));

    if (IS_ERR(vaddr)) {
    err = PTR_ERR(vaddr);
    intel_context_unpin(ce);

[PATCH] drm/tegra: Remove duplicate struct declaration

[Wan Jiabing]

struct tegra_dc is declared at 13rd line.
The declaration here is unnecessary. Remove it.

Signed-off-by: Wan Jiabing 
---
 drivers/gpu/drm/tegra/hub.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/hub.h b/drivers/gpu/drm/tegra/hub.h
index 3efa1be07ff8..23c4b2115ed1 100644
--- a/drivers/gpu/drm/tegra/hub.h
+++ b/drivers/gpu/drm/tegra/hub.h
@@ -72,7 +72,6 @@ to_tegra_display_hub_state(struct drm_private_state *priv)
return container_of(priv, struct tegra_display_hub_state, base);
 }
 
-struct tegra_dc;
 struct tegra_plane;
 
 int tegra_display_hub_prepare(struct tegra_display_hub *hub);
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 4/4] drm/i915/uapi: convert i915_query and friend to kernel doc

[Matthew Auld]

Add a note about the two-step process.

v2(Tvrtko):
  - Also document the other method of just passing in a buffer which is
large enough, which avoids two ioctl calls. Can make sense for
smaller query items.
v3: prefer kernel-doc references for structs and members

Suggested-by: Daniel Vetter 
Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
Cc: Jordan Justen 
Cc: Daniel Vetter 
Cc: Kenneth Graunke 
Cc: Jason Ekstrand 
Cc: Dave Airlie 
Cc: dri-devel@lists.freedesktop.org
Cc: mesa-...@lists.freedesktop.org
Reviewed-by: Daniel Vetter 
Reviewed-by: Jason Ekstrand 
---
 include/uapi/drm/i915_drm.h | 69 +
 1 file changed, 55 insertions(+), 14 deletions(-)

diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index e2867d8cd5e3..6a34243a7646 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -2218,53 +2218,94 @@ struct drm_i915_perf_oa_config {
__u64 flex_regs_ptr;
 };
 
+/**
+ * struct drm_i915_query_item - An individual query for the kernel to process.
+ *
+ * The behaviour is determined by the @query_id. Note that exactly what
+ * @data_ptr is also depends on the specific @query_id.
+ */
 struct drm_i915_query_item {
+   /** @query_id: The id for this query */
__u64 query_id;
 #define DRM_I915_QUERY_TOPOLOGY_INFO1
 #define DRM_I915_QUERY_ENGINE_INFO 2
 #define DRM_I915_QUERY_PERF_CONFIG  3
 /* Must be kept compact -- no holes and well documented */
 
-   /*
+   /**
+* @length:
+*
 * When set to zero by userspace, this is filled with the size of the
-* data to be written at the data_ptr pointer. The kernel sets this
+* data to be written at the @data_ptr pointer. The kernel sets this
 * value to a negative value to signal an error on a particular query
 * item.
 */
__s32 length;
 
-   /*
+   /**
+* @flags:
+*
 * When query_id == DRM_I915_QUERY_TOPOLOGY_INFO, must be 0.
 *
 * When query_id == DRM_I915_QUERY_PERF_CONFIG, must be one of the
-* following :
-* - DRM_I915_QUERY_PERF_CONFIG_LIST
-* - DRM_I915_QUERY_PERF_CONFIG_DATA_FOR_UUID
-* - DRM_I915_QUERY_PERF_CONFIG_FOR_UUID
+* following:
+*
+*  - DRM_I915_QUERY_PERF_CONFIG_LIST
+*  - DRM_I915_QUERY_PERF_CONFIG_DATA_FOR_UUID
+*  - DRM_I915_QUERY_PERF_CONFIG_FOR_UUID
 */
__u32 flags;
 #define DRM_I915_QUERY_PERF_CONFIG_LIST  1
 #define DRM_I915_QUERY_PERF_CONFIG_DATA_FOR_UUID 2
 #define DRM_I915_QUERY_PERF_CONFIG_DATA_FOR_ID   3
 
-   /*
-* Data will be written at the location pointed by data_ptr when the
-* value of length matches the length of the data to be written by the
+   /**
+* @data_ptr:
+*
+* Data will be written at the location pointed by @data_ptr when the
+* value of @length matches the length of the data to be written by the
 * kernel.
 */
__u64 data_ptr;
 };
 
+/**
+ * struct drm_i915_query - Supply an array of struct drm_i915_query_item for 
the
+ * kernel to fill out.
+ *
+ * Note that this is generally a two step process for each struct
+ * drm_i915_query_item in the array:
+ *
+ * 1. Call the DRM_IOCTL_I915_QUERY, giving it our array of struct
+ *drm_i915_query_item, with _i915_query_item.length set to zero. The
+ *kernel will then fill in the size, in bytes, which tells userspace how
+ *memory it needs to allocate for the blob(say for an array of properties).
+ *
+ * 2. Next we call DRM_IOCTL_I915_QUERY again, this time with the
+ *_i915_query_item.data_ptr equal to our newly allocated blob. Note 
that
+ *the _i915_query_item.length should still be the same as what the
+ *kernel previously set. At this point the kernel can fill in the blob.
+ *
+ * Note that for some query items it can make sense for userspace to just pass
+ * in a buffer/blob equal to or larger than the required size. In this case 
only
+ * a single ioctl call is needed. For some smaller query items this can work
+ * quite well.
+ *
+ */
 struct drm_i915_query {
+   /** @num_items: The number of elements in the @items_ptr array */
__u32 num_items;
 
-   /*
-* Unused for now. Must be cleared to zero.
+   /**
+* @flags: Unused for now. Must be cleared to zero.
 */
__u32 flags;
 
-   /*
-* This points to an array of num_items drm_i915_query_item structures.
+   /**
+* @items_ptr:
+*
+* Pointer to an array of struct drm_i915_query_item. The number of
+* array elements is @num_items.
 */
__u64 items_ptr;
 };
-- 
2.26.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org

[PATCH v2 3/4] drm/i915/uapi: convert i915_user_extension to kernel doc

[Matthew Auld]

Add some example usage for the extension chaining also, which is quite
nifty.

v2: (Daniel)
  - clarify that the name is just some integer, also document that the
name space is not global
v3: prefer kernel-doc references for structs

Suggested-by: Daniel Vetter 
Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Jordan Justen 
Cc: Daniel Vetter 
Cc: Kenneth Graunke 
Cc: Jason Ekstrand 
Cc: Dave Airlie 
Cc: dri-devel@lists.freedesktop.org
Cc: mesa-...@lists.freedesktop.org
Reviewed-by: Daniel Vetter 
Reviewed-by: Jason Ekstrand 
---
 include/uapi/drm/i915_drm.h | 54 ++---
 1 file changed, 50 insertions(+), 4 deletions(-)

diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 92da48e935d1..e2867d8cd5e3 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -62,8 +62,8 @@ extern "C" {
 #define I915_ERROR_UEVENT  "ERROR"
 #define I915_RESET_UEVENT  "RESET"
 
-/*
- * i915_user_extension: Base class for defining a chain of extensions
+/**
+ * struct i915_user_extension - Base class for defining a chain of extensions
  *
  * Many interfaces need to grow over time. In most cases we can simply
  * extend the struct and have userspace pass in more data. Another option,
@@ -76,12 +76,58 @@ extern "C" {
  * increasing complexity, and for large parts of that interface to be
  * entirely optional. The downside is more pointer chasing; chasing across
  * the __user boundary with pointers encapsulated inside u64.
+ *
+ * Example chaining:
+ *
+ * .. code-block:: C
+ *
+ * struct i915_user_extension ext3 {
+ * .next_extension = 0, // end
+ * .name = ...,
+ * };
+ * struct i915_user_extension ext2 {
+ * .next_extension = (uintptr_t),
+ * .name = ...,
+ * };
+ * struct i915_user_extension ext1 {
+ * .next_extension = (uintptr_t),
+ * .name = ...,
+ * };
+ *
+ * Typically the struct i915_user_extension would be embedded in some uAPI
+ * struct, and in this case we would feed it the head of the chain(i.e ext1),
+ * which would then apply all of the above extensions.
+ *
  */
 struct i915_user_extension {
+   /**
+* @next_extension:
+*
+* Pointer to the next struct i915_user_extension, or zero if the end.
+*/
__u64 next_extension;
+   /**
+* @name: Name of the extension.
+*
+* Note that the name here is just some integer.
+*
+* Also note that the name space for this is not global for the whole
+* driver, but rather its scope/meaning is limited to the specific piece
+* of uAPI which has embedded the struct i915_user_extension.
+*/
__u32 name;
-   __u32 flags; /* All undefined bits must be zero. */
-   __u32 rsvd[4]; /* Reserved for future use; must be zero. */
+   /**
+* @flags: MBZ
+*
+* All undefined bits must be zero.
+*/
+   __u32 flags;
+   /**
+* @rsvd: MBZ
+*
+* Reserved for future use; must be zero.
+*/
+   __u32 rsvd[4];
 };
 
 /*
-- 
2.26.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/4] drm/doc: add section for driver uAPI

[Matthew Auld]

Add section for drm/i915 uAPI and pull in i915_drm.h.

Suggested-by: Daniel Vetter 
Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Jordan Justen 
Cc: Daniel Vetter 
Cc: Kenneth Graunke 
Cc: Jason Ekstrand 
Cc: Dave Airlie 
Cc: dri-devel@lists.freedesktop.org
Cc: mesa-...@lists.freedesktop.org
Reviewed-by: Daniel Vetter 
---
 Documentation/gpu/driver-uapi.rst | 8 
 Documentation/gpu/index.rst   | 1 +
 2 files changed, 9 insertions(+)
 create mode 100644 Documentation/gpu/driver-uapi.rst

diff --git a/Documentation/gpu/driver-uapi.rst 
b/Documentation/gpu/driver-uapi.rst
new file mode 100644
index ..4411e6919a3d
--- /dev/null
+++ b/Documentation/gpu/driver-uapi.rst
@@ -0,0 +1,8 @@
+===
+DRM Driver uAPI
+===
+
+drm/i915 uAPI
+=
+
+.. kernel-doc:: include/uapi/drm/i915_drm.h
diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
index ec4bc72438e4..b9c1214d8f23 100644
--- a/Documentation/gpu/index.rst
+++ b/Documentation/gpu/index.rst
@@ -10,6 +10,7 @@ Linux GPU Driver Developer's Guide
drm-kms
drm-kms-helpers
drm-uapi
+   driver-uapi
drm-client
drivers
backlight
-- 
2.26.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/4] drm/i915/uapi: fix kernel doc warnings

[Matthew Auld]

Fix the cases where it is almost already valid kernel doc, for the
others just nerf the warnings for now.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Jordan Justen 
Cc: Daniel Vetter 
Cc: Kenneth Graunke 
Cc: Jason Ekstrand 
Cc: Dave Airlie 
Cc: dri-devel@lists.freedesktop.org
Cc: mesa-...@lists.freedesktop.org
Reviewed-by: Daniel Vetter 
---
 include/uapi/drm/i915_drm.h | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index ddc47bbf48b6..92da48e935d1 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1054,12 +1054,12 @@ struct drm_i915_gem_exec_fence {
__u32 flags;
 };
 
-/**
+/*
  * See drm_i915_gem_execbuffer_ext_timeline_fences.
  */
 #define DRM_I915_GEM_EXECBUFFER_EXT_TIMELINE_FENCES 0
 
-/**
+/*
  * This structure describes an array of drm_syncobj and associated points for
  * timeline variants of drm_syncobj. It is invalid to append this structure to
  * the execbuf if I915_EXEC_FENCE_ARRAY is set.
@@ -1700,7 +1700,7 @@ struct drm_i915_gem_context_param {
__u64 value;
 };
 
-/**
+/*
  * Context SSEU programming
  *
  * It may be necessary for either functional or performance reason to configure
@@ -2067,7 +2067,7 @@ struct drm_i915_perf_open_param {
__u64 properties_ptr;
 };
 
-/**
+/*
  * Enable data capture for a stream that was either opened in a disabled state
  * via I915_PERF_FLAG_DISABLED or was later disabled via
  * I915_PERF_IOCTL_DISABLE.
@@ -2081,7 +2081,7 @@ struct drm_i915_perf_open_param {
  */
 #define I915_PERF_IOCTL_ENABLE _IO('i', 0x0)
 
-/**
+/*
  * Disable data capture for a stream.
  *
  * It is an error to try and read a stream that is disabled.
@@ -2090,7 +2090,7 @@ struct drm_i915_perf_open_param {
  */
 #define I915_PERF_IOCTL_DISABLE_IO('i', 0x1)
 
-/**
+/*
  * Change metrics_set captured by a stream.
  *
  * If the stream is bound to a specific context, the configuration change
@@ -2103,7 +2103,7 @@ struct drm_i915_perf_open_param {
  */
 #define I915_PERF_IOCTL_CONFIG _IO('i', 0x2)
 
-/**
+/*
  * Common to all i915 perf records
  */
 struct drm_i915_perf_record_header {
@@ -2151,7 +2151,7 @@ enum drm_i915_perf_record_type {
DRM_I915_PERF_RECORD_MAX /* non-ABI */
 };
 
-/**
+/*
  * Structure to upload perf dynamic configuration into the kernel.
  */
 struct drm_i915_perf_oa_config {
@@ -2292,21 +2292,21 @@ struct drm_i915_query_topology_info {
  * Describes one engine and it's capabilities as known to the driver.
  */
 struct drm_i915_engine_info {
-   /** Engine class and instance. */
+   /** @engine: Engine class and instance. */
struct i915_engine_class_instance engine;
 
-   /** Reserved field. */
+   /** @rsvd0: Reserved field. */
__u32 rsvd0;
 
-   /** Engine flags. */
+   /** @flags: Engine flags. */
__u64 flags;
 
-   /** Capabilities of this engine. */
+   /** @capabilities: Capabilities of this engine. */
__u64 capabilities;
 #define I915_VIDEO_CLASS_CAPABILITY_HEVC   (1 << 0)
 #define I915_VIDEO_AND_ENHANCE_CLASS_CAPABILITY_SFC(1 << 1)
 
-   /** Reserved fields. */
+   /** @rsvd1: Reserved fields. */
__u64 rsvd1[4];
 };
 
@@ -2317,13 +2317,13 @@ struct drm_i915_engine_info {
  * an array of struct drm_i915_engine_info structures.
  */
 struct drm_i915_query_engine_info {
-   /** Number of struct drm_i915_engine_info structs following. */
+   /** @num_engines: Number of struct drm_i915_engine_info structs 
following. */
__u32 num_engines;
 
-   /** MBZ */
+   /** @rsvd: MBZ */
__u32 rsvd[3];
 
-   /** Marker for drm_i915_engine_info structures. */
+   /** @engines: Marker for drm_i915_engine_info structures. */
struct drm_i915_engine_info engines[];
 };
 
-- 
2.26.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

[Marek Olšák]

Hi,

This is our initial proposal for explicit fences everywhere and new memory
management that doesn't use BO fences. It's a redesign of how Linux
graphics drivers work, and it can coexist with what we have now.


*1. Introduction*
(skip this if you are already sold on explicit fences)

The current Linux graphics architecture was initially designed for GPUs
with only one graphics queue where everything was executed in the
submission order and per-BO fences were used for memory management and
CPU-GPU synchronization, not GPU-GPU synchronization. Later, multiple
queues were added on top, which required the introduction of implicit
GPU-GPU synchronization between queues of different processes using per-BO
fences. Recently, even parallel execution within one queue was enabled
where a command buffer starts draws and compute shaders, but doesn't wait
for them, enabling parallelism between back-to-back command buffers.
Modesetting also uses per-BO fences for scheduling flips. Our GPU scheduler
was created to enable all those use cases, and it's the only reason why the
scheduler exists.

The GPU scheduler, implicit synchronization, BO-fence-based memory
management, and the tracking of per-BO fences increase CPU overhead and
latency, and reduce parallelism. There is a desire to replace all of them
with something much simpler. Below is how we could do it.


*2. Explicit synchronization for window systems and modesetting*

The producer is an application and the consumer is a compositor or a
modesetting driver.

*2.1. The Present request*

As part of the Present request, the producer will pass 2 fences (sync
objects) to the consumer alongside the presented DMABUF BO:
- The submit fence: Initially unsignalled, it will be signalled when the
producer has finished drawing into the presented buffer.
- The return fence: Initially unsignalled, it will be signalled when the
consumer has finished using the presented buffer.

Deadlock mitigation to recover from segfaults:
- The kernel knows which process is obliged to signal which fence. This
information is part of the Present request and supplied by userspace.
- If the producer crashes, the kernel signals the submit fence, so that the
consumer can make forward progress.
- If the consumer crashes, the kernel signals the return fence, so that the
producer can reclaim the buffer.
- A GPU hang signals all fences. Other deadlocks will be handled like GPU
hangs.

Other window system requests can follow the same idea.

Merged fences where one fence object contains multiple fences will be
supported. A merged fence is signalled only when its fences are signalled.
The consumer will have the option to redefine the unsignalled return fence
to a merged fence.

*2.2. Modesetting*

Since a modesetting driver can also be the consumer, the present ioctl will
contain a submit fence and a return fence too. One small problem with this
is that userspace can hang the modesetting driver, but in theory, any later
present ioctl can override the previous one, so the unsignalled
presentation is never used.


*3. New memory management*

The per-BO fences will be removed and the kernel will not know which
buffers are busy. This will reduce CPU overhead and latency. The kernel
will not need per-BO fences with explicit synchronization, so we just need
to remove their last user: buffer evictions. It also resolves the current
OOM deadlock.

*3.1. Evictions*

If the kernel wants to move a buffer, it will have to wait for everything
to go idle, halt all userspace command submissions, move the buffer, and
resume everything. This is not expected to happen when memory is not
exhausted. Other more efficient ways of synchronization are also possible
(e.g. sync only one process), but are not discussed here.

*3.2. Per-process VRAM usage quota*

Each process can optionally and periodically query its VRAM usage quota and
change domains of its buffers to obey that quota. For example, a process
allocated 2 GB of buffers in VRAM, but the kernel decreased the quota to 1
GB. The process can change the domains of the least important buffers to
GTT to get the best outcome for itself. If the process doesn't do it, the
kernel will choose which buffers to evict at random. (thanks to Christian
Koenig for this idea)

*3.3. Buffer destruction without per-BO fences*

When the buffer destroy ioctl is called, an optional fence list can be
passed to the kernel to indicate when it's safe to deallocate the buffer.
If the fence list is empty, the buffer will be deallocated immediately.
Shared buffers will be handled by merging fence lists from all processes
that destroy them. Mitigation of malicious behavior:
- If userspace destroys a busy buffer, it will get a GPU page fault.
- If userspace sends fences that never signal, the kernel will have a
timeout period and then will proceed to deallocate the buffer anyway.

*3.4. Other notes on MM*

Overcommitment of GPU-accessible memory will cause an allocation failure or
invoke the OOM 

Re: [PATCH v6 1/4] mfd: rt4831: Adds support for Richtek RT4831

[ChiYuan Huang]

Lee Jones  於 2021年4月19日 週一 下午3:24寫道：
>
> On Mon, 19 Apr 2021, Lee Jones wrote:
>
> > On Mon, 19 Apr 2021, Lee Jones wrote:
> >
> > > On Mon, 19 Apr 2021, ChiYuan Huang wrote:
> > >
> > > > Hi, Linux mfd reviewers:
> > > >It's been three weeks not to get any response from you.
> > > > Is there something wrong about this mfd patch?
> > > > If yes, please feel free to let me know.
> > >
> > > Couple of things:
> > >
> > > First, if you think a patch had fallen through the gaps, which does
> > > happen sometimes, it is generally considered acceptable to submit a
> > > [RESEND] ~2 weeks after the initial submission.  FYI: This was such a
> > > patch.  It was not on, or had fallen off of my radar for some reason.
> > >
> > > Secondly, we are really late in the release cycle.  -rc8 has just been
> > > released.  Quite a few maintainers slow down at ~-rc6.  Particularly
> > > for new drivers.
> > >
> > > No need to resubmit this driver this time.  It is now on my to-review
> > > list and I will tend to it shortly.
> > >
> > > Thanks for your patience.
> >
> > Also you are missing a DT review on patch 4.
>
> ... looks like you forgot to Cc them!
>
Yap, really. I''ll resend patch 4 and cc them. Thx.
> --
> Lee Jones [李琼斯]
> Senior Technical Lead - Developer Services
> Linaro.org │ Open source software for Arm SoCs
> Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] topic/intel-gen-to-ver -> drm-intel-next and drm-intel-gt-next

[Jani Nikula]

Hi Joonas and Rodrigo -

Here's the gen to ver conversion topic branch to be merged to both
drm-intel-next and drm-intel-gt-next.

Lots of Cc's for heads up.


BR,
Jani.


topic/intel-gen-to-ver-2021-04-19:
Gen to ver conversions across the driver

The main change is Lucas' series [1], with Ville's GLK fixes [2] and a
cherry-pick of Matt's commit [3] from drm-intel-next as a base to avoid
conflicts.

[1] https://patchwork.freedesktop.org/series/88825/
[2] https://patchwork.freedesktop.org/series/88938/
[3] 70bfb30743d5 ("drm/i915/display: Eliminate IS_GEN9_{BC,LP}")

BR,
Jani.

The following changes since commit 9c0fed84d5750e1eea6c664e073ffa2534a17743:

  Merge tag 'drm-intel-next-2021-04-01' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2021-04-08 14:02:21 
+1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel 
tags/topic/intel-gen-to-ver-2021-04-19

for you to fetch changes up to 425390c5dce6da76578389629d19517fcd79c959:

  drm/i915: split dgfx features from gen 12 (2021-04-14 13:05:06 +0300)


Gen to ver conversions across the driver

The main change is Lucas' series [1], with Ville's GLK fixes [2] and a
cherry-pick of Matt's commit [3] from drm-intel-next as a base to avoid
conflicts.

[1] https://patchwork.freedesktop.org/series/88825/
[2] https://patchwork.freedesktop.org/series/88938/
[3] 70bfb30743d5 ("drm/i915/display: Eliminate IS_GEN9_{BC,LP}")


Lucas De Marchi (12):
  drm/i915/display: use DISPLAY_VER() on remaining users
  drm/i915: rename display.version to display.ver
  drm/i915/display: rename display version macros
  drm/i915: add macros for graphics and media versions
  drm/i915/gt: replace gen use in intel_engine_cs
  drm/i915/selftests: replace unused mask with simple version
  drm/i915/selftests: eliminate use of gen_mask
  drm/i915: finish removal of gen_mask
  drm/i915: eliminate remaining uses of intel_device_info->gen
  drm/i915: finish removal of gen from intel_device_info
  drm/i915: add media and display versions to device_info print
  drm/i915: split dgfx features from gen 12

Matt Roper (1):
  drm/i915/display: Eliminate IS_GEN9_{BC,LP}

Ville Syrjälä (5):
  drm/i915: Restore lost glk FBC 16bpp w/a
  drm/i915: Restore lost glk ccs w/a
  drm/i915: Disable LTTPR detection on GLK once again
  drm/i915: Don't use {skl, cnl}_hpd_pin() for bxt/glk
  drm/i915: Remove a few redundant glk checks

 drivers/gpu/drm/i915/display/i9xx_plane.c  |  2 +-
 drivers/gpu/drm/i915/display/icl_dsi.c |  4 +-
 drivers/gpu/drm/i915/display/intel_atomic.c|  2 +-
 drivers/gpu/drm/i915/display/intel_audio.c |  4 +-
 drivers/gpu/drm/i915/display/intel_bios.c  |  9 +--
 drivers/gpu/drm/i915/display/intel_bw.c|  8 +--
 drivers/gpu/drm/i915/display/intel_cdclk.c | 42 +++---
 drivers/gpu/drm/i915/display/intel_color.c |  6 +-
 drivers/gpu/drm/i915/display/intel_crt.c   |  6 +-
 drivers/gpu/drm/i915/display/intel_crtc.c  |  4 +-
 drivers/gpu/drm/i915/display/intel_csr.c   |  4 +-
 drivers/gpu/drm/i915/display/intel_ddi.c   | 53 +-
 drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c | 10 ++--
 drivers/gpu/drm/i915/display/intel_display.c   | 64 +++---
 .../gpu/drm/i915/display/intel_display_debugfs.c   |  2 +-
 drivers/gpu/drm/i915/display/intel_display_power.c | 57 ++-
 drivers/gpu/drm/i915/display/intel_dp.c| 10 ++--
 .../gpu/drm/i915/display/intel_dp_link_training.c  |  2 +-
 drivers/gpu/drm/i915/display/intel_dp_mst.c|  2 +-
 drivers/gpu/drm/i915/display/intel_dpll.c  |  8 +--
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c  |  6 +-
 drivers/gpu/drm/i915/display/intel_fb.c|  2 +-
 drivers/gpu/drm/i915/display/intel_fbc.c   | 21 +++
 drivers/gpu/drm/i915/display/intel_fifo_underrun.c |  4 +-
 drivers/gpu/drm/i915/display/intel_gmbus.c | 12 ++--
 drivers/gpu/drm/i915/display/intel_hdcp.c  |  9 +--
 drivers/gpu/drm/i915/display/intel_hdmi.c  |  9 +--
 drivers/gpu/drm/i915/display/intel_lvds.c  |  2 +-
 drivers/gpu/drm/i915/display/intel_overlay.c   | 10 ++--
 drivers/gpu/drm/i915/display/intel_panel.c | 10 ++--
 drivers/gpu/drm/i915/display/intel_pipe_crc.c  |  4 +-
 drivers/gpu/drm/i915/display/intel_pps.c   | 14 ++---
 drivers/gpu/drm/i915/display/intel_psr.c   |  4 +-
 drivers/gpu/drm/i915/display/intel_tc.c|  6 +-
 drivers/gpu/drm/i915/display/intel_tv.c|  6 +-
 drivers/gpu/drm/i915/display/skl_universal_plane.c | 10 ++--
 drivers/gpu/drm/i915/display/vlv_dsi.c | 46 
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 

Re: [PATCH v4 2/3] drm: bridge: add it66121 driver

[Robert Foss]

Hey Neil,

Thanks for the quick respin.

Reviewed-by: Robert Foss 

On Mon, 19 Apr 2021 at 09:12, Neil Armstrong  wrote:
>
> From: Phong LE 
>
> This commit is a simple driver for bridge HMDI it66121.
> The input format is RBG and there is no color conversion.
> Audio, HDCP and CEC are not supported yet.
>
> Signed-off-by: Phong LE 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/gpu/drm/bridge/Kconfig   |8 +
>  drivers/gpu/drm/bridge/Makefile  |1 +
>  drivers/gpu/drm/bridge/ite-it66121.c | 1021 ++
>  3 files changed, 1030 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/ite-it66121.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index e4110d6ca7b3..6915c38fa459 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -74,6 +74,14 @@ config DRM_LONTIUM_LT9611UXC
>   HDMI signals
>   Please say Y if you have such hardware.
>
> +config DRM_ITE_IT66121
> +   tristate "ITE IT66121 HDMI bridge"
> +   depends on OF
> +   select DRM_KMS_HELPER
> +   select REGMAP_I2C
> +   help
> + Support for ITE IT66121 HDMI bridge.
> +
>  config DRM_LVDS_CODEC
> tristate "Transparent LVDS encoders and decoders support"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 86e7acc76f8d..4f725753117c 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -24,6 +24,7 @@ obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
>  obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
>  obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o
>  obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o
> +obj-$(CONFIG_DRM_ITE_IT66121) += ite-it66121.o
>
>  obj-y += analogix/
>  obj-y += cadence/
> diff --git a/drivers/gpu/drm/bridge/ite-it66121.c 
> b/drivers/gpu/drm/bridge/ite-it66121.c
> new file mode 100644
> index ..d8a60691fd32
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ite-it66121.c
> @@ -0,0 +1,1021 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2020 BayLibre, SAS
> + * Author: Phong LE 
> + * Copyright (C) 2018-2019, Artem Mygaiev
> + * Copyright (C) 2017, Fresco Logic, Incorporated.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define IT66121_VENDOR_ID0_REG 0x00
> +#define IT66121_VENDOR_ID1_REG 0x01
> +#define IT66121_DEVICE_ID0_REG 0x02
> +#define IT66121_DEVICE_ID1_REG 0x03
> +
> +#define IT66121_VENDOR_ID0 0x54
> +#define IT66121_VENDOR_ID1 0x49
> +#define IT66121_DEVICE_ID0 0x12
> +#define IT66121_DEVICE_ID1 0x06
> +#define IT66121_REVISION_MASK  GENMASK(7, 4)
> +#define IT66121_DEVICE_ID1_MASKGENMASK(3, 0)
> +
> +#define IT66121_MASTER_SEL_REG 0x10
> +#define IT66121_MASTER_SEL_HOSTBIT(0)
> +
> +#define IT66121_AFE_DRV_REG0x61
> +#define IT66121_AFE_DRV_RSTBIT(4)
> +#define IT66121_AFE_DRV_PWDBIT(5)
> +
> +#define IT66121_INPUT_MODE_REG 0x70
> +#define IT66121_INPUT_MODE_RGB (0 << 6)
> +#define IT66121_INPUT_MODE_YUV422  BIT(6)
> +#define IT66121_INPUT_MODE_YUV444  (2 << 6)
> +#define IT66121_INPUT_MODE_CCIR656 BIT(4)
> +#define IT66121_INPUT_MODE_SYNCEMB BIT(3)
> +#define IT66121_INPUT_MODE_DDR BIT(2)
> +
> +#define IT66121_INPUT_CSC_REG  0x72
> +#define IT66121_INPUT_CSC_ENDITHER BIT(7)
> +#define IT66121_INPUT_CSC_ENUDFILTER   BIT(6)
> +#define IT66121_INPUT_CSC_DNFREE_GOBIT(5)
> +#define IT66121_INPUT_CSC_RGB_TO_YUV   0x02
> +#define IT66121_INPUT_CSC_YUV_TO_RGB   0x03
> +#define IT66121_INPUT_CSC_NO_CONV  0x00
> +
> +#define IT66121_AFE_XP_REG 0x62
> +#define IT66121_AFE_XP_GAINBIT BIT(7)
> +#define IT66121_AFE_XP_PWDPLL  BIT(6)
> +#define IT66121_AFE_XP_ENI BIT(5)
> +#define IT66121_AFE_XP_ENO BIT(4)
> +#define IT66121_AFE_XP_RESETB  BIT(3)
> +#define IT66121_AFE_XP_PWDIBIT(2)
> +
> +#define IT66121_AFE_IP_REG 0x64
> +#define IT66121_AFE_IP_GAINBIT BIT(7)
> +#define IT66121_AFE_IP_PWDPLL  BIT(6)
> +#define IT66121_AFE_IP_CKSEL_05(0 << 4)
> +#define IT66121_AFE_IP_CKSEL_1 BIT(4)
> +#define IT66121_AFE_IP_CKSEL_2 (2 << 4)
> +#define 

Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match

[Dominique MARTINET]

Geert Uytterhoeven wrote on Mon, Apr 19, 2021 at 11:03:24AM +0200:
> > This is going to need quite some more work to be acceptable, in my
> > opinion, but I think it should be possible.
> 
> In general, this is very hard to do, IMHO. Some drivers may be used on
> multiple platforms, some of them registering an SoC device, some of
> them not registering an SoC device.  So there is no way to know the
> difference between "SoC device not registered, intentionally", and
> "SoC device not yet registered".

Hm, good point, I was probably a bit too optimistic if there are devices
which don't register any soc yet have drivers which want one; I don't
see how to make the difference indeed... And that does mean we can't
just defer all the time.

> soc_device_match() should only be used as a last resort, to identify
> systems that cannot be identified otherwise.  Typically this is used for
> quirks, which should only be enabled on a very specific subset of
> systems.  IMHO such systems should make sure soc_device_match()
> is available early, by registering their SoC device early.

I definitely agree there, my suggestion to defer was only because I know
of no other way to influence the ordering of drivers loading reliably
and gave up on soc being init'd early.

In this particular case the problem is that since 7d981405d0fd ("soc:
imx8m: change to use platform driver") the soc probe tries to use the
nvmem driver for ocotp fuses for imx8m devices, which isn't ready yet.
So soc loading gets pushed back to the end of the list because it gets
defered and other drivers relying on soc_device_match get confused
because they wrongly think a device doesn't match a quirk when it
actually does.

If there is a way to ensure the nvmem driver gets loaded before the soc,
that would also solve the problem nicely, and avoid the need to mess
with all the ~50 drivers which use it.


Is there a way to control in what order drivers get loaded? Something in
the dtb perhaps?


Thanks,
-- 
Dominique
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/ttm: remove special handling for non GEM drivers

[Christian König]

vmwgfx is the only driver actually using this. Move the handling into
the driver instead.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c   | 11 ---
 drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 10 ++
 include/drm/ttm/ttm_bo_api.h   | 19 ---
 3 files changed, 10 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 80831df0ef61..38183e227116 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -460,8 +460,6 @@ static void ttm_bo_release(struct kref *kref)
 
atomic_dec(_glob.bo_count);
dma_fence_put(bo->moving);
-   if (!ttm_bo_uses_embedded_gem_object(bo))
-   dma_resv_fini(>base._resv);
bo->destroy(bo);
 }
 
@@ -1056,15 +1054,6 @@ int ttm_bo_init_reserved(struct ttm_device *bdev,
} else {
bo->base.resv = >base._resv;
}
-   if (!ttm_bo_uses_embedded_gem_object(bo)) {
-   /*
-* bo.base is not initialized, so we have to setup the
-* struct elements we want use regardless.
-*/
-   bo->base.size = size;
-   dma_resv_init(>base._resv);
-   drm_vma_node_reset(>base.vma_node);
-   }
atomic_inc(_glob.bo_count);
 
/*
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index 50e529a01677..587314d57991 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -460,6 +460,7 @@ void vmw_bo_bo_free(struct ttm_buffer_object *bo)
WARN_ON(vmw_bo->dirty);
WARN_ON(!RB_EMPTY_ROOT(_bo->res_tree));
vmw_bo_unmap(vmw_bo);
+   dma_resv_fini(>base._resv);
kfree(vmw_bo);
 }
 
@@ -512,6 +513,11 @@ int vmw_bo_create_kernel(struct vmw_private *dev_priv, 
unsigned long size,
if (unlikely(ret))
goto error_free;
 
+
+   bo->base.size = size;
+   dma_resv_init(>base._resv);
+   drm_vma_node_reset(>base.vma_node);
+
ret = ttm_bo_init_reserved(_priv->bdev, bo, size,
   ttm_bo_type_device, placement, 0,
   , NULL, NULL, NULL);
@@ -570,6 +576,10 @@ int vmw_bo_init(struct vmw_private *dev_priv,
if (unlikely(ret))
return ret;
 
+   vmw_bo->base.base.size = size;
+   dma_resv_init(_bo->base.base._resv);
+   drm_vma_node_reset(_bo->base.base.vma_node);
+
ret = ttm_bo_init_reserved(bdev, _bo->base, size,
   ttm_bo_type_device, placement,
   0, , NULL, NULL, bo_free);
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 3587f660e8f4..e88da481a976 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -562,25 +562,6 @@ ssize_t ttm_bo_io(struct ttm_device *bdev, struct file 
*filp,
 int ttm_bo_swapout(struct ttm_buffer_object *bo, struct ttm_operation_ctx *ctx,
   gfp_t gfp_flags);
 
-/**
- * ttm_bo_uses_embedded_gem_object - check if the given bo uses the
- * embedded drm_gem_object.
- *
- * Most ttm drivers are using gem too, so the embedded
- * ttm_buffer_object.base will be initialized by the driver (before
- * calling ttm_bo_init).  It is also possible to use ttm without gem
- * though (vmwgfx does that).
- *
- * This helper will figure whenever a given ttm bo is a gem object too
- * or not.
- *
- * @bo: The bo to check.
- */
-static inline bool ttm_bo_uses_embedded_gem_object(struct ttm_buffer_object 
*bo)
-{
-   return bo->base.dev != NULL;
-}
-
 /**
  * ttm_bo_pin - Pin the buffer object.
  * @bo: The buffer object to pin
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match

[Geert Uytterhoeven]

Hi Dominique,

CC Arnd (soc_device_match() author)

On Mon, Apr 19, 2021 at 7:03 AM Dominique MARTINET
 wrote:
> Alice Guo (OSS) wrote on Mon, Apr 19, 2021 at 12:27:22PM +0800:
> > From: Alice Guo 
> > Update all the code that use soc_device_match
>
> A single patch might be difficult to accept for all components, a each
> maintainer will probably want to have a say on their subsystem?
>
> I would suggest to split these for a non-RFC version; a this will really
> need to be case-by-case handling.
>
> > because add support for soc_device_match returning -EPROBE_DEFER.
>
> (English does not parse here for me)
>
> I've only commented a couple of places in the code itself, but this
> doesn't seem to add much support for errors, just sweep the problem
> under the rug.
>
> > Signed-off-by: Alice Guo 
> > ---
> >
> > diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
> > index 5fae60f8c135..00c59aa217c1 100644
> > --- a/drivers/bus/ti-sysc.c
> > +++ b/drivers/bus/ti-sysc.c
> > @@ -2909,7 +2909,7 @@ static int sysc_init_soc(struct sysc *ddata)
> >   }
> >
> >   match = soc_device_match(sysc_soc_feat_match);
> > - if (!match)
> > + if (!match || IS_ERR(match))
> >   return 0;
>
> This function handles errors, I would recommend returning the error as
> is if soc_device_match returned one so the probe can be retried later.

Depends...

> > --- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > +++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > @@ -439,6 +439,7 @@ static const unsigned int r8a7795es2_mod_nullify[] 
> > __initconst = {
> >
> >  static int __init r8a7795_cpg_mssr_init(struct device *dev)
> >  {
> > + const struct soc_device_attribute *match;
> >   const struct rcar_gen3_cpg_pll_config *cpg_pll_config;
> >   u32 cpg_mode;
> >   int error;
> > @@ -453,7 +454,8 @@ static int __init r8a7795_cpg_mssr_init(struct device 
> > *dev)
> >   return -EINVAL;
> >   }
> >
> > - if (soc_device_match(r8a7795es1)) {
> > + match = soc_device_match(r8a7795es1);
> > + if (!IS_ERR(match) && match) {
>
> Same, return the error.
> Assuming an error means no match will just lead to hard to debug
> problems because the driver potentially assumed the wrong device when
> it's just not ready yet.

When running on R-Car H3, there will always be a match device, as
the SoC device is registered early.

>
> >   cpg_core_nullify_range(r8a7795_core_clks,
> >  ARRAY_SIZE(r8a7795_core_clks),
> >  R8A7795_CLK_S0D2, R8A7795_CLK_S0D12);
> > [...]
> > diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
> > index eaaec0a55cc6..13a06b613379 100644
> > --- a/drivers/iommu/ipmmu-vmsa.c
> > +++ b/drivers/iommu/ipmmu-vmsa.c
> > @@ -757,17 +757,20 @@ static const char * const devices_allowlist[] = {
> >
> >  static bool ipmmu_device_is_allowed(struct device *dev)
> >  {
> > + const struct soc_device_attribute *match1, *match2;
> >   unsigned int i;
> >
> >   /*
> >* R-Car Gen3 and RZ/G2 use the allow list to opt-in devices.
> >* For Other SoCs, this returns true anyway.
> >*/
> > - if (!soc_device_match(soc_needs_opt_in))
> > + match1 = soc_device_match(soc_needs_opt_in);
> > + if (!IS_ERR(match1) && !match1)
>
> I'm not sure what you intended to do, but !match1 already means there is
> no error so the original code is identical.
>
> In this case ipmmu_device_is_allowed does not allow errors so this is
> one of the "difficult" drivers that require slightly more thinking.
> It is only called in ipmmu_of_xlate which does return errors properly,
> so in this case the most straightforward approach would be to make
> ipmmu_device_is_allowed return an int and forward errors as well.
>
> ...
> This is going to need quite some more work to be acceptable, in my
> opinion, but I think it should be possible.

In general, this is very hard to do, IMHO. Some drivers may be used on
multiple platforms, some of them registering an SoC device, some of
them not registering an SoC device.  So there is no way to know the
difference between "SoC device not registered, intentionally", and
"SoC device not yet registered".

soc_device_match() should only be used as a last resort, to identify
systems that cannot be identified otherwise.  Typically this is used for
quirks, which should only be enabled on a very specific subset of
systems.  IMHO such systems should make sure soc_device_match()
is available early, by registering their SoC device early.

Gr{oetje,eeting}s,

Geert

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

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

[PATCH v3] drm/bridge/sii8620: fix dependency on extcon

[Robert Foss]

The DRM_SIL_SII8620 kconfig has a weak `imply` dependency
on EXTCON, which causes issues when sii8620 is built
as a builtin and EXTCON is built as a module.

The symptoms are 'undefined reference' errors caused
by the symbols in EXTCON not being available
to the sii8620 driver.

Fixes: 688838442147 ("drm/bridge/sii8620: use micro-USB cable detection logic 
to detect MHL")
Signed-off-by: Robert Foss 
Reported-by: kernel test robot 
---

LKP reported issue:
https://lore.kernel.org/lkml/202104040604.sste2cxf-...@intel.com/


Changes since v1:
 - Fix typo on comment

Changes since v2:
 - Randy: Changed from `depends` to `select` 


 drivers/gpu/drm/bridge/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 22a467abd3e9..70402da5cc70 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -169,7 +169,7 @@ config DRM_SIL_SII8620
tristate "Silicon Image SII8620 HDMI/MHL bridge"
depends on OF
select DRM_KMS_HELPER
-   imply EXTCON
+   select EXTCON
depends on RC_CORE || !RC_CORE
help
  Silicon Image SII8620 HDMI/MHL bridge chip driver.
-- 
2.31.0.30.g398dba342d.dirty

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v1 PATCH 1/3] drivers: soc: add support for soc_device_match returning -EPROBE_DEFER

[Geert Uytterhoeven]

Hi Alice,

CC Arnd (soc_device_match() author)

On Mon, Apr 19, 2021 at 6:28 AM Alice Guo (OSS)  wrote:
> From: Alice Guo 
>
> In i.MX8M boards, the registration of SoC device is later than caam
> driver which needs it. Caam driver needs soc_device_match to provide
> -EPROBE_DEFER when no SoC device is registered and no
> early_soc_dev_attr.

I'm wondering if this is really a good idea: soc_device_match() is a
last-resort low-level check, and IMHO should be made available early on,
so there is no need for -EPROBE_DEFER.

>
> Signed-off-by: Alice Guo 

Thanks for your patch!

> --- a/drivers/base/soc.c
> +++ b/drivers/base/soc.c
> @@ -110,6 +110,7 @@ static void soc_release(struct device *dev)
>  }
>
>  static struct soc_device_attribute *early_soc_dev_attr;
> +static bool soc_dev_attr_init_done = false;

Do you need this variable?

>
>  struct soc_device *soc_device_register(struct soc_device_attribute 
> *soc_dev_attr)
>  {
> @@ -157,6 +158,7 @@ struct soc_device *soc_device_register(struct 
> soc_device_attribute *soc_dev_attr
> return ERR_PTR(ret);
> }
>
> +   soc_dev_attr_init_done = true;
> return soc_dev;
>
>  out3:
> @@ -246,6 +248,9 @@ const struct soc_device_attribute *soc_device_match(
> if (!matches)
> return NULL;
>
> +   if (!soc_dev_attr_init_done && !early_soc_dev_attr)

if (!soc_bus_type.p && !early_soc_dev_attr)

> +   return ERR_PTR(-EPROBE_DEFER);
> +
> while (!ret) {
> if (!(matches->machine || matches->family ||
>   matches->revision || matches->soc_id))

Gr{oetje,eeting}s,

Geert

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

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/gma500: remove trailing whitespaces

[Krzysztof Kozlowski]

Remove trailing whitespaces.  No functional change.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/gpu/drm/gma500/backlight.c|  4 +--
 drivers/gpu/drm/gma500/cdv_intel_dp.c | 50 +--
 2 files changed, 26 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/gma500/backlight.c 
b/drivers/gpu/drm/gma500/backlight.c
index 35600d070cb5..9e90258541a4 100644
--- a/drivers/gpu/drm/gma500/backlight.c
+++ b/drivers/gpu/drm/gma500/backlight.c
@@ -42,7 +42,7 @@ void gma_backlight_disable(struct drm_device *dev)
dev_priv->backlight_device->props.brightness = 0;
do_gma_backlight_set(dev);
}
-#endif 
+#endif
 }
 
 void gma_backlight_set(struct drm_device *dev, int v)
@@ -54,7 +54,7 @@ void gma_backlight_set(struct drm_device *dev, int v)
dev_priv->backlight_device->props.brightness = v;
do_gma_backlight_set(dev);
}
-#endif 
+#endif
 }
 
 int gma_backlight_init(struct drm_device *dev)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_dp.c 
b/drivers/gpu/drm/gma500/cdv_intel_dp.c
index 6d3ada39ff86..595b765ecc71 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_dp.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_dp.c
@@ -245,7 +245,7 @@ i2c_dp_aux_add_bus(struct i2c_adapter *adapter)
 if (W && !in_dbg_master()) msleep(W);   \
 }   \
 ret__;  \
-})  
+})
 
 #define wait_for(COND, MS) _wait_for(COND, MS, 1)
 
@@ -386,7 +386,7 @@ static void cdv_intel_edp_panel_vdd_on(struct gma_encoder 
*intel_encoder)
if (intel_dp->panel_on) {
DRM_DEBUG_KMS("Skip VDD on because of panel on\n");
return;
-   }   
+   }
DRM_DEBUG_KMS("\n");
 
pp = REG_READ(PP_CONTROL);
@@ -433,7 +433,7 @@ static bool cdv_intel_edp_panel_on(struct gma_encoder 
*intel_encoder)
DRM_DEBUG_KMS("Error in Powering up eDP panel, status %x\n", 
REG_READ(PP_STATUS));
intel_dp->panel_on = false;
} else
-   intel_dp->panel_on = true;  
+   intel_dp->panel_on = true;
msleep(intel_dp->panel_power_up_delay);
 
return false;
@@ -449,7 +449,7 @@ static void cdv_intel_edp_panel_off (struct gma_encoder 
*intel_encoder)
 
pp = REG_READ(PP_CONTROL);
 
-   if ((pp & POWER_TARGET_ON) == 0) 
+   if ((pp & POWER_TARGET_ON) == 0)
return;
 
intel_dp->panel_on = false;
@@ -464,7 +464,7 @@ static void cdv_intel_edp_panel_off (struct gma_encoder 
*intel_encoder)
DRM_DEBUG_KMS("PP_STATUS %x\n", REG_READ(PP_STATUS));
 
if (wait_for((REG_READ(PP_STATUS) & idle_off_mask) == 0, 1000)) {
-   DRM_DEBUG_KMS("Error in turning off Panel\n");  
+   DRM_DEBUG_KMS("Error in turning off Panel\n");
}
 
msleep(intel_dp->panel_power_cycle_delay);
@@ -535,7 +535,7 @@ cdv_intel_dp_mode_valid(struct drm_connector *connector,
if (cdv_intel_dp_link_required(mode->clock, 24)
> cdv_intel_dp_max_data_rate(max_link_clock, max_lanes))
return MODE_CLOCK_HIGH;
-   
+
}
if (mode->clock < 1)
return MODE_CLOCK_LOW;
@@ -606,7 +606,7 @@ cdv_intel_dp_aux_ch(struct gma_encoder *encoder,
for (i = 0; i < send_bytes; i += 4)
REG_WRITE(ch_data + i,
   pack_aux(send + i, send_bytes - i));
-   
+
/* Send the command and wait for it to complete */
REG_WRITE(ch_ctl,
   DP_AUX_CH_CTL_SEND_BUSY |
@@ -623,7 +623,7 @@ cdv_intel_dp_aux_ch(struct gma_encoder *encoder,
break;
udelay(100);
}
-   
+
/* Clear done status and any errors */
REG_WRITE(ch_ctl,
   status |
@@ -659,7 +659,7 @@ cdv_intel_dp_aux_ch(struct gma_encoder *encoder,
  DP_AUX_CH_CTL_MESSAGE_SIZE_SHIFT);
if (recv_bytes > recv_size)
recv_bytes = recv_size;
-   
+
for (i = 0; i < recv_bytes; i += 4)
unpack_aux(REG_READ(ch_data + i),
   recv + i, recv_bytes - i);
@@ -870,7 +870,7 @@ cdv_intel_dp_i2c_init(struct gma_connector *connector,
ret = i2c_dp_aux_add_bus(_dp->adapter);
if (is_edp(encoder))
cdv_intel_edp_panel_vdd_off(encoder);
-   
+
return ret;
 }
 
@@ -1291,13 +1291,13 @@ cdv_intel_get_adjust_train(struct gma_encoder *encoder)
if (this_p > p)
p = this_p;
}
-   
+
if (v >= CDV_DP_VOLTAGE_MAX)
v = CDV_DP_VOLTAGE_MAX | DP_TRAIN_MAX_SWING_REACHED;
 
if (p == DP_TRAIN_PRE_EMPHASIS_MASK)
  

[PATCH 1/2] drm/gma500: correct kerneldoc

[Krzysztof Kozlowski]

Correct kerneldoc (remove wrong /** marker and adjust function name) to
fix W=1 warnings:

  drivers/gpu/drm/gma500/cdv_intel_lvds.c:27: warning:
expecting prototype for LVDS I2C backlight control macros(). Prototype was 
for BRIGHTNESS_MAX_LEVEL() instead

  drivers/gpu/drm/gma500/intel_gmbus.c:386: warning:
expecting prototype for intel_gmbus_setup(). Prototype was for 
gma_intel_setup_gmbus() instead

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/gpu/drm/gma500/cdv_intel_lvds.c | 2 +-
 drivers/gpu/drm/gma500/intel_gmbus.c| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c 
b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
index 5bff7d9e3aa6..8a2219fcf9b4 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -21,7 +21,7 @@
 #include "psb_intel_drv.h"
 #include "psb_intel_reg.h"
 
-/**
+/*
  * LVDS I2C backlight control macros
  */
 #define BRIGHTNESS_MAX_LEVEL 100
diff --git a/drivers/gpu/drm/gma500/intel_gmbus.c 
b/drivers/gpu/drm/gma500/intel_gmbus.c
index eb0924473a21..c17cbafa468a 100644
--- a/drivers/gpu/drm/gma500/intel_gmbus.c
+++ b/drivers/gpu/drm/gma500/intel_gmbus.c
@@ -379,7 +379,7 @@ static const struct i2c_algorithm gmbus_algorithm = {
 };
 
 /**
- * intel_gmbus_setup - instantiate all Intel i2c GMBuses
+ * gma_intel_setup_gmbus() - instantiate all Intel i2c GMBuses
  * @dev: DRM device
  */
 int gma_intel_setup_gmbus(struct drm_device *dev)
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 0/9] drm: Support simple-framebuffer devices and firmware fbs

[Geert Uytterhoeven]

Hi Thomas,

On Fri, Apr 16, 2021 at 11:00 AM Thomas Zimmermann  wrote:
> This patchset adds support for simple-framebuffer platform devices and
> a handover mechanism for native drivers to take-over control of the
> hardware.
>
> The new driver, called simpledrm, binds to a simple-frambuffer platform
> device. The kernel's boot code creates such devices for firmware-provided
> framebuffers, such as EFI-GOP or VESA. Typically the BIOS, UEFI or boot
> loader sets up the framebuffers. Description via device tree is also an
> option.

I guess this can be used as a replacement for offb, too...

> Patches 4 to 8 add the simpledrm driver. It's build on simple DRM helpers
> and SHMEM. It supports 16-bit, 24-bit and 32-bit RGB framebuffers. During

 if support for 8-bit frame buffers would be added?

Gr{oetje,eeting}s,

Geert

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

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 5/5] gpu/drm: mediatek: hdmi: add MT8167 configuration

[Neil Armstrong]

The MT8167 SoC have a hard limit on the maximal supported HDMI TMDS clock,
and is not validated and supported for HDMI modes out of HDMI CEA modes,
so add a configuration entry linked to the MT8167 compatible.

Signed-off-by: Fabien Parent 
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index bc50d97f2553..c1651a83700d 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1787,10 +1787,18 @@ static const struct mtk_hdmi_conf mtk_hdmi_conf_mt2701 
= {
.tz_disabled = true,
 };
 
+static const struct mtk_hdmi_conf mtk_hdmi_conf_mt8167 = {
+   .max_mode_clock = 148500,
+   .cea_modes_only = true,
+};
+
 static const struct of_device_id mtk_drm_hdmi_of_ids[] = {
{ .compatible = "mediatek,mt2701-hdmi",
  .data = _hdmi_conf_mt2701,
},
+   { .compatible = "mediatek,mt8167-hdmi",
+ .data = _hdmi_conf_mt8167,
+   },
{ .compatible = "mediatek,mt8173-hdmi",
},
{}
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 4/5] gpu/drm: mediatek: hdmi: add optional limit on maximal HDMI mode clock

[Neil Armstrong]

Some SoCs like the MT8167 have a hard limit on the maximal supported HDMI TMDS
clock, so add a configuration value to filter out those modes.

Signed-off-by: Fabien Parent 
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 0539262e69d3..bc50d97f2553 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -149,6 +149,7 @@ struct hdmi_audio_param {
 struct mtk_hdmi_conf {
bool tz_disabled;
bool cea_modes_only;
+   unsigned long max_mode_clock;
 };
 
 struct mtk_hdmi {
@@ -1226,6 +1227,10 @@ static int mtk_hdmi_bridge_mode_valid(struct drm_bridge 
*bridge,
if (hdmi->conf->cea_modes_only && !drm_match_cea_mode(mode))
return MODE_BAD;
 
+   if (hdmi->conf->max_mode_clock &&
+   mode->clock > hdmi->conf->max_mode_clock)
+   return MODE_CLOCK_HIGH;
+
if (mode->clock < 27000)
return MODE_CLOCK_LOW;
if (mode->clock > 297000)
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 3/5] gpu/drm: mediatek: hdmi: add check for CEA modes only

[Neil Armstrong]

Some SoCs like the MT8167 are not validated and supported for HDMI modes
out of HDMI CEA modes, so add a configuration boolean to filter out
non-CEA modes.

Signed-off-by: Fabien Parent 
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index dea46d66e712..0539262e69d3 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -148,6 +148,7 @@ struct hdmi_audio_param {
 
 struct mtk_hdmi_conf {
bool tz_disabled;
+   bool cea_modes_only;
 };
 
 struct mtk_hdmi {
@@ -1222,6 +1223,9 @@ static int mtk_hdmi_bridge_mode_valid(struct drm_bridge 
*bridge,
return MODE_BAD;
}
 
+   if (hdmi->conf->cea_modes_only && !drm_match_cea_mode(mode))
+   return MODE_BAD;
+
if (mode->clock < 27000)
return MODE_CLOCK_LOW;
if (mode->clock > 297000)
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel